In the past, I’ve been guilty of assuming that I understand someone’s problem. “Got it, what about if you….” I’ve said, cutting the other person off mid-sentence while silently congratulating myself for saving the other person from the burden of speaking their mind. I cringe when I think about times when I’ve done this, and I try not to do this any more.

A simple mushroom based bolognese, with lots of depth.

Adam Ragusea’s Roasted Tomato Sauce is a super simple and quick recipe to make a tomato sauce that takes no effort at all. The only thing to watch out for is burning yourself. As someone who rarely uses a kitchen towel to grasp pans, this one has burned me a couple times (literally).

Jacque Pépin’s Chili con Carne minus the carne. This recipe’s almost comically easy.

I stole this from Bon Appetit. Super delicious, comforting, very forgiving, with a silky texture that is unlike other pasta recipes I’ve made (probably due to the crushed chickpeas).

When I’m learning a new language, I tend to take a very dumb approach (and I don’t mean that in some enlightened way). I’ll usually try out a tutorial or two, but if the language is similar to another language that I know, I’ll basically just start coding without investing a lot of time learning the language features. This leads me to often googling how to do extremely basic things. Stuff like ‘python iterate over dict’. ‘javascript get object keys’. ‘elixir keyword list to map’. In the past, I’ve felt extremely adept at finding exactly what I need, but recently I’ve noticed that it’s been taking me longer and longer to really find the answers I’m looking for.

Programming Languages are created in order to solve problems. This might seem obvious, but I don’t think it is as obvious as it seems. Some languages are focused on working with statistical and numerical data. Some are focused on ease of learning and usage. Others are focused on making it easier to write performant code. There are languages that attempt to work for all usecases and problems. But languages that are crafted to focus on a set of specific problems feel more powerful.

There are tons of posts on the internet about how to write code. There are blogs emphasizing readability when writing code. There are plenty of essays, even books about how to write code that is easy to extend and add functionality. While I think emphasizing readability and adding functionality are important qualities of writing scalable code, I think there’s not as much stuff out there about how to write code that’s easy to debug. I’m hoping to write more of these, but here’s one lesson I’ve learned on making code easier to untangle and debug.