Paul Graham, whom I agree with about 70% of the time and think he’s got things completely backwards the other 30%, presents us with Holding a program in one’s head - which I think is mostly on the agreement side of the fence.
I’ve read articles like this before - the whole you can get more done when you aren’t distracted thing isn’t exactly news. But I thought it would be interesting to re-think each of his points about how programmers spend their time within the context of how I now spend my time. My experience at railsconf this year and my subsequent attempt to hire and partner with other people doing things similar to thoughtbot has confirmed my suspicion that a decent chunk of the ruby and rails consulting ecosystem is made up of 1-10 person shops (I suspect it’s weighted towards 2-3 people)—which means that a big chunk of the participants in our still-young-and-still-niche market are wearing a lot of hats while they attempt to judo chop all the low hanging fruit in front of them.
Clearly, with so many programmers, designers and web engineers changing the focus of what they do from cog in a big corporate machine to agile programming consultancy owner, the challenges of that transition must be partially shared. Here’s my take on it.
Avoid distractions
The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.
I find this problem to be less severe in non-programming mode than it is in programming mode. If I’m finding new business, sending invoices, checking email, scanning rss feeds, calling clients and so on - I can really change tasks pretty fluidly. Each task is small and discrete and does not require a large amount of context to be held at one time. When programming though, he’s right. The smallest change in the atmosphere around you, or an email about something unrelated to the at hand can be fatal, and send your mind wandering.
Work in long stretches
I’ve heard of people hacking for 36 hours straight, but the most I’ve ever been able to manage is about 18, and I work best in chunks of no more than 12.
I’ve found that the fresh angle that you get from leaving a problem and returning to it later is more valuable in non-programming work. The details of contract proposal or a product strategy plan start to take shape for me when I work on them briefly, step away, and return to work on them briefly again. With programming, I’d never get anything done that way.
Use succinct languages
More powerful programming languages make programs shorter. And programmers seem to think of programs at least partially in the language they’re using to write them.
Ruby has been great for me, productivity-wise. The convention of Rails in particular allows you step away from something and immediately know where it is when you return. No more trying to remember which particular arrangement you used on this particular PHP app.
The business analogy, I think, is to literally use succinct language. Don’t write a 5 paragraph email reply when two sentences would have done. Don’t try to prove the merit of your creative writing background in every project spec you write. I haven’t jumped on this crazy train yet, but it doesn’t sound too absurd.
Keep rewriting your program
Rewriting a program often yields a cleaner design.
Indeed. But don’t rewrite your business communications just to understand them more. Reread whatever you’re responding to, and then eliminate what you don’t need from your response.
One spot this kills me again and again in the non-code world is meeting summaries and project summaries. For many of our projects and clients, I’m often the first contact for a new project or for the new details of an existing project. When you write code that makes sense right now but won’t make sense to you (or anyone else, for that matter) in an hour’s time - you know it’s time to refactor.
Same things with a meeting or a phone call. When you get off a call or done with a meeting, it’s important to immediately look at your notes and decide if they actually make sense. If not, don’t try to save time by promising to clean it up later. Once later arrives, you’ll forget what half of it means, and leave yourself (or, even worse, another member of your team!) lost in the wild the next time the project needs work.
Work in small groups
When you manipulate a program in your head, your vision tends to stop at the edge of the code you own. Other parts you don’t understand as well, and more importantly, can’t take liberties with.
Big groups and big meetings are just as lethal in the business world as big teams are in a programmers world. In fact, I’m pretty sure big meetings are just designed to achieve a false sense of consensus and make sure no one is responsible for producing any results. Sometimes I try to tell our clients this and they just kinda pretend that they’re not allowed to not have pointless meetings. This is really fun for me, for some reason.
Don’t have multiple people editing the same piece of code
You never understand other people’s code as well as your own. No matter how thoroughly you’ve read it, you’ve only read it, not written it.
I would agree with this from a don’t coauthor documents perspective—but in the same way that you might want another developer to bless your code or your data migrations before they go to production, you probably want one of your partners (or your lawyer) to bless your proposals and offers and other communications where the precision and intent of the language really matters.
Start small
If you start with too big a problem, you may never quite be able to encompass it. So if you need to write a big, complex program, the best way to begin may not be to write a spec for it, but to write a prototype that solves a subset of the problem.
I think this makes sense in the way he means it, but not as an overall rule. Sometimes you’re thinking about the overall architecture of your problem—and when you’re thinking about a web service solution vs. a remote database read solution, you probably shouldn’t also be thinking about the small decision of variable naming conventions or something.
Likewise - if you’re thinking about your financial projections and modeling your business over the next 24 months, don’t spend too much time thinking about how much you can save by getting rid of the red staplers and standardizing on black ones.
Still with me
Paul’s conclusion is more or less…
Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong. In fact, if you look at the way software gets written in most organizations, it’s almost as if they were deliberately trying to do things wrong. In a sense, they are. One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars.
I think this makes sense, and I’m sure it doesn’t apply only to programmers. Any task which involves a considerable amount of mental attention, context-holding and strategy forming probably plays by these rules - and the organization surrounding the people doing those tasks could probably stand to benefit from this thinking.
But then he jumps into the economic sphere a bit…
Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. Arguably a market is such a form of organization, though it may be more accurate to describe a market as a degenerate case—as what you get by default when organization isn’t possible.
…and I don’t understand what this remark has to do with the rest of his essay.
The market is what allows us to even use the plural and compare organizations rather than looking at our one hulking organization and trying to see what’s wrong with it without any basis for comparison. In the same way that inter-organization competition can play out between companies by awarding (in theory) those who are most efficient (and, in the programming world, much of Paul’s article is certainly in play in that regard)—there also exist intra-organization markets - where the courage to go over your head and introduce these ideas and (gasp!) even follow them - can bring a reward in the form of a promotion, a raise, or a happier more productive existence as a developer.
