This happened in my first professional project, and although it wasn't that significant or technical, I'm proud of it since it helped move the project forward and taught me a lesson that I always keep in mind.

My first professional project was the development of a small product that had the goal of helping manage workforces. You can think of it as a glorified to-do application. The project was greenfield, which meant that a lot of requirements were yet to be defined/discovered. Since I was working in a small team, I ended up attending meetings with the client, which over time, gave me the necessary confidence to speak my mind whenever I thought I had a useful contribution. It also gave me a perspective on the business side of the product.

One day at the office, my boss told me that I should stop working on my current feature and instead work on a new one the client had just requested. The new feature was to introduce tasks that had sub-tasks, and the task would be completed when the user completed all the sub-tasks. Asking for that feature at that particular time didn't make much sense to me from a business perspective. And on top of that, it was a relatively expensive feature since we had to make changes in all parts of the system (UI, FE, BE, and DB). Thankfully, we had a meeting with the client later that day, and my boss agreed to wait until after the meeting for us to start developing the feature. This was great because it allowed me to clarify what was happening.

During the meeting, I asked the client why he was in such a rush to get that new feature. The problem was that users couldn't grasp what they had to do for the day, because their list of tasks was getting cluttered by tasks with the same name, but that had to be done at different times. Our client's solution to the issue was to create a sub-task system so that in the UI, we could group tasks and show them as a single card. Since I now knew what the problem was, I suggested that we could just change the UI to group tasks with the same name, we didn't need sub-tasks. This approach would solve the problem, be cheaper to implement, and allow us to focus on other essential features. The client accepted the suggestion, and it worked well! And as far as I worked on the project, we never needed to implement that sub-tasks system.

What I understood from that point onwards was that our value as developers doesn't have to be just technical. I would even argue that where we can provide the most value is on closing the gap between the business side and the technical side of software development. Our clients don't know which features add a lot of complexity to the system and which don't. A lot of times, they have misconceptions or simply don't know what it's possible to do with software. And I believe that it is our job as developers to not only build the systems but also to advise our clients on what seems for us the better route for them to have success.

What about you? What's something that you've done in software development, technical or not, that you're proud of?