Seriousness

bell-tolls.jpg

As I get older and further along in my career, I'm starting to realize that many people are fundamentally Unserious about what they're doing. Seriousness here is not a description of status or career, but rather a combination of tenacity, effort, and luck. You need some combination of all three to be a Serious person, you need to be able to push through difficulty and bullshit, you need to be willing to do so, and you need to be at a place where you have the opportunity to do so.

For example, Twitter and LinkedIn are profoundly unserious places. Twitter is unserious because a good chunk of people seem to think all complex things are the same complex thing, believing that the way they've approached programming works for approaching basically any other topic. LinkedIn is unserious because it fetishizes some kind of form, even though it's a prison we're all sort of trapped in. No one wants to be on LinkedIn, and yet we're all beholden to it in some way, so the jailers try to make the walls colorful.

Sometimes I see people skim-reading the same 10 bullshit books, peddling some kind of shallow influentialism. The obvious target are the productivity books, but I'm a believer that DDIA has reached this stage too1. There exists a whole class of people who peddle the book, seemingly without reading it or understanding that nothing presented in the book is particularly difficult2.

I suspect a good chunk of this is that programming is hard now, and there's a strong external pressure to always be learning. Meetups, book clubs, endless tutorial blog posts, all feed into this, creating a sort of cruel optimism, where we want more content, but the content actually prevents us from meaningfully engaging with our computers and our software. No amount of DDIA will replace real experience, no amount of tutorial blog posts will turn you into a senior eng. We are drowning in information but starved for knowledge.

The most offensive form of this is the people who reply with "ask ChatGPT" for any question they're not sure about. I am actually quite pro LLM-tooling, but the LLM is complexity-muddling personified. There is tremendous value in using the robot as a enhancer, such as code-autocomplete, but there is nothing more asinine than offloading your thinking to it. Asking it on topics you can't check it on is committing the Twitter sin, where you believe that all complexity can be stirred into one big pot.

To be serious is to be able to develop empathy with the systems you work with. I've worked with programmers that can feel when things are slow and where they're slow, I've myself experienced situations where my intuition about a system caught something quite rare. We can't avoid horror in software, because experience is being able to find matter out of place, the code and the hardware that violate boundaries. How many times have we seen writes-on-the-read-path, abstractions missed or out of place, "wtf"s in IRC? All of these come with experience, and they come with an experience grown from a particular form of mechanical empathy.

Passion, or whether you have to like software to be working in it is oft-bandied about, but I think that misses the mark. It's not about whether you are "passionate", but about whether you are willing to treat something Seriously. Passion is fluid, it wanes with your time. But to be Serious about software is to be willing to develop expertise, far beyond the shallow influences peddled in our industry. Zach Tellman has a wonderful point on this:

Michael Polanyi coined the term “tacit knowledge” to describe something we only understand as part of something else. When we speak, for instance, we don’t focus on the sounds we’re making, we focus on our words. We understand how to speak, but would struggle to explain it. Tacit knowledge comprises the vast majority of what we know; we rely on it constantly.

When that knowledge begins to lead us astray, however, Polanyi tells us that we must delve into it. We must make it explicit. An explicit understanding of speech might be necessary for someone with a speech impediment, but also for a professional performer; to be at the top of your field, it’s almost always necessary to transform innate talent into something more.

A rare exception to this rule is the chicken sexer, who can quickly and accurately determine whether a day-old chick is male or female. The two are indistinguishable to most, but an expert can classify a thousand chicks an hour with 98% accuracy. The knowledge underpinning this expertise has never been made explicit; a trainee is simply corrected by an expert, over and over, until their intuition is equally refined.

Held to this standard, however, we all fall short. No one’s sensibilities about software design are so refined that they can teach simply through demonstration. We have to distill our intuition down to principles, and let those principles guide us beyond the bounds of our intuition. Anything less is just rentier pedagogy; maxims stripped of any context, whose true meaning within a given situation can only be judged by a single person.

To borrow Zach's terms, our industry calls on us to be chicken sexers. Software has existed for far too long in a position of little liability, where people buy software, but have no recourse when the software goes wrong. The steady decline of software speed in the last two decades is clear of this, our software has proceeded to get shittier every year, even as the amount of developers grows. We speak of how terrible COVID hires are, but every year it appears to me the more lemons show up in the labor market.

The era of zero interest rates and easy jobs is over, but the opportunities for climbing ever higher in software have only grown. As programmers, we are being squeezed in both directions: at the top, more and more users are using computers, generating data, flooding the network pipes; while at the bottom the end of Moore's Law and Dennard Scaling means that our software must get more efficient. Electricity in the datacenter is now a rare commodity, as we have to juggle GPU workloads with others. We cannot depend on hardware to give us a free pass anymore. Others are seeing it too: Vlad-Stefan Harbuz has written a manifesto for programmers that care, Thousand Rabbits have been hacking away at the idea of permacomputing, and James Bridle points out how our computers, having paradoxically gotten more and more powerful, have left people with a greater feeling of helplessness.

I am sensitive to the idea that the abstractions have gotten ever higher. To understand the computer you now have to push through 50 layers of bullshit, from your package manager, to your cgroup, through the kernel, and all the way down. But that is precisely why the end crowns the work, because all of us are solving problems in disparate domains, yet those domains are still widely understudied. The engineer who works on DC networking and the engineer working on package management are both exploring the edge of knowledge, and the frontiers are so expansive, that if you take the time to care, to be Serious, you can reach it too, and push that frontier just a bit. The incredible thing about working in software is that our iteration times are so quick, and knowledge in our industry spreads so fast, that we are all bound together. And that's what makes it all worth it.

Footnotes:

1

Really any book that reaches common knowledge is susceptible to this. You see people recommending CLRS without a second of thought on whether it's actually relevant, people have thankfully finally stopped recommending the Dragon book for anything compilers related.

2

The book is fine, it's a primer for L4s. That has immense value, but knee jerk suggesting it seems specious.

Posted: 2024-08-24
Filed Under: computer