this post was submitted on 01 Aug 2023
213 points (99.1% liked)
Programming
17495 readers
142 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've seen this play out a couple time. I agree about a lot of what you said and this is indeed true that you can have very senior and very knowledgeable devs basically "hack" or "bulldoze" their way into a backlog, I would personally argue that this is not a decent or desirable behavior.
There is no such thing as "small finition". Making sure that a change or a feature works all the way through is not finition, it is core to the task, and you can't expect someone else to digest and do the latter half of the work without being in your head.
I guess I am too lazy to type out all the examples with the downfall, but basically if you allow this, you will be shielding a senior from his own butched work, and lets be honest, most people who do this skip the "boring" work for their own selfish reasons. If they want to split the task and have you fix the tests, have them spell it out and justify it.
Management might not understand what is going on, all they might see is a superstar flying through the backlog, while everyone else struggle because they're constantly fixing this guy's shit. This rarely lead to good engineering, or team dynamic, or team management, and of course you end up with this one guy claiming credit for so much shit, while other team members stagnate. Unfortunately appearance is a thing in dev work, as much as I wish it wasn't.
I've seen this play out many times, but only once was it good. BUT ONCE I did see it be good. It was interesting enough that I took the mental notes of why it worked. Huge asterisk because there are still pitfalls around the team having a single point of failure, but that's an issue with many other modes with mixed skill.
Anyhow:
-The whole team was bought into it as a working mode
-There was a QA embedded directly into the team
-The bulldozer was forced, but willing, to routinely re-communicate plans and issues
-The bulldozer became good at proactively communicating "hotspots"
-The bulldozer was not allowed to do estimation, the surrounding team did that.
-The bulldozer agreed to be obligated to prioritize helping the team if they had questions (I think this is what helped him to be so proactive... He was incentivized to avoid this scenario of confusion entirely)
Anyways... I still don't recommend it. But, assuming people are into it, I think there are ways to arrange the right individuals into teams in a way that minimizes the major pitfalls. I'm a pretty big fan of letting/helping teams self-organize into whatever their efficiency maximum is.