[throwaway713]

> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).

Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively request your report to go back and make changes. This is a great way to lose employees.

[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!"

[hinkley]

There are worse outcomes than that. Software devs are clever people. Not all of us can be confrontational, and confrontation is not the only tool available to those who can.

If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them.

They’re letting you choke to death on your own arrogance and control issues.

[ninetyninenine]

Software devs also all think they're smart and they talk that way and take pride in it. The reality is many software devs are dumb af.

[hinkley]

We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average.

It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both.

But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that.

[marcosdumay]

> You can blame Taylor for that.

No, you can't. Taylor was a huge advocate for standardizing people's work so it could be studied and improved. He was also an advocate for well-studied people to go and teach workers how to do their jobs, and a not intense advocate for thinking ill of workers based on everything you can expect from a rich 19 century guy.

What he advocate a lot against was doing power games against workers or automatically dismissing everything they say.

[hinkley]

Standardizing people’s work turned them into automatons to be studied and improved by a management elite.

Which all came crashing down when Deming had to go to Japan to get people to listen to his ideas and triggered a massive recession in the US.

Deming and (to a lesser extent) Goldratt pull the employees back into the conversation. Tether are closest to the problem and even if they can’t solve it, they can help you shape the answer. Taylor was neofeudalism and he can rot.

[marcosdumay]

The one thing people are complaining upthread is not Taylor's fault. He actively fought against it.

The stuff you are complaining on the first line is. But also, Taylor was an advocate for listening what the workers had to say too. You can't really blame Taylorism on him, he invented only the mildest parts of it.

And that said, Deming advocated standardizing work too. You just can't run a factory without doing that.

[appreciatorBus]

Developers may be hired for cleverness, but cleverness in code and technical matters does not necessarily carry over into cleverness with respect to office politics or good management.

[InexSquirrel]

Hired for ultimately a fairly narrow field of expertise. But do need support in the sense of building the right thing, ensuring that thing aligns with business objectives, that constraints and requirements and customer needs have been communicated.

So in that light - either you give engineers the support they need (which can be quite a lot, more than I think most care to admit), or accept they're going to get a lot of stuff wrong. Probably technically correct and good, but still wrong.

[hinkley]

Management often spends less time with the users than we do.

[ninetyninenine]

Cleverness in code actually correlates with cleverness in social aspects. People come up with this artificial dichotomy of the awkward nerd with high iq but zero social skill but the reality is both of the two correlate slightly.

At the very least we know there isn’t an inverse correlation meaning the stereotype isn’t really true.

[ninetyninenine]

It’s not clever to brag about how smart you are or imply you and your entire cohort are smarter than other occupations. It’s a sign of how much you are the opposite of clever.

Additionally the average IQ of software developers is measured to be 110-113. That’s barely above one std of the average so you’re actually wrong. Software devs aren’t particularly clever but a disproportionate number likes to think they are smarter than normal.

So bragging about something that you’re completely wrong about… is that clever? No.

[ahdidhd]

While I mostly agree with your original post (egos in this field are huge), it’s hard to interpret that IQ stat without more data. Kinda low IQ to present it like that without additional info cause it’s impossible to really evaluate.

[ninetyninenine]

Only because while you don’t brag about it you truly do believe you’re smarter. It’s not even about acting humble. The ego is real because despite me saying software engineers have roughly above average intelligence you couldn’t take it.

https://brght.org/iq/study/software-engineering/

[tptacek]

I'll ask you too, given your 110-113 stat: when was the cross-sectional survey of IQ that would be required to generate this stat been done?

[tonyedgecombe]

Meanwhile the average IQ of computer science graduates is 130. Draw what conclusion you want from that.

[tptacek]

This stat seems far-fetched. When has a cross-sectional IQ survey of CS graduates ever been taken?

[ninetyninenine]

Did you deep dive into this? Given the amount of downvotes I have I’m sure you weren’t the only one if you did.

About 30 percent of developers have no degree. Which means… if the average graduate of CS is 130, how low does the average swe without it a degree have to be in order to bring it down to 110?

I mean I spelled out the math. Dear readers, Draw what conclusion you want from that while asking yourself: “Do I have a degree?”

I will say that iq varies heavily across schools as well.

[binary132]

“trust nobody, not even yourself” applies here for sure.

[petralithic]

Exactly, these two sentences seem at first related,

> No deadlines, minimal coordination, and no managers telling you what to do.

> In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself.

but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.

[wordpad]

I think if you are empowered to make decisions as an employee it's YOUR responsibility to know the limitations of your scope and when to seek feedback and approvals from architecture, management, business or whoever.

So if your decisions are getting turned over, you are either making decisions outside of your scope or your management is genuinely micromanaging you.

[kykat]

At my previous job, "what about..." slowly became a trigger word for me

EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework

[hinkley]

    The four worst words on a software project are:
    “Why can’t you just…”

[fullofideas]

Closely followed by “This should be an easy lift”

[neilv]

"Delivering this feature goes against everything I know to be right and true. And I will sooner lay you into this barren earth, than entertain your folly for a moment longer."

-- Krazam, "Microservices", https://www.youtube.com/watch?v=y8OnoxKotPQ

[Aperocky]

I mutter this a lot. Except when I do 95% of the time I perform the easy lift right after.

[rdtsc]

That’s the only way I would utter it — if I can then sit down and so do it. If I am asking someone else to do I would ask them to tell me how hard it would be and if they need help or if they suggest a different approach.

[marcusb]

I once worked at a place where one of the partners consistently claimed the engineering team over-built and over-thought everything (reality: almost everything was under-engineered and hanging on by a thread.)

His catch phrase was "all you gotta do is [insert dumb idea here.]"

It was anxiety inducing for a while, then it turned into a big joke amongst the engineering staff, where we would compete to come up with the most ridiculous "all you gotta do is ..." idea.

[0x457]

Have WE tried using caching?

[theideaofcoffee]

Similar to my experience doing low-level systems work, being prodded by a "manager" with a fifth of my experience. No, I'm not going to implement something you heard about from a candidate in an interview, an individual whom we passed on within the first 30 minutes. No, you reading out the AI overview of a google search to me for a problem that I've thought about for days ain't gonna work, nor will it get us closer to a solution. Get the fuck out of the way.

"Can't we just..."

[CBLT]

I'm there right now at my current job. It's always the same engineer, and they always get a pass because (for some reason) they don't have to do design reviews for anything they do, but they go concern-troll everyone else's designs.

Last week, after 3 near-misses that would have brought down our service for hours if not days from a corner this engineer cut, I chaired a meeting to decide how we were going to improve this particular component. This engineer got invited, and spent thr entire allocated meeting time spreading FUD about all the options we gathered. Management decided on inaction.

[asa400]

People think management sucks at hiring good talent (which is sometimes true, but I have worked with some truly incredible people), but one of the most consistent and costly mistakes I’ve observed over my career has been management's poor ability to identify and fire nuisance employees.

I don’t mean people who “aren't rockstars” or people for whom some things take too long, or people who get things wrong occasionally (we all do).

I mean people who, like you describe, systemically undermine the rest of the team’s work.

I’ve been on teams where a single person managed to derail an entire team’s delivery for the better part of a year, despite the rest of the team screaming at management that this person was taking huge shortcuts, trying to undermine other people’s designs in bad faith, bypassing agreed-upon practices and rules and then lying about it, pushing stuff to production without understanding it, etc.

Management continued to deflect and defer until the team lead and another senior engineer ragequit over management’s inaction and we missed multiple deadlines at which point they started to realize we weren’t just making this up for fun.

[tossandthrow]

"it's your call" does not mean there are no requirements.

On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing.

If a manager, denotationally, can call out that there is something missing, then it was not implemented right.

[enraged_camel]

“It’s your call” specifically means all the decisions on the table are valid and fit the requirements and the employee is being granted permission to make a judgment call. Questioning that judgment call afterwards is shitty and leads to an erosion of trust because the employee will thereon second guess themselves and also try to avoid making any decisions (because they expect them to be overridden).

[jsiepkes]

> and fit the requirements

And that is where the friction is. A lot of these requirements are implicit.

For example; If an application is built around Protobuf / gRPC and you suddenly start doing JSON / REST you are going to need a really, really good reason for that. Since you are introducing a new technology, with all it's glory and all it's horror. So your judgment is going to be questioned on that and most likely the reaction will be; We are not going to do that.

[6510]

If you know they are going to be like that you could try getting the information out of them as early as possible. Ask a bit to much about every detail, find the point where it annoys them then try not to cross it. When you inevitably do remind him of the previous rewrites and the time it consumed. It is our job to perfect this system. It gets considerably harder to request changes after you've asked not to be bothered with every detail.

That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.

[jstummbillig]

> This is a great way to lose employees.

A great way, you say. Taking notes!

[dragonwriter]

I'm not sure that's a corollary, it seems to have tension with "Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process."

Though I guess it is in tune with "no managers telling you what to do."

[nojs]

If you don’t collaborate before it’s shipped and don’t retroactively review after it’s shipped, how do you provide input?

[kevmo314]

You iterate on what’s shipped. It’s not a one-and-done kind of deal.

[dragonwriter]

Iterating on what has shipped inherently involves review of what has shipped.

[bfkwlfkjf]

I just gave this feedback to my boss today

[ergocoder]

The equivalent of "I told you so". Yeah, you should never do that in any situation.