Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Showing The Way

Showing The Way

While his material is worth reading for anyone in the software industry, Ryan Peterman’s work is especially valuable for mid-level developers looking to take that next step. The Tech Lead’s Playbook, for example, captured the responsibilities better than my own thoughts despite being half the length.

He jumped 3 levels in 3 years at Meta, which is an insanely-fast series of promotions. He knows what he’s talking about! That being said, I bet it took a decent amount of luck too, so don’t expect similar results even if you follow his advice perfectly.

Not An Option

Not An Option

A big oops happened this weekend, and it has me thinking about failure. It’s a topic I’ve talked about before, but there’s plenty more that can be said.

Common leadership advice is to avoid making failure out to be a bad thing. “Failure is good,” well meaning folks will say. They’re not completely wrong, but they’re not absolutely right either.

Failure can only be good in moderation. Of course repeated failure of the same kind is bad. Absolutely learn from mistakes so they’re not repeated. But continually making new kinds of failure isn’t great either. No endeavor, professional or personal, can sustain that.

Eventually there need to be successes to offset the setbacks. So I’m not keen on over-celebrating failures, or treating failure as something that ought not have consequences. Maybe in the case of this CrowdStrike fiasco no one deserves to take the blame? But I doubt it.

Easy Peasy

Easy Peasy

Can’t focus on an important bit of work? Stressed out? Need some time to think?

Take a walk outside.

An afternoon walk has become a regular part of my routine, as important as any other daily task. I can’t recommend the habit highly enough.

Jump The Line

Jump The Line

While it’s not an absolute guarantee, there are a few ways to get my attention when applying for an open role for which I’m responsible.

First, read the job description and the minimum requirements. If you don’t meet them but want to take a chance anyways, don’t shy away from where you fall short. Address any gaps head-on in your cover letter and how you can mitigate.

Speaking of a cover letter, you should absolutely write one. Yes, actual you, not an LLM. I value engineers who can communicate effectively, especially in writing, given the realities of remote work. This isn’t about nitpicking spelling or grammar (though in 2024 there’s little excuse for stumbles here, given the tooling available), nor is it about quantity. It’s about concisely communicating what you value in a job and what excites you about the role enough to apply.

When describing what you value, show don’t tell. I love to see an example of work you’re proud of in a cover letter, because the way you discuss what’s important really matters: are you enamored with technology as an end in itself, or do you value impact on a customer? And what kind of impact do you value?

Finally, be sure to follow the instructions in the application process. Employers may have specific reasons for their requests; deviation does you no favors. For example, RIPL asks for an email to a specific address that goes to a shared inbox. If you send your info directly to an individual it might be missed. And if you DM me in LinkedIn instead, well, I get a lot of DMs, so don’t expect a response.

Into The Flood

Into The Flood

A great example of “you don’t know until you know” is being responsible for hiring. It’s a non-trivial task, hard to get right, and absolutely essential to running a successful organization.

Look, I remember what it’s like to be on the other side of this equation. Reaching out to anyone who will listen. Sending your resume far and wide. Waiting. So much waiting. It sucks, no question about it.

But right now, with so many technical professionals on the job market, it’s been a little overwhelming to sort through all the interest in open roles, especially for an organization that’s not big enough for professional recruiters. I like to think I’m a pretty responsive guy, but it’s simply impossible to review and respond to every single email and LinkedIn message, let alone include personalized details about exactly why we made the decision we did.

I wish the above weren’t true, but it is. And I’m not willing to “solve” it by handing the reins over to AI. At least not yet, because hiring is not a formula. Like much else, it’s a human process, and in general, everyone is doing their best.

Straight Talk

Straight Talk

Much digital ink is spilled on LinkedIn pontificating about hiring processes, what recruiters and hiring managers should and shouldn’t do, etc. There’s some truth amongst the noise, but I get a good chuckle when perspectives are shared with no basis in either data or experience.

This is especially true of management advice. If you haven’t actually been a manager, your opinions on how to do it are worth less than a byte stored in S3 (i.e. not much). Go give it a try and let’s talk again, eh?

Even if you don’t see yourself in such a role long-term, I recommend everyone do a tour of duty as a people manager if they can. You’ll gain valuable insights into what it takes do the very human work of running a business.

The Struggle Is Real

The Struggle Is Real

This week I got into a friendly debate about developer onboarding in two different fora (the Rands Leadership Slack and an in-person CTO Lunches gathering). My hot take: technical onboarding documentation is at best over-rated, at worst counterproductive, and most organizations shouldn’t give it much thought.

Before you pick up stones, hear me out. My logic is based partly on experience, and partly on a theory. The experience is that writing detailed onboarding steps takes considerable time, usually from well-tenured developers whose attention is better spent elsewhere. Keeping said documentation up-to-date takes even more time and is nearly impossible to do with a fast moving product. And having half-baked or incorrect instructions is worse than nothing for a new team member. Putting in all this effort just to save a little bit of onboarding time doesn’t make sense. The juice isn’t worth the squeeze.

But there’s more. My theory is that having an onboarding process spelled out in painstaking details actually robs the newcomer of the chance to build muscle through struggle, shortcuts creative exploration of how things could be better, and sets an expectation that “getting up to speed” means following a mechanized set of steps instead of self-directed discovery of a codebase and getting to know fellow team-members and their institutional knowledge through asking excellent questions.

Sure, this might mean some initial frustration. That can be managed. And it might mean a new developer is slower to begin delivering value. But my hypothesis is that once they do, they’ll be better prepared to provide broader and deeper value in the long run.

And besides, it’s likely your system isn’t as complex as you think it is, and you should be looking for the kind of people that can do their own problem-solving. If it takes someone many days just to get an app running, you’ve got more serious problems. Which makes me think this could make for an interesting interview exercise: “Here’s our code repository. Get it running in a fresh environment.”

Confessional

Confessional

What they say: “I want to be respectful of your time.”

What they mean: “I’m tired of this conversation and want it to end.”

And by “they” I mean “me”.

One Day Closer

One Day Closer

My dad died ten years ago today. Hard to believe it’s been a decade, but time marches on no matter our feelings.

I’ve written about him before: how his early investment in a home computer forever altered the course of my future, how his prodding to my shy teenage self got me my first job (and a wealth of early life lessons), and how his constant encouragement became the bedrock of my sense of self.

But today I was reminded of something else he modeled: the value of just showing up. The man bent over backwards to be at every little league game, every band concert, every academic awards banquet, and so much more, usually with video camera in hand.

I’m not as good at it as he was, if I’m honest. But it’s an ideal I strive for, both personally and professionally. Do what you say you’ll do, be where you say you’ll be, pay attention, be engaged. There are no small things.

(Oh, and yes, I am wearing a Star Wars tie at my high school graduation, thanks for noticing!)

All Will Love Me And Despair

All Will Love Me And Despair

A joy of my life is hacking around on APIs so I can automate things that would otherwise be manual. I’ve done it with Ticketmaster, American Airlines, WordPress (i.e. this blog), the AWS Product API, a payment page, a bunch of internal Amazon tools, and now (I’m happy to say) Tableau.

Deep in the land of San Diego, in the fires of his MacBook, the Developer Jud forged a Python script, and into this script he poured his creativity, his manipulations, and his will to dominate all APIs.

One script to rule them all.

One by one, the free websites of the Internet fell to the power of the script. There were some who resisted… but the power of Chrome Dev Tools could not be undone.