Looking under the hood will change your relationship to your code.

Last week I was working with an engineer on some Python code. We’d built a couple of APIs using FastAPI, and they were managing the features and complexity well. They were ready to go deeper.

I showed them with just a small socket snippet, how their code would be able to respond to a curl request.

“Wow! I can do that?!”

They’d already built way harder things. They’d shown little trouble managing tables, routes, permissions, authentication. But calling their own code from curl crossed a system boundary, one we often take for granted (that HTTP works lol).

We just needed to bridge the gap between “code I can write” and “code someone else can write.”

A few months ago, I recommended writing your own library. Before I’d internalized this idea, I often felt like I was coding cautiously. At any moment, I may hit the edge of what a library or framework was able to do, and I’d be stuck.

One time I didn’t finish a mapping project for a few weeks because the one library to do it on GitHub had a performance issue. Once I realized those were tools written by someone similar to myself, I started seeing them as just that: tools that may be appropriate for one job, less so for another. (And I finished the map.)

When you realize your tools were built by someone with a similar skillset to you, your code stops being so intimidating and starts being a lot more fun.

In other news:

• I’m continuing to play with my browser-based Memphis REPL. This week while poking around, I realized int(21/10) and float("2.3") both raised TypeErrors when they shouldn’t. Yikes!

-Tyler