When I talk to developers about code complexity, they often say that they want to write simple code, but deadline pressure or underlying issues mean that they just don’t have the time or knowledge necessary to both complete the task and refine it to simplicity.

Well, it’s certainly true that putting time pressure on developers tends to lead to them writing complex code. However, deadlines don’t have to lead to complexity. Instead of saying “This deadline prevents me from writing simple code,” one could equally say, “I am not a fast-enough programmer to make this simple.” That is, the faster you are as a programmer, the less your code quality has to be affected by deadlines.

Now, that’s nice to say, but how does one actually become faster? Is it a magic skill that people are born with? Do you become fast by being somehow “smarter” than other people?

No, it’s not magic or in-born at all. In fact, there is just one simple rule that, if followed, will eventually solve the problem entirely:

Any time you find yourself stopping to think, something is wrong.

Perhaps that sounds incredible, but it works remarkably well. Think about it—when you’re sitting in front of your editor but not coding very quickly, is it because you’re a slow typer? I doubt it—“having to type too much” is rarely a developer’s productivity problem. Instead, the pauses where you’re not typing are what make it slow. And what are developers usually doing during those pauses? Stopping to think—perhaps about the problem, perhaps about the tools, perhaps about email, whatever. But any time this happens, it indicates a problem.

The thinking is not the problem itself—it is a sign of some other problem. It could be one of many different issues:

Understanding

The most common reason developers stop to think is that they did not fully understand some word or symbol.

This happened to me just the other day. It was taking me hours to write what should have been a really simple service. I kept stopping to think about it, trying to work out how it should behave. Finally, I realized that I didn’t understand one of the input variables to the primary function. I knew the name of its type, but I had never gone and read the definition of the type—I didn’t really understand what that variable (a word or symbol) meant. As soon as I looked up the type’s code and docs, everything became clear and I wrote that service like a demon (pun partially intended).

This can happen in almost infinite ways. Many people dive into a programming language without learning what (, ), [, ], {, }, +, *, and % really mean in that language. Some developers don’t understand how the computer really works. Remember when I wrote The Singular Secret of the Rockstar Programmer? This is why! Because when you truly understand, you don’t have to stop to think. It’s also a major motivation behind my book—understanding that there are unshakable laws to software design can eliminate a lot of the “stopping to think” moments.

So if you find that you are stopping to think, don’t try to solve the problem in your mind—search outside of yourself for what you didn’t understand. Then go look at something that will help you understand it. This even applies to questions like “Will a user ever read this text?” You might not have a User Experience Research Department to really answer that question, but you can at least make a drawing, show it to somebody, and ask their opinion. Don’t just sit there and think—do something. Only action leads to understanding.

Drawing

Sometimes developers stop to think because they can’t hold enough concepts in their mind at once—lots of things are relating to each other in a complex way and they have to think through it. In this case, it’s almost always more efficient to write or draw something than it is to think about it. What you want is something you can look at, or somehow perceive outside of yourself. This is a form of understanding, but it’s special enough that I wanted to call it out on its own.

Starting

Sometimes the problem is “I have no idea what code to start writing.” The simplest solution here is to just start writing whatever code you know that you can write right now. Pick the part of the problem that you understand completely, and write the solution for that—even if it’s just one function, or an unimportant class.

Often, the simplest piece of code to start with is the “core” of the application. For example, if I was going to write a YouTube app, I would start with the video player. Think of it as an exercise in continuous delivery—write the code that would actually make a product first, no matter how silly or small that product is. A video player without any other UI is a product that does something useful (play video), even if it’s not a complete product yet.

If you’re not sure how to write even that core code yet, then just start with the code you are sure about. Generally I find that once a piece of the problem becomes solved, it’s much easier to solve the rest of it. Sometimes the problem unfolds in steps—you solve one part, which makes the solution of the next part obvious, and so forth. Whichever part doesn’t require much thinking to create, write that part now.

Skipping a Step

Another specialized understanding problem is when you’ve skipped some step in the proper sequence of development. For example, let’s say our Bike object depends on the Wheels, Pedals, and Frame objects. If you try to write the whole Bike object without writing the Wheels, Pedals, or Frame objects, you’re going to have to think a lot about those non-existent classes. On the other hand, if you write the Wheels class when there is no Bike class at all, you might have to think a lot about how the Wheels class is going to be used by the Bike class.

