Most of the software engineering problems are solved in what I call the high-level brainstorming sessions. We basically walk into a meeting room and white-board our thoughts and come up with solutions. When things start falling apart, you better believe this happens in the last stretch of projects and it does work. Now the issue is that we as programmers do NOT do the similar type of exercise before a line of code is written?
I typically see developers get requirements in the form of a document or a user story or in the form of walk-by requirements. The next thing I see on developers’ screens is code editors or IDEs. Is that the right thing to do? You may say that you are advanced enough and that you like to dive into coding right away, but this happens even to the best of us. We fall into this trap and rarely step back and review our habits.
We have to go back to fundamentals. What did we do in school? Professors taught us to write down our thoughts and to show what we plan to eventually express in code. A piece of paper and a pen can do amazing things early in the game before a line of code is written. Even if it is a napkin, please use it and write down what you plan to do. It does NOT have to be pseudo-code; it could be just a bullet point list in English (or your choice of language) and a bunch of boxes/diagrams describing what you are planning to do when you put your hands on that keyboard in front of your choice of code editor or IDE.
This approach prevents potential confusions down the line and it can actually prevent show-stoppers in the 11th hour of your project. Whatever you write down on this piece of paper can also be used as a verification for your code because when you get into coding, you dive down too deep and forget the big picture; this piece of paper is there for you to keep you in check. When a tech lead ask developers how they implemented a specific requirement/user story, developers need to be able to articulate the implementation without showing any line of code. What’s the best way to show a solution and have discussions than a piece of paper with your approach. Then these discussions could lead to what I call “drive-by” mini demos and code reviews which are another great benefit, and that deserves its own blog post.
A developer may use the following argument against what I wrote here: “This is slowing me down. Why do I need to waste my time putting my thoughts on paper if I can just sit in front of my computer and start coding it?”
My response to the above argument would be: That’s fine; I am talking about guidelines here. These are not rules. It is up to you to choose when you want to use paper first and as your experience grows, you become better and better in making these decisions. There is no right or wrong; I am just providing some approaches/tools that help with the whole process. In many cases, this takes a bit of your time at the beginning and saves you a lot of headaches later in the project. At the end of the day, if a tech lead asks you to explain how you implemented something, you need to be able to articulate without showing code :)
What’s the conclusion? Think paper, paper, then code.
Thank you for reading this article.
Almir Mustafic
Comments
Post a Comment