The older we get or the more experienced we get in the field in which we work, the more knowledge and wisdom we 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 years ago, then it would go something like .

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.