Member-only story
The Worst Question You Can Ask a Software Developer
Managers ask it. Developers hate it. Know why that is and what you should be asking instead
This isn’t some cooking blog where I spend six pages describing my travels through rural Italy before telling you how much cheese goes into lasagna. Here it is, right up front — the worst question you, as a software development manager, can ask a developer: “When will you be done?”
That’s it. The worst question. Don’t leave now because the question you should really be asking is at the end (Ha!).
What’s wrong with this question? Don’t managers need to know when things will be done? How else can they find out if they don’t ask?
Imagine yourself as that developer (let’s assume you are working in some Agile framework and the unit of work is a story, but this question is bad regardless of the development model you happen to operate in). You picked up a new story yesterday and in standup, some manager type asks, “When will this be done?” You know you still have a bunch of code to write. You know that code has to call the User API that you have docs for but have never used. You know Bob is rewriting some of the config system in his story, and you will have to merge this into yours. You know the test environment has had issues recently, and Jane, your awesome QE, is still trying to figure out if this is the reason the API tests are randomly failing. You know that as part of your definition of done, you need to get Sandy, the senior dev on your team, to code review your pull request — and Sandy is famously busy.
Knowing all this, what do you say? Do you assume a best-case scenario for every one of the dozen things that have to happen to get this story done? Do you assume that something will go wrong, even though you don’t know what it is and couldn’t say when asked? What happens if you just say, “probably about three days of work” but then find out that the documentation for the User API is actually horribly out of date and all your pleading emails, Slack messages, and (gasp) actual phone calls to its sole remaining developer go unanswered? How do you account for all this messiness, complexity, and uncertainty in your answer?
