Comment by exabrial | Hacker News Reader

Comment by exabrial | Hacker News Reader

There is a remarkable difference between being a strong individual contributor and a team leader. Organizations sort of need both, but being good at one doesn't make you good at the other.

I hired a guy like this, and he was extremely useful. However, he did do some outrageous things. For instance, he was learning Kotlin, and decided to do one his projects in Kotlin without so much as an approval from me or even discussing amongst his peers (which I do delegate most of the tech decisions to those in the trenches). Shocked, I had a one-on-one in which he told me we were falling behind. I reminded him our number one focus is to support the salesfloor in the company, and that our stack is "boring" on purpose because of stability and predictability. I had him work long hours to rewrite the project in the correct stack so it could be supported by the whole department, not just him.

Eventually he left, which I wasn't terribly upset by, and he went to work for a startup which I think better fit his personality and skillset. I keep up with him on linked in and it seems he's continued to surf between startups and making a decent living doing so. I think he's much happier doing this, because having a structure did not suit him.

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.

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.

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.

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.

People like you describe love structure, if it's supportive. You didn't provide a supportive structure. You accused him of falling behind on synthetic targets because of his ambition.

It's no wonder he prefers to avoid that sort of "structure". Jesus Christ.

The elephant in every room you occupy is probably "this guy needs his authority validated".

Those "synthetic" targets you mention are goals the CEO and executive board laid down. The tech stack was chosen but his peers. It was a case of poor attitude, and he was processing towards his termination before he poisened the well for everyone else.

I had another guy on the team that is just as productive but supports junior engineers by mentoring them on the stack, takes notes, clearly communicates, and takes initiative. Unlike the cowboy, he could teach people to do what he did.

Kotlin is a very tame language choice, in what I assume is a very Java heavy organization. Peers should be accountable for learning new languages and following the implementers rule.

nah, this is just the brilliant hacker type mentality (individual over team, parachute in and rewrite everything in today's cool language) type stuff that gets really annoying once you're responsible for a set of interconnected components of software that matter.

it's critical to root out these hero types lest they ruin your organization with hand grenades wrapped up as "refactored" projects using the latest language. seniors won't put up with this, and rightfully so: it basically raises a middle finger to the organization's previous culture/work, and they are now responsible for doing it... again. it's disrepectful and ought to be a fireable offense, ideally rooted out in the first few weeks when the new team member is given some slightly autonomous tasks.

This is ridiculous language. The horrible stink of authoritarianism in this thread!

Good thing for you, that excellent software is always written at the bark of a sadly decomposing mind. You're making wherever great again, I suppose.

It seems to me that the real problem is hiring engineers who only know one language and rest on that language choice for their entire career. If you build an organization of engineers with a versatile set of skills then there is no such thing as a wrong language choice.

Mandate the standardization of interfaces rather than languages and you empower all types of developers in your organization.

I have no issues with the language other than hiring pool is pretty small.

Unfortunately letting something like this sit means you have a huge time bomb of tech debt that only one person can work on. It is a liability for the company and long term profitability.

Any Java engineer worth their salt should be able to use a JVM derivative. If you hire people who are capable of using multiple languages then you won't have an organization of people restricted to a single language.. and the problem is gone.

Reply on news.ycombinator.com