[irrational]

This happened to me this past week. I built exactly what the spec said. They came back and said it all looks good, except we expected this to be that. Um, nothing about that was in the spec, nor was it ever mentioned verbally in a meeting. Making the change from this to that will require everything to be redone since it requires fundamental changes. I would have built it differently had it been communicated to me from the beginning. Apparently it didn’t occur to them to mention it. But they really want it. So I’ve started rebuilding it. Sigh.

[brazzy]

A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

[tstrimple]

This is why it’s important for devs to understand the problem being solved with their code, not just blindly executing to a spec that everyone knows doesn’t spell out every last detail the customer is interested in. Stop treating devs as fungible spec builders and more as partners of the business so they can shift from building against specs to solving real problems. The devs who have this “sixth sense” are finding a mismatch between the spec and the underlying business problem problem they know they are trying to solve.

[nine_zeros]

> A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

While true, a key requirement for even senior developers to function well is good management or a good team lead.

If effective management doesn't exist, the senior engineer should be made manager/team lead since he's doing that work anyway.

On the other hand, if management is micromanaging, then the responsibility of clarification is on the micromanagers.

Management of knowledge workers is a hard job. Most managers are incapable of understanding their reports and understanding their OWN standing among their reports.