unicolet.org

This bit from Sean Goedecke hurt a lot because of the guilt it triggers when I compare my teen years to my chidren's: True or not, my sense is that Millennials and later generations think that worrying about “selling out” is a sign that you had it too good. Consider the endless anecdotes of Boomers and GenX-ers living in a van surfing until their mid-thirties and then walking into a good office job because they had a firm handshake: they could afford to be authentic because they didn’t have to hustle.  ouch

In business, a cost center (e.g., IT, HR, Legal) is a team that does not directly generate revenue, regardless of how well it is perceived. Within that category, there can be teams that end up being seen as a low-value cost center. In this writing, I am intentionally conflating the two, and even push for the logic that a cost center team (from a business point of view) can be perceived as a profit center when it increases business efficiency. My explanation is that this shift into negative happens when these teams' output does not meet the required business outcomes. For example, a software team could be constantly merging code but never ship anything useful or shipping too late: output is high, business outcomes are low. ( Read this excellent paper for more details ). Any attempt on the team's part to disprove this negative perception with facts or hard numbers is doomed to fail unless it is about business outcomes. Depending on the organizational maturity, understanding how a...

The narrative around AI keeps bouncing from it's slop and it kills software engineering to it has allowed to clear 2 years of backlog in two weeks . I think both are true, and ultimately the difference is made by how AI is deployed by Leadership. So what's different? Durable Teams and Domain Context:  while AI makes individual implementation much cheaper and faster, high-judgment individuals and agents still hit limits when they lack deep domain context. Durable, high-ownership teams remain the fundamental building block of engineering. AI can accelerate the writing of code, but teams must still possess the proprietary context to know what should be built—and what production metrics or instrumentation are actually required. Structural Improvements Over Haphazard AI Adoption:  clearing a multi-year backlog isn't just a matter of telling engineers to use AI; it requires leadership to focus on structural improvements and clear architectural patterns. When teams use AI to migr...

I've long been convinced that AI focus needs to be balanced and look at the processes upstream of sw development. There's incredible potential to improve product and strategy work and very little evidence of any effort going into it. This isn't entirely OpenAI or Anthropic's fault. Product work requires crossing organizational boundaries, querying fragmented tooling, talking to people, and continuously defining and refining strategy. None of this context is readily structured for an AI model to consume; it remains siloed, undocumented, or locked inside people's heads. Melissa Perri talks about this (and other topics) in the latest episode of her Product Thinking podcast. The most interesting part is just 3 minutes into the episode (emphasis mine): [...] "Delivery of designs and code got very fast. Delivery of good decisions became the new bottleneck." Now, I don't think this bottleneck is new. It's exactly what I talk about in the build trap. Wh...

Readwise just launched global ghostreader (their AI integration) which allows you to chat with your library. So I though I'd give it a try and I have to say the interaction was genuinely useful, and in line with what I feel is Readwise true value: rediscovering things you already know. See below what it had to say: