Tag Archives: productivity

The Focus Course

Today, Shawn Blanc launched The Focus Course. Originally conceived as a book on productivity, it expanded during his research and writing to include 18 videos, PDF workbooks, and a discussion forum, wrapped together with 75,000 words in a 40-day course package:

“The Focus Course is for anyone who wants to increase productivity, personal integrity, morale, and overall quality of life. What sets the course apart is that it guides you in the implementation of these principles so that these topics go beyond mere head knowledge and into experiential knowledge.”

I love the scope of this. It sounds like he put everything into it.

We need more bad ideas

Shawn Blanc has been publishing a series of essays leading up to his new book and online course, The Focus Course. In a recent post, he writes about how we all need to get through more bad ideas. It’s easy to assume that because your friends’ lives appear perfect on Facebook, that you should reserve only your brilliant ideas for posting:

“One of the things that comes with having the internet in our pocket is that we can share moments and slices of our life with the world. But most of us are sharing the highlights. We share the best photos of the grandest places. Which is fine. But it also can cause a slight sense of disillusionment.”

The essay reminds me of something that always stuck with me reading about legendary Warner Bros. animation director Chuck Jones years ago. He said that when he was young, his father would give him and his siblings essentially unlimited paper to draw on, unused supplies from his business. We all have 100,000 bad drawings in us. The sooner we get through all the bad drawings — in Shawn’s essay, the bad ideas — the sooner we can start producing our best work.

Fancy-pants productivity

There are a few things in this post by “Ryan Norbauer”:http://notrocketsurgery.com/articles/2008/02/26/mention-in-wired-piece-on-37signals (via 37signals) that bother me. One is this idea that “code is meant to be read by humans first and computers only secondarily”. I understand what he is getting at, but even though I respect new advances in productivity, we have to be very careful to keep our core priorities. There’s a word for when the balance shifts away from the user and more to us as programmers: selfishness.

Imagine two programs: one is ugly and hard to read, but it compiles and is bug-free; the other is beautiful and readable, and it also compiles and is bug-free. To the user they are identical. They both succeed.

Now take those two and give them both identical beauty and readability, but accidentally break one so that it either does not compile or runs so horribly buggy and slow that it is useless to everyone. Writing code for other programmers to read isn’t enough. You have to start with code that works before you get all fancy-pants.

This growing trend to raise beautiful code and programmer productivity above the performance or functionality of the final product is dangerous. The final product is what counts. Not how you build it, but what you’ve built: how it scales, how it performs, how it solves a particular problem.

And sure, there are many times when I write slow, lazy code that doesn’t work well. But that’s a compromise you make when you have to meet a deadline, or because you aren’t sure how to optimize yet, not because you start out by deprecating user experience. If you believe Ryan, it sounds like there is a whole “movement” of programmers who toss any potential performance achievements out the window before they even get started.

You can say that great products are complex, and so you need to focus attention on how the software is built and maintained. That is true. When I ported a large application from Carbon to Cocoa a few years ago I made the decision to do so because of future productivity.

You can say that happy programmers create high-quality products. That is also true. When I am feeling most productive I am usually enjoying myself because the work environment I’m in is encouraging.

But don’t put the practice of software development above the actual result, because to do so means you care more about writing code than solving problems.