How Senior Developers Fix Problems

I can assure you that, more often than not, most seniors don't know most of the problems they face and must repeat an error several times, similar to junior developers.

So, how do senior developers solve problems quickly and seem not to get stuck?

What I'll share in this post is not a secret and might not apply to everyone. However, it's good to gain some perspective and improve how we address issues, whether software-related or not.

Here's the framework I use when I have a problem, starting with the basics: is this a problem?

1: Is This a Problem?

This might seem obvious, but not everything that appears to be a problem is.

The best example I can give you is this: in chess, you might be threatened by the opponent's pieces. However, this might not be a problem. A threat might not require immediate reaction, so it is not a problem.

My first tip is to write down the problem and why this is a problem.

Here's an example of a problem:

My washing machine is broken.

This is a problem because I will spend money replacing/fixing it, and, it will take more time to do the dishes since I have to do them by hand now.

Here's an example of something that seems like a problem and it might not be:

My pen just blotched the paper I was writing in.

This is not a problem since I can throw the paper and pen away. I can also re-write everything on a new piece of paper.

Of course, both these examples might be problems (or not) for other people. It depends on your point of view and particular situation.

We can move forward to the next tip, which I think is the most important (and sometimes more difficult to follow): Why is this problem happening?

2: Why is This Problem Occurring?

Let me first get something straight here: sometimes, you can't or don't need to understand why a problem is happening.

Take the washing machine example. If you're not the one fixing it, why should you worry about why it's happening?

This is for situations when you're the one fixing the issue. It's challenging to do this because understanding the why might take a long time.

The why of the problem might require you to do a lot of debugging of the code, and it's at this stage you need to have discipline and organization so as not to get lost.

Here are my tips to mitigate the why of a problem:

Think of yourself as a scientist, and you're doing experiments. To understand why, you first need to create a hypothesis.

Let's understand this with an example:

The turn signals of my car don't work.

Hypothesis: The battery of my car is flat.

What would you do to address this?

When I was in this situation, the first thing I did was start the car.

Since I knew that if I could start my car, the battery would not be broken.

Here's a brief diagram of what I'm talking about:

Since this hypothesis was proven false, you can cross it out and start to funnel your hypothesis pool more and more.

Debugging the code doesn't need to be a mindless task. You can create and test hypotheses by performing automated tests to prove them wrong or right.

3: Have I Seen This Problem Before?

This section depends on your background and experience, so of course, a person with more years of experience will have more advantages than a junior person.

However, don't feel discouraged if you're a junior reading this.

Over the years, you will notice some patterns, such as company mistakes, approaches to development, specific features, and so on.

You will especially remember the hours spent debugging a problem. These situations might help in the future if you have a good memory or keep track of how you solve these problems.

Having a database of different problems and solutions allows you to visit it quickly, check how you solved it, and apply what you have learned to the case you have now.

4: Two 🧠 Think Better Than One

After trying everything (and I mean everything), and I'm usually still stuck, I will ask for help from someone with more knowledge than me on that topic.

Before suggesting a pair-programming session, here's what I suggest you send to your colleague:

• The problem you're having with error logs (if they exist).
• A list of the things you tried before and why they didn't work (if you have screenshots here, add them).
• Add why you feel stuck and ask the engineer their opinion first on your approach.

Sometimes, even a person reading your approach is enough to detect what is missing. Other times, you might need pair programming.

I love pair programming. However, I tend to use it as a last resort to be more efficient with my approach and to avoid wasting my colleague's time.

Conclusion

I thought creating a Notion page with a template for fixing a problem I discussed here would be helpful. It's very minimalistic, and it's available here:

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

A new tool that blends your everyday work apps into one. It’s the all-in-one workspace for you and your team

Notion

I hope you enjoyed this approach to how I, a more senior developer, would solve a problem. Did I miss anything? Let me know!

And if you haven't already, don't forget to 👇