Ask HN: How to break up and delegate programming tasks

Stop treating your junior developers like monkeys who are only there to implement your brilliant ideas. That&#x27;s not their job. <i>Every</i> developer should be able to solve problems; the more senior the developer the greater the impact and complexity of the problem they should be solving. Your job as a senior developer is to work out the high-level architecture that will contain the solutions to the smaller problems - eg solving the highest impact problems.<p>My advice would be to think in terms of black boxes. You should couch tasks in terms of what the developer can expect to receive through an API and what their code should output. What happens in the middle shouldn&#x27;t be anything you concern yourself with. When the junior developer works out a solution they can run their idea past you, and if it sounds OK then they write the code. And then you can review their code. The minutia of implementation is not your problem any more.

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.<p>I encourage that sort of thinking from devs I&#x27;m mentoring.<p>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.<p>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.<p>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 &quot;right&quot; answer, and sometimes something I wouldn&#x27;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.<p>Sometimes I&#x27;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&#x2F;prototype, time-boxed, that explores the problem. Then we evaluate the results together against the goals and constraints.<p>This has worked very well for me.<p>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.

The most important realization I had this year is that the biggest problem in software development (from the tech perspective) is not about programming, but about getting people to talk and cooperate.<p>I don&#x27;t think you can successfully break up programming tasks for junior devs, who can then independently implement them. It has two problems:<p>1) You either get a lot of code with incompatible ideas, or you do a lot of coaching.<p>2) The junior devs are not learning as much as they could.<p>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&#x27;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&#x27;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.<p>Regarding the task breakdown itself, I try to think of how I&#x27;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&#x27;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&#x27;t do much about that, but you can at least some milestones for them.<p>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.)

When I&#x27;m outsourcing stuff, I like to use the &quot;clean room&quot; approach. I give the junior developer&#x2F;outsourcer either a simplified version of the codebase, or some raw materials, and ask them to do the task I need. Then they hand me back the code and <i>I</i> integrate it into the full codebase.<p>This way they don&#x27;t need to know the full system or even have access to version control; they just need to get their small goal completed, I can take care of the rest.<p>Over time, they can earn more and greater responsibility&#x2F;access.

This may be a very unpopular approach, but it has always worked well for me. Look at the tenets of Extreme Programming and I would imagine you will find great success.<p>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&#x27;t overthink a task, bite sized chunks are easier to digest, after all.<p>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&#x27;t worry about the implementation details so much, that will come more in a second.<p>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.<p>Fourth, pair program. You don&#x27;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&#x27;t &quot;getting your style&quot; pair for a while. You might start to understand them as well.<p>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.

What&#x27;s the first thing? Whats the next thing? Whats the next thing?<p>That&#x27;s the process of thinking i usually take. First, i&#x27;m gonna need a project. Then I&#x27;m going to need to instantiate a database. Then I have to create the controlling class. then I need to create the initialization. etc.<p>For the juniors, it helps a lot to have things more bullet point. they should be able to fill in the more minute details on their own, but do get fairly verbose. Break the work into a small logical scope, and then bullet point what needs to happen for it to be completed. And always explain why.<p>For the mid-level, be more general about it and have them define the tasks that will be completed. This is to give them more say in the process, enable checks &amp; balances, and trains them to write tasks for juniors and mid-level developers when they are one day senior devs. And that&#x27;s really what your goal should be.<p>Everything you work on is a means to make everyone below you better. If you know how to solve a problem, let someone else take a crack at it. If they get it wrong, or need some help along the way, you&#x27;ve already got an answer.<p>And of course, code reviews are an important feedback loop. But always let them maintain ownership. Its their baby. don&#x27;t fix their code for them unless its more or less an emergency. Mistakes they make can often be reflected back as a failure of process, and not of themselves.

