Focus: Assign multiple engineers to the same task | Hacker News Reader

Focus: Assign multiple engineers to the same task

dpc.pw

46 pointssigna1119 comments

I agree with mostly all of this but I find in practise that developers often have a kind of instinctive revulsion of this kind of joint collaboration. There are a lot of people who hate pairing for instance.

I'm not really sure why and I'm not sure what to do about it. I certainly don't want to force them work in a way that doesnt sit well with them, but on the other hand you lose a lot of the benefits of closer collaboration highlighted here.

I also get the feeling that this instinctive revulsion is often rooted in something developers usually dont want to speak openly and honestly about (e.g. fears about being commoditized or the mental stress of having your every keystroke scrutinized). This makes it almost impossible to create solutions which mitigate these issues (e.g. a pact) since the issues are shrouded in mystery.

As you point out, the issue is forcing people to some artificial collaboration. People don't dislike collaboration. They dislike the lack of autonomy. In my experience, Scrum teams have some of the worse collaboration. People are focused on their assigned task and don't have time to speak to others.

The issue here is not that a task is assigned to one person. The issue is that building software around the concept of fragmented tasks is an horrible way of managing work.

The author of this blog mention reading "The goal", which is a Taylorism/lean bible. That's the issue.

I mostly agree in principle, but I think this quote illustrates the downside of this approach if applied all the time:

> Oftentimes they will either have to slow down and learn this and that, by reading some stuff online and internally asking questions. That is a slowdown and it often generates a lot of interruptions and delays for everyone.

Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped to solve similar problems in the future.

But... 1) The long tail. You may never face a similar problem in the future. 2) Surely being forced to figure it out on your own is not the most productive and healthy manner of improving your skills. All human performance areas have teachers and coaches.

I often find it easier to learn how to do a new thing when I'm shown how to do the new thing and can ask questions about the new thing to someone who understands how the thing works. It could be that this pair approach can actually help skill development

I vastly prefer this approach to being onboarded.

Documentation is always way too vague about or just plain missing critical details and too specific about things I don't care about.

> Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped...

That's been true in my experience. Almost every step forward in my career development has involved a very uncomfortable and uncertain adjustment period. It helps immensely to have people around who are curious, receptive to questions and who can empathize and provide some guidance.

It seems that the more heavily project-management-oriented a workplace is, the less slack there is for this kind of career development. It's not uncommon to have workplace cultures where one has to prove themselves in some kind of "sink-or-swim" or "show-how-you've-suffered" scenario before they are deemed "worthy" of consideration. It's sort of visible in the culture of stackoverflow which I think of as a kind of microcosm of the attitude in many workplaces.

My previous company called that somewhat uncomfortable feeling where you sort of know how to proceed but not completely the "learning edge", and it's a term I really like. I always aim to keep myself and my team on that learning edge to keep people growing (avoiding complacency/stagnation) while not exposing them to too many roadblocks. It's a constant balancing act.

The purpose of assigning one person to a task is NOT that the assignee has to do it all or know it all. The purpose is to have a single point of responsibility that oversees things and get it done. Assigning to multiple persons without clearly dividing responsibilities is doomed to fail. And what's worse, when the task failed, people point fingers towards each other and no one wants to take responsibility.

Takes a long time before it acknowledges pair programming, but it gets there in the end. But it never even attempts to quantify the bottom line:

> the work actually assigned getting done faster as people working together can get it done much faster

The only thing that's definitely true is the task is consuming 2x FTE salaries for its duration. Does that translate into 2x faster progress? It's extremely hard to say, as all the previous struggles with software estimation and time recording have shown us.

The challenges are not dissimilar to allocating work to execution units within a CPU; a programmer with two tasks assigned who swaps between them when blocked is "hyperthreading" and usually achieves higher throughput, although frequent task switching incurs time costs.

So in practice engineers have multiple things in progress, both for their own account and things they're helping other people with. That is, after all, part of the point of telling other people about it in standups.

> Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”?

This is however a warning sign to me. There are a lot of mechanical systems you can run at more than their rated performance in emergencies before experiencing burnout, and the same applies to humans. You can't just crank the team up to "flank speed" and leave it there.

(irrelevant aside: apparently the USN have called their O365 migration plan "Operation Flank Speed", which I find unreasonably funny. https://federalnewsnetwork.com/navy/2021/05/navy-transitioni... )

I've tried pair-programming and it felt exactly like that - working at 100% intensity for the whole 8 hours. It felt very productive and intense but also quite tiring.

I certainly learnt a lot and it was probably twice as fast as if we would have worked alone, but I wouldn't want it to be the default for every task, I would just burn out quickly.

The main benefit was finding edge cases immediately (so feedback loop of design-implement-test-fix needed less iterations) and on-the-fly debugging was faster.

That's weird coz I feel more stressed out about working solitary.

With pair programming if im having a rough or unproductive day i can let my pair do the heavy lifting (or vice versa).

When programming alone I get anxiety about whether or not Im doing the right thing almost all the time which causes stress.

I prefer solitary (& am more efficient) if i have a very clear picture of what needs to be done and how but realistically most of the time Im dealing with ambiguity and subtle trade offs.

> You can't just crank the team up to "flank speed" and leave it there.

That attitude also ignores the nature of the work. Incident response is 90% investigation while development is 90% creation.

It's the difference between reading a map of a city and planning a city.

I've always been annoyed with JIRA's limitation of 1 task = 1 assignee, but IMHO assigning 2+ people to every task by default is overdoing it. Depending on the product and the team, many tasks can be pretty straightforward if the backlog grooming is done often and the tasks are prepared well.

Also, many developers chose to become a developer because they have a more introverted personality and they like working on their own for long stretches of time. If you force them to always work together or sync up with each other more often than is necessary, it will lead to more burn-out.

> The coding part might or might not be pair-programming

If more than one developer is working on a task and they aren't pair-programming doesn't that suggest that they have looked at the task and how to implement it and split the task into independent sub tasks that they are each working on. But isn't that the approach to just about any modern development process?

In just about any team I've been in we've all had a good understanding of the architecture and issues/approaches that other developers are working on both formally and informally.

This is the essence of Mob Programming as popularised by Woody Zuill. Can recommend.

I think you could also argue that the solution here is not to assign multiple people to one "task", but to write "tasks" that are atomic enough that one person can and should do them, and use some higher-level abstraction for problems that require teamwork.

What problems do you work on in isolation without teamwork? No talks about design, no code reviews, no functionality review, no one updating the documentation etc?

> Let's contrast with an approach where two (or even more) engineers with somewhat disjoin (sic) skills were assigned to one task...

Holy crap! He's invented the Software Development Team!

Reply on news.ycombinator.com