When I was an IC engineer, I learned a lot by reading pull requests. Like, a lot a lot, probably more than any other single source. But PRs have changed dramatically over the last couple of years. What used to be lovely, well-crafted stories have devolved into an arms race of which LLM can write the most number of words about what the code is doing (which btw, the code already tells you).
The PRs of old were glorious teaching tools. I learned about tradeoffs and the long windy road to solutions. I learned how to apply prior art and previous experience. I learned about baking off different solutions. I learned about failures and how to deal with them. I learned about icebergs. I learned discipline. I learned tricks that seemed like magic. I learned storytelling, socializing, and how to make a case. I myself learned how to teach using them. And I learned about my coworkers and how much I appreciated them. In short, I developed my style. They helped shape me into the engineer and manager that I am today.
There is a real art to writing thoughtful PR descriptions and code comments, and I would love nothing more than to see this style of teaching make a comeback.
This is gonna sound old man and “back in my day” but I genuinely long for the days of brevity. I remember not that long ago when you’d read a post, doc, or pull request and it would be like a few sentences or paragraphs, and that would be that. You’d read it, understand it, talk to the person about it, and refine it, but it wouldn’t be a 30,000 word diatribe.
But there is an obvious and clear pattern now where folks are using LLMs to write basically everything, and all those artifacts are at least 10x longer than they need to be. Nobody needs 5 pages of context on a single todo. Nobody needs a pull request description that describes everything the code already says.
On the surface it looks impressive the first 10 times you’ve seen it, but after that you know you’re not going to read any of it ever again. You might end up feeding it through an LLM to summarize the unreadably long post, and now you’re just in an LLM-driven endless flat circle.
Writing with brevity and clarity is an art, and I genuinely applaud everyone who does it well, regularly, and without an LLM. Truly, thank you.
Literally anyone can use AI to blindly make a thing. What will differentiate you is how you demonstrate an ability to use it critically. It’s a tool, and just like any other tool it’s going to be good at some things and fail miserably at others. Your ability to understand, socialize, and operationalize all of that, together, is worth so much more to a team than some bro who can slap together yet another slop dashboard.
I like the premise that engineers are “lazy”, understanding that it’s very much a virtue and compliment when used appropriately. From Bryan Cantrill’s “The peril of laziness lost”:
We undertake the hard intellectual work of developing these abstractions in part because we are optimizing the hypothetical time of our future selves, even if at the expense of our current one. When we get this calculus right, it is glorious, as the abstraction serves not just ourselves, but all who come after us. That is, our laziness serves to make software easier to write, and systems easier to compose — to allow more people to write more of it.
The problem is of course the ever-present misguided brogrammer, especially in the age of AI, who confuses virtuous laziness with mass shitting out of code. Prime example: Gary Tan stupidly bragging about how many lines of code he generated. Predictably, none of what he generated makes any sense or is by any definition good:
Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s “newsletter-blog-thingy” included multiple test harnesses (!), the Hello World Rails app (?!), a stowaway text editor, and then eight different variants of the same logo — one of which with zero bytes.
I sent this out last Friday, and now after a week has passed where I was AI-ing a lot, it feels even truer. I cannot stress enough how important it is to regularly (or entirely?) unplug from the robots and find hands-on, creative work to lean into. I’m pretty certain you’ll find a level of satisfaction and joy that you may not consciously realize you’ve been missing.
I’ve spent the entire day so far OUTSIDE of Claude, haven’t opened it once. Wasn’t intentional, it just turned out that the work I was doing didn’t need an assistant, and I happened to hit a good flow. I ended up slowing down, reading more carefully, and prioritizing my todos for the day to what I could realistically get done vs. piling on like 7 things in the background. And I gotta say it’s been lovely. I would argue it’s been one of the best feeling, productive mornings I’ve had in a while.
That’s not to discount the real wins that AI can bring (including a lot of help I got from it this week), but more that hey, maybe it’s OK, even good, to step away from the assistant here and there. I know it’s hard (impossible?) to accept or validate subjective measures like “feeling good” in work when objective measures (how much you did/shipped) are so prevalent, so I guess I just wanted to say there’s real value in feeling good in your work beyond shipping.
I fully acknowledge that not everyone has this luxury, whether it’s your job function, expectations, or customer pressures. Engineers in particular, so much of your work relies on those agents, so stepping away from them probably seems unrealistic. I just wanted to say out loud that it might be worth trying to find some space here and there, especially if you’re feeling fried at the end of a long week.
This is wildly helpful yet hadn’t heard about it til now. Can finally have FileVault enabled and still remotely login to a Mac if it reboots. Previously you had to either be at the physical machine or keep FileVault off to get back in.
I don’t know what is says about me and/or the state of tech in general but I absolutely LOVE, LOVE, LOVE plaintextsports.com. An absolute thing of beauty in its simplicity and function.
Along with some broader points about responsible AI usage, Fastmail CEO Bron Gondwana reminds us how important email is. In an age where anything and everything can change (or be hallucinated), having your own copy of history is even more important:
In a world where there’s enough AI capability to process the entire web and rewrite every page to remove something, the cost of “changing history” is much reduced, so we can expect more of it.
This is where the immutability of email really shines. An email is your copy, and the sender can’t revise it later. This is frustrating when you’ve sent the wrong thing and have to send a separate correction later, but in the long term it’s insanely valuable.
It makes a huge difference to be able to go back and double-check your memory against an email you saw years ago and know that if they disagree, the email is correct. This is already not the case with web pages — they change, and it’s only becoming worse.
Worth a reminder: everyone you work with is going through something outside of work. They might be dealing with tricky relationships (kids, parents, partner, friends), health concerns, financial pressures, emotional distress or grief, or like a hundred other possible stressors. A little grace and humility can go a long way in helping your coworkers have an OK day at work, and as a result make things a little better for them at home. 💙
Trust me, when someone signs up for your service, nobody wants 50 emails in the first week explaining all the amazing things it does. Like one email every couple weeks, fine, but blasting people every day of the week with your app is just annoying. If your product works well and does what it says, I assure you we’ll come back and use it.
Please never change Dropbox, you’re still BY FAR the best at file sync and file management. Every other service (iCloud, Google Drive, OneDrive) is either bad at the actual job of syncing or is littered with a bunch of cruft nobody wants or asked for. Doing one thing well is so underrated. 🏆🔄
It’s well known that multitasking is a myth and that constantly jumping around wastes more time than it saves, but now we’re supposed to “orchestrate” like 17 different agents at once and expect amazing outcomes? Sure.
When I block an AI hype bro on LinkedIn (“I’ll teach you how to 10x your engineers with AI!”) it says they won’t notify the person that I blocked them. But really I want the opposite – give me an option to definitely let them know I blocked their dumb posts from my timeline forever.
Good one by Nathaniel Fishel on hype bros locking in on AI vanity metrics:
The winners will be the ones with the discipline to measure what matters: Does the user’s life get better, or did we just make our repo bigger?
I’m still pretty new at my current gig and it’s reminded me that the hardest thing to figure out in any new role, especially as a manager, is knowing out how much to get involved, what to change, what to keep, and maybe most importantly when to just stay out of the way.
The last part is the toughest. Maybe if you’re joining a wildly dysfunctional team it’d be easy to justify moving all the cheese, but in a lot of cases you’re probably jumping into something semi-functional. But at the same time they didn’t hire you just to be a layer on top of a perfectly well-oiled machine. Reading between the lines and deciding when to jump in and when to let the team keep rolling is hard!
Let’s also acknowledge that since you’ve just been hired, your ego/fears are on full blast, sitting on your shoulders and telling you that you have to show “value”. But that’s the trick isn’t it, because in your first few months the very thin line between doing things and doing actually valuable things is quite hard to see. You could go the nuclear version and just do all the things and hope that you’ve got it right, but that can backfire badly.
All that to say, I’ve been doing this EM thing for a while now and I’m still like maybe 60% sure that I’m kinda sorta doing it right. There are a wild number of variables at play — company culture, the work itself, industry upheavals, humans and their personalities, your own baggage, and about 10,000 other subtleties to figure out.
So if you’re transitioning into a new role, just know that we see you and recognize it’s hard. In an ideal scenario you have really lovely, supportive teammates who help you figure it out day to day. But also talk to your peers, lean on your manager, and actively collect feedback from the folks you work with. That’s about the best “strategy” that I’ve come up with to date.
It must be so annoying to be on the other end of a partner who’s stuck in the AI hype bubble. That dude who finishes a day of work and then all weekend drones on and on about AI to their families about how it’s changing the world and how they should be using it for everything. Must be insufferable.
Say it with me for the people in the back (aka, those stuck in the AI slop hype bubble): WRITING CODE HAS NEVER BEEN THE BOTTLENECK.
It’s such an odd but kinda fun feeling to be the old, grizzled, experienced dude in the room. By virtue of sheer volume and having seen some truly brain-meltingly-stupid stuff, seems like the best thing I can do is to share my lived experiences and perspectives so we can hopefully avoid making the same mistakes for the 10th time (see terrible tech bros doing terrible tech bro stuff).
So when you see me going on and on about some specific theme (layoffs, AI slop, hype bubbles of late), it’s very likely a flashback to a story line that ends badly that I’ve seen before and we probably want to avoid doing again.
Transitioning from being the young, rage-filled, justice-seeking guy to the old, rage-filled, justice-seeking guy really creeps up on you!
It’s like, cool to listen to Weezer again?! Yes, I’ve been here for 30 years. =w= 🤓🤘
I’m not a doomsdayer but there’s something very cool about someone taking the time to package up terabytes of human knowledge in case an internet disabled apocalypse hits, and wrap it up nicely in an open source app. Love weird projects like this.
This entire post about when and how to slow down in the age of AI by James Stanier is full of great stuff, including this:
If the decisions that precede execution are flawed, AI will faithfully implement those flaws in a way that looks like fully featured code. Looks can often be deceiving, especially with powerful and confident models. It will generate thousands of lines of code based on a misunderstood requirement. It will happily build an elegant solution to the wrong problem.
The illusion of speed is that you’re making progress when you’re actually digging yourself into a deeper hole.
The answer isn’t to abandon speed, but to deploy it deliberately. We should only unleash AI’s pace when we’re confident it’s pointed in the right direction.
And this:
Given that AI is speeding things up so much, if you haven’t already been challenged on why something’s taking so long, you certainly will be soon.
“Can’t you just use AI?” is a new form of velocity pressure, and it’s particularly insidious because it conflates the appearance of productivity with actual throughput. Yes, AI can generate code in seconds. But generating code and solving the right problem are not the same thing.
I’m pragmatic and a tech nerd, so I’m not gonna sit here and say I don’t use AI tools. I’ve seen it do some wildly cool, useful things. But I’ve also seen it fail miserably just as often, if not more.
The very bright line I won’t cross though is to blindly accept AI with no regard for human impact. It’s regularly being used as excuse for layoffs, accepting fast work over good work (and thereby causing long term fatigue), creating unrealistic/unfair expectations for job performance, and generally just devaluing the human parts of everything it touches.
AI can be a useful tool, but just like any tool, used improperly it can cause some serious damage. And if you take a hard look at the AI hype train, there’s an awful lot of that going on right now.
An astute observation from M.G. Siegler on AI’s notable lack of taste, especially with something as complex as personal travel preferences:
From here we quickly enter a maze of a hundred little preferences that are altered by thousands of real-world variables. If the powers that be thought the game of Go was a good, complex task to prove out AI, wait until it gets a load of trying to book travel for a family with children.
For all these stories about AI creating 500,000 lines of code and 90% of an app in 10 minutes, where are the follow up posts about the meaningful, measurable outcomes it created?
Like what actual business problem was solved? How well did it integrate with your existing product and strategy? How many new paying customers did you land because of it? What profit did it generate? What was the customer support experience for it like? Did customers actually like it? Did customers actually use it? How did it materially impact your business or revenue? How maintainable was the code base over time? 🦗
