Earlier quoted context omitted.
Pair programming.
That was too easy.
Almost like a bait.
Collaboration sucks
231–240 of 262 posts
Re: Collaboration sucks
#232> 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…
"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.
Re: Collaboration sucks
#233> 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…
"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.
“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).
Re: Collaboration sucks
#234Like with everything else this is provable with numbers. What this is really about is having at least the appropriate amount of social intelligence for people who are otherwise individually productive. That’s it: productive people who know when to engage.
The way to solve for that is force additional business ownership onto the developers. When there is increased liability and increased risk of failure the developers will know exactly the right amount of feedback to provide, especially to each other, because are operating conditions are dictated by velocity and code quality baselines.
I am saying this as a software manager of people.
Re: Collaboration sucks
#235Earlier quoted context omitted.
"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.
“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).
> 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.
Re: Collaboration sucks
#236Having an AI destroy human collaboration
Re: Collaboration sucks
#237Re: Collaboration sucks
#238> A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it. Well, if the product roadmap doesn't hold up to scrutiny, it _should_ be reevaluated. Too often people commit to something, and then continue building it, despite the market realities having shifted underneath them. I see most teams not asking themselves often enough "should we still be doing what…
Sometimes you can't get every staff engineer to agree to the plan, but you can't sit around forever unto someone caves.
No, but especially of staff+ engineers I'd expect that they know how to disagree and commit after a reasonable (not too long!) time.
Re: Collaboration sucks
#239I 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…
> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.” Everyone feels like an asshole giving an approval wh…
> I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
Re: Collaboration sucks
#240Earlier quoted context omitted.
Have a formatter. There are plently out there that can be part of the compile/build/commit flow, to the point of failing pipelines if the files you changed not match the style. Let people know if you have a requirement on layout and enforce it. Code review is far too late.
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.