Reference: Python Crash Course, 3rd Edition

First, some background.

The biggest gaps between me and the employers I'm talking to / the positions I'm interested in are the following:

  • Python
  • Go
  • Terraform (tf)
  • Kubernetes (k8s)

While in seven+ years as an engineer, I have done all the things these technologies do via other means (cloudformation, homebrew orchestration, ECS, etc.), and while I knew that picking up their syntax would be possible with a very little effort, truth be told I do need to put in the effort. Preferably soon; both for my own sake and for the sake of my next employer.

A winding tale of why

A couple weeks ago, I interviewed with an early stage startup in the big NYC AI soup. I (IMO) knocked it out of the park with the breadth of my experience in their problem space; the manager was excited, I was excited, and then... nothing. Radio silence.

I poked the recruiter who was my bridge to these companies, and a short time later I received a link to a notion doc describing a take home project involving... python, tf, and k8s. Great. From the perspective of "hell yes, or no," I didn't think the opportunity merited the kind of deep-dive hackathon that I'd need to perform to deliver on the goal — after all, they forgot about me for a week. But I knew I'd want to build these skills """eventually""".

In my heart, I know there's a huge difference between "could code adequately in a language" and "knows the language;" with five solid years of Node.js under my belt, I still regularly sense that I've hewed too closely to the straight and narrow, and don't truly understand the language, quirks and all... and this, from someone who regularly peruses the nodejs/node repo to resolve fiddly questions of implementation that the documentation isn't always clear on.

This attitude is both correct and totally useless from the point of view of getting a job: while it's theoretically possible to conserve energy by working on my side projects while looking for a job, and then hunker down on the exact stack that's demanded of me once I'm certain of the technologies I'm certain my new employer will be using, in practice the four bullets above are such greatest common factors among the jobs I've been looking at that not knowing them is only holding me back.

Meanwhile, a close 𝕏 mutual of mine had a position open up at his company, and I threw my hat in the ring, but was quickly turned down. Even though I'm brilliant on the backend, the gap they needed to fill was very particular: they needed a k8s pod wrangler.

Well, I said to myself, I am also mutuals with the previous pod wrangler. Maybe I should ask him how he got started?

His answer? "Once upon a time, I got a take home test that used k8s, which was supposed to take 2 hours; I took 6. In those 6 hours, I learned 90% of what I needed to know to do my job."

Well, shit.

The Claude school of Python

Bouncing back and forth with Claude, we came up with two versions of a curriculum that gets me up-to-speed with the four (five, including Docker) technologies above. The first syllabus was based on the twelve week timeframe allotted at bootcamps like AppAcademy, from which I graduated in 2015.

On my suggestion, we also narrowed it down to a two-phase curriculum, spending the same amount of time overall, but gaining a much quicker exposure to all the technologies in a single pass, then turning back around to cover the ground we'd missed on the first whirlwind tour. Based on its advice, I acquired "Python Crash Course: 3rd Edition,"[1] and got to work.

Third language acquisition: Python as Romance Language

From best to worst, the languages I speak are:[2]

  • Javascript, with an emphasis on "backend-flavored Typescript"
  • SQL, particularly the PostgreSQL dialect
  • ruby
  • HTML/CSS ("""languages""")
  • BASIC

When you consider only the most strict definition of languages (mostly written for general purpose computers, still in commercial use), only two remain: javascript and ruby. Fortunately, python is a lot like these! It is dynamically typed, interpreted, and leans toward object-oriented with some hints of functional design.

The previous times I had tried to learn python (~2007, 2010), I had been bogged down by a couple interlocking phenomena:

  • I was obsessed with reading every word, as I had taken to heart Zed's admonition to read everything and to execute every step exactly as described in programming books, so that things would stick.
  • I kept getting caught up in syntax: keywords and built-ins just wouldn't stick in my head without completing a lot more exercises than I truly wanted to.
  • I didn't have any particular itch I wanted to scratch with python, especially once I got comfortable with rails and later, node.

