"Second-guessing works by forcing someone to reverse acts of destruction. If I delegate a decision to you, you quickly spin up a set of relevant mental models, work to get a lot of momentum into them, pay the cost of killing many possible worlds, and experience the relief of a lightened load to carry. Then, by second guessing, I suddenly demand that you resurrect dead models, so I can validate or override your decision. Next time, you won’t put so much momentum in to begin with." (Venkatesh Rao, Tempo: timing, tactics and strategy in narrative-driven decision-making)

One of the many reasons I'm still at Apple. My manager honors my decisions (sometimes, let's be honest, with gritted teeth).

("People don't leave jobs, they leave managers")

Yep. There are many, many teams at Apple. Your manager makes all the difference in the world. Hated working on the Photos team at Apple, loved all the other teams I worked on. (So I left the Photos team to go work on a team where the manager was cool. I was able to stay at Apple, just move about.)

I don't dispute that. I wish I had been on a better team. My team had a famously high turnover rate, so it wasn't just me. I liked my direct manager just fine, he's a decent dude, but I thought his manager, who I had to deal with a lot, was kind of a dumbass and I did not enjoy working with him at all.

I tried joining other teams but without going into elaborate detail it didn't pan out.

one tactic is forming a group which bullies a manager out of their job. it's depressingly effective and rife within the professional public sector

I'm in public service, teach me you ways XD

It only works versus good managers.

I normally move within a company when I want to quit a manager. It's much easier than getting an entirely new job usually. And you have a lot more information about the potential role.

It's also a good way to get into areas you have no experience of.

I tried that, multiple times actually. My options were already pretty limited because I didn't want to move to California, and without going into elaborate detail I the interviews for other teams just didn't work out.

Yuck.

The attitude I like to have is that the author can choose to do the design (doc + approval, or live discussion, some kind of buy in) first or go straight to the PR.

If the design is agreed on first, reviewers would need a really good reason to make the author go back and rethink the design—it happens, sometimes a whole team misses something, but it should be very rare. Usually, there's just implementation things, and ones that are objective improvements or optional. (For project style preferences, there should be a guide to avoid surprises.)

If the author goes straight to a PR, it's an experiment, so they should be willing to throw it away if someone says "did you think about this completely different design (that might be simpler/more robust/whatever)".

This is not the approach suggested by this article, and I'm okay with that. I tend to work on high reliability infrastructure, so quality over velocity, within reason.

I like this - and I think it’s a natural reality. When trust is low (for many reasons, including joining a new team), it may reduce risk to start with a design doc.

There are a lot of reasons anyway I like to have the design doc around. A few:

* I think the designs are often better when people write down their goals, non-goals, assumptions, and alternatives rather than just writing code.

* Reading previous designs helps new people (or even LLMs I guess) understand the system and team design philosophy.

* It helps everyone evaluate if the design still makes sense after goals change.

* It helps explain to upper management (or promotion committee in a large company) the work the author is doing. They're not gonna dig into the code!

...so it's usually worth writing up even if not as a stage before implementation starts. It can be a quick thing. If people start using a LLM for the writing, your format is too heavy-weight or focused on style over substance.

There's definitely a negative side to approval stages before shipping, as this article points out, but when quality (reliability, privacy/security, ...) is the system's most important attribute, I can't justify having zero. And while getting the design approved before starting implementation isn't necessary, it should avoid the bad experience tombert had of having to redo everything.

Any chance you were in one of that infamous orgs?

Yeah, my org had a pretty high turnover rate. I didn't enjoy it, I wish my transfer had gone through because I suspect I would have enjoyed the team I was applying for considerably more. Not how it worked out though, and after a certain point I couldn't take it anymore.

"Just decide for yourself and be self-reliant... no, not like that!"