The right solution there would be to implement enough of the Bike class to get to the point where you need Wheels. Then write enough of the Wheels class to satisfy your immediate need in the Bike class. Then go back to the Bike class, and work on that until the next time you need one of the underlying pieces. Just like the “Starting” section, find the part of the problem that you can solve without thinking, and solve that immediately.

Don’t jump over steps in the development of your system and expect that you’ll be productive.

Physical Problems

If I haven’t eaten enough, I tend to get distracted and start to think because I’m hungry. It might not be thoughts about my stomach, but I wouldn’t be thinking if I were full—I’d be focused. This can also happen with sleep, illness, or any sort of body problem. It’s not as common as the “understanding” problem from above, so first always look for something you didn’t fully understand. If you’re really sure you understood everything, then physical problems could be a candidate.

Distractions

When a developer becomes distracted by something external, such as noise, it can take some thinking to remember where they were in their solution. The answer here is relatively simple—before you start to develop, make sure that you are in an environment that will not distract you, or make it impossible for distractions to interrupt you. Some people close the door to their office, some people put on headphones, some people put up a “do not disturb” sign—whatever it takes. You might have to work together with your manager or co-workers to create a truly distraction-free environment for development.

Self-doubt

Sometimes a developer sits and thinks because they feel unsure about themselves or their decisions. The solution to this is similar to the solution in the “Understanding” section—whatever you are uncertain about, learn more about it until you become certain enough to write code. If you just feel generally uncertain as a programmer, it might be that there are many things to learn more about, such as the fundamentals listed in Why Programmers Suck. Go through each piece you need to learn until you really understand it, then move on to the next piece, and so on. There will always be learning involved in the process of programming, but as you know more and more about it, you will become faster and faster and have to think less and less.

False Ideas

Many people have been told that thinking is what smart people do, thus, they stop to think in order to make intelligent decisions. However, this is a false idea. If thinking alone made you a genius, then everybody would be Einstein. Truly smart people learn, observe, decide, and act. They gain knowledge and then use that knowledge to address the problems in front of them. If you really want to be smart, use your intelligence to cause action in the physical universe—don’t use it just to think great thoughts to yourself.

Caveat

All of the above is the secret to being a fast programmer when you are sitting and writing code. If you are caught up all day in reading email and going to meetings, then no programming happens whatsoever—that’s a different problem. Some aspects of it are similar (it’s a bit like the organization “stopping to think,”) but it’s not the same.

Still, there are some analogous solutions you could try. Perhaps the organization does not fully understand you or your role, which is why they’re sending you so much email and putting you in so many meetings. Perhaps there’s something about the organization that you don’t fully understand, such as how to go to fewer meetings and get less email. 🙂 Maybe even some organizational difficulties can be resolved by adapting the solutions in this post to groups of people instead of individuals.

Hey Ankur. I do think it’s easy, though it can take time at first to get into a state where you can code quickly. It can take some time to ramp up and make sure that you know everything you need to know so clearly that you don’t have to wonder about it. But once you reach that point, I really do think that this post pretty much covers what needs to be done to keep up your momentum and code quickly. 🙂

I certainly hope your quality team does agree–the power to write code quickly leads to the power to change things quickly, which leads to the power to fix bugs and improve features quickly! 🙂

Perhaps the title could be “Stop Stopping to Think” ? Or even, “The Secret of Fast Programming: Don’t Stop”

Totally agree with pretty much everything, except scanning for the word “test” came up empty. Whenever I am tempted to stop, I write corresponding tests. Or I try things and run the test. Or I take a first stab at something and run the test. On the average I would guess that I only write an average of 10 lines of code between test runs.

As a confirmed computer god, this is the first text I read on this specific subject that is close to the mark. Bravissimo! People don’t understand that first you learn the tools, and then you burn through the universe, of course you iterate back and learn things you need for the problem at hand, but then again, you light the fire and watch it all burn. Love the speed.

Really like this post (and your blog which I just found haha). Thanks!

