3 ms·

If there are a bunch of mundane tasks, the responsible thing to do is to delegate those tasks to a junior developer: 1. I'm happy because I don't have to do mu

If there are a bunch of mundane tasks, the responsible thing to do is to delegate those tasks to a junior developer: 1. I'm happy because I don't have to do mundane tasks. 2. The junior developer is happy because those tasks aren't mundane for them. 3. Management is happy because the junior developer gets paid half as much as I do.

nocarrier 10y ago
I disagree with this approach. My policy as a tech lead (and then manager) was to spread the mundane tasks across the team equally. This let everyone experience the pain points and usually led to faster elimination of technical debt, since the senior developers would see patterns in the pain and find ways to address it. (Junior engineers often don't have the experience to recognize bad patterns or bad smells and would happily plow through a bunch of mundane tasks that could be done better with a higher level solution.) It helped that we had a Tech Debt Week every 8-10 weeks where we took a week to fix problematic code and harden our deployment and automation processes. It was hugely popular with the engineers, we gave out trophies for the best fixes based on team vote. The "share the love, share the hate" approach also meant that new junior developers were given challenging tasks as soon as they joined the team (and were paired with a senior developer for support). If they excelled, we gave them even harder things to work on. If they struggled, we found easier projects for them to work on and coached them through it so they didn't feel bad about their struggle--we always said it was better to try challenging problems and fail than attempt something safe and easy. Either way, we started new team members with the hard stuff instead of ramping them up slowly on the easy stuff. The same policy applied to interns. They got challenging and impactful projects, no busy work or work the team didn't want to do. This meant we had a huge return rate on our interns and most of them joined our team when they came to work full-time.
candu 10y ago
No, the responsible thing to do is to build tools that do them for you, and then other tools that check they're being done correctly. Failing that: often, products are made or broken on the ability to get the mundane parts done efficiently and properly. If anything, this means those parts deserve the attention of a more experienced engineer; otherwise, you'll end up rewriting them anyways, or at the very least spending more time in supervision than you would have to just write the damn thing. (And if you don't spend that time in supervision, well, you probably shouldn't be in a position to mentor anyone.) I couldn't agree more with GP: good programmers are the ones who bring the same standard of work to the mundane tasks as to the fiendishly challenging ones. I'd go further: the best programmers are those who look at the supposedly challenging tasks and ask: "Why are we solving this problem? Is there a mundane problem we can substitute to achieve the same result?"

nocarrier 10y ago

I disagree with this approach. My policy as a tech lead (and then manager) was to spread the mundane tasks across the team equally. This let everyone experience the pain points and usually led to faster elimination of technical debt, since the senior developers would see patterns in the pain and find ways to address it. (Junior engineers often don't have the experience to recognize bad patterns or bad smells and would happily plow through a bunch of mundane tasks that could be done better with a higher level solution.) It helped that we had a Tech Debt Week every 8-10 weeks where we took a week to fix problematic code and harden our deployment and automation processes. It was hugely popular with the engineers, we gave out trophies for the best fixes based on team vote. The "share the love, share the hate" approach also meant that new junior developers were given challenging tasks as soon as they joined the team (and were paired with a senior developer for support). If they excelled, we gave them even harder things to work on. If they struggled, we found easier projects for them to work on and coached them through it so they didn't feel bad about their struggle--we always said it was better to try challenging problems and fail than attempt something safe and easy. Either way, we started new team members with the hard stuff instead of ramping them up slowly on the easy stuff. The same policy applied to interns. They got challenging and impactful projects, no busy work or work the team didn't want to do. This meant we had a huge return rate on our interns and most of them joined our team when they came to work full-time.

candu 10y ago

No, the responsible thing to do is to build tools that do them for you, and then other tools that check they're being done correctly. Failing that: often, products are made or broken on the ability to get the mundane parts done efficiently and properly. If anything, this means those parts deserve the attention of a more experienced engineer; otherwise, you'll end up rewriting them anyways, or at the very least spending more time in supervision than you would have to just write the damn thing. (And if you don't spend that time in supervision, well, you probably shouldn't be in a position to mentor anyone.) I couldn't agree more with GP: good programmers are the ones who bring the same standard of work to the mundane tasks as to the fiendishly challenging ones. I'd go further: the best programmers are those who look at the supposedly challenging tasks and ask: "Why are we solving this problem? Is there a mundane problem we can substitute to achieve the same result?"