The older we get or the more experienced we get in the field in which we work, the more knowledge and wisdom we [hopefully] accumulate. During any given work day, one of the things that I occasionally find myself thinking about is:

If I could go back and tell myself [about a certain aspect of programming] years ago, then it would go something like [this].

For example:

If I could go back and tell myself about programming when I first started, I’d tell myself so slow down.

But what does that even mean?

It’s not hard to find a lot of material on the web or in books or magazines about how the act of programming is also about thinking through problems while you’re out on a walk, or designing an algorithm on paper.

That is, there’s more to it than typing characters into an IDE.

But when I was interning and/or first out of school and was working as a programmer for these companies, I often found myself trying to get things done quickly. It came out in my quarterly reviews, too – I’d be told that I should slow down a bit and take my time.

The interesting thing is that I wasn’t severely breaking anything (at least not often – we all have our days, though :), and I was still trying to get better at what I was doing through reading books, articles, blogs, and other material, but I felt this constant pressure to get things done quickly.

So, you know, I went through all of the usual steps of trying to determine where that pressure was coming from. I’ve been fortunate enough to have great managers and bosses prior to self-employment (now my boss is a big jerk) and they always gave ample time for planning a project’s features, time for implementation and testing, and ways that we could easily turn new features on or off quickly once they were deployed.

Clearly, it wasn’t them that was the source of the pressure. So who did that leave?

Yeah. Me. Self-imposed pressure to do something that I had ample time to do.

Self-Imposed Programming Pressure

Why is this worth writing about? For me, it comes down to two points:

  1. Self-imposed pressure takes the fun out of programming
  2. Self-imposed pressure results in lower quality work

The Fun

First, when you feel as if you’re always shaking hands with the clock to get something shipped out the door, you miss the satisfaction that comes with actually solving a problem.

Sure, programming is challenging. In fact, I think most fields are challenging (though many of us like to play the elitist and say we have it harder than other people, but I digress) and satisfaction comes from doing good work in overcoming those challenges.

Additionally, you miss opportunities to actually spend time planning out your solution. Since you don’t take time away from your desk to ponder a the solution, work through potential ways to solve the problem, or anything like that, you end up missing out on opportunities to be creative – that is, you miss out on coming up with creative ways of solving problems.

The Quality

Secondly, when you force this pressure upon yourself to get something done, you likely aren’t doing your best work.

Granted, there are going to be times where things have to get done quickly and those times will often call for just getting something working – if only for the time being – so that you can proceed with moving on to the next critical task. But that’s not how most projects are managed.

Instead, the quality of work can be drastically improved when you’ve had time to explore the entire space of the problem, evaluate potential solutions, and come up with one that not only fits best with the program at hand, but that’s also architected in such a way that it plays nicely with the rest of the system that’s in place.

In some cases, you may end up with a library that you can even reuse for future projects or that you can share with others.

Give It Up?

I wouldn’t say that I no longer apply pressure to myself when working on projects for myself or others, but I will say that I’ve learned to pace myself to make sure that I’m solving problems the best way that I can given my ability and the constraints put on the project.

I also try to spend more time thinking through how to actually solve a given problem before jumping into writing code – that’s one of the most important lessons I think any young programmer should learn – the next being not to rush to a solution.

At least for me, it resulted in a less than stellar experience.

Category:
Articles

