Skip to main content

Programming / Software Engineering  — Think Paper, Paper, then Code

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


Labels:

Comments

Post a Comment

Popular posts from this blog

Teaching kids the importance of information security — A simple fun example with encoding/decoding

Teaching kids about information security is very important today because the social network websites and applications are blurring the line between what should be shared securely and what not. Everybody is busy over-sharing the good, bad and ugly over the internet and in the process of doing that forgetting the basics of information security or never taking the time to learn it. Or is it that nobody is introducing these concepts in school? It is something that needs to be introduced in our education systems from early days. Do you remember the days when we used to send those short messages on a piece of paper in our classrooms? Some encoded those messages because you did not want another person in the middle to open it and understand what it says. How were those messages encoded? The simplest example is: You create a simple mapping for each letter and number in the alphabet. Then you encode your message and write it on a piece of paper. Then the person on the other end decodes...
Post a Comment
Read more

Daylight saving time and A Software Engineering state of mind ?

You may be wondering what the Daylight saving time has to do with a software engineering state of mind. When thinking about writing this article, at first I thought to start with the following joke and I am: “ Did you know that the Daylight saving time was started because a software developer coded a function that does smart timezone and configurable calculations and then this developer created a problem to solve to use the algorithm; hence, the Daylight saving time was born. ” This is a joke, but  on a more serious note , this brings me to a state of mind in software engineering that make this joke a reality to some degree. How many times did we find ourselves in situations where we learned something new in programming and we looked for ways to apply it at any cost? How many times did we see a cool new feature from a creator of a framework and we decided to use it even though that was not the right solution for the problem or maybe there was no problem to solve in the ...
Post a Comment
Read more

Language of Software Engineers and scrum-master skills (quick thoughts)

Language of software engineers and skills of scrum-masters? All software developers speak the same language and that is pseudo-code :) However, there are still communication issues among software engineers specifically with other teams. That's where the role of great scrum-masters fits in. That great scrum-master does not necessarily need to be technical but he/she needs to have the skills of hearing roadblocks that engineers communicate in their technical language. I said "hearing" and hearing is not the same as listening. Listening is just a pre-requisite for hearing. Once you hear it, now you need to know how to action it and mobilize the right people. Coaching comes along with all of this, but that is a separate topic because it is also a responsibility of the tech manager. These skills separate great scrum-masters from others. Almir Mustafic P.S. Disclaimer: On any given day, I wear a hat of a solutions architect, engineer, scrum-master and tech manager.
Post a Comment
Read more