Think, think, think… before you code!

I have a weird habit — I am rarely at my work desk when I have a programming task at hand. When I’m not at my desk, I’m mostly walking around or looking at a whiteboard in the most secluded focus room available. The reason being — It helps me focus; it helps me understand the bigger picture; it helps me design the solution in a much better way. And after all these years, I’ve realized, planning your code is even more important than actually coding.

Most of the time, we as programmers, out of passion and excitement, rush to solve programming problems. As soon as the requirement document is available, as soon as the acceptance criteria is added to the user story, as soon as the meeting is over, we just fire up the IDE and start coding, don’t we? I have been like this before, during the first couple of years of my career. Then I realized that this habit is actually slowing me down instead of making me faster at solving problems. Here’s how.

Let’s take an example — let’s say we have a simple problem — to read data from a database, filter/transform/model it and show it back to the user in a web page. To make this happen, what I would’ve done a few years ago is — 1. Create data model classes, 2. Create a database service/wrapper class, 3. Get data from database in the service class using data models and then pass it to the web page using the view-model object. And voila, work is done and I can go home and play with my dog. :)

Now, let’s see what could have been better in the above solution and what I missed — I didn’t try to find if there is already a service/wrapper class available in the solution which can be reused, I didn’t check if the models can be reused or derived from any existing classes, I didn’t think about extensibility, scalability and performance of the app, I didn’t think about using the right data structures, design patterns and code structuring. Well, it seems I missed a lot of things just because I was too excited to solve the problem.

If I would’ve thought of all these things, the overall application would have been much more organized, stable and performant, to say the least. Most of the time, when we rush to code, without thinking and proper planning, we miss all these things and when the time comes to release the bits in production, we are hit with all the bugs related to performance and regression. This ultimately makes us slow and delays the deliverable.

Now, after realizing this, I tried to change my approach towards solving programming problems. What I do now is I take time before starting to code. First of all, I try to find if there is an existing solution to the problem I am trying to solve. Sometimes there is a solution in the same code base and we just have to look for it, otherwise internet/google/stack overflow are always there to help. Then, if there are multiple solutions available then I try to find out which one best fits the existing code base and timelines.

And then starts the fun part — I generally write the problem statement and then draw possible solutions on a white board and then look at them to get the bigger picture. Once I have that big picture in my head then I take a walk and think about the pros and cons of these solution options. By the time I reach my desk, I generally have a decision and a final solution to code. This approach has helped me solve some of the most challenging problems with the most satisfying solutions. At the end of the day, I guess, we all are looking for satisfaction from our work, aren’t we?