I have been quieter than usual over the past few months.
Although I enjoy building in public, some work is better done behind the scenes until it reaches a point where there is something worth talking about.
For the past few months, I have been working as the Chief Technology Officer at a small startup in the United Kingdom. We are building an educational technology software as a service product for researchers around the world.
During that time, I came across a mistake that changed the way I approach software development.
Understanding the problem is only half the work
When people talk about building products, one piece of advice comes up repeatedly.
Understand the problem.
I agree with it.
The mistake is assuming that understanding the problem automatically means you understand the right solution.
Those two points carry more weight than they are often given. It is easy to understand the problem and assume you already know the right solution.
I found that out during one of our product demos.
The demo that sent us back to the drawing board
We had spent months building the product.
Features were coming together. The application worked. From a technical point of view, everything seemed to be moving in the right direction.
Then we presented the product.
The feedback exposed something I had missed.
I understood the users’ problem, but the solution I built did not solve that problem in the best way.
The difference sounds small.
It is not.
A product can be technically well built and still fail because the solution is based on the wrong assumptions.
That was our situation.
We made the decision to throw away months of work and start again.
Throwing away code is not always failure
Developers often become attached to the code they write.
I understand why. Building software takes time. It is difficult to accept that weeks or months of work may never reach production.
But keeping the wrong solution because you have already invested time in it is usually a more expensive mistake.
Starting over was frustrating.
It was also the right decision.
The code was not the problem.
Our approach was.
What changed for me
I still enjoy writing code.
I still enjoy building quickly.
What changed is the amount of time I spend before writing the first line.
Now I ask more questions.
Is this the actual problem?
Is this the simplest way to solve it?
What assumptions am I making that have not been tested?
Those conversations are much cheaper than rebuilding a product several months later.
Writing software is not only about producing code.
It is also about choosing the right direction before you begin building.
Have you ever thrown away an entire codebase and started from scratch?
If you have, I would like to know what led to that decision.
Connect with me on:
I share short, practical dev lessons regularly.
Follow me for more short, beginner-friendly JavaScript lessons every week.
Reach out to me for your web development gigs:
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)
Enter fullscreen mode Exit fullscreen mode
Email: [email protected]
See you next week! 🚀
Till then, write clean code and stay curious. 🦋
답글 남기기