Code Simplicity

The Secret of Fast Programming: Stop Thinking

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.

-Max

14 Responses to The Secret of Fast Programming: Stop Thinking

  1. Ankur says:

    That’s some really nice ideas and thoughts. Although coding fast may not be that easy as stated here but I like the overall presentation of this article.

    My quality team may not agree to it. :-)

    • Max Kanat-Alexander says:

      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! :-)

      -Max

  2. Marc says:

    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.

  3. xrosolar says:

    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.

  4. 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.

    I’m not being very specific on purpose :)

    thanks

    • Max Kanat-Alexander says:

      Hey Diogo! So glad that you liked the post and the blog in general! :-)

      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.

      -Max

  5. Great post.

    All of the distractions you spoke of are real problems, not just for programmers, but for all knowledge workers.

  6. Dalmas says:

    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.

    • Max Kanat-Alexander says:

      Yes! Very much so. There are no “magic” people, except perhaps magic in their ability to realize what they _don’t_ know so that they can go out and learn it.

  7. Víctor Jesús Arroyo Reyes says:

    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.

    Reading your article I’m learning more about how to stop thinking.

    Thank you and greetings!

  8. Dan Luevano says:

    Greate book, felicidades!

  9. “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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>