One of the nice things about being a professional software developer is that you're always learning things. On a given day, you might be learning about

• A programming language or framework
• Your computer or operating system
• Your tools (like editors, build systems and IDEs)
• The domain you're working in (finance, biology, energy, games, etc.)
• How to communicate with your collaborators
• How to effectively manage the projects you're working on

There are many things to learn. Indeed, one of the problems you might have is finding all of the things that you want to learn about.

There are lots of ways to try to explore these topics: aggregators like Lobsters or the disappointingly neoliberal orange website; following the blogs or Twitter feeds of programmers you like; the many, many podcasts devoted to various facets of the profession. I partake in my fair share of these things, but I've come to see a lot of it as futile or counterproductive.

I collect things from these channels with the intention of coming back to them later when I have time and energy to invest in them “properly”. This would be a very useful thing to do if I was about to enter a period of my life with a surplus of free-time and vigour, where I'd have time and energy for sitting down with a new tool to engage in deliberate, effortful practice so that I can develop and retain a mental model of how it works and gain some fluency in the skills I need to operate it.

Of course, I'm not about to enter a magical period of free-time and vigour. It feels like I might; it's human nature to underestimate how much effort things in the future will take. A more realistic assessment is that tomorrow will be just as difficult and today, and I won't miraculously have time for all these conference talk videos and neat looking blog posts. In the meantime, the aggregation sites and social media feeds will be happy to enable my browsing and collecting habit for as long as I care to click on the links they put in front of me.

I suspect that I'm not the only software developer who experiences this. I also suspect that, like me, other software developers also feel fear-of-missing-out and anxiety that they're being left behind. As you can probably guess, these feelings are entirely detrimental, with no discernible benefit to my professional effectiveness or personal well-being. I'm sure they're just as helpful to the industry at large.

Though I have expressed a desire to learn things, my behaviour reveals a desire to collect URLs and then never look at them again. There's a dangerous combination of hyperbolic discounting, FOMO, and operant conditioning by websites that want me to click on one more link standing between me and that sweet, sweet personal/professional development.

How to approach learning with an accurate view of what's scarce

Here are the things that help me overcome my shortage of time and energy and actually learn stuff. Naturally, these are all subjective and may not work for you, but hopefully they'll be a useful starting place.

• Don't pretend that browsing the web is helping you learn. Try to do something that will let you accrue time and energy instead. This is quite hard, because you need at least a little bit of time and energy to figure out how to gain more time and energy later, and it's usually not obvious how you should go about doing it.

• Recognize that learning will take resources, and allocate them. You're not going to master a new technology in two hours with a video course and a coffee. Be realistic about the time and effort you need to achieve your goals; carve out a place for them rather than trying to achieve them with whatever you happen to have at your disposal.

• In my experience, the best way to learn technical skills is to use them. Write programs with that language; build a thing with that framework; spin up and operate that database. The best way I've found to do that (given the constraints on time and energy that we're trying to overcome) is to pick a project, scope it down until it will only take a few hours, execute it, and then re-evaluate. This makes the up-front commitment achievable and taps into all those delicious goal-setting incremental progress dopamine productivity hacks that we humans are so susceptible to.

• If you can, get a book. I usually learn more effectively from an old fashioned pulp-and-pigment book than from an equivalent website or PDF. There might be a deep, neurological or social reason for this, or it might be because “reaching for my phone” is enough of a barrier that the usual digital temptations are less appealing than turning the page.

• Choose things that you don't want to learn. I find that the huge pile of things I want to learn is less scary if I periodically take chunks off of it and throw them into the pile of things I don't need to learn. Even if deciding that I don't care to learn assembly language, RISC-V, blockchain, PHP, and the Unity game engine won't free up all the time and energy it would take to learn all the things I want to learn, it nevertheless makes me feel better.

Your time is valuable. Thanks for spending some of it with me. I hope something you've read will help you make good choices about learning.

The comparison between debugging and the scientific method has been made before. Originally, I understood this to be a cyclical process where you proceed based on observations of your program using things like interactive debuggers, lots of print statements, and a short iteration cycle. A recent experience with some buggy code has convinced me that this is the wrong way to look at the scientific method as it applies to debugging—at least for the beginner.

As part of my thesis research I'm working on tracing sources of emissions of carbonaceous aerosols using a general circulation model. This involves having an optimization routine modify emissions to bring them into agreement with observations. My results were obviously wrong, but they had a pattern that matched the spatial distribution of the biogenic emissions source in the model to the pixel. Clearly this observation implied that the biogenic emissions were to blame. (Spoilers: that wasn't the problem.)

What followed was a downward spiral of frustration and ineffectual iteration in the observe-edit-run cycle. That madness only stopped when I settled down and remembered a part of the scientific process that I'd left out (as the astute reader will have noticed). The essence of the scientific method and the most important insight it offers into debugging is:

Have a hypothesis.

Before you load the debugger, before you go crazy with print statements, before you do anything but carefully review the information about why your program is failing, have a hypothesis. Doing so ensures you spend some time thinking about your code, helps structure your investigation and keep it moving forward, and steers you away from bad some habits. In retrospect it's an obvious oversight, but it's essential to making the process work efficiently.

To have a hypothesis, you have to understand how your program works. Without a solid grasp of its overarching structure, an accurate mental model of how it executes, and at least an inkling of where the problem is, you can't form a hypothesis about your program. You also probably can't debug it effectively. If you find that can't easily come up with a hypothesis or two, it's probably time to pause and learn about the parts you don't understand. Having a brief space to think without the distraction of furiously interrogating the source code can also be enough to bring about that vivid flash of insight. It's important to have the right ratio of thinking, coding, and refining your ideas, but striking that balance is no mean feat even for an experienced developer. Having a hypothesis is a shortcut, an easy thing to keep in mind to get the mix just about right.

One of the motivations for applying the scientific method to debugging is to simplify an otherwise overwhelming task. Trivial examples aside, bugs arise in obscure and unexpected ways, so it's never obvious how to tackle them. Through a combination of optimism, desperation, and the apparent lack of alternatives, it's easy to escalate into logging, simulations, elaborate visualizations, flushing out the problem through sheer force of print statements etc. There are a multitude of activities that can help you understand how your code works, and you can pour hours into them achieving nothing but a frantic, buzzed half-instinct about what's going on. By putting the hypothesis first, you focus on the goals of your analysis and have a clear endpoint: the hypothesis stands, doesn't, or reveals another hole in your thinking. Having a hypothesis isn't as good as a detailed plan or solid good habits and instinct, but it lifts you out of the weeds and demands that you proceed in light of the bigger picture.

I've noticed a number of transparently bad habits in my debugging: poring over source code unrelated to my problem, belabouring preliminary points, relentless logging and printing, and (in times of truly dire frustration) the `change-a-line-and-pray-it-compiles' method of code validation. Each of these behaviours has its own trigger, it's own destructive cycle, it's own threats to watch for. Each is also inconsistent with having a hypothesis. Perhaps the most beneficial effect of having a hypothesis is that it's a tight, simple defense against seductive bad habits.

In my Carbonaceous Aerosols case, it turns out there was a bug in my optimization algorithm; the extra source was a red herring. I arrived at this conclusion after a large amount of inefectual flailing, followed by a walk, a few deep breaths, and a focused effort to keep my hypothesis in mind as I tracked down the problem. It's a useful brain-hack; coming to it on my own (at least in this instance) has made it particularly sticky. Now if only I'd had it two months ago ...