Building software is something that is impacting every single field there is today. It is everywhere you look. From the education field teaching students, to the medical field saving lives, to the aviation industry keeping millions of airborne people safe, and even to the space rockets going to Mars. Software guides our lives.
And because it guides our lives, we have a big job to do. To build beautiful, robust, and solid software, every software engineer, developer, hobbyist, or even entrepreneur must ask the question: How do I do this right?
So whether you want to build a small program to help you organize your time better, or you want to build your next multi-million dollar idea, or you are making software for a client. The way you start is the same.
My name is Adam GOUJDAMI, and I will tell you my exact thought process before I build software and how I carry myself throughout all of it.
Think About the Problem
Before tackling anything whatsoever, one must sit with himself and just think.
This is the most important part. You cannot skip this. You have to think thoroughly about the problem you are facing, the problem you want to solve. You have to ask yourself: How can it be solved? What is a solution that is perfect enough to work?
Most people rush. They get an idea and they open the computer. They want to see the buttons and the colors immediately. But this is a trap. If you do not sit with yourself first, you are going to get lost. You are building a house without a blueprint.
Document Every Thought
Throughout that phase, you should sit and document every thought you had to not lose it later on. Brainstorm to the point you miss no idea.
Why do I say this? Because your brain will forget. You will have a great idea about how the login screen should work, and then two hours later, you will be thinking about the database, and that first idea is gone. Or maybe you wake up in the middle of the night with the perfect solution. If you don't write it down, it disappears by morning.
So, put it on paper. Or use a Notion document. It does not matter what tool you use, just get it out of your head. This document becomes your map.
Do not make the mistake of writing the code once and then remembering that you had wanted to do it another way. I see this happen all the time. You waste hours, if not days, coding something. Then you realize it is wrong. You have to delete it and replace it with something else. All due to not having planned things accordingly and good enough.
The Example of Thomas
A good approach to do the thinking phase is to map everything needed. Let’s use a real example to show you what I mean.
Say my neighbor, Thomas, approached me. He wants me to build him a Billing System for his new grocery store.
Thomas is a good guy, but he doesn't know about code. He just knows he needs a system to sell his goods. If I just say "Okay" and start coding immediately, I will fail him. I will build something he cannot use.
I should sit with myself and think. I need to become Thomas for a moment. I ask myself these questions:
-
Who is going to use that system? Is it just Thomas? Or does he have employees?
-
Is it one or two people? Maybe he has an accountant who needs to see the numbers from home.
-
Will the people see the same interface? Does the cashier need to see the profit margins? Probably not.
-
Should they have access to all the features or not? Can the cashier delete a sale history? That sounds dangerous. Maybe only Thomas should do that.
-
What does my neighbor’s grocery store need? Does he sell by weight? Does he use barcodes? Does he give receipts?
While I’m asking these questions, I am noting all sorts of answers on a paper, or in a Notion document. I am filling up pages with notes. I list everything that comes to mind.
What If You Don't Know the Answer?
Sometimes, if you are building for a client, you won't know all the answers. Maybe it is a business you are unfamiliar with. Maybe you don't know how a grocery store runs, or how a dentist office works.
If that happens, one should not hesitate to note down all the questions and book one or two meetings with the client.
Trust me, you don’t want to be the guy building an app for a scenario that doesn’t exist. Imagine you build a beautiful feature for scanning barcodes, and then you find out Thomas types everything in by hand because he sells loose vegetables. You just wasted your time, and you wasted Thomas's money.
Sit with them. Ask them. Listen to them. This is how you build trust, and this is how you build software that actually solves the problem.
Think About the Solution
Having thought about the problem and identified all the areas of it, now we’re going to tackle thinking about the solution.
We are not coding yet. We are beginning to imagine how our problem is going to be solved. We are building the house in our minds first.
Let’s take back the example of our neighbor’s grocery store.
We know from our notes that the billing app will have multiple users. In this case, our dear Thomas and his cashier employee. We know that they all won’t have the same features.
-
Thomas: He will be able to see an overview of the entire transactions in the store. He sees the revenue. He sees the profits. He is the boss.
-
The Cashier: They shouldn't see the profits. But both of them should be able to make transactions.
We begin to have a rough idea of the entire product we’re thinking of building. In this case, our billing app. We start to see the shape of it.
Walk Through Their Day
Do not be shy to pick up the pen again and start planning how the app will be. Plan it like you’re telling a story.
This is my favorite trick. I close my eyes and I imagine the user using the app. I walk through their day.
I imagine our dear neighbor Thomas. He boots up my beautiful billing app on his computer in the back office. He sees a login screen. He enters his credentials. The system knows it is him. It knows he is the boss. So, it shows him everything. No one else can see the features that he only has the privilege to. He sees a dashboard with the revenue of the store, the profits, the cost of goods, the inventory. He feels in control.
Then I imagine the cashier at the front of the store. They boot up the same app on a touch screen. They enter their credentials. The system sees it is an employee. It gives them a session where their dashboard looks a lot more simple. It allows them, depending on the privileges that Thomas gave them, to make a new sale. Maybe they can look up an order based on the ID in the receipt. But they cannot change the prices. They cannot see the costs.
When you tell this story, you find the holes in your plan. You realize things like, "Wait, what happens if the cashier forgets their password? How do they reset it?" And then you write that down too.
Building the First Piece (The Steel Thread)
Now that we have the story, you might think it is time to build the whole thing.
No. Not yet.
The biggest mistake developers make is trying to do everything at once. You try to build the login, and the database, and the design, and the settings page all at the same time. You end up with a mess. You end up with "spaghetti code."
I use a simple way to build. It's commonly called the Steel Thread.
Pick One Thing
For Thomas, what is the most important thing? What does his store actually do?
It sells things.
So, I pick that one feature. Just one. "Make a Sale."
I don't worry about the login screen yet. I don't worry about the pretty charts yet. I don't worry about printing the receipt yet. I just want to prove that I can make a sale happen in the code.
Build It Top to Bottom
I build the parts for only that one feature, following the user's action:
-
The Screen: I make a simple button that says "Sell."
-
The Code: I make the function that catches that click and processes the sale.
-
The Database: I make a place (a table) to save that sale forever.
I stop there. I test it. Does the button work? Does it save to the database? Yes? Good.
Now I know my software works. The core of it is solid. It is robust. I have a steel thread running through the app. I have proven that the idea works.
Now, and only now, do I add the next thing. Maybe now I add the login screen. Then I add the inventory list. Then I add the receipt printer.
This way, I never waste days coding something that doesn't work. I build it piece by piece, brick by brick.
Keep the Tools Simple
One last thing about my process.
When you are finally ready to build, do not try to be fancy.
You have a limited amount of energy. You want to use that energy to solve Thomas's problem. You do not want to use that energy fighting with a new computer language you don't know.
If you know how to use Python, use Python.
If you know how to use JavaScript, use JavaScript.
Don't try to learn a new hard language while you are trying to build your next multi-million dollar idea. You will get frustrated and you will quit. And Thomas will still not have his billing system.
Use a boring database. Use a boring server. The goal is to make the software work for the human using it. Thomas doesn't care if you used the newest, fanciest tech. He cares that the billing system works when he has a line of customers waiting.
In a Nutshell
Building software is beautiful. But it is only beautiful if it works.
To make it work, you have to slow down. You have to sit with yourself. You have to ask the questions. You have to document the answers. You have to care about the problem before you care about the code.
This is how I have shipped complex systems that run for years without crashing, and without me ever having to pull an all-nighter to fix a mistake I could have avoided by thinking first.
If you follow this thought process, if you think about the problem, think about the solution, and build it piece by piece, you will build software that is solid. You will build software that is robust. You will build software that impacts lives.
Thanks for reading. Share your thoughts.