This time, however, something marvelous happened: As I blitzed my way through PCC3, I found the python concepts presented nesting easily into place between my ruby knowledge and my JS knowledge. (Method lookups through the inheritance chain, via __dict__ checks? Why, that looks just like how JS navigates the prototype chain, and how ruby resolves methods!)

Some of this is certainly downstream of having Claude as a resource: in most cases, I can pose vague, handwaving questions ("why did the community decide to do this?" "give me a few examples where the mod argument to pow() justifies its inclusion in the standard library") and get answers that would have taken me a half an hour or more to get an answer on my own.

But I think the biggest changes are in me: I am intimately familiar with the needs of a particular style of programming via constantly trying to push node to do what I need to, so I know where to put new information about python in my brain, and I know which questions to ask about how I can do in python what I do every day in node. I am also much more willing to skip entire paragraphs or sections of a book as not worth the time,[3] and instead drill on the things that do provide value.

With Claude's help, I was able to blitz through the book in under two days, and get a much more complete understanding of the language than I had ever gotten during my past attempts.

Seeing python with new eyes

So, after two days, what are my takeaways about python? In no particular order:

Yet another web language?

I had avoided python in part because I already knew how to build web servers in other languages, and those languages do quite well at that. What's the point of learning another flavor of language to do the same thing you're already doing, quite successfully, in another language?

Well, the answer is: since any[4] language can be used to run a webserver, you should probably choose the libraries that express your business's problem domain most effectively, and work backwards from there to determine what language (and web framework) to use on your server. (Assuming, of course, that you have a server.)

Over the past 20 years, python has become the lingua franca for people who have Serious Problems but aren't "actually" software developers. As such, it has a wealth of libraries that provide performant solutions for any number of domains, and as glue it works Well Enough out of the box that you can just get things done without too much hassle.

The new reference language

