[tombert]

One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.

[Arubis]

"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)

[AceJohnny2]

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")

[JKCalhoun]

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.)

[tombert]

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.

[867-5309]

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

[qwertytyyuu]

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

[rightbyte]

It only works versus good managers.

[IshKebab]

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.

[tombert]

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.

[scottlamb]

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.

[dfee]

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.

[scottlamb]

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.

[oumua_don17]

Any chance you were in one of that infamous orgs?

[tombert]

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.

[wink]

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