By Deane Barker | May 14, 2006 | 27 Comments
Here’s something I’ve learned: when faced with a programming project, the worst thing you can do is start coding right away.
Programming is not like building a house. When you build a house, a wall goes together a standard way. Match up Tab A with Slot B and you’re good to go. (A gross over-simplification — please don’t flame me over this…)
But programming an app — there’s a million different ways you can do it. And it keeps changing. The way you programmed an app a year ago is probably not the way you’d do it now. There are new languages, new frameworks, new methods, new capabilities, new interface expectations, etc.
I have a problem with procrastination. But I’ve learned that sometimes, I’m not procrastinating as much as I’m really thinking. Sometimes, the worst thing you can do is start programming right away. Sometimes the best thing you can do is think about the problem — either actively, or just by letting it simmer on the back burner of your mind for a while. The way you’d start coding the thing two days from now, very well may be 100x different.
This weekend, I needed to program a simple job application. I’ve done this before (in the end, it’s just a form submission, really), but I still didn’t think I should jump into it right away. I started thinking about it while I went about my average Saturday, and didn’t start coding it until five or six hours later. Sure enough, during that period, I came up with some really good ideas on how to do a couple of things which resulted in a much better app overall.
It’s almost like every app has a gestation period. I know from having three kids that my wife got pretty sick of the whole pregnancy thing about four months into each of them. But, obviously, that baby needs to stay in there until it’s done. Likewise, even if you’re flat sure you know how to program that app, maybe sleep on it. Let it gestate a little more before throwing down any code.
When I was in the Navy, I was a medic supporting a platoon of Marines. I remember clearly sitting on a ridge overlooking the urban combat training facility in Camp Pendleton. In the “city” were hundreds of bad guys. On the ridge were hundreds of Marines.
Everyone had a plan, and they all involved doing something right now. But the sergeant that everyone really respected and listened to said something I’ll never forget. He said, “There are a thousand different ways to do this. Problem is, 999 of them are wrong.”
The same can be said of programming.
What Links Here
Agreed. That’s a philosophy that I’ve long subscribed to. Maybe it is partially a justification for putting things off, but there definitely is merit in letting an idea simmer for a while.
A year ago I was involved in a project to program the logic for an autonomous vehicle. We had to take input from a digital camera, GPS, proximity sensors, and various vehicle feedback sensors, and then send appropriate commands to the drive motor and steering. Being extremely psyched about the project, we started coding immediately, and what resulted was a disaster of spaghetti code and terribly inefficient architecture. It became so difficult to revise and debug it that we scrapped the entire program, took a week off to collect our thoughts, and then sat down and wrote a much more elegant and modular system.
I was working on the project with my roommate at the time, and the funny part is that most of the collective brainstorming happened after we both quit for the night. Half an hour after trying to sleep he’d yell over from his room, “hey, I’ve got an idea for the navigation algorithm” and we’d stay up til all hours working the idea out on paper.
Sometimes it just takes that little bit of mental downtime to allow those back-burner ideas to bubble up to the surface.
I actually refer to that process of thinking or procrastinating as background processing. It is actually a term that is used fairly often around our house now that I got my wife clued into what it is. Nowadays, when she has something for me to do, she’ll give me a couple days notice and tell me to background process how I want to coordinate or act on the given task.
I do the same at work. When people come over to me with an issue and if I am right in the middle of something, I’ll let them outline the problem then but tell them that I’ll get back to them after I background process it for a little bit. Gives me time to finish the task at hand and think about how to solve their issue.
I consider it a low level process thread running in the background of my mind that I can just drop things onto and during brain lulls, they get picked up and tossed around a little to see what shakes out.
This is me to a tee — always has been. I can’t count the number of times I went to bed on a problem in University, only to wake the next morning up with a workable soution.
It seems, however, that some problems require those failed first attempts in order to frame what the real shape of the problem is. Walk a mile in the problem’s shoes, kick them off and design some new ones.
But the problem with me is that, if I don’t code it today, I will never code it. Lazy Bug will bite me and I will keep procrastinating it.
Why not start coding now, and when you think of those great ideas 5-6 hours later, change your code to adjust them? Worst case, you just have to throw out everything you’ve done so far, which leaves you no worse off than if you’d done nothing.
Like everyone else, I’ve experienced those “A-ha!” moments when you shelve a project for a few hours and come back later. But I’ve found I experience them more often while I’m actually coding. The process of actually wrestling with the problem seems to generate more creative ideas than just turning it over in my head.
It’s not like code is hard to change. If you think of something better, rewrite it.
Interesting post. What you’re talking about has as much to do with writing anything as it does with coding.
One other thought: You mention that it’s not like building a house. But then, maybe that’s the problem with the way houses are built these days. Christopher Alexander (architect, and inspiration for so many coders becauese of his “A Pattern Language”) says that the way we build houses (and other structures) is broken. It shouldn’t be “slot A meet tab B”, but something akin to what you’re talking about here.
That doesn’t work for me. By the time I actually sit down to write code, the project is essentially done. I’m very structurally-oriented, and to me the most important thing is the architecture of a program. If I start coding before thinking the whole project through and deciding on an approach, chances are I’ll get hung up with a crappy design and the code will end up being sloppy and inefficient.
I think this probably comes from my formal training, which is engineering. The design is key and there’s no ‘rewrites’ when it comes to mechanical projects, because this is prohibitively expensive most of the time and also unsafe if not caught soon enough. Revisions of subroutines or modules are understandable, but I think that if you find yourself having to significantly rewrite or reorganize the code, then you’ve started prematurely.
I think the key to being able to do the ‘back burner’ thing successfully is to be honest with yourself – are you ‘really’ working on it, or are you just kidding yourself and putting it off? It works for me because I find myself blessed/cursed with an overly-active technocentric mind and I typically can’t stop thinking about pending projects even if I wanted to.
My previous post is in reference to Jonathan’s response, not Paul’s. :-)
This is very true and it really points out the design aspect of our science. The more time invested up front to this kind of explorative thinking, the better my final results tend to be. It’s the same thing as they say “you don’t know what you don’t know until you know it”. When I”m facing a new problem I have all the ideas for what source files I will create and perhaps some of the division of labor between kinds of structures that will be needed and all kinds of implementation details that we use daily as practical tools. So – it is tempting – and I think 99% of my colleagues fall victim to this bad behavior – to just jump into the structures and details and start “making progress” with the new problem they are solving. But really you should pause and just think and doodle and make notes and read literature for a day or two (or a couple hours, depending on the scale). The design aspect of computer science really requires at not just a procedural level to work prototypes and to iterate on the “design”, but to also iterate on just the preconceptions of the “implementation”. And iterating on the implementation doesn’t mean writing 4 versions of a solution. I think you need that incubation period of one person just sitting there with a blank slate and sketching and “procrastinating” for a while. It’s invaluable.
Plus – you’re more likely to find that 30th version of a solution that is wacky and no one thought of, but is better than anything previously considered. That is the real payoff to this kind of gentle approach. Furthermore, I work within a field where there has been years and years of poor development and it is extremely difficult to introduce innovative ways to approach a problem (isn’t all software poorly developed?). So, I have as my task to not only to come up with the best solution, but to work within a faulty paradigm and make the solution within the same “tradition” as what has been laid before me. Taking the time to question my surroundings like this on a daily basis perhaps is a bit obsessive, yes, it can appear to be procrastination, but actually it is time well spent to achieve something that works for all parties and uses (which can be very difficult and usually is never accomplished in most real world engineering projects). There is always an elusive goal we’d like to reach where everything is perfect and it’s our duty to always work towards that, even if it means “doing nothing” and just “thinking”. And those folks that are always “so busy”, I am suspicious of them and I wonder what is making them so busy and if they are really working towards the future or are just keeping up appearances to avoid actually effecting any real solutions. (ok end of rant before I go to far here ;)
Yep, sounds familiar. Just today I had an enlightening spot of test-first, document-first. Maybe this is another approach. It certainly forces you to really think about what you are going to do. After all, when documenting, you are explaining it to someone. Coupled with tests helps to really nail things down, at least at the API or user-experience level. This coupling I have elaborated on in an article of my own:
good article but i think im just lazy ;p
I’d dive into how the cause could be A.D.D. related as well but I’d lose my train of oh look a new link on reddit!
I find that the best compromise is to find the nearest bit of scrap paper, or napkin and start sketching the idea.
This seems to speed up the “Gestation period” and re-assures me that I’m not just procrastinating.
This would be true for Software design, House Design, or Economics drafts… the same principle applies
I often find that taking a walk is more productive than diving in and coding right away. Walks are also great for when I run into a programming impasse – something where I’ve got several options which all seem pretty good. Too bad that walking around is frowned upon by management in many places…
Oh, for software development I’d change that quote from: “There are a thousand different ways to do this. Problem is, 999 of them are wrong.?
To: “There are a thousand different ways to do this and about 500 of them are going to be suboptimal.’
This post totally validates what I’ve been doing lately.
I’ve been tasked to write an internal web app for time tracking and I’m honestly trying to clear my head on how to write it best.
I’ve produced zero code so far, but I’ve been actively thinking about it non-stop. I’m coming to a point where i might actually produce sometimes soon.
Here’s to hopin’.
Great post. I’m inspried. Tomorrow I’ll stop procrastinating….
Until then I’ll think about stopping. :-)
Remember my favorite saying:
procrastination is the key to flexibility…
I like your baby analogy a lot: it’s one I’ve used myself on occasion. As in, “Give birth even a few months too early and what do you end up with?” That usually evokes enough imagination so I don’t need to go into the gory details.
To people like me who has been brainwashed to work hard, it takes a conscious effort to ‘procrastinate’ and mull. This is the sure sign of workaholism and it applies across every other field.
It obvious in software business because it’s tempting to dive into coding for instant gratification. Not producing tangibles just feel wrong.
When I brainstorm and not make a move, logically I know I’m right and it’s necessary. Emotionally it’s downright threatening to self-esteem. This is most painful when the task gives no instant gratification, like marketing.
So I guess the workaholics truly need some magic phrase to be internalized to convince ourselves to not move and feel secure about it.
See its posts like these that tell me I’m not the only one on this train of thought, before I would assume the boss/project-leader was right that I was just lagging but NO! I’m thinking (as I actually was/am) but definitely not about the project. If anything I was trying to remember what the project was or what was talked about for 3 hours at that mini-meeting that was supposedly just a 10 minute meeting.
I found it so refreshing to read your post.
I’m a writer but I also train groups inn creative thinking techniques. I’ve been banging on for ages now about the value of thinking time.
Admittedly this doesn’t work for everyone but I really find that, allowed time to think about a piece, it forms itself in my head and, close to deadline can be transferred to paper as a pretty good draft.
In training, I’ve noticed that those people who start on a project instantly will end up rejecting 90% of their thinking by the time they get to the finished project.
On balance, I think the early starters are probably going through the same processes but need the discipline of putting it on paper to ‘remind’ themselves that their minds are working. I find that the more confident people become in their creativity, the more happy they are that the process going on in their head will deliver the right result on time.
Slightly OT, but I’m also a great fan of using ‘liminal thinking time’. I often set my alarm an hour early in the morning so I can lie around half asleep to really give my brain the chance to mull things over.
OTOH, I might be just idle :)
mmmm… sadly…. on Web environmets there is not too much room for innovation…
Web server/Web Service/ Database….
Throw in past componments, extend/refine existing to adapt them to the new environment and there we go. At the end of the day, is mostly on database design were I am going to spend more “pencil & paper” time.
The rest? After a few years coding in web anybody should have a base line of code to throw in at the beginning of new projects. Only when backoffice processes are required is when the project gets interesting.
From Tim Hayward’s post:
“Slightly OT, but I?m also a great fan of using ?liminal thinking time?. I often set my alarm an hour early in the morning so I can lie around half asleep to really give my brain the chance to mull things over.”
This is definitely an interesting thing to do. Typically I don’t do this in the morning, but rather over the second half of my lunch break. I’ll set the alarm on my cell phone, recline the seat back, close my eyes and begin with a concept or problem in mind. Where it goes from there is anyone’s guess, but I find it fascinating to see how ideas form when you leave them unconstrained like that.
Granted, a lot of times the results from this are not very practical or useable, but it’s an interesting exercise all the same.
like the sergeant and the soldiars, i think experience shows you how to do it right when you need it more likely then for the unexperienced. so with code, how many webapps do you need to write to be free from mulling the next one over for a day? what has changed from the umpteen million before till now. like sudar said, jump in. because then you know you are grappling with whats at stake. if your walking, jogging, whatever and simmering, while those are good, you aren’t as embroiled as you are when you are walking around befor the project. later, when you are in the trenches, you can go for a walk because your brain is filled to capacity and you’ll find that clearthought helpful because you have the relavent issues at hand. and, as anyone that reads their scientific american a la about a year ago knows, that subconscious thought is far superior to finding patterns then the conscious mind. the conscious mind is better at analysis and dissection. so, again citing sudar, dive in and get your brain filled up, THEN go on that walk beacuse then you know for sure every major detail you need to work with and you aren’t just hymin and haw’n about what all the potentials are. why consider or even deal with them? if this is your first app, then ya, you need to look at all of them because you won’t know what lies beyind them, but any of us that are really out there writing software have been doing it for awile and should be well enough in tune with the Force to just dive in. i see newer programmers struggling like this on apps and being limited to what they can see. but once you’ve done it enough, you don’t even look at it anymore, its all just patterns and you change the names to fit appropriately.
In some ways perhaps it is like building a house. The builder doesn’t just show up on site and start hammering pieces of wood together, or start by mixing mortar up. Even if the design is already done, there needs to be a period of familiarisation, examination, contemplation and planning of the how, not just the what.
When I am starting a coding project I like to “solve” the tricky parts in my head, or sometimes in actual code, before I start on the acual “work”.
I’m pretty sure I’m actually just procrastinating.
The problem I had with this plan is that back in the 80′s, when I worked at Hughes Aircraft, they always wanted you to be sitting at your desk working, and it looks really bad if you’re there and staring into space…. It’s worse if they find you walking around thinking about a problem, simply because you’re you guessed it, not at your desk….
Survived that hegemony 3 years, actually….