If requirements were provided and person didn't fulfill them, they did a bad job. If requirements were fulfilled, but you aren't happy with the result, then you did a bad job.
> If requirements were fulfilled, but you aren't happy with the result, then your requirements were wrong.
Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?
There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.
You're talking about completely different thing than what OP was talking about. It's about developer having a different vision than you.
You either need to accept that someone sees the problem differently than you and accept their solution, or if it is something important to you, you need to get better at explaining your vision.
Anyway, back to your requirements, as you pointed those requirements are subjective. If those are important things you should still outline what's expected. You don't have to do it for every project, and can be when person is being on-boarded.
Right, in that case I'm in agreement, if the employee didn't deliver what was expected because they didn't understand (or weren't convinced with) the manager's vision, then that's most likely the fault of the manager's communication.
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.
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.
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.
> 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.
Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?
There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.