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

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...
Post a Comment
Read more

10,000 foot level view in technology

10,000 foot level view in technology: How useful is it? What can be done at this level? If the 30,000 foot level is the CTO level, then consider the 10,000 foot level as the level that software engineering managers and directors operate at. To achieve the success at 10,000 foot level, you as a software engineering manager need to dive deep into technical details, help the team lay the foundation from BOTH organizational and technical side. It is the little moves that get the team to this level. Once the team’s applications and results at that level, then you as a manager have ability to perform the high level analysis and troubleshooting without necessarily being in code on daily or weekly basis. Therefore, your ability to troubleshoot technical issues at the 10,000 foot level is a testament to the great work of your team. Go TEAM !! Almir Mustafic
Post a Comment
Read more

Programming languages to teach students in high-school and university

Python-like or C-like as the language to introduce programming to students in high school and university? The question is: Do you introduce programming concepts to high-school/university students using languages that handle memory and other things for you or do you start introducing all of these concepts in languages like C that require you to understand all aspects. I will tell you what worked for me. I was introduced to programming in grade 10 using Basic programming language. There was a version called Better Basic and also Quick Basic. Then in grade 11 we learned procedural programming in a programming language called Turing (not Turing machine but a Pascal-like language developed by University of Toronto for teaching purposes). Then a year later, I started getting interested in C and C++. As you can see, I eased into the languages that introduced me to NULL exceptions and memory leaks :) With this approach I was not overwhelmed and this set up the foundation for a fun journey ...
Post a Comment
Read more