Searls of Wisdom for October 2024

I will forever remember October 2024 as the month I managed to clear a year's worth of personal to-do items only to come out the other end asking, "what am I supposed to do with my life when I have nothing left to do?"

Big "dog who just caught the car" energy.

I like to use this newsletter as a way to experiment with different modes of writing. Playful stuff. Put an interesting spin on an old memory. Send a meaningful message by telling a story. Write some jokes. So let's see what we have here…

Looks like you get a stream-of-consciousness essay on the challenges facing software developers in the current job market and ideas for what to do about it based on conversations I've had with various tech leaders. Weird, but here we are. I don't make the rules, I just type out what the voices tell me to.

Before we dive in, I'll take a moment to plug my podcast, Breaking Change, which I feel like is really hitting its stride when it comes to format, content, and audio quality. The best part is that because nothing I say matters, it's like one of those sightseeing buses you can hop on and hop off at any time. Listen here and there. Finish an episode or don't. Write in questions and comments and you'll keep getting free access to more episodes. I've had folks write in to say they take copious notes as they listen and one person who claims to use my semi-dulcet tones as a sleep aid for their newborn. I'm sure the podcast has other uses too, but those are two of them, apparently.

Ok, let's dive in.

A new kind of job market

Here are a few things that I believe about writing code in a traditional employment setting:

1. It's much harder to evaluate a computer programmer's productivity and performance than it would be if they were working in a factory, driving a truck, or remodeling a kitchen
2. To accurately demonstrate their contributions to management, the programmer has to find a way to communicate their tasks clearly and comprehensibly (often non-technically)
3. To correctly interpret what the programmer is telling them, the manager also needs to appreciate and contextualize all relevant exogenous factors outside the programmer's control (known unknowns and unknown unknowns uncovered along the way)
4. To validate a programmer's self-reported progress, management must identify meaningful indicators of success, then objectively and consistently measure them (whether quantitative or qualitative)
5. To do anything useful with those measurements (e.g., determining compensation, titles, etc.), the organization must first adopt an assessment regime designed to fairly compare programmers' relative strengths, weaknesses, and overall value to the business
6. To navigate so much uncertainty, all parties should assume everyone is basically "making it up as they go," such that it's very difficult for good actors to reach shared understanding and very easy for bad actors to use exaggeration and obfuscation to get ahead

And how are we doing? Well, most people fail to grasp (1), few programmers seriously attempt (2), and most managers thoughtful enough to practice (3) nevertheless fold at the first sign of deadline pressure. It's been more than 50 years, and the industry still has yet to come up with repeatable solutions for either (4) or (5). A big reason for that is the result of (6), as translating between code listings and their corresponding business value requires so much domain-specific context that most material progress is localized to individual organizations, teams, and relationships.

If your goal is to make a career out of writing software, all of the above makes it absurdly difficult to make consistent forward progress. Maybe it was thanks to my liberal arts education, but I'm grateful that (1) seemed obvious to me right out the gate. And I hadn't even completed my first internship before I realized how crucial (2) would be to my success. Likewise, it was self-evident each of (3), (4), and (5) were entirely outside my control, and not something I could count on an employer to do for me. The only apparent way to wrest some kind of control over my own career was to take advantage of (6) by over-indexing on explanation, storytelling, and persuasion as tools in my toolkit.

How other people cope with this messy, unprofessional reality is an under-discussed aspect of the software industry. The lack of agreed-upon language to describe the work, standard practices to make it repeatable, and long-term thinking to make it sustainable means that quite a lot more is left to chance in programming than in other professions. This is one reason why I've always been skeptical of "learn to code" movements, apprenticeship programs, and the valorization of hiring junior developers before they're sufficiently competent. We have failed to even identify the things a person really needs to succeed as a programmer, so we're definitely not equipped to reliably guide others through it—and it's cruel to pretend otherwise. To wit, far too few people attribute as much of their success to dumb luck and accidents of timing as they probably should.

