Defining the way I approach problems

As a software developer, it is insanely easy to get tunnel vision on a certain issue when working on a project. In fact, it stems from the fact that the “software developer mentality” often emphasizes being able to break a large problem into smaller individual ones and tackle them one by one. I do this, and just about every one else I know does as well. And it is applicable outside of software development.

While an effective and thorough approach, consider this. As you break the large problem down, you are inadvertently setting short term goals for each sub-problem with the overall hope of being able to tie everything together in the end. This allows the focus to shift onto the short term goals and lose track of the big picture, so to say.

You may have been given the task to refactor a current system so that it uses a new piece of software, and you may be stuck on how the new software communicates with other running tasks. If the business value of this is not considered beforehand, the complexity of the issue will force you to explore multiple solutions. Much like Alice, your mind will be attracted to all of the various ways that this task can be done, and you can easily spend more time than is actually worth.

So what does this mean? Why is the example above so vague?

Well, try to think about your own experience and when you have spent too much time on a feature and in the end have seen it discarded or rarely used. Software developers build for others, and ultimately we need to think about what the customer wants and needs. In the quest for software perfection and immaculate metrics, the customer’s needs have to surpass all.

We have to build for them and explore in our own time.

You may be thinking “but what about time constraints? My job is 9 to 5 and I am tired when coming home”. Completely valid, I understand. My advice for that would be to, every day, identify a part (in whatever you are working on) that you would want to try something different with. Think a bit about how you can do it, and note it down. Then attempt it when you get home and see how it performs.

Take all this with a grain of salt, of course. But do consider the benefits of looking at projects and issues in a more holistic way. It all has to work together, and many factors have to be taken into consideration. There will always be a large number of unknowns to consider, and a lot of future potential problems.

Thank you for taking the time to read through this article. I am in no way a professional in anything but I thought it would be good (for myself) to try to define how I think about problems and solving them.