In the past, if you wanted to write a new language that was mostly imperative and mostly structured, you probably wanted to base its syntax on C. (See also: C++, Objective C, C#, Java, JavaScript...)

Through deep-diving with Claude, I discovered there is a vast ecosystem of python-inspired languages that use python syntax for unexpected purposes.

Want to configure your build process? Starlark allows you to configure your Bazel builds using python syntax!

Want to get into microcontrollers? MicroPython and CircuitPython will allow you to target many of the most popular chips out there, using python syntax!

Want to get into language design? RPython is a language for writing interpreters...

and so on, not even to mention the wealth of interpreters, each emphasizing different aspects of or targets for the language.

Getting comfortable with python has opened a bunch of doors that felt much further removed from where I stood a week ago.

Echoes of C

Even though python looks like a new juncture in the world of reference languages, python itself feels like a thin wrapper on C, just as C has echoes of assembly. Quite frequently, I feel like I can sense the sorts of manipulations happening under the hood (especially obvious in the case of libraries like array, with its very C-like typecodes) and predict what C code was written, and what stdlib calls were made, to make the earliest versions of python.[5]

Small language, rich standard library

Ruby and JS are slightly weird, for different reasons. JS, even via node, has a history that is strongly tied to the browser; in particular, with no ways to segment off the language, every new version of JS has to jam its features onto window. Want to add proper Arrays for low-level data manipulations? window.ArrayBuffer. Want to add proper sets and map implementations? window.Set and window.Map.

This quirk of the browser — any new feature must be ambient — along with compatibility concerns (don't break existing websites!) and the years long gap between ES3 and ES5 means that JS is a big language by default, and "standard library" is practically a non-sequitur.

Node, by contrast, is nearly as big as JS in the browser (via global instead of window), but it also has a relatively modest number of core libraries that are accessible via require (now import), largely giving access to server-specific functionality like http and crypto. Meanwhile, things that would be part of a "standard library" in any other ecosystem as just as frequently gated behind npm packages.[6]

In contrast, ruby, with its goal of maximizing developer happiness, has a slightly larger core language, with pieces like RegExp, File, and Thread always in easy reach.

Python is small. Like, learn in two hours small. There are a few core ideas (lists, classes, tuples, etc.); a large amount of culture (PEP-8, "idiomatic python")... and one of the most satifying standard libraries I've ever seen. Sure, in order to use regexes, you have to reach for re... but meanwhile readline is sitting right next to it on the shelf. Async paradigms? We've got tons! uuid, curses, tempfile... all libraries that I'd normally have to reach out to npm for,[7] that in python all come for free with the language.

And don't get me started about the top libraries in the ecosystem. There is so much to be said here, but in brief: there are many times I've wanted to generate simple visualizations, and I normally reached for Excel + screenshot, or d3.js. For the types of problems I'm generally solving, though, matplotlib and plotly are game-changers: much faster iteration, and much better tuned to the types of customization and presentation I generally look for in dataviz.

I owe you an apology, python. I wasn't really familiar with your game.

Next steps: what does it mean to "know" a language?

I've been obliquely prodding my 𝕏 followers about the nature of professional knowledge. Where they interact, it's somewhat of a scissor: half the people think you can learn C in a day; half of them think C is fiendishly difficult. (s/C/COBOL/ or python or ..., mutatis mutandis.)

I tend to fall on the latter side: "knowing" a language, to me, is like "knowing" your spouse. Not just a single date, or being able to pick them out of their junior high school class photo; you should be comfortable with them, have a sense of what they'll do in novel situations, know what they're thinking without them having to finish their sentences.

Python, just like any other language, has its quirks. In a large enough codebase, under ancient OO design principles, figuring out which layer of indirection is responsible for a particular bug can be nightmarish even though the language itself is simple. The ecosystem (venvs, libraries, APIs) will take a good deal of time to get used to... but now that I know they're there, I can reason about them.

I often say that the hallmark of a mid-level engineer, the sign that shows an engineer is no longer a junior, is to be able to stop what they're doing mid-implementation and ask "am I re-inventing a wheel here?"

In just a couple days, I have written a fair amount of python, and now know that there are shelves and shelves of options available to me to help solve any of a number of problems, and (on my own, or with LLM assistance) can trust in my ability to use those solutions to solve problems that interest me.

The next throwaway code I write will be in python, and I am no longer "scared of," or uncomfortable with the language in any meaningful sense.

And hell, with this experience under my belt, maybe it's time to take another whack at learning Spanish. After all, I already know English and French; how hard can it be?

  1. When looking for affordable copies of this book online, I realized that a lot copies misrepresented which edition they had. No Starch books all use the same cover style, but all editions later than the first will have a black keystone on the cover stating "Second Edition" or "Third Edition" in ALL CAPS. Given how quickly the language has evolved the past ten years, it really behooves you to ensure you're acquiring the right one. ↩︎

  2. There are a few languages I recognize and generally parse: C/C++ (I frequently find myself having to parse source code from the various tools I use to make sense of their edge cases), languages in the APL/J family, and a restricted subset of languages like Haskell, Java, ObjC, Go, etc. (Also coffeescript, but we don't talk about coffeescript.) ↩︎

  3. This is probably rooted in the worry that, without reading everything in depth, I can't say I have "read" the book in question, or perhaps a worry that I'll miss some little tidbit whose absence will bite me in the ass later. This belief, in retrospect, is f-cking stupid. Maybe if I were back in high school, studying for a test on language trivia this would matter more, but in the current learning landscape the marginal value of getting 100% coverage just isn't there... and may never have been. ↩︎

  4. Within reason, of course. While it is possible to wire up nginx to a postgres database and build API responses directly in the database, this is only ever done as a pathological exercise, to cow other developers with your elite skills. ↩︎

  5. Python is old enough, and mature enough, that it takes into account all kinds of edge cases whose necessity might not be obvious when writing a naive solution. ↩︎

  6. I cannot begin to tell you how many times I have installed lru-cache across projects; meanwhile, python offers a very handy LRU-capable data structure via collections.OrderedMap. ↩︎

  7. The curses situation on npm is particularly dire; there are a half-dozen solutions, and the last time I looked, every one I found was in at a different level of unmaintained. ↩︎