Doubt is Essential in Debugging

Doubt isn’t fun. We want to have confidence in our direction and doubt is most powerful just when we need the courage to move. When we don’t have the right amount of experience. But in a different light doubt is caution. An important guardrail against our inherent risk-taking.

See on twitter

Doubt is probably the worst when we’re debugging. At 2 am when we’re staring at the screen, completely out of ideas… Should I even do this? Am I qualified? Do other programmers spend this much time looking at problems like this? I should have solved it by now!

Well. Yes. If you don’t go through those feelings, then you probably didn’t build anything interesting and aren’t dedicated enough to chase an issue to its conclusion. Yes, going to sleep is the best way to deal with some issues, but sometimes it isn’t enough. Sometimes it isn’t an option and sometimes I won’t fall asleep until the issue is resolved. Doubt doesn’t die when we kill the bug, you live to fight another day.

Why Debugging?

I don’t want to talk about impostor syndrome, I’m not a psychologist and have nothing interesting to say on the subject. I think it’s interesting that the point in which we feel it the most is a long and ugly debugging session. After all, there are many areas where it should creep during the day but when speaking to developers it’s universal when we debug.

There are many reasons for that but I think one of the core reasons is that we are impostors to debugging. We pretend to know how to debug but there’s no taught technique. We didn’t learn debugging in bootcamp or university. Maybe the “step-over” button and inspecting a variable. That’s about it. Look at the logs and bang your head against the wall.

Even as we try to fix the problems, we look at that process as taking out the trash. We hold our nose and run to the door. Trying not to breathe in the stench. There’s no technique. No learning. No joy. Just a terrible path we need to take. No wonder we feel doubt, we don’t want to be here. We don’t have the tooling to figure this out and we’re probably not really qualified for this.

Learning debugging techniques and embracing that process won’t make doubt go away. That’s a fixture. But it will make it manageable and will reduce the time when it rears its ugly head. Solving issues quickly and effectively provides a level of confidence that only public speaking can rival.

I wrote about debugging a lot in the previous blog, e.g. with this series. I’m redoing a lot of that work with the hope of reducing this particular pain and making debugging more accessible for all. Also, there’s a book coming out, which you can preorder now…

I’m also working on a new course on the same subject to further clarify some things that are harder to explain in writing. It will follow a similar path to the book. I hope that in a small way it will help one of the big pain points I had as a young programmer.

I have a talk covering debugging techniques in a couple of weeks. The last time I gave it the reviews were pretty amazing.

A Solution to Twitter

On a different subject, with everyone going to mastodon (including me) I’ve been thinking about improving the situation a bit. The first problem with moving to something like that is the lack of content. Many content creators don’t post directly to Twitter. When inspiration strikes we write to a buffering tool. This gets tweeted/posted at times that make more sense in the social network. Some tools are even smart enough to retweet recent posts so people don’t miss them.

Right now the top tools are commercial and have lots of issues. None support mastodon. I’d like to create a free/open-source tool like that. Ideally, something that’s more “hacker-friendly” and works with git. For this purpose, I tried to work with the twitter API which is nothing short of a disaster. It’s got several levels and versions. If you don’t have the higher access level, then you can’t use version 1.1 APIs. For version 1.1 we have twitter4j which is simple and excellent. But we can’t use it without the elevated status of the developer account. It seems everyone responsible for elevating developer accounts was fired. I’m also concerned they’ll cut some permissions like that in the fight against bots.

The problem is that APIs don’t work well with version 2. Even Twitter itself hasn’t ported media upload to version 2 so they expect you to use version one for images and version two for everything else. The documentation is plentiful and unhelpful for anything beyond the most basic use cases. Pretty frustrating. If you have experience with server-side social networks and know what to do with this issue, then drop me a line.

Leaving Lightrun

On a more personal note. I left Lightrun. I joined the company as the first non-founder and wrote the initial implementations of the server, plugin and CLI. It’s been a lot of fun but hasn’t been as much fun in the past few months. Right now I’m muling my options. I signed up to write another book which I just started on. I’m also creating new online courses and working on a few OSS projects.

I also have an idea for something cool in the Java space. I’m exploring that and might build it out.

I will speak at the ADDO conference, but if you listen to only one of my talks, please join me for my LJC talk. It’s one of my better talks as I mentioned above.

Also Published Here