Issue #7 - How To Debug, 10 Simple Steps

Debugging is a critical skill for developers, we dig into the 10 essential steps.

Welcome!

Welcome to Developing Skills - Skills for Developers looking to develop their careers.

This week we have:

• Tip of the week: How to Debug, 10 Simple Steps

• Book of the week: Deep Work

• Finds of the week: Feature Flags: Theory vs Reality, The reality of Big Tech's 'fake work' problem Building Personal and Organizational Prestige

Tip of The Week: How to Debug, 10 Simple Steps

1. Get to know the system. If you don’t know what the system is supposed to do, why it’s supposed to do it or how it’s supposed to do it, you don’t actually know it’s broken and you’ll have no idea where to start debugging. Read the documentation for the system.

2. Make it fail, then make it fail repeatedly. If you can’t make it fail in the same way repeatedly you haven’t gathered enough detail to understand what triggers the failure. Automate the process of making it fail repeatedly.

3. Inspect the system. Use logging, debuggers and metrics to understand what the system is doing, the state it is in and what happens as each step of the process to reproduce the issue occurs. Do not guess at the cause, gather and record data.

4. Apply your algorithm knowledge - divide and conquer. As you look for the cause of the defect keep narrowing down the search space. Start where the issue is and work successively back from there. Like a doctor with a barium meal try to inject things into the system that are easy to pick out on the diagnostics.

5. Change one thing at a time. If you change something and it has no effect, remove that change before trying another change. If you have no idea what to change after inspecting the system then figure out what changed since the last time it worked - your version control is your friend!

6. Keep a record of what you’re done. If this is a production system you should be writing the postmortem timeline of events AS YOU DO IT. This ensures you have both an accurate record but also keeps a record of what you’ve done, what you’re tried and what moved the needle that you can refer to as you figure it out.

7. Check, don’t assume. Don’t assume you know what version you are working with, check. Don’t assume you know what configuration is running, check. Don’t assume anything. Check.

8. Use your team. Two heads are better than one. A fresh perspective helps. Explaining the issue to someone else helps - if there’s no on else around, explain it to your dog, cat, teddy bear or write it down - the action of explaining the issue will help clarify your thoughts and suggest what to do next.

9. If you can’t point to the fix, you didn’t fix it. If you remove the fix and it’s still fixed, you didn’t fix it (and you didn’t do 1 right either)!

10. Conduct a postmortem or after action review. If it’s a production system conduct a blameless postmortem and write it up. If it’s not conduct a review, figure out what lead to the bug and what could be done to improve the process so similar future bugs are less likely.

Want to Level Up Your Coding Skills?

I believe the best way to do this is to build real-world applications. For that reason I write a weekly newsletter sharing Coding Challenges.

The coding challenges are all designed to walk you through the process of creating an application and to be less than 8 hours work.

Each challenge has you focus on building real-world software rather than toy applications or algorithms and data structures.

You can tackle the challenges in the programming language of your choice. You can even tackle them in several different languages if you prefer.

You can see the challenges and subscribe on the Coding Challenges SubStack.

Book of The Week: Deep Work

Over the course of our day, perhaps even over the 5 minutes it takes you to read this newsletter you’ll get a notification, email or text message. They’re all distractions and they’re all stopping you from being as productive as you could be.

There is a difference between deep work and being in the zone. Being in the zone happens by chance, when you get into the flow after not being productive. Deep work is intentional and planned so it helps to have rituals that help achieve it. A time, a place and a set of boundaries.

Deep Work by Cal Newport suggests doing the following:

1. Multitasking feels productive, but it isn’t. Context switching and constant distractions ruin our focus, too. As a result we perform the tasks we’re doing at a lower level than we’re capable of.

2. There are several strategies to achieving deep work, all of which require us to make an intentional choice to pursue them. They are:

   1. Monk Mode - eliminate all sources of distraction and schedule your time like a monk.

   2. Sacred Hours - block of a number of hours as long periods of secluded time to focus.

   3. Rhythmic - form a habit of doing blocks of deep work in a pattern.

   4. Journalistic - grab unexpected free time to do deep work.

3. Focus your brain and be selective about distractions. Use moments that might otherwise be unproductive, but distraction free - i.e. a shower - to consider a problem.

4. Schedule your work and free time so that you’re mindful of how you’re spending your time.

Share(s) of the Week:

1. Feature Flags: Theory vs Reality

2. The reality of Big Tech's 'fake work' problem

3. Building Personal and Organizational Prestige