Background
TL, DR.
First and foremost, I honestly don't consider myself a software engineer yet a person who learned how to write computer programs while in high school.
About 3 years ago I got my first job as a software engineer in a small start-up company in South Africa, and in that same year, people started calling me either Software [engineer, developer, etc…] you name it.
As a consequence of working in a start-up that developed a solution for outside customers, I was always expected to get things done. Moving jobs and the story remains the same, in the end, I realized that my job was to get things done and most of the time get them done quickly.
One day, last year November to be precise I read an interesting article titled "The Product-Minded Software Engineer" by Gergely Orosz, and it drastically changed my way of viewing my job as a "Software Engineer", in this blog post the author stated a lot of very interesting points that I wish everyone that builds software should think through.
The checkboxes
But why the title you may ask?
The answer is that what we all do ends up becoming at some point a part of our careers. We end up becoming people that checkboxes and mark them as done to secure our monthly income. - This may apply to other jobs as well.
Most of the time, as an engineer you'd get called by your managers or team leaders where they will assign you a task, explain to you their expectations (which most of them come from clients), and give you a time to complete it. Then you will simply say yes without asking the intent of the job. You will go and perform the task and wait for the next one, and the cycle repeats itself.
And you are there having that fake sense of growth because you completed 10x more tasks this week than the previous week and you got 100+ commits in a month, and you are done with your checklist. Not realizing that you trapped yourself in an addictive cycle of ticking off boxes.
The problems
After being there I realized that checking the boxes alone was feeding my impostor syndrome more and more, as I was constantly on the mindset of it is working don't touch it, move to the next one. It was fun and exciting to always get kudos due to the number of tasks I was checking on my "to-do list". Yet I've found some problems with this:
Doing things because they have to be done without understanding the reason for their existence:
I believe all software engineers can relate. Many times, we are asked to change or add functionality to a system and we just go and build, being unable to differentiate why is it needed vs why am I building it. You might be building an unnecessary feature because the client or project owner said so and in the end, you will be asked to remove it because it was not needed.
Being a false solution provider:
Do software engineers know what is it that their job means? - let's forget about the job description. Thus, when you constantly tick off boxes you will get things twisted to think that you are providing solutions yet you are simply pleasing the asker.
Build things that you don't understand:
This one complements my first point. The overall beauty of any job is being able to provide solutions to a specific group of people and it is sad sometimes to see that the solution providers don't take some time to understand what we are trying to solve, thinking that if it is done it is done. The small boxes we tick off every day add up to a bigger one which is our contribution to the outside world and not knowing what are you solving for can add up to future failure.
Poor solution
Yes, you are ticking off things but is the overall picture important? - Many of us get called to meetings and are given the project scope and then we get the feature list and start implementing. As the other points above state, small tasks add up to a bigger one, the feature list you get will add up to an entire software system, web app, you name it. Yet you can deliver it on time and within scope, and everyone is clapping, etc… forgetting that you don't know who you will build it for and if it is needed to use x approach instead of y approach. So you built what I call a poor solution that you would also not prefer to use.
Conclusion
In conclusion, I believe that all software engineers should know a bit of product mindset as everything has a lifecycle and needs to tell a story for those who will use your solutions. Ticking boxes alone may prevent you to understand what is it that you are doing. When we are assigned tasks or requests we need to always be able to analyze and understand who are we solving for, why is the solution needed and what is it that we are creating? - if ever we aren't sure and unable to answer these questions we are just ticking off boxes.
Software engineering is more than simply writing a nice feature, it is about user experience and constant solution creation. I strongly believe that everyone should do things only when they understand the intent of the request.
I constantly say that building software is an art and good artists know what story they are trying to tell.
Happy hacking!
Top comments (0)