None of these are bulletproof, but try a couple of the following.<p>Try thinking in terms of strategies and tactics. The overall problem can be described in one high-level sentence of &quot;what&quot; to do. That&#x27;s the strategy. That strategy can be described in one high-level sentence of &quot;how&quot; to do it. That&#x27;s the tactic. Then that tactic can be broken down into 2-5 slightly lower-level sentences of &quot;what&quot; to do, which are strategies that are sufficient to meet that tactic. You may continue this for a few strategy&#x2F;tactic levels. Eventually you have some medium-level strategies you can pass on to junior&#x2F;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&#x27;re micro-managing.<p>This is also roughly what a lot of refactoring and clean code is about. In a method, you don&#x27;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&#x2F;facade some of these higher level methods&#x2F;classes&#x2F;functions&#x2F;whatever so you can finish implementing and testing the higher level method&#x2F;function&#x2F;class&#x2F;whatever that calls it.<p>A full-stack developer that hasn&#x27;t quite made the jump to &quot;architectural&quot; thinking will often immediately and intuitively identify the lowest-level tasks that need to be done for a project, but like you&#x27;ve noticed, focusing on that implementation style doesn&#x27;t really scale.

It takes experience, experimentation, and what works for one team or individual, may need to be altered to work for another team or individual.<p>I like to break up tasks into what I hope is achievable in 4 hours. Always assign yourself as much (or more) of these sized tasks than those your assigning others, if you don&#x27;t want to appear that your only a manager.<p>Re-evaluate these sizes often. Especially with a new project, new team, or new person. Maybe due to something you did not foresee right out of the gate, this 4 hour task is really a 16 hour task. Or possibly the other developer is working hard, and learning fast, but you just misjudged how quickly they can complete it in. In this scenario, the next time it comes to split up work (or if you really over-shot, you can re-split up what you gave them) remember this metric, and size it a bit smaller.<p>Depending on distractions, and how well the above process is tuned, I only hope for 1 of these 4 hour issues to be completed per day, while at the same time, looking at it over a week or two average, not daily, as many programmers do not work in a predictable linear fashion.<p>Over time as engineers progress and grow at their craft, what they may have been able to do in 4 hours, might be 20 minutes. As you work with others you will get a feel for this, and become more tuned into other people&#x27;s forte&#x27;s. Not everyone is good at CSS for example, even if you know how it works. So its not just about skill. The longer you work with people, the better you will get at carving out tasks that work for you and for them, and for the team.<p>So in summary, experiment with it, give yourself as much work, and in the same manner you delegate tasks to others delegate tasks to yourself. Re-evaluate the size of these tasks often, and try to create tasks that others can get done in a reasonable amount of time, so that they get the feeling of completing something.<p>Not everyone can be given a big gigantic month long task and not get lost in it, and on the other hand, tasks smaller than 4 hours, really start to feel (and take the energy) of micro-managing. The more senior the developer that has proven they meet goals on time and communicate well, these can be relaxed a bit, and you might find someone really prefers 2-3 day sized tasks, but can also be reliable in this manner.<p>Finally, ask them. You might be surprised.

There is one key point missing in this discussion, though spotman sort of alludes to it: You cannot do this because you haven&#x27;t, yet. You will be very poor at this until you have done it a few times. Eventually you will be good at it.<p>Delegation is a skill. Matching problems to the capabilities of team members is a skill. Accurately recognizing the capabilities of team members is a skill.<p>These are all skills you can acquire, but they are all skills that you will do more or less poorly on unless and until you have sufficient practice.<p>You will also be very slow at it until you have practiced a while and gotten better. So you must recognize that at first productivity will decline, because it will take you longer to delegate than doing it yourself.<p>Is your work environment reasonably &quot;safe&quot;? (Yes, I do mean that in the &quot;touchy-feely&quot; emotional sense; this is important (not trying to dismiss the idea, just using glib humour to forestall inevitable negative comments - some people are uncomfortable recognizing we have emotions and are affected by them...)).<p>If so, take your team out to lunch, off site. Tell them what you want to do: Delegate more. Tell them why: So the team gets more done, so there isn&#x27;t a single point of failure or just one person on the critical path, so that junior members can grow into senior members, to challenge people&#x27;s abilities, to make better hackers.<p>Next, tell them that this means you need to practice chunking, delegating, managing, etc., and it will take time for you to get better at these things.<p>Now ask for their help. Work as a team to do these things.<p>Note: You may also need buy-in from your management before you proceed. They may view this as a risky change, if they like how things are. Depends how supportive they are.

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.<p>It&#x27;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&#x27;re going to assign.<p>The abstraction level of the tasks that you should assign will also come out of the level of discussion you&#x27;re able to have with the person. Everyone has different abilities&#x2F;amounts of domain knowledge&#x2F;available time&#x2F;etc., so there is never &quot;One True Task List&quot; for implementing something; it must depend on the developer.<p>Finally, it is deeply motivating for the person who&#x27;s going to do the work to be an involved part of the planning discussion. It&#x27;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.

