It’s interesting how many responses here are outraged about “Rick” taking the fall for something that appeared to be a management problem. While it’s clear that there were certainly missteps on both sides, ultimately “Rick” didn’t raise his own concerns, set reasonable limits for himself in terms of time and boundaries, take any responsibility for the direction that the code was taking nor, ultimately, behave like a professional. Firing him was completely appropriate under the circumstances. All he had to do was say something ordinary and adult and humble, such as “You are correct. I feel overwhelmed and under-appreciated. I could use some help here and I am not sure how to fix the issues I’ve contributed to creating.”

The criticism that the company “did not involve him in decision-making” strikes me as naive and incorrect. It was “Rick’s” job to be a subject matter expert in his field and to perform his job well — which includes raising red flags when the work is out of control or moving in the wrong direction (even if it’s his own work) as well as creating solid documentation and maintainable code to the best of his ability— but NOT to set strategic direction and make management decisions.

I thought the whole article well-reasoned and well-articulated. And, frankly, I’m pleased to see the inner workings of coding teams become part of the general conversation about technology. Too often we carry around this heroic mythology about the “mad genius” but it’s a dangerous and distracting fiction that creates a mostly negative narrative (and also creates bad software)…