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

Driving Manual-transmission cars and C/C++ Programmers — What do they have in common?

You may ask what the drivers of traditional manual-transmission cars and C/C++ programmers have anything to do with each other. Well, I am a software engineer and I am also a car enthusiast (aka a petrolhead in UK). I am noticing certain trends in both the car industry and the software engineering community/industry; therefore, I wanted to share my opinions. I started programming in Basic before I even owned my own computer. I remember when I first learned a for-loop in Basic, I walked over to my friend’s house and typed it up on his Commodore 64. When I was in high-school, I did more Basic (Better Basic and QuickBASIC) and also some Turing (not Turing Machine….I am talking about a language invented by University of Toronto to teach programming and it was Pascal-like). Then I switched to C/C++ and learned all about proper handling of memory and what we call “unmanaged” code these days. C/C++ were the choice if you wanted to do some low-level programming or also if you wanted to
Post a Comment
Read more

SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS

SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS are some of many important things to achieve the enterprise-level microservice architecture and microservices. Names mean things. So you first need to properly name your services and that’s the names that you would use when talking to your teammates and clients of your services/APIs. I have a separate article on how you go about defining what a microservice is. That's titled "Micro in Microservices" on my site almirsCorner .com. Essentially, you need define the purpose and boundaries of your service. Then you get into API routes and properly defining them for each service. The goal is to keep the routes RESTful and if you run into the situation when they are not, then it should trigger you to revisit the purpose and boundaries of that given microservice. Maybe that service needs to be split into smaller services. Thank you for reading this. Almir Mustafic
Post a Comment
Read more