I&#x27;m a big fan of old fashion modules are flow charting.<p>Start by flow charting your program, divide the task into a group of single statements tasks that can be described without the words, &quot;and&quot;, &quot;or&quot;, &quot;but&quot;, etc. If you need to use those words, you need to chain tasks or make decisions.<p>After several revisions (3-4) you should have a nice overview of what the program should do, and how it will do this.<p>Selected tightly interacting objects, and combine them into modules. This will be very apparently visually if you followed the first step correctly.<p>Now you have your scrum&#x2F;agile modules which can be outlined and given to subordinates, and tracked.<p>:.:.:<p>If the whole thing is a just a big ball of spaghetti, make a another revision. If its very very small you might be glossing over the technical details.

<a href="http://en.wikipedia.org/wiki/Structured_programming" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Structured_programming</a><p>Stepwise refinement: <a href="http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Top-down_and_bottom-up_design</a><p>Both were written about by Niklaus Wirth, (co-)inventor of Pascal, Modula, Oberon, etc.:<p><a href="http://en.wikipedia.org/wiki/Niklaus_Wirth" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Niklaus_Wirth</a><p>From the above page:<p><a href="http://sunnyday.mit.edu/16.355/wirth-refinement.html" rel="nofollow">http:&#x2F;&#x2F;sunnyday.mit.edu&#x2F;16.355&#x2F;wirth-refinement.html</a><p>Not a panacea, but useful, and can be used together with other techniques like OOP &#x2F; OOAD.

We&#x27;ve tried to handle in a couple different ways depending on the Feature. We either slice up a feature into the different layers they impact, so that individual Dev&#x27;s can work on a layer. This presents issues related to dependencies. But typically, you can have have two Dev&#x27;s start at the bitter ends, i.e. Presentation and Data then one of them will tie it up in the middle.<p>For smaller features, we&#x27;ll have a Dev just implement it full stack. This takes for granted that a lot of the plumbing is there, i.e. Service Layers<p>It helps to have these conversation during Planning Meetings. This will help the Dev&#x27;s involved to get a better understanding of the Stories and Tasks needed to implement.

Draw flow charts, identifying the smallest components along the way. Figure out which components depend on each other. Delegate tasks depending on what&#x27;s already built, your deadline and each team member&#x27;s specialty&#x2F;ability.

I wrote something recently on how to create small tasks for estimating (<a href="http://keithba.net/estimate-like-a-boss" rel="nofollow">http:&#x2F;&#x2F;keithba.net&#x2F;estimate-like-a-boss</a>), which includes an example design doc and spreadsheet of the breakdown. You may find that example useful.<p>Generally speaking, finding a way to communicate this will depend on the engineer. Someone very junior may require much more detail both in the technical design and the feature itself. Someone more senior needs less of that.

1. Have them pair program with seniors half of their time.<p>2. Review EVERY piece of code their write. Code reviews daily.

personally i like to write the mvc skeleton myself and decide which frameworks will be used and go from there. or a leader for the backend who assigns out small tasks as small as a &quot;function to draw this btn or move this element&quot; or to &quot;find me a library that does X and is...&quot; and then he can merge them in... then once it takes shape you can share the files and the work.<p>i suppose usually for me one guy (say techsupp or network admin) sets up the svn&#x2F;webserver&#x2F;db, one guy decides on frameworks, one guy writes the skeleton, one guy starts on the interface, art guy does art stuff, typically the lead dev is watching over all this and merging stuff and when ready gives orders and access to the repo. if theres at least some structure and one template or working file&#x2F;interface the juniors will have more success imo.