The checkbox Software Engineer
Firstly, I want to clarify that I don't consider myself a sound software engineer, even though I learned how to write computer programs in high school. About three years ago, I landed my first job as a software engineer in a small start-up company in South Africa. That same year, people started calling me either software [engineer, developer, etc…] or whatever else.
As a result of working in a start-up that developed a solution for outside customers, I was expected to get things done. Although I moved jobs, the story remained the same. Eventually, I realized that my job was to get things done, and most of the time, I got them done quickly.
One day, in November of last year, I read an interesting article titled "The Product-Minded Software Engineer" by Gergely Orosz. It drastically changed my way of viewing my job as a Software Engineer. In this blog post, the author stated many interesting points that I wish everyone who builds software would think about.
The Checkboxes
But why the title, you may ask? The answer is that we all eventually become people who check boxes 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 will get called by your managers or team leaders, who will assign you a task, explain to you their expectations (most of which come from clients), and give you time to complete it. Then, you will 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.
You may feel like you are growing because you completed 10x more tasks this week than the previous week, you got 100+ commits in a month, and you are done with your checklist. But you may not realize 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 in 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 found some problems with this:
1. Doing things because they have to be done without understanding the reason for their existence
All software engineers can relate. Many times, we are asked to change or add functionality to a system and just go and build, being unable to differentiate why it is needed vs. why I am 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.
2. Being a false solution provider
Do software engineers know what their job means? Let's remember the job description. When you constantly tick off boxes, you will think that you are providing solutions, yet you are simply pleasing the asker.
3. Building 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 you are solving for can lead to future failure.
4. Poor solution
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 a poor solution that you would also not prefer to use.
In conclusion, I believe that all software engineers should know a bit of product mindset because everything has a lifecycle and needs to tell a story for those who will use your solutions. Ticking boxes alone may prevent you from understanding what you are doing. When we are assigned tasks or requests, we need to always be able to analyze and understand who we are solving for, why the solution is needed, and what it is that we are creating. If 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. Everyone should do things only when they understand the intent of the request.
I constantly say that building software is an art, and sound artists know what story they are trying to tell.
Happy hacking!