I always hate providing a SWAG [guess] on how long something will take. Predicting how much time I will work on something is never a good indicator on when the item will be finished.

A talent a good dev will have is to take two 1 week features and finish them in 1.5 weeks. It may seem like black magic, but most people don't work on everything serially. You interleave work between tasks; coding on one while the other is still compiling.  Washing your clothes will take 1 hour, but washing two loads benefits from usage of the washer and drier at the same time in the middle.

This model of “shorter done together” seems to go against the grain of traditional software planning. You can’t put it into a spreadsheet and sum it together, because the total time spent will end up being less than the sum.

In the end, given 12 weeks and 5 features, as long as all 5 are done at the end of 12 weeks who should care? Turns out managers tend to care because they need to measure everyone’s time the same way to get an accurate picture where their team is.

Plugging into this model is something that’s not easy to do and requires some patients on both ends. A good dev will know how to emulate what their manager wants to hear, and a good a manager will be able to interpret their report’s work style in a way which plugs in to their tacking methods.

Now can someone teach me to be a good dev given the above? I always seem to frustrate someone with my “trust me it’ll just get done” attitude problem.