Ask HN: How to break up and delegate programming tasks

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 "function to draw this btn or move this element" or to "find me a library that does X and is..." and then he can merge them in... then once it takes shape you can share the files and the work.

i suppose usually for me one guy (say techsupp or network admin) sets up the svn/webserver/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/interface the juniors will have more success imo.

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

Stop treating your junior developers like monkeys who are only there to implement your brilliant ideas. That's not their job. Every 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.

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'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.

I think the lead should be setting up source control, the dev/staging environment, deciding on the frameworks used (for the big stuff at least), and defining the architecture and code style for the project, and last but not least, they should break up the project into major features, and individual modules/components/tasks. As far as the last bit goes, the level of detail I shoot for is something like this (given a fabricated web app as the software being developed):

Feature: User can register an account

Tasks:

  - Registration page markup/styles

  - Registration page JavaScript (form validation/submission)

  - Registration API endpoint (validate properties, ensure user doesn't already exist, persist user model, send email confirmation).

Prerequisites:

  - Data access layer implementation

  - User model

  - App layout markup/styles

  - Email service implementation

I agree with the lead setting up the initial project skeleton, but I'd take it one step farther and say the lead should also document the conventions for adding new modules/etc, so that the structure doesn't start to fall apart once the lead stops being the one managing it day to day.

I agree with most of this, but I don't agree that the lead should only care about inputs/outputs when it comes to a task a given dev is working on. A lead should have defined conventions for how code in the project is written, and I think it's absolutely reasonable for that to be part of handing off a task to a junior. My approach is usually something like: "Ok Paul, I'm going to have you build out feature X, Y, and Z, defined in ticket #s 1,3, and 5, see the README about coding conventions, and let me know if you need more context/detail on any of these. I'll swing by each morning for a few minutes to see how things are going"). Then beyond talking to each team member every day, we have standups to keep everyone on the same page, on whatever interval makes sense given the complexity of the project.

I think a lead should care about how their team is implementing the features they are working on, because as the lead, it's crucial that you know the ins and outs of the system - where I think we agree though is that a lead shouldn't care about how the work is done, as long as it's done within the project guidelines (coding style, consistent structure, testing, etc.).