Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to break up and delegate programming tasks

news.ycombinator.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Ask HN: How to break up and delegate programming tasks

#31

Post by mod »

balabaster wrote: post #30
sergiosgc wrote: post #21

Earlier quoted context omitted.

Code reviews. I can't stress enough the importance of code reviews to bring developers aboard a team. They are as important to junior developers as they are to senior developers. It's just that you can wean off senior developers quicker (if you wish to). When people imagine code reviews, they imagine people analyzing code and haggling about coding guidelines. They are much more than that. Code reviews are more about…

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. Some…

The last point is really not a good one.

It would clearly be better to have the chance someone spends a week wading through your code than explaining all the changes you made to avoid that happening. You'll spend more than a week doing that.

I don't disagree with your other points, though. Two heads are better than one, and code reviews are important for a slew of reasons at all levels.

Re: Ask HN: How to break up and delegate programming tasks

#32

Post by balabaster »

bitwalker wrote: post #10
onion2k wrote: post #6

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 so…

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…

I agree to a point. As a lead developer, you should care about it all, but it's also your job to be a mentor. Give your junior devs just enough rope to hang themselves, but be close enough by and approachable enough so that they don't. A little pointer like, "think about this approach" or "don't use a dictionary here because..." or "generics will be your friend here, but beware of x, y and z".

You should be holding your junior developers accountable for writing tests for their code, ensuring that the test coverage is there, ensuring they understand what problem they're solving, ensuring they understand the approach they're taking, ensuring they understand the repercussions of the decisions they're making. This is how they advance from junior to intermediate and eventually to senior.

It is your job as the senior/lead developer to groom your junior devs to make the steps forward and eventually do your job. You shouldn't be telling them how to write the code. When picking holes in their code, it should be constructive, don't just to pick holes in it to pick holes in it, making them feel bad. The goal is to help them understand what's not up to par, why it's not up to par and what approach they can take to fix it. You should neither be writing code for them, nor should you be expecting they make every decision in the same way you would.

Re: Ask HN: How to break up and delegate programming tasks

#33

Post by PeterWhittaker »

There is one key point missing in this discussion, though spotman sort of alludes to it: You cannot do this because you haven't, yet. You will be very poor at this until you have done it a few times. Eventually you will be good at it.

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.

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.

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.

Is your work environment reasonably "safe"? (Yes, I do mean that in the "touchy-feely" 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...)).

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'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's abilities, to make better hackers.

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.

Now ask for their help. Work as a team to do these things.

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.

Re: Ask HN: How to break up and delegate programming tasks

#34

Post by sergiosgc »

balabaster wrote: post #30
sergiosgc wrote: post #21

Earlier quoted context omitted.

Code reviews. I can't stress enough the importance of code reviews to bring developers aboard a team. They are as important to junior developers as they are to senior developers. It's just that you can wean off senior developers quicker (if you wish to). When people imagine code reviews, they imagine people analyzing code and haggling about coding guidelines. They are much more than that. Code reviews are more about…

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. Some…

What I mean is that if you do not see permanent value in code reviews, at least the onboarding aspect should be considered undisputabe.

Re: Ask HN: How to break up and delegate programming tasks

#36

Post by markbernard »

mod wrote: post #31
balabaster wrote: post #30

Earlier quoted context omitted.

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. Some…

The last point is really not a good one. It would clearly be better to have the chance someone spends a week wading through your code than explaining all the changes you made to avoid that happening. You'll spend more than a week doing that. I don't disagree with your other points, though. Two heads are better than one, and code reviews are important for a slew of reasons at all levels.

Not really. Trying to explain your code to someone else helps you understand better as much as it helps someone else to understand it. You only explain it at a high level unless there is a complicated part that you might then go through line by line.
Post reply on HN