Head nodding my way through this entire post. I was a little skeptical going into it because, well, Google, but the lessons are pretty universal. Worth a read.
Engineering manager, Kotlin enthusiast, speaker, and dad. Writing about tech, work, and life.
Because people who work in tech still believe in the power of tech to do good things, many of us won’t just dismiss outright the possibility that any technology — even AI tools like LLMs — could yield some benefits. But the optimistic takes are tempered by the first-hand knowledge of how the tools are being used as an excuse to sideline or victimize good people.
Anil is on an absolute tear with his writing. 🔥
Anil Dash speaks the truth. A bunch of folks have gone out of their way to help me with my job hunt and I really will remember all of them. Can only hope I’ll be able to pay it forward in the future.
The values section of Jake Wharton’s hire me page is the best thing I’ve read in years. Clear, honest, principled, and ethical. Tech would be a much better place with more of this and more people like Jake.
You can follow Jake on Mastodon or on his site.
Back to Hugo + Cloudflare Pages for my personal site. Realized how important pure text themes, flexibility, and Markdown were over Ghost’s editor, media embeds, and newsletters/network. Ultimately found the editor slowed me down and the themes were too media heavy/glossy for me.
And though I’ve always found the fiddly parts of programming the most calming, and the most essential, I’m not especially good at them. I’ve failed many classic coding interview tests of the kind you find at Big Tech companies. The thing I’m relatively good at is knowing what’s worth building, what users like, how to communicate both technically and humanely. A friend of mine has called this A.I. moment “the revenge of the so-so programmer.” As coding per se begins to matter less, maybe softer skills will shine.
The whole (long) article about AI and coding from James Somers is excellent, but this point specifically was highly relatable. I am the literal embodiment of the so-so programmer. 😅
One of the most counter-intuitive phenomena in trust repair is where initial success in building trust leads to a short-term surge in reported ‘negative metrics’.
When institutions successfully remove this barrier by demonstrating responsiveness and competence, citizens are suddenly incentivised to report issues, believing the effort is worthwhile. This resulting spike in reported complaints or low-level ASB is not a sign of rising disorder, but the successful conversion of latent, unreported incidents into official, actionable data.
This is an excellent exploration on how to both enact change AND how to interpret its signals. So much good stuff here.
Senior engineers look at the big, messy, abstract thing and start digging:
- They ask questions nobody else thought to ask.
- They separate what matters from noise.
- They identify what should be done now vs. what to punt.
And you know what’s funny? When senior engineers do this well, it looks easy. Like nothing was even done. The project just… goes smoothly. Fewer surprises, production fires, or emergency meetings. But what actually happened was that someone did a lot of invisible work upfront.
Absolutely perfect, spot-on analysis.
This post by Molly Graham is excellent. I’ve never really liked the blindly-follow vibe of “disagree and commit”. The original intent was to enable decision making and drive alignment, and while that’s noble, enough bad actors have abused it to the point that It’s become a buzzword excuse they can use to justify squashing discussion and getting their way. I’ve definitely seen it happen.
Molly’s take is much smarter, far more nuanced, and as a leader, far more achievable. You don’t have to feel like you’re selling something you don’t believe in, but rather can acknowledge that the team is making an educated guess that will be assessed and reviewed afterwards. That builds trust, helps everyone learn, and is much easier to get behind. So, so much better. 👏
Kind of shocking to me that the majority of job postings still list number of years as a requirement.
First and most importantly, this shows an (unintentional?) implicit bias against underrepresented groups, cutting out those with non-linear career paths and those who have faced systematic barriers (women, people of color, minorities). Diversity is so critical for a team’s overall success, as any good product should have representation of its customer base.
Secondly, years of experience is in no way a proxy for competence. Some of the very best people I’ve worked with had a year of experience, and some of the biggest duds were people with dozens of years of experience. Smarts, ambition, and attitude are what matter, not years.
When in doubt, share your professional failures. If you’ve had any level of success in your career, sharing failures shows there’s room for growth for everyone at all levels. Nobody’s perfect and we all struggle at times, so people appreciate and connect with those kinds of experiences far more than some glossy accomplishment.
So share your tough moments and your missteps. Be honest and transparent. It might be hard to do and maybe even a little embarrassing, but that little bit of selflessness is an excellent way to teach and help grow others.