Frankly, every time I look around, I still see people doling out advice that sounds an awful lot like, "here's a list of things that just so happened to work for me between 2010 and 2022," as if they had fundamentally cracked the nut on how to "make it" in software. What I don't see is acknowledgment that the particularities of that era point to it being an entirely past-tense anomaly: money was free, venture capitalists were in heat, and an inflated engineering headcount was the ultimate symbol of startup success.

During that decade, I gave the same extremely boring career advice to anyone who would listen (but due to the amount of money sloshing around, hardly anyone did). That advice? In the absence of an objective and accurate management system, the only reliable formula for success is to connect your individual effort to how much money it makes or saves your employer. Are you delivering a multiple of what your salary and benefits cost them? If yes, you're in good shape. If not, tread lightly.

On the contrary, as the gold rush intensified, companies kept getting larger for the sake of getting larger, which resulted in fewer and fewer people having any perceptible connection between their work and whatever value it created. Everything about it felt (and was) tenuous. And the whole charade had gone on long enough that an entire generation of tech workers had entered the industry during an unprecedented age of decadence. The upshot? As soon as interest rates started going up, dozens of would-be tech emperors were found to be wearing no clothes, and neither they nor their leadership nor their front-line employees were equipped to start running their companies like they were real businesses. Then—just like that—countless tech workers who had attained positions that had been considered safe and important were suddenly and simultaneously ejected into a job market that didn't want them.

Best I can tell, the job market is still pretty damn tough for programmers. Especially for people who insist on finding an employer who will match the total compensation they were offered during the heady post-COVID hiring spree of late 2020 through early 2022. But it's toughest of all for folks who just entered the industry and can't independently demonstrate competence without the support of more experienced colleagues. I have a lot of sympathy for anyone who bought the "learn to code" marketing hype that obscured just how fucking hard programming is, how unnecessarily difficult it's become to accomplish basic tasks in "modern" software stacks, and how the bar to clear a job interview just doubled or tripled in height overnight, through no fault of their own. I don't have anything to offer them.

But if you're in tech and you find yourself gainfully employed, I might have something of interest to you.

Over the past year, I've asked a few technology leaders—each with years of experience hiring programmers and (more recent experience) laying off programmers—for their perspective on this. What do they look for in employees today? What traits do they see in the people they're most eager to retain? What patterns of behavior have they identified among the people they've let go and fired? Because I'm in the fortunate position of not having to waste time talking to people I don't want to, these are all people I like and respect.

Here's a summary of what they told me.

Three kinds of people they look for:

1. People who identify problems: so long as they also bring a solution. Problem identification is important, but it's easier than you'd think, and demonstrating enthusiasm for pointing out problems but no motivation for solving them is better known as complaining. Managers and executives have people bringing them problems all day, so they most value people they associate with taking problems off their plate. And by solution, I don't mean a finished product: it could be an informal proposal, a request for time to research a fix, or hell… even some ideas about root causes (so long as they don't come across like you're blaming someone)
2. People willing to get their hands dirty: I could not believe the degree to which business leaders felt like they had to use kids gloves to deal with highly compensated programmers throughout the 2010s. I lost track of how many times I was on a sales call in which a prospective client wanted to hire consultants because their top business priorities were seen as insufficiently glamorous by their full-time programmers. Likewise, I'm sort of shocked by how few programmers are willing to exert even an ounce of effort reframing work they don't want to do in a more positive light. Want to be seen as trustworthy and reliable? Start volunteering to pick up work management asks for that nobody else wants to do. And there's no need to suffer in silence: take some credit by making it clear you're willingly setting aside your personal desires in the interest of others
3. People who don't need support: basically, be good at your job. And if you were hired for a job that management regrets hiring people for (as is the case for a boatload of junior developer roles), figure out how to reach the next level of competency with minimal support from others. Look, there's no sugarcoating this: a huge number of programmers making six-figure salaries don't know how to program. I'm old enough to remember the outrage generated by this Jeff Atwood post in 2007 as well as a decade of discussion about how unhelpful this message is vis-à-vis imposter syndrome and DEI goals, but that doesn't change the fact that this is what technology leaders are prioritizing right now. More than ever, tech leaders would rather have a select few people they can trust to solve a problem without any handholding than teams full of people who require constant oversight

