The longer we work with a given library, framework, set of APIs, or whatever, the more comfortable we get with solving problems using them.

It’s a natural by product of experience, isn’t it?

But that doesn’t mean we’re solving the same problems over and over again. Sometimes, sure, we might be solving a problem like we’ve done previously. And really, in those instances, we should have libraries ready to plug into our work, but that’s content for another post.

Other times though, we may be working with the same foundation to solve new problems.

And that’s where it gets to be a little more touchy:

Because of our familiarity with the tools with which we’re working, we think we’re ready to jump in and solve the problem.

That’s not really the case though, is it? I mean, we might be working with the usual toolset, but we’re still solving a unique problem.

And in that case, shouldn’t we be taking a few steps prior before jumping into our IDE?

Pseudocode Before Code

I’m a big believer in writing up pseudocode before actually writing code to solve a specific problem.


My handwriting is terrible. This isn’t even good pseudocode.

Of course, pseudocode can come in a variety of ways:

  • It might be written on a whiteboard
  • It might be written in code comments in an IDE
  • It might be written in another language catering more to rapid-application development
  • It might be written in a notebook
  • …who knows?

Whatever the case, I’ve generally found taking at least a little bit of time to think through the solution I’m trying to implement prior to jumping directly into my IDE to write the code yields are more productivity than the alternative.

That is, if I sit down and immediately begin writing code, I can usually get something working, but simply having something working for someone – unless it’s just a demo – is rarely enough, right?

I mean, once the project is done, then we’ve got to maintain it for months or years. In order to ease maintenance, we need to make sure we have modules and components as organized as possible given the information we have right now.

In my experience – and I know that may not be saying much for some of you :) – I’ve found when I sit down to immediately begin coding, I almost always end up going back and refactoring code over and over and over a few times before finally getting it to a point where it’s production ready.

But, on the other hand, if I take some time to plan out the architecture, flow of control, and different aspects of what I’m working on, then I have a far easier time getting things done when I decide to jump into my IDE.


Join the conversation! 2 Comments

  1. Big fan of pseudo-code, how you call it.

    When I need to solve complex problems which seems to complex, the best approach is always to break it in smaller problems,

    and I use to write down a list of the mini-functions that I need…

    Cool that I’m not the only one :)

    • When I need to solve complex problems which seems to complex, the best approach is always to break it in smaller problems,

      Divide and conquer. It’s one of the foundations of algorithms in computer science :).

Leave a Reply