I’m not sure if I fully understand 🙂
Do you consider thinking about a problem, or the main components of what you need to solve, as stopping?
In the bike example, before you decide to jump into coding something, you first have to know it needs wheels, etc.

What’s your take on quickly drawing a sketch of the high level solution and get a feel for what isn’t yet clear.

The primary thing I’m trying to steer people away from is pausing to have a long mental process go on that mostly involves sort of “talking to yourself” or something like that while you’re coding, and instead get out of your head and _look_ at something or _do_ something to solve the problem. Doing a diagram is something that happens outside of your mind, so it’s a good solution.

I do sometimes think about problems, but not usually while I’m writing them. In fact, I’m not even sure that I would categorize the most valuable mental processes as “thinking” at all, except in the loosest sense. For example, when I’m in the shower or taking a walk and I sort of have an epiphany about something that was bothering me for a long time, I often attribute that to having some distance from the problem (a sort of action that I took) rather than the power of chewing things around in my mind.

Very good post. I work on Android and often meet programmers who think they master the framework because they know many advanced features but then write poor code or get stuck on simple problems because they never took time to read the beginner’s guide properly, or to learn the language they work on (Java).

I realized that talented programmers don’t have some special skill that makes them think or write faster. They just instinctively know the facts listed in this post.

It’s my first time around here and I found this very real and interesting at that point that I made something similar similar to the bike example: create the classes or methods as if they were separate capsules, after that join them.

“I realized that talented programmers don’t have some special skill that makes them think or write faster. They just instinctively know the facts listed in this post”

That seems to be a contradiction. If you just instinctively know something that is a special skill, is it not?

I have an experience that few could relate to. I was a late blooming savant. I started programmer for real when I was in my 30s. With no formal education, I quickly caught up to and passed my peers. I could take on new projects with no familiarity of the language, complete it time, with code both lean and working. Early in my career, I figured out how the mechanics of programming worked to the point where I can automate as much as 90% of the code generation for a database driven application.

My point here being that some folks are born with special skills, or talents if you prefer. I don’t call it magic, just the amazing potential of our species. To this day, I still meet degreed programmer and managers who do not believe that folks like me exist or can work on their level. Odd, since I created the only commercially working UDDI Server. I did by myself and in the child-language of ColdFusion. Your professors will tell you that is not possible, UDDI was unworkable. I did it. I was also the first programmer to go to the NSA and demonstrate product integration with DoD PKI, something no major firm like Microsoft or Sun had achieved at the time. Some folks have special skills. And there is nothing magic about it.

No contradiction involved. If you believe there is a special innate, inborn quality that distinguishes talented programmers from those who are not, you consequently believe there is no way to achieve such talent if you weren’t born with it. “It’s all genetics” and other such notions which discourage taking action to achieve excellence.

If you realize that the qualities comprising a genius programmer are definable and can be learned and mastered, you DO believe you can take action to achieve them and thus it IS worth doing.

Some folks do indeed have special skills. And each one of them achieved those skills in ways that CAN be duplicated by others.

So it’s the difference between believing in “bad luck” and acquiring skills through knowledge, understanding and practice.

Meaning you do not understand the problem at hand (one you are trying to solve) or perhaps you don’t understand the tool that you are using quiet well. I think its more like the processes of software engineering where by the planning and the feasibility study will consume most of the programming time than actually doing the coding..

I have been writing too much code before testing. Today I implemented a new “step by step” approach, where I keep it really simple by programming one thing at a time. I felt an immediate difference, my mind was clear, brain fog gone!

I was researching about how to code faster or increasing productivity and I came across this blog post. At beginning I thought it was hitting right on the spot. Then I started to feel odd about it. Don’t get me wrong I think there are some valuable lessons here.

Facebook used to have the mantra of “don’t think, prototype”. While I don’t disagree with this I also believe it is important to stop and think. Specially at the beginning. You can assist your mind with draws and books and asking around but at the end is your mind that will produce the code, so I don’t see anything wrong about stop to think.

In fact, when you stop to think you let your head to have the opportunity to solve a problem and then express it through code. Once you have done this many time, with the same language, you can say you are productive or code faster. Really is not just that you are coding faster it is that your mind went through the same situation many times before and got better.

