Willingness to do grunt work is a fast track to becoming a manager who says "I haven't coded in years".

No good deed goes unpunished. When you step up to be a team player and do that grunt work, you open yourself up to getting more and more of it. Next thing you know you have to stand up for yourself or become a door mat.

If you're in an environment where rolling up one's sleeves and taking on the grunt work leads so quickly to negative reinforcement loops, in the way you describe... then that's a sure sign that you've found yourself in the wrong environment.

In healthy environments (and yes, they do exists) good deeds are actually rewarded, not punished.

I don't think it's so black and white. In this case, the "punishment" isn't literal. It simply comes in the form of more grunt work, which people trust you with because you have taken it on before and did a good job with it. You may actually be rewarded too when the annual review comes, if you know how to spin it.

Furthermore, grunt work can be an excellent opportunity to shine. For example, you can figure out a way to automate it so that the next person who works on it (which may be you again) has to spend only a fraction of the time on it. Things like running reports or generating documents tend to lend themselves really well to automation, and a little programming ability can take you a long way.

So yeah... think twice before turning away grunt work, even if you believe that you may be given more of it in the future if you agree to take it on now.

I was thinking more in terms of this

http://www.daedtech.com/the-gravitational-force-of-wage-labo...

You certainly have to be careful not to become a door mat but I agree that grunt work is where it's at.

* Deal with difficult users or customers

* Write documentation

* Go back and forth between different stakeholders to make sure everybody is on the same page

* Make sure other developers have the right tools and equipment

Depending on the manager he could be doing this but if he doesn't the senior Dev has to do it or the project fails

The trick is to not volunteer for recurring work. My stance is I will volunteer for 1 thing per week which is defined, ad-hoc, and <5 hours. The bonus to this is your far less likely to be forced into endless time sinks as you have team credibility to say no.

*ad hoc

Do you have any suggestions for becoming more accurate when it comes to estimating effort?

I find that my estimates are generally all over the place and multiple attempts at predicting how much time it will take to complete an assignment don't converge as time passes. Even though I had seen and been given diverse tasks over the course of my work, I can not really pick a previous item of similar magnitude for reference.

I'm a chronic under-estimator. So, whenever we're in grooming or sprint planning, I make it a habit to ask the other members of the team if the size/hours make sense, or are straight out of "Al's world".

In those occasions where I'm asked to provide a WAG to an executive or salesperson, I always multiply my first thought by 150-200%. Maybe even 300% if there's an external stakeholder (3rd party integration, something for a specific client, etc).

I've found that https://www.amazon.com/Software-Estimation-Demystifying-Deve... is a fantastic resource for improving estimation.

I'm not terribly good at this, but I've had some luck taking the first answer that pops to mind and multiplying it by three. It's a crude method, but over time, it has worked well for me.

This usually works OK in practice for small or medium projects, but as Brooks points out in the Mythical Man Month, you are also tripling your estimation error. This can cause a lot of divergence for longer projects.

These are all very good points, coming from someone in a agency/consulting shop. Big things I find are being able to communicate effectively with non-technical folks, budget accurately, and knowing when to ask for help vs. hammering something out.