Ask HN: How to break up and delegate programming tasks

"Agile" micromanagement is great if you're looking to bleed talent. Highly recommended if you're looking to reduce costs and don't care who leaves.

First, how to break up tasks. I write very small user stories. I aim for things that can be accomplished in half a day. This forces me to do two things. We now have smaller tasks with tangible end goals that actually produce something for the end user. These are usually easier for everyone, from management to intern to understand and follow through to completion. We also don't overthink a task, bite sized chunks are easier to digest, after all.

Second, as a few others hand pointed out, you have to trust your junior and mid level developers to complete a task on their own. Write the story in a way that they can understand what the end goal and tangible result will be. If you keep it small and discuss these openly, this will get a lot easier in a short period of time. Don't worry about the implementation details so much, that will come more in a second.

Third, (here comes the unpopular parts!) TEST! Preferably, at least in my view, use Test Driven Development. Enforce an cultural change of moving towards testing. This will document the code as much as anything and if a refactor needs to be done after a junior or mid level developer completes a task, the tests will facilitate that. It will increase your level of trust in their work as they complete tangible user story goals.

Fourth, pair program. You don't always have to, but heck after a while you might actually like it. Pairing allows you to riff off of one another. Junior and senior level developers can get a lot out of this, far more than just the junior learning something from the senior. If you are finding that your junior developers aren't "getting your style" pair for a while. You might start to understand them as well.

Finally, all of this leads to trust. Look, code bases will need refactoring. I am quite Senior and I am sure if I sat with your code, or you with my code, we would find areas where things could have been done better. Trust that if the code works and does what it needs to do according to the small tangible goals of a user story, and that when it has accompanying tests, you and others will be able to refactor it and make it even better over time.

For the first problem I would consider that after you give them a problem and they solve it have them white board it for you. Ask questions about how they handle certain edge cases or problems. If they haven't have them go back and figure it out.

For the problem with sloppy code have code reviews every few days. Just keep on asking questions about special cases, and giving advice on how to better structure code.

I don't think you can successfully break up programming tasks for junior devs, who can then independently implement them. It has two problems:

1) You either get a lot of code with incompatible ideas, or you do a lot of coaching.

2) The junior devs are not learning as much as they could.

So you should not try to do this on your own, but rather involve the people who will be implementing the project in the process. You can still design the system in your head in advance, but I think the best approach is to then discuss it with the people on the project and come up with the final version together. Maybe somebody will have a better idea, or just tell you something you missed. As you go deeper and deeper, you will keep discovering problems on the lower levels. Some things will remain unknown or require experimentation, but for most you can come up with a solution. I think it's very valuable if everybody on the team understands the big picture. If the application has a few completely separate modules, then you can do the lower level design in different groups, but it's still useful if the task breakdown comes from the people who will be working on the code. Doing it in a meeting, rather than a write up and review process, gives them instant feedback.

Regarding the task breakdown itself, I try to think of how I'd implement all of the code myself. That means thinking about what data comes though the system and where it can be used to set code boundaries, which parts are more important and which can wait, what would be the smallest presentable version and how can I move it further after it's done, do I have some non-code dependencies (business decisions, dealing with external services). I like to draw diagrams (mainly the data flow). Sometimes tasks are simply large and you can't do much about that, but you can at least some milestones for them.

This makes sense to me in a smaller company when building some web application, probably does not make sense in a different situation. (Sorry for a long comment.)