2 ms·

I simply cannot believe how myopic this whole comment is. It seems you simply cannot be satisfied with excellence, and would prefer mediocrity. This is the con

I simply cannot believe how myopic this whole comment is. It seems you simply cannot be satisfied with excellence, and would prefer mediocrity. This is the condition of our society. You have absolutely no knowledge of the history of software if you think this engineer fits the description of anything but "brilliant pioneer". If you had any skill whatsoever in your role you would be pushing your team to match his effort. The problem is blindingly clear, and I want to thank you ironically for making it so honestly clear in your comment.

zmmmmm 7y ago
Thanks, it's always interesting to hear responses from people who strongly disagree with what I've said. The only point I'd make in reply is that I work in a fairly highly regulated industry, and I am accountable for the code that makes it to production and its downstream impacts. That means, like it or not, I have to understand everything that is going out (or have enormous trust in the people who are doing it). In that environment, things that break the mold or impose a high rate of change, especially unexpectedly, are very very expensive. For example, they can put huge deployment blocks on code that is pending review. We had critical code delayed by a month from reaching production because it was woven into one of these changes by this person, but the size of the change set was so huge just reviewing and testing it was a significant amount of work Then another time he actually caused a production outage by refactoring some code so that it used a list as a default for an argument in a python function (which we should have caught, but didn't, partly because there were so many changes in what he shipped). Maybe I suck at software, but for lots of reasons (beyond just software skills) I'm the one given the responsibility for this and therefore yes, the process to some extent revolves around my limitations as a human being to understand the changes going out.

zmmmmm 7y ago

Thanks, it's always interesting to hear responses from people who strongly disagree with what I've said. The only point I'd make in reply is that I work in a fairly highly regulated industry, and I am accountable for the code that makes it to production and its downstream impacts. That means, like it or not, I have to understand everything that is going out (or have enormous trust in the people who are doing it). In that environment, things that break the mold or impose a high rate of change, especially unexpectedly, are very very expensive. For example, they can put huge deployment blocks on code that is pending review. We had critical code delayed by a month from reaching production because it was woven into one of these changes by this person, but the size of the change set was so huge just reviewing and testing it was a significant amount of work Then another time he actually caused a production outage by refactoring some code so that it used a list as a default for an argument in a python function (which we should have caught, but didn't, partly because there were so many changes in what he shipped). Maybe I suck at software, but for lots of reasons (beyond just software skills) I'm the one given the responsibility for this and therefore yes, the process to some extent revolves around my limitations as a human being to understand the changes going out.