Join the conversation! 8 Comments

  1. I often put pressure on myself to get my work done and often compete against myself as well which can be bad. That creates a struggle which ends up in constant frustration because I am often working in time constraints and never seem to get the work completed when I’m in that state. Or at the very least, I end up with things that I’ve missed, or I’ve done something the wrong way.

    Then there’s the other side of the coin where I get excited and want to see the project completed, only to find things I’ve missed or again, done improperly because I’ve pushed completion too quickly without taking the time to do it right. I end up having to go back and redo it (correctly).

    I can also find that if things are taking too long, I put the pressure on myself to finish it, only to later start to dislike the project, hence “taking the fun out of programming”.

    • I think this is something that’s somewhat pervasive among a lot of programmers – at least based on what you’ve said and some of the tweets I’ve seen, though I’m not sure why that is.

      I think there’s this constant pressure to want to prove to ourselves we can actually do it and sometimes just getting it working feels like enough when, ironically, we know it’s not.

      Time, to me, is the one thing that has made me more patient, careful, and focused on what I’m doing. I’m still not great at it – far, far from it. But I’m better at it. And I want keep that trend going.

      Thanks for the comment – it’s nice to hear from other people who have experienced the same.

  2. I actually don’t have this specific problem. I tend to over think, over plan and over analyze when approaching a problem. Which ultimately leads to not enough action.

    I do have the issue with growing and learning though. I’m constantly pressuring myself to learn and improve, so much so that I completely remove the fun from it. This is something I’ve had to work really hard on the last few years.

    I’m glad you shared your thoughts, I love your honesty with your work. Makes me feel good to know I’m not alone.

    • I think what you’ve mentioned about “not enough action” is very similar, but on the opposite end of the spectrum. 

      It can be hard to get started with your analyzing every little thing (which is good and has its own place), but at some point you do have to ship and you do have to get started with what you’ve got even if it isn’t as pristine as you’d like.

      I know that feeling.

      • It’s so hard to just get it done though because like you said, sometimes you have to ship it when it’s not as pristine as you would like. Even just thinking about it makes me slightly twitch inside. However, I do have to get over it because it is something that has held me up for far too long.

        • I think this is something that’s natural to a lot of developers.

          We want to create the best designed, functional systems possible. The challenge is that we know least about a project at the beginning than we do at the end so we can really only do so much at the start.

          There’s a balance to be struck. Pragmatism is where it counts.

          • This is why I love reading your blog and hearing your input. I can’t even express how much it means to me to know that someone I look up to feels the same way and experiences some of the exact same things I do. It gives me hope for the future of my own development :)

  3. I’ve been coding for 35 years, started with assembler on the 8080,8085,Z80, 6502 CPU’s. Alot has changed… LOL.

    Under-thinkers and over thinkers get Smart Draw or Mindmap, any of these tools that allow for mapping thoughts to a design. I used to use UML alot an at times still do especially on C# / .Net work.

    For those who under-think a task these tools allow you to visually see a task and break it down farther. For Over-thinkers these tools allow you to STAY ON COURSE without getting sidetracked. As new ideas about your work gel around in your head you can map them as stubs and come back to them later or even include knowing when/where to stub code to implement something (or not) a a later date.

    Once you get used to using them they are near as fast as pencil and paper. The added benefit of course being you can conceptually alter at any time, with pencil and paper thats messy.

    Once I have a good map in place depending on the complexity of the code tasks at hand I may make other maps. If its not all too complex I may use MS Word’s outliner to help break down tasks to a lowest or near lowest denominator.

    Easier stuff… right to code.

    This format allows tremendous flexibility. If for example your just sorta stuck on some part of code you can readily go, “well need think this out further, mental prototype it more” and because you HAVE a plan, sorta like an architect you can work on other areas of the codebase.

    In as far as time goes… well… Pressure is working in the commercial video games industry. Its been many years since I have and it was BRUTAL back then.

    If your in overload writing code, the code with most folks will just suck. You’ll look at it in the future and go, “ummm… need do this over”. Yet some produce best results that way.

    Learn to multitask. Every top notch coder I think I have ever met can at least to some extent multitask. Not what we THINK of in that term. Most folks if watching TV cannot be writing a book at the sametime. Most folks writing code cant be thinking of perhaps images or layouts at the sametime.

    The brain however is capable of real multitasking. Many have lost this natural capability. Your brain is always multitasking both conscience and sub-conscience.

    When your driving your car or riding your bike LOTS of multitasking going on. Theres a red light, another car, this/that. Repetition of the task has trained your most local noodle to task. Yet, if you ONLY were to focus on YOUR driving what happens? Bingo.

    You can train your brain to open up this same capability in focused thought.

    When your writing code typing perhaps just happens. Again, trained. You can train the brain to task thought.

    Warning however… In doing so BALANCE becomes important. That is to say, knowing your spiritual self in balance. It is a facet that modern living has stripped from most humanity, or shall I say, made dormant.

    Flipping it back on and training it means ALOT more about thinking, direction, life, purpose also comes to bare and thus balance becomes more important as lie today is more complex in many ways than it was 800 years ago lets say.

    Its not “new”. In fact, its been used for centuries making us more intelligent is some respects and stupid as door nails in others. The average westernized individual for example believes they are well informed by 60 minutes of news on whatever news topic, say Hurricanes. In reality, it’d take months and months and months to actually understand SOME of hurricanes. Same with just about anything. But we have been trained “down” in really using mental acuity. But its still there waiting to be used.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.