3 ms·

Yeah, I have a similar employee. Pretty much no matter what task I assign him, unless I spell out down to precise detail how to implement it, he will go off-sta

by zmmmmm 7y ago

Yeah, I have a similar employee. Pretty much no matter what task I assign him, unless I spell out down to precise detail how to implement it, he will go off-stack to do it. Or if he stays on-stack he will insist on completely refactoring the code, creating his own library (which several times he has done and then asked to open source) or in some other way dramatically upending whatever code he is working with. At this point I'm not sure what to do because he is the most productive employee in terms of simply "getting things done", but I consider him almost dead weight in the sense that he creates almost as much technical debt (in an odd sense because its often forward looking - using tech newer and more fancy that what we are running, or just disrupting code everybody already understood so everybody has to relearn it) as he contributes usable code with everything he does. A couple of times I've forced him to go back and rewrite using our stack but it doesn't seem to be changing his behavior.

exabrial 7y ago
One cowboy is not worth the trouble when once you're out of the startup phase. It's disruptive and counterproductive to team growth. I hope you can get your guy to come around, my advice is lay out expectations and let them experience consequences when clearly managed expectations aren't met.
ubu7737 7y ago
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.

by zmmmmm 7y ago

exabrial 7y ago

One cowboy is not worth the trouble when once you're out of the startup phase. It's disruptive and counterproductive to team growth. I hope you can get your guy to come around, my advice is lay out expectations and let them experience consequences when clearly managed expectations aren't met.

ubu7737 7y ago

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.