HomeBlogAbout

Mindful software development

Jan 27 2023 · 3 min read

When I started learning programming, everything was new to me. I had to learn the syntax, understand the language, and practice problem solving.

I wasn’t focused on writing the most efficient solution, or architecting a maintainable system. My goal was simply to get the thing to work.

Instead of thinking about reusability, encapsulation and other such principles, I was just trying to figure out why the code isn’t working, and how to fix it.

To fix my program, I needed to test the assumptions I made about it. Is every variable what I expect it to be? Did I actually call the function?

I needed to trace the logic of my code to understand what went wrong and figure out how to fix it.

As I gained more experience, I understand the code I wrote more. I become better at quickly spotting and fixing bugs.

Because of this, I was able to focus more on writing maintainable code instead of just trying to get a working solution. As a result, it became even easier for me to fix errors in my programs.

Then I got my first job.

I was assigned to a legacy codebase, developed over the years by many people with different levels of experience, using now outdated technologies, employing some questionable practices.

I got to work on my first, seemingly simple task. I wrote the solution, but it didn’t work. Why doesn’t it work? It should work.

After some debugging, I found out that it was because another part of the system was interfering with the code I wrote. I looked at that code thinking “who in the world would write this?“.

I quickly realised that the codebase was a global mess of spaghetti code and getting anything done will be difficult. Instead of developing the system, I spent my time wrestling with its complexity, getting angry, and demotivated.

I was constantly frustrated when working on the project. What should I do?

While rewriting the entire thing from scratch using new tech, and sticking to good practices would probably be fun, it’s not an option, because of how much time it would take.

I could switch to a different project, but I was thinking “I’m not a quitter, I can do this”. So how should I approach working with a codebase like that?

I need to go back to where I started. Instead of becoming frustrated because my code isn’t working as expected, I need to diligently test my assumptions about it. That’s how I find out why the program is broken, and how to fix it.

Instead of feeling resentful because of the bad practices in the codebase, I need to accept it for what it is. I need to let go of my emotions, be objective, and focus on the present. I need to be mindful.

Everything in our programs happens for a reason, and my job is to find that reason.

It’s a tedious, time-consuming, and exhausting process.

However, after all the hard work, when I finally manage to find and fix the bug, I feel a spark of joy. The same joy that I felt when I was learning to code.

Getting lost and figuring out my way to the solution. Feeling like a beginner again.