I saw this interesting post on Twitter from Chris Krycho the other day:

One of the frustrating side-effects of being 100% self-taught in software and computer science is having massive, *massive* gaps in my knowledge and experience, and accordingly being actually intimidated by entire classes of problems. [...]

I replied to it at the time, but I couldn't quite shake the idea out of my head. I recognize that feeling. Self-taught leaves out quite a lot. Some of the things you know aren't necessarily right, and some of the things you don't know you don't know you don't know.

It also fits in with a recent pair of episodes from Talk Python To Me: Coming into Python from another Industry (part 1) and Coming into Python from another Industry (part 2). These two episodes are talks with panels of people who turned some side work they did in Python at their old jobs into new jobs that required Python (sometimes at the same organization). Most of them told the same story: they learned Python on a lark or to solve a problem, then it turned into a superpower, then they used their superpower to solve more difficult problems and change their lives. They didn't set out with a goal in mind—they created, learned, kept at it, and drip-by-drip became someone new.

So. Two things:

One. That initial post and the podcasts turned into a solid creative week of writing some tools at work. I had lost the confidence to do that for a while, and now it's back. All the old patterns were there I could manipulate them into place like Legos, often in new configurations.

Two. I don't make tools for tools' sake. Sometimes I'll write a bit of software that saves time or produces a better looking output, and there's some joker that will ask if making tools is something I want to do. No. I do it because it helps me get the work done, but also because I get to think about the problem in a deeper, more thorough way than I otherwise would. You have to understand the interfaces of the problem, as well as what it's supposed to do and why, in order to get a tool to work with it. You have to think more abstractly when you're designing the software to solve the problem—you can't reach inside it and fix things that don't line up, you have to train the software (or the inputs to the software) to identify aspects of the problem and deal with it.

And maybe also Three: it's fun to make things.