I think you have to stop and think first, then you can code. You do that many times and you will code faster.

Some of the points in this articles are obviously correct (the distract issue, etc) but generally, i tend to think the writer is missing a whole lot.

Also, programming faster is not a worthwhile goal: producing good results is a much worthwhile goal!

i think the main concern with developing software, as it is with all knowledge work if not absolutely everything whatsoever, is CLARITY.
Clarity is better nurtured and developed and practiced. Sometimes on have to simple stop and rest, or think, or draw or experiment or consult or explain to others in order to gain the clarity.
Also, one better sustain the clarity as he program.
That would bring to better code, shorter times, better fit between solution to problem and the precious peace of mind ….

Interesting article, but I think some of your points are only relevant to the development of new software.

I find that the majority of the time that I’m sat in front of the computer not coding is spent reading the code, not just sitting there thinking. For many developers like me, at the end of the day they may have only written 5 lines of code but it took all day to figure out what to write and where to write them. This is what happens when you join a team to work on a code base that has already been written.

If you randomly open a google code jam problem from previous years and start immediately coding after reading the problem, then I will be convinced. I stop for thinking whenever I try to solve a nontrivial problem. Of course that is not the case for donkey work tasks. Traversing a tree or refactoring an ugly legacy code makes me think.

I liked the whole post. But I like “Any time you find yourself stopping to think, something is wrong.” most. Yes, sometimes I stop to think about the problem. And this is only a cause of not understanding anything. I completely agree with you.

While it is true that if you find yourself stopping to think, something is wrong, it may sometimes be worse if you just decide to proceed without thinking. Oftentimes, as soon as I see a problem, I will think of a solution immediately. However, I have realized over time that most problems in non-trivial codebases have edge cases and can be solved by multiple solutions. Simply implementing the first solution that comes to my mind without thinking about potential edge cases and how the code will behave in the system as a whole leads to problems in the future. Ideally, the first solution that comes to my mind would be the right one but that doesn’t tend to happen often if I’m working on a large codebase with multiple contributors.

I do not completely agree with the post. Sometimes it is a better idea to stop and draw out a plan or a chart of what to code about instead of bumbling around and writing code mindlessly. Doing that would only create bad code which would eventually have to be refactored.

I think the key here is that when you have enough data, the correct solution will be obvious. If you don’t know what to write, you’re missing data. Bumbling around in your head thinking mindlessly is at least as bad as coding mindlessly—either one will not get you the data you need. 😉

Also, did you see the section headed “Drawing”? 🙂 Stopping and drawing out a plan is very different from struggling through ideas in your head, sort of chewing on them internally without putting anything there that you can _look_ at. Drawing a plan or chart as you suggest is absolutely a good idea and part of the design process.

This is a heuristic. If you are stopping to think, then you are not coding. The author is saying that thinking should be done before coding, not during coding. However it’s not always practical to know exactly what you’re going to write before it’s written. If that is to be the case, then the basic unit of coding in your framework, language or domain should be small. If the goal is to build an entire feature out that involves multiple user flows, classes, etc, which programmer do you know will have it all planned out and not have to stop to think? It’s a good ideal to strive toward though.

I am a junior developer so I run into these thinking traps often. I tried some of your suggestions today and already notice an improvement in my productivity. It was refreshing to spend so much more time typing than thinking. Thank you! 🙂

Very well presented article (y)
Fortunately, my approach to programming is similar to the ideas stated here, by default 😀
Like the “Starting” section, I can relate to it very closely.
So, that makes most other points you mentioned much acceptable for me.
Indeed, gem of an article this is. Loved it.

Well, don’t know what kind of programming you are doing, but for me without thinking there is no fast programming… By fast, it should be meant the time measured from the very start to the working code that is in production without bugs and that is ready for future improvements without excesivly changing the code that should be doing the same thing. If we are speaking about some larger component that needs to be done, if you just go with the first thing that pops up in your mind, then rearly would you avoid that the something needs to be refactored or that you will miss some points where later you need to use that code and you will have a problem, or even you might miss the whole use case that will make your initial solution close to useless.
“No thinking” is a zen principle that would need a some adjustments to be applied for coding.