Bad ideas that aren't bad anymore

I’ve been working in software for about 15 years now, and over that time I’ve made a lot of mistakes and learned from a lot of other people’s mistakes. This experience is a deep well that I can draw from when discussing possible solutions for both technical and non-technical problems. This is how I know what sorts of solutions sound good in theory but run into problems in practice, or what fringe idea is actually a perfect fit for the problem we’re trying to solve here. This knowledge & experience is a big part of what has made me effective as a leader. Lately, though, a lot of the things my gut tells me are bad ideas are turning out to work really well. In our team’s retro this week that hit me pretty hard, and it was a real learning moment for me. It made me realize that a big chunk of the intuition I’ve been relying on might not be worth as much as I thought anymore, and that I need to question that experience more frequently. So I wanted to write down a few of the “bad ideas” that we’re doing right now that are actually working really well, and then to try and figure out what that means for people like me. Nobody reviews anybody else’s PRs For pretty much my whole career, code review has worked the same way: one person writes the code and opens the PR, and then somebody else on the team reviews it before it gets merged. The second set of eyes catches bugs, spreads knowledge around the team, and keeps any one person from quietly drifting the codebase off in their own direction. Merging your own PR without review was one of those things that was a “break glass in case of emergency” kind of situation. About a month ago we changed that completely. We had been struggling with code review due to the increased pace of PRs being opened, and so we decided to try something crazy - just not doing it. Now the engineer working on a ticket works with Claude, which then opens the PR, and then the human working on the ticket reviews Claude’s work. Once CI is green & the Greptile review is clean, if the human working on the ticket feels confident that the solution is solid, they merge the PR. That’s it. No waiting on a teammate to find time to context switch into your change, no pinging people in Slack to please take a look. And it’s been working great! When I actually think about why it works, it’s because the thing that code review was protecting against is still being protected against. There’s still a second set of eyes on every change - it’s just that the author is Claude and the reviewer is the human who owns the ticket. That human understands the problem better than anyone else on the team, because they’re the one who’s been working on it. They’re a much better reviewer for that change than a teammate who has to page in all the context from scratch. But also, Claude & Greptile are just better at finding the kinds of things that are often found in Code Review, like small bugs or inconsistencies. It’s pretty rare (at least on the teams I’ve worked on) for big things like architectural flaws or unintended product impact to be found at this stage. I’ve written before about how review gates can be a sign of a lack of trust, so maybe I shouldn’t have been so surprised that removing one worked out. But my gut still said “you can’t just merge stuff without somebody else looking at it,” and my gut was wrong. At least so far that’s been true - we’re only one month into the change, but it’s feeling really good so far. Splitting the team up across separate streams of work This is the one that came up in our retro. Recently we had a few people out on holiday, and at the same time we had a couple of parallel and fairly separate streams of work going on. So we split it up, and basically each person owned one stream of work and ran with it. Historically I really haven’t liked doing this. When everybody on a team is working on a different thing, you get knowledge silos. Only one person knows how the thing they built works, and if they leave or get sick or go on holiday, the team is stuck. Even worse, I think it erodes the feeling of actually being a team . You’re not working together to solve the same problem anymore, you’re just a group of people solving different problems at the same time who happen to share a standup. I’ve pushed back on this kind of setup on basically every team I’ve led. But in the retro, we talked about it, and we’re just not seeing any of the consequences I was worried about - at least not in terms of knowledge silos. And the reason is that it’s become so easy to get up to speed on someone else’s work. If I need to jump into something a colleague has been working on, I can say to Claude “hey, bring me up to speed on this thing they’ve been building - how does it work, where is it at, and what still needs to be done?” A few minutes later I have what I need to start contributing. I don’t need anybody else to onboard me, and I don’t need to spend a day reading through code to figure out what’s going on. The thing that’s really changed here is that the cost of context switching has dropped dramatically, because we’re operating a level higher than we used to. I don’t really need to context switch into the specific code and how it works (or at least not that much to get started). What I do need to context switch into is the problem. As long as I have a conceptual understanding of the problem that we’re trying to solve, and roughly the shape of the solution we’re going for, I can jump in and be useful. Will there be some long-term consequences of working this way that we haven’t seen yet? Maybe! I’m honestly not sure. But “maybe there’s a problem we haven’t seen yet” is a very different argument than the one I’d have made a year ago, which was “I’m pretty sure this is a bad idea and we’ll regret it.” Don’t go deep This one is less about how my team works and more about the advice I give to the people I manage. For a long time, my standard advice for engineers on their technical and professional development was the classic “T-shaped” thing. First you build up a solid base of general engineering practices, and then you pick one or two areas and go really deep on them. Become the performance person, or the accessibility person, or the distributed systems person. Or pick a widely used framework and become the expert in it - become a regular contributor to Rails or Phoenix and know all the ins and outs of how it works. That kind of deep expertise used to be one of the most reliable ways to make yourself really valuable. Now I’m telling people pretty much the opposite. Deep expertise in a specific technology is a lot less valuable when you have a collaborator that has read all of the source code for that framework and can answer any question about it in a few seconds. This is another case (like what I mentioned above) where knowledge is less valuable, but where judgement is still important. What I’m recommending instead is to still build a very strong foundation in engineering fundamentals, because that’s where I think we as humans offer the most value right now. That’s things like how to architect code, how to design good abstractions, and how to tell when an abstraction isn’t really fitting anymore. It’s being able to look at something and say “this is starting to get a little weak, and we should break it up,” and then come up with what the right abstraction should actually be. It’s noticing that “it seems like we’re missing something here that needs a name,” and being able to find that concept and name it. That’s the stuff that keeps the high-level architecture, the domain modeling and the data modeling at a high level of quality, and that’s where a good engineer really earns their keep these days. But I’m also telling them that being great at the tech is now only one small part of the job. Being great at the tech is no longer enough. You need to learn m