Live data from Hacker News

Collaboration sucks

newsletter.posthog.com

251–260 of 262 posts

Re: Collaboration sucks

#251

Earlier quoted context omitted.

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…

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.

I can’t blame Taylorism on Taylor?

Collaboration is between peers. Taylor was top-down. That’s dictatorial, not collaboration. When you take collab out of the mix it’s a product manager and one dev and that’s a power imbalance.

Re: Collaboration sucks

#252

Earlier quoted context omitted.

Where I work the formatter is the final arbiter of formatting code. If you don't like it, good luck justifying a change and you had better have really thought about it and why your change is good, because thousands of engineers have tried and been defeated for one reason or another :)

> Where I work the formatter is the final arbiter of formatting code. And I'm fine with that. Consistency is key for readability, code is read more than written, legacy code is code that people can't read anymore and want to start again, and most of the changes people want to make aren't standard making it harder for new team members to read the code. Install Black, Prettier, Spotless, and move on.

I like it too. It is reliable, predictable. Removes a common source of opinionated friction.

Re: Collaboration sucks

#253
post #213

Earlier quoted context omitted.

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 thing…

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.

Re: Collaboration sucks

#254

This is simply an awful thought piece and is wrongheaded. The problem is not collaboration nor feedback. It is the lack of a decider. Deciding by committee is a bad way to run as an org grows. Collaboration is still key. One person needs to be the person who decides. Decides what? That is the trick. The further down you push decision making, the faster things go. But someone is the decider, not a group.

Yes, dictatorship works amazingly when you have a benevolent dictator...

The problem is that deciders are almost always picked for their ability to kiss management's ass as opposed to their technical savvy.

I would agree with you if companies started embracing workplace democracy and electing the decision makers.

Re: Collaboration sucks

#255
post #96
post #50

Earlier quoted context omitted.

This is the key insight for me about this post, and I fully agree with you. No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth. Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all releva…

> if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down. I kind of agree. Without what you describe, teams often get lost. But I’ve also seen that approach keep teams stuck in comfortable local minima. Sometimes you’ve got to take risks.

People need agency, and feel empowered to go forward. I'm not arguing against that interpretation of the post. But having agency doesn't equal a lack of accountability, or being able to explain what you're doing.

In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.

Re: Collaboration sucks

#256
post #18

Taking the article's analogy of the "collaboration while driving", the F1 sport is quite insanely collaborative. For example, the drivers literally do have someone in their ear by radio being their coach and spotter for the entire trip. I've never heard of the equivalent in software. Does anyone know of anything like this?

We literally followed his “bad” analogy for driving by doing software teaming aka mob pair programming. You switch drivers every 10m or so. It can be great. Everyone learns a lot about the feature and the codebase fast. But it can feel slow. And it tires some more than others. Most people liked it.

Re: Collaboration sucks

#257

Earlier quoted context omitted.

it's funny because the facile sportsball analogy actually fails horribly here. "playing together more" is the absolute last thing that the undifferentiated mass of hundreds of people hitting the like button on a random nonsensical comment need to do more of. the only situation where collaboration of this sort is productive is when you cannot reasonably expect any other participants to have some sort of proprietary kn…

This is such a great response. It leaves me wishing I could delete my comment. A.I. told me there was a 2020 match between Lakers and Globetrotters which the Lakers won. Turns out it was a fictional match. I've had great success with mob programming so that's where my brain was at.

hahaha that makes so much more sense. kinda takes the bite out of that rant, but i already knew it was silly after word number… 600? but i was already on a heater and felt i had no choice but to continue lol. no, never delete! you can hold your head up high, knowing that at least you’re not the loser who spent the better part of 45 minutes copy-editing a 800 word semi-unhinged— and possibly not semi- — “possibly” — rant just to make fun of someone on the internet for no reason whatsoever. i guess the OP awakened my own inner feelings about “collaboration”, as someone who does genuinely very highly value collaboration, and do view it as a skill that does genuinely require a lot of practice. :)

Re: Collaboration sucks

#258

Earlier quoted context omitted.

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 sm…

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

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

Re: Collaboration sucks

#259

> 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…

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 com…

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.

Re: Collaboration sucks

#260
post #87

Earlier quoted context omitted.

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…

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 sm…

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?
Post reply on HN