And three (extremely related) behaviors to avoid:

1. Performative misery: as discussed at the top, it's really hard for programmers to demonstrate individual productivity and harder still to find an organization that objectively evaluates programmer performance. Because measuring results is very hard, it is often substituted with measurements of exertion instead. Employers start tracking availability in Slack, physical office attendance, and hours worked. Employees start emphasizing how hard they're working, how exhausted they are, and how much of a slog they've been trudging through. The latter used to be highly effective (I used to do this myself!), but weariness over rampant COVID-era negativity has resulted in leaders seeing this sort of performative misery as a significant drag on morale and alignment. One VP of Engineering I spoke with this summer put it better than I could: "If you're constantly complaining about working long hours and have nothing of value to show for it, maybe you're wasting both of our time"
2. Self-centered demands: before the previous tech economy evaporated two years ago, programmers could write their own ticket. Not working on what you want? Not making as much as you want? Not given the title you want? Impatience was rational at the time! Back then, you could quit and find a job that would offer you all of these things. And when that job failed to deliver, you could respond to any of a dozen recruiter e-mails and find another. The market has cooled significantly since 2022, but many employees' impulse to reflexively protest every minor dissatisfaction apparently hasn't. When leadership is figuring out who should survive the next round of layoffs, having a long paper trail demonstrating frequent dissent over one's role, compensation, and duties is a way easier case to push through HR than a vague qualitative notion that a programmer isn't very good at programming—as a result, less-skilled team players often make the cut while highly-skilled detractors get tossed
3. Inclusion at all costs: the backlash is real. I'm a left-of-center guy, and I'm pretty sure all the people I spoke with are too, but it's clear that following the George Floyd protests in 2020, many of the loudest DEI advocates went so far that they ultimately engendered caution and skepticism among tech leaders who otherwise saw themselves as eager to change and improve. Later, the market downturn brought this issue to a head, just as it did with performance management and employee engagement. When forced to cut budgets, leaders trying to reduce discretionary spending and avoid layoffs report being met with uncompromising resistance to any question about the costs and benefits of ongoing corporate DEI initiatives (which, from the perspective of their proponents, surely felt like a conveniently-timed rug-pull). In 2020, it wasn't uncommon for DEI-related demands that were in direct opposition to an employer's business model to be tolerated, but here in 2024, leaders expect proposals to come with a clear business case (one that goes beyond linking to the same study they've seen a hundred times). Everyone I talked to is eager to find ways to improve with respect to DEI, but they were clearly frustrated with employees who, in their zeal, denied basic business realities or responded to fair questions with hostility

What should you do with all of this? Beats the hell out of me! All I know is that most people will only experience a handful of major inflection points over the course of their career, and it sure seems like we're in the middle of one right now. As no-strings-attached capital dries up and AI startups promise a future where businesses will be able to get by with fewer programmers, the balance of power between employees and employers has shifted for perhaps the first time since computer programming became something resembling a profession. (You could point to the dot-com bust or the 2008 financial crisis as similar moments, but those felt different—then, programmers were losing their jobs as a simple function of their employers' financial struggles. Today, tech stocks are single-handedly driving record market gains even while they're still laying people off.)

I don't think many tech workers were prepared for this, and that's entirely fair. But I'm more than a little concerned by how little I see people talking about how to best adjust to this new reality we find ourselves in. My advice is the same as ever: it's much easier to ask for someone's money when you can point to how it will make or save them even more money. And if you can't, don't take anything for granted.

Okay, bye!