Actually, the story comes across as the kind of 'incomplete, subjective account' I'd hear from both sides in the past, somehow mashed together into one. Maybe that's what makes it interesting?
Actually, the story comes across as the kind of 'incomplete, subjective account' I'd hear from both sides in the past, somehow mashed together into one. Maybe that's what makes it interesting?
In this case, we see a supervisor who is still close enough to the code to have the engineer's hat on, but whenever they interact with their own superiors they get the same refrain of "I don't understand this" -- so those people are managers. The problem is that the risk decision of keeping or firing the troublesome team member (as well as other decisions like whether the team's methodology should be agile or not etc.) has been usurped by management.
Normally this decision-making takes a more-concrete form like the 90s-era "And the code absolutely must be written in Java" ... "do you know what Java is?" ... "Yes, it is the software that enterprise businesses like ours use! We must use it!" ... "But this will be faster and more maintainable in another language" ... "Don't care, we need Java", or whatever. In this case I find it interesting that the issue exists one level up in hierarchy, sort of the same problem at a higher abstraction.