Live data from Hacker News

Collaboration sucks

newsletter.posthog.com

121–130 of 262 posts

Re: Collaboration sucks

#121
post #9

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

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

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.

Re: Collaboration sucks

#122

I think the real problem here is "decision making" as opposed to "collaboration" I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision. Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree…

The thing is: once you have feedback, you have to act on it. Ignoring the feedback is dangerous unless sanctioned by higher leadership. This is our nature, and the blog does hit this point where we default to collaborate. There is of course a better way. A senior employee should be more intentional about feedback e.g. whether can be done later, put it on a backlog, or must address right now. A junior employee should…

With PRs we prefix comments with issue/question/nitpick. Not everything must be fixed, but it's still useful to at least read the comments.

Re: Collaboration sucks

#123
post #15

While I don't agree with Charles' (clearly nuts) distaste for sparkling water, I'm happy to see people finally talking about this issue publicly. I've suffered through this at several companies, down to the level of sometimes spending like 3x the time it took to implement the actual feature on answering and 'fixing' pedantic stylistic nitpicks during code reviews. While having a homogenous style is important, I'm sol…

> style nitpicks

Other commenter point at auto-formating, but I think companies not using any are pretty rare, hitting that very issue in several companies is highly improbable.

We're probably down to function/variable naming, ternal operators, return types, this kind of thing ?

Someone who can't bother looking around and adapt their style to the surrounding code sounds like a problem to me. What is seen as pendantic and nitpicky can have pretty large impact on readability and go against others' assumptions.

Re: Collaboration sucks

#124
post #103

I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…

> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?

That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.

Re: Collaboration sucks

#126

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, exactly. In many cases you don't exactly need to involve the whole group but without a decider things stall out. And suddenly getting a decision about something looks like "collaboration", and gets struck down by the great confusion which is this authors take. It's a lack of decision making, simply put.

Articles like this are quite poisonous, because they take language and mutate it for purposes that aren't quite sincere, and then next thing you know something necessary and good is worthless.

Re: Collaboration sucks

#127
post #15

While I don't agree with Charles' (clearly nuts) distaste for sparkling water, I'm happy to see people finally talking about this issue publicly. I've suffered through this at several companies, down to the level of sometimes spending like 3x the time it took to implement the actual feature on answering and 'fixing' pedantic stylistic nitpicks during code reviews. While having a homogenous style is important, I'm sol…

> style nitpicks Other commenter point at auto-formating, but I think companies not using any are pretty rare, hitting that very issue in several companies is highly improbable. We're probably down to function/variable naming, ternal operators, return types, this kind of thing ? Someone who can't bother looking around and adapt their style to the surrounding code sounds like a problem to me. What is seen as pendantic…

Even more than that, it means the developer has spent no time understanding the surrounding code, and thus is likely adding debt/CRUFT/risk.

Re: Collaboration sucks

#128
One reason for collaboration is to raise the bus factor.

For small to medium-sized applications, it's not hard to get a single good developer to crank out feature after feature... but they're the only one that understands any of it. Then that single developer is hit by the proverbial bus (or Corona, or retires, or resigns, or whatever...) and you have important software without any maintainer.

That might be OK for some startups where the expectation is that the code will be thrown away and replaced by something better pretty quickly, but for slower organizations, that's often a nightmare scenario.

Re: Collaboration sucks

#129

I think the real problem here is "decision making" as opposed to "collaboration" I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision. Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree…

One of the things that good managers/leaders do is not "make decisions", ie do it this way, but increase the number of decisions that can be made autonomously.

THat could be giving guidance; The product is aimed at x, which means that feature y will need to happen before feature z

Or a framework; We choose to prioritise small throwaway prototypes vs ground up intensive planning

or just taking away decision dimensions: buy this software in and concentrate on this other thing

Re: Collaboration sucks

#130

I think the real problem here is "decision making" as opposed to "collaboration" I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision. Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree…

For me there are two things about collaboration.

Decision making is one, which you emphasized.

The other is knowing what the collaboration brings to the table and shaping the rules of engagement to fit that expectation. Sometimes you collaborate with SMEs; they bring the domain knowledge - you don't, but you understand the goal better than them. Sometimes you are creating or refining the corporate strategy based on the actions from individual projects or partners; you are learning ground realities from them. Sometimes you need help from others to improve your take on a subject.

In each of these cases, you have to be clear about what you expect from the collaborators (and motivate them to contribute). Without being clear on what the collaboration is about and what they get in return is the number one killer of collaborative projects even though there is no ill-intent anywhere.

Post reply on HN