Hacker News Reader

Yes, be wary of hiring geniuses if you have poor management.

Why do we expect that someone who is fantastic at twiddling bits, to also be good at documentation? It's like saying to a Program Manager "great, you specified how it has to work, so now just take a few hours and code everything up". Or "how come you weren't coding as you went along?"

The solution is to pair these 'unbalanced' developers with people who are good in other areas. Where was the technical writer who was talking with him on a near daily basis? Or the SDET who worked with him to make sure the important aspects of his design were codified into tests?

You can have 10 reasonable devs spend a year getting something to work and have it be reasonably maintainable/documented/tested/etc. (If you actually even have 10 reasonable devs in the first place). Or you can have 1 'genius' do something fantastic in 6 months with minimal support and hope that your other devs can fill in the gaps.

Remember, you don't go to war with the army you want--you can't say "this person would be great if only they __". You can only work with them or not work with them. If they are genuinely doing what they think is best for the company, then I recommend you figure out how to work with them. Their challenge is to figure out how to be effective in an organization that doesn't understand, and your challenge is to figure out how to make an organization that can understand.

> genius developer

Who writes unmaintainable, unreadable code? Not my definition of genius at all. I worked with one genius in my 20 year career. He was a marine biologist and knew more about computers than me. He was scary smart and all the advice I had from other people about working with him was - he thinks in steps 1, 6 and 20. You need to get him to explain how he got from 1 to 6, and then how he got from 6 to 20. Often this would take weeks to get out of him, but the though had just popped into his head (often while working on something else.) Very interesting man. One of his quirks was the he had no idea what time of day it was. We had to tell him to go home or eat his lunch, else he'd just think it was perpetually "about half nine"

I highly disagree with this.

There is such a thing as domain expertise. For example, machine learning, compiler design, graphics programming, etc. If you are say, a web developer these people might seem like geniuses to you, and no, you wont' be able to pick up and understand their code. This isn't because it's not documented well enough, or that it's not written well, it's because you lack the domain knowledge to understand it. For example, I've written code that you absolutely will not understand without weeks or more of study in the domain. The code is documented, and has links to science papers that you need to read to understand it. But know that you may need to spend months to learn enough to really know it.

It's not the responsibility of the domain expert to teach you an entire domain. So yes, they may just tell you to trust them instead of telling you to go study some volume of domain work. It would be better if they did the latter, but I suspect that many here would still complain with that answer.

Agreed. Background / culture makes a big difference on how well devs can understand each other's code.

I still wish more of my teammates (past & present) wrote more comments (as in "statement of purpose", at the top of a chunk, not just "this part is complicated", in the middle here and there) in their code, though. :-)

Anecdata: As somebody who did actual paid work in an interpreted / dynamic language in the late 80s during and just after college, I seem to see people who have only been through the C ... Java regime struggling with more "modern" (? alternate, anyway) dynamic / functional scripting type languages. It's just not something they are familiar with (intuitive = familiar).

Not that CSU did a great job teaching FP in the 80s, but we at least got to play with original flavor Lisp a few times...

I understand what you're saying but it's not the case in my specific situation. We're all developers within the same field of expertise and know what we're working with. Some of the code does require clever solutions, but we try to make it as understandable as possible and document the obscure things. This guy however would just disregard all that, implement clever but convoluted solutions to problems and all he would offer as an explanation was "trust me guys, this is how it's done." And that would be all.

Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented.

Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.

>there are parts of the code we can't touch because "he said it had to be this way".

You know what? That just means you haven't shrugged his influence off. He's still casting that long shadow.

When our local genius left, I felt lost but eventually stepped up, went through his code line by line documenting it, wrote enough tests so that I could be sure that I wouldn't introduce bugs while rewriting his code to make it readable for me. I learned quite a bit from that.

Seconded. If this guy really wrote good stuff then this is a great learning opportunity. If you have some way to contact him even moreso. He may not be the type of person who can easily summarize or teach someone new to the codebase, but I bet if you read through it, got to know the problem and had specific questions about details of his approach, he would be more than able to discuss it with you. Often this kind of personality enjoys sharing their thoughts, they just don't enjoy spending lots of time getting someone up to speed from ground zero. But putting in the hours to grok the code might put you in a good position to have productive conversations.

I personally shrug it off, but I'm one of the newest guys in the team so I don't have a lot of clout to push for changes yet. Everyone else though seems to be caught into some sort of mysticism around the genius guy. Even our architect and our manager have this attitude of "we can't change this; it might look strange and we don't know why it's there, but he said that was how it had to be." It's very upsetting.

Good for you. I didn't want to pick on you or your colleges so much, I just think your local "genius" has weaknesses like everybody, but in reality your company is at fault.

They should not mystify him, they should have made sure he shares knowledge with others and brings other up to speed. And as he is gone, they should make sure the code is refactored to suit the documentation level and code style the remaining devs are used to.

> be wary of genius developers.

Is not it a subset of "high performers"? The dirty secret of all such "genius developers" is exactly this - they all simply traded rigour and quality for a speedy spitting out of a "good enough" code.

For the outsider this pace may look like magic, for someone who is left to maintain the mess it looks, well, like a mess.

I think code review can help here. Even genius developers' code should be reviewed and understood by other developers. This can help reduce the bus factor and level up other team members. The genius developer will learn to "dumb down" (hopefully in a good way) their code to reduce overhead to their productivity from long code reviews with many questions.

Can't you just pull that part out into a test driver, and "treat it as a hostile object" ( a hostile witness is one who only answers yes or no questions )?

If I was his manager, "it just has to be this way" wouldn't work, but obviously different strokes.