Jerry Jones

Category: Process

  • How I Debug

    How I Debug

    For most of my career I thought there was always something missing with how I debugged, like I needed to set-up an advanced error reporting system that would log and track down every error seamlessly. Then, I would really know how to debug like a 1337 haxor.

    1337 haxor cam

    Now that I have a big kid job, how has my debugging system evolved to be more professional?

    It hasn’t.

    The same things I did when I started, I still do. I still console.log things. I still var_dump or print_r() arrays to see what’s going on. Even in extremely complex codebases and systems, the same ideas work.

    Debugging is Problem Solving

    What I understand now is that console.log or var_dump isn’t debugging. Those are tools to help you debug. The real debugging happens with you.

    You got this.

    I don’t consciously go through this checklist, but this is the general idea of how I debug.

    Recreate the bug.

    Can you reliably reproduce the bug? If you don’t know what environments and situations it happens in, it’s extremely hard to debug. Is it a certain browser? A certain device? Does it happen consistently after a certain action?

    Check your assumptions.

    Is that variable really what I think it is? Does that function really return what I think it does? This is where I will console.log stuff, or code directly in the console to test basic functions and methods to make sure I really understand what does happen vs what is supposed to happen.

    Isolate.

    Reduce the scope of your issue to the tiniest bit of code you can. If you’re working on a complex CSS issue, how can you boil it down to the most basic test case possible?

    If you’re not able to isolate the issue and reliably reproduce it, then you don’t really understand what the fix is. CodePen is great for helping with this, as you can isolate in a clean environment and then share results with your team.

    Be persistent.

    There’s nothing incredible or advanced about debugging. It’s just about being persistent to understand the root cause of the issue. Some bugs take a long time, but the more you poke and prod at it, the more you’ll understand it.

    You’re Debugging. Not the Tools.

    Remember, you’re the one doing the debugging. To put it all together, we’ve got:

    • Recreate the bug.
    • Check your assumptions.
    • Isolate.
    • Be persistent

    We can easily remember this with RCIB, or BIRC, or hrmm.. CRIB? I bet you’ll be OK without an acronym, there are already enough things to remember.

    The tools assist you, and can help guide you to the issue. In the end, you’re the one solving the problem, so use whatever tools you want to help you. 🙌

  • Across the Atlantic Handoffs

    Across the Atlantic Handoffs

    Automattic is a large worldwide team, made up of smaller, worldwide teams where everyone works remotely. That was one of the things that made me excited to work there, but also very curious as to how it worked in practice.

    Would the timezone differences slow us down? Would we unintentionally get in each other’s way? What if we needed an answer from someone who had already logged off hours ago?

    Working as a Team

    The team of eight I’m on is made up of people from 6 countries:

    • Argentina
    • Czech Republic
    • Germany
    • England
    • United States
    • Greece

    And it’s amazing. We work so well together. This boils down to:

    • Caring about doing a good job.
    • Wanting to help the team.
    • Being responsible and motivated to work independently.
    • Communicating * 3

    I’m a big fan of everyone on the team. We all do the above points well, in my opinion. I’m not sure how well it would work otherwise.

    The End of Day Handoff

    One thing that really helps us work efficiently is our End of Day notes. Everyday before logging off for the day, you post:

    • The status of what you’ve been working on.
    • Any PRs you need reviewed.
    • Is there anything you want to handoff? Lots of notes here, if so.
    • Is there anything blocking or that you need help with? Similar to the above, but not exactly. This could be something outside of a code-related thing.

    This helps us know the status of everything in a consistent way, while also being able to pick-up work or help each other out. We call this asynchronous communication. A lot of things don’t need to be real-time conversations if you communicate clearly enough.

    The handoff works especially well when there are two people spread out over far enough timezones that they have 2 – 4 hours of overlapping time. One person starts work in a more focused way, then there’s enough overlap time for working together and getting on the same page, then handing off to the next person to work on it.

    It also builds a lot of team camaraderie as well as being deeply satisfying when you say you need help with something, go to bed, then wake up and find it’s taken care of.

    Working in Sync

    Earlier on when I’d joined Automattic, I was helping out on a complicated issue where two of us were working actively on the same PR. I was trying to act in a supporting role to get it over the finish line without getting in the way. I tried to walk the line between helping out without taking over.

    I reached out to my co-worker Damián to make sure I wasn’t stepping on his toes by working on the issue.

    “Please, step on my toes.” he said. “I’ll let you know if something isn’t going well, and I ask you to do the same for me.”

    So many places look at being in one office at one location as an advantage, but I’d argue that this kind of open, honest communication and End of Day handoffs allows our team to work more efficiently than if we were all in one area.

    Either way, it’s an amazing team. We’re hiring, so be sure to apply if you think you’d enjoy working remotely on a worldwide team.