Ask HN: How to break up and delegate programming tasks

Senior devs learn a better tolerance for ambiguity, and have better ability to see the big picture in both the problem space as well as the solution space.

I encourage that sort of thinking from devs I'm mentoring.

I do this by giving creating a rapport where they feel comfortable asking questions. I do by having an attitude that part of my role is to help them be more effective. When asked a question, I drop everything to help them.

I then specifically give them problems that force them to ask questions. This in turn gives me the opportunity push the envelope with their thinking by asking them to answer their own questions.

So when I get asked a question on how to do something, I will ask them if they understand the goals and constraints we need to work in. I make sure they understand that first. Then I ask them for different ways of solving their problem, the pros and cons of each and ultimately what their recommendation is considering those goals and constraints. By that time they generally end up with the "right" answer, and sometimes something I wouldn't have thought of. What I am doing with that exercise is guiding them through the process of how to think about solving the problem. Soon when they come to me, they are already giving me options, pros and cons with a recommendation.

Sometimes I'm asked to decide about a difference of opinion between two devs. Making sure both have the same view of the goals and constraints is really important and most of the time aligning these solves the dispute. If not, then I will have one or both create a minimal test/prototype, time-boxed, that explores the problem. Then we evaluate the results together against the goals and constraints.

This has worked very well for me.

As far as breaking up tasks and delegating, it all depends on their tolerance for ambiguity. I usually start more junior devs with smaller, well defined tasks that have specific acceptance criteria. I adjust the level of definition based on their ability to succeed, but always do it in such a way that it forces them to grow.

Well, junior developers are just that: junior. That definition can range from 'just finished a coding bootcamp' to '4 years of CS with a bunch of practical internships'. Depending where a developer is on that spectrum, they may behave very differently when given a problem and a bunch of time to solve it.

For example, they might not realise that they should be looking into the framework. They may be scared to ask stupid questions because they don't think they deserve the job in the first place. They got a bit of harsh feedback from someone who didn't take their level into account, and mentioned a whole bunch of things they'd never heard of before, and now they're running around in circles panicking. But not saying anything about it.

Obviously a lot of this boils down to "it depends on the person" and none of this may be true. But here are a few thoughts:

Take a step back and think about what the expectations are and whether those are communicated at all. Assign a specific senior developer as an active mentor, and coach them on how to give constructive feedback if they aren't very good at it (it's a growth opportunity for them). Suggest reading lists, talks, and examples of best practices - including stuff that makes working on a team smoother, like source control, etc. Pair program for the first week or two. Code reviews (as small as possible), design reviews, and even giving them less freedom at first so they get confident rather than overwhelmed. Check in frequently so you don't get a steaming pile that could hopefully have been avoided :)

This is a great question! I find that the act of explaining the problem itself helps a great deal in figuring out what the pieces are.

It's totally okay to just talk to a developer about the problem and start sketching out your ideas, without necessarily knowing the specific tasks that you're going to assign.

The abstraction level of the tasks that you should assign will also come out of the level of discussion you're able to have with the person. Everyone has different abilities/amounts of domain knowledge/available time/etc., so there is never "One True Task List" for implementing something; it must depend on the developer.

Finally, it is deeply motivating for the person who's going to do the work to be an involved part of the planning discussion. It's important to anyone to have a certain amount of autonomy in their work, and making them be a part of planning is a great way to do that.

None of these are bulletproof, but try a couple of the following.

Try thinking in terms of strategies and tactics. The overall problem can be described in one high-level sentence of "what" to do. That's the strategy. That strategy can be described in one high-level sentence of "how" to do it. That's the tactic. Then that tactic can be broken down into 2-5 slightly lower-level sentences of "what" to do, which are strategies that are sufficient to meet that tactic. You may continue this for a few strategy/tactic levels. Eventually you have some medium-level strategies you can pass on to junior/midlevel people. But trust them to determine the tactic. If you give someone else a strategy and then tell them what their tactic is, you're micro-managing.

This is also roughly what a lot of refactoring and clean code is about. In a method, you don't want to mix levels of abstraction. Instead, a parent method should call inner methods that are named by what they do, while those inner methods in turn have the logic that is how to do what the method is named. And this can also continue on down to lower levels. When developing this way, you might even mock/facade some of these higher level methods/classes/functions/whatever so you can finish implementing and testing the higher level method/function/class/whatever that calls it.

A full-stack developer that hasn't quite made the jump to "architectural" thinking will often immediately and intuitively identify the lowest-level tasks that need to be done for a project, but like you've noticed, focusing on that implementation style doesn't really scale.

Perhaps I'm missing your meaning: "It's just that you can wean off senior developers quicker"

Code reviews are just as necessary for senior devs, but it's more about helping everyone to understand what just happened and why: Here's the problem, here's what I did to resolve it, here are the pieces of the system it touches.

That way at least one other developer is in the loop. Two heads are always better than one. Someone else might spot something you've missed... and worst case scenario, if I get hit by a bus tomorrow, someone else knows what I did and there's less of a chance that someone will have to spend a week wading through my code trying to reverse engineer what I just did.