Are Quirky Developers Brilliant Or Dangerous?

jammag writes "Most developers have worked with a dude like Josh, who's so brilliant the management fawns over him even as he takes a dump in the lobby flowerpot. Eric Spiegel tells of one such Josh, who wears T-shirts with offensive slogans, insults female co-workers and, when asked about documentation, smirks, "What documentation?' Sure, he was whipsmart and could churn out code that saved the company millions, but can we please stop enabling these people?"

Comments

Lack of Documentation == dangerous

[yincrash]

Lack of documentation only chains you more to a developer. It makes it that much harder for someone else to maintain the code base.

Stop coddling your little genius

[Anita Coney]

When kids are recognized as being highly intelligent and gifted, parents, extended family, and teachers go out of their to coddle them. To treat them as special. To give them far greater leniency and independence than kids with normal intelligence.

Is it any shock that these kids grow up to think the rules don't apply to them?

Re:Stop coddling your little genius

[stevied]

There's a fine line, I think. All kids should certainly be taught respect for others and society, regardless of their talents.

On the other hand, subjecting smart kids to excruciatingly slow tuition along with everybody else because streaming is seen as un-egalitarian is a pretty effective form of torture, as is forcing them to endure bullying while trying to play team sports that they don't understand and are no good at, for example.

I'm willing to buy into the idea that all people are equal, but not that they are identical, and our culture increasingly cannot cope with people who are not exactly the same as everyone else. People with talent can serve society by developing that talent and using it to help society, if they're given the opportunity: otherwise they just end up broken and resentful.

Re:Dr. House Syndrome

[java killed the dino]

Shows like 'House' glorify it and apparently make people think it is okay to be an asshole as long as you get the job done.

It isn't?

Not worth it

[squoozer]

I started on the software coal fact many years ago and have slowly worked my way up to the point where I now employ programmers and right from day one I've found the Josh type developer to be nothing but a pain in the neck and generally not worth it. They might be great developers but in my team (at least) that alone is not good enough. I need people that can communicate and get on with others as well. I need people that I can take to customers occasionally. In my experience Josh types are also loose cannons that can't be trusted to do what they are asked to do, they go off mission because they think they know better. Unfortunately they rarely do see the whole picture and end up causing problems further down the road.

My view of this type of programmer is probably rather skewed because one of them actually managed to bankrupt a company I was working for by promising far more than he could actually deliver. Management just kept lapping up the promises despite warnings right up to the end when they noticed how much they had spent and what they actually had got in return.

Re: Seems ridiculous to me as well.

[guidryp]

I would say for every "freak" like this there must be a thousand+ that can code as well and are great to work with. This is just a egregious stereotype that would be quite hard to find in most modern Dev shops.

I have been doing SW dev for a living for about 15 years. Most of it large scale teams. I never saw anyone remotely close to this description and I have worked with some brilliant people. The best were humble, normal down to earth people. There has been a touch of arrogance, by some, but nothing like this.

I don't think the described person would last a week in the environments I work in.

Only in a small shop run by an idiot who won't pay for quality developers that are both talented and decent to work with, would you get this kind of freak and any dependency on him.

Re:brilliant or dangerous?

[Razalhague]

The English word "or" is more often used (and understood) to mean XOR rather than OR.

Real geniuses aren't arseholes

[David Gerard]

In my continued and repeated experience, the real geniuses aren't arseholes. They may be socially inept, but they aren't contemptuous about it.

Paul Graham talks about this in How to start a startup:

For programmers we had three additional tests. Was the person genuinely smart? If so, could they actually get things done? And finally, since a few good hackers have unbearable personalities, could we stand to have them around?

That last test filters out surprisingly few people. We could bear any amount of nerdiness if someone was truly smart. What we couldn't stand were people with a lot of attitude. But most of those weren't truly smart, so our third test was largely a restatement of the first.

When nerds are unbearable it's usually because they're trying too hard to seem smart. But the smarter they are, the less pressure they feel to act smart. So as a rule you can recognize genuinely smart people by their ability to say things like "I don't know," "Maybe you're right," and "I don't understand x well enough."

This technique doesn't always work, because people can be influenced by their environment. In the MIT CS department, there seems to be a tradition of acting like a brusque know-it-all. I'm told it derives ultimately from Marvin Minsky, in the same way the classic airline pilot manner is said to derive from Chuck Yeager. Even genuinely smart people start to act this way there, so you have to make allowances.

It helped us to have Robert Morris, who is one of the readiest to say "I don't know" of anyone I've met. (At least, he was before he became a professor at MIT.) No one dared put on attitude around Robert, because he was obviously smarter than they were and yet had zero attitude himself.

Re:brilliant or dangerous?

[thedonger]

There is a place for "clever" or "novel" code. We shouldn't be so locked into doing things a certain way that we never deviate from the path. It is important, however, to understand the history of what you are working on in order to avoid repeating past mistakes, or re-engineering the wheel.

There very well may be a good reason why something is done a certain way, but that reason may simply be that no one ever thought of it before. That doesn't make it wrong.

Brilliance is a three-edged sword?

[fugue]

They should be recognized as douchebags and fired on the spot.

Sounds like you want him fired because you don't get along with him. Perhaps you're jealous of his ability, such as it is? You needn't be--a good coder who can work with people is generally far more useful than a great one who can't.

Proper management and planning means you don't need a Josh on your team.

Proper planning means you'll anticipate every eventuality and be ready for it, which is of course impossible given that outside factors are basically random.

The guy should have been fired before he was ever allowed to become so integral to their solutions that getting rid of him would mean pain for the group.

You're confusing two issues here. He should clearly not have been allowed to become so integral to a sustainable solution, since he fucked up any hope of that. Firing him is one way to keep him from becoming integral to long-term solutions.

You might just as well advocate firing any manager who lets a Josh become involved in long-term projects. That would be just as correct. Clearly there are things Josh shouldn't be doing. A good manager will see that.

Actually, I like the idea of keeping Josh around just in order to test new managers. If they can't figure out how to use him effectively, fire them. He could be a truly invaluable resource to the company even if not a single piece of his code ever gets executed.

The fundamentals of being a good engineer

[DomainDominator]

1. knowing the theories and technologies 2. being able to communicate your ideas effectively to your team If you fail at either of these you don't belong in any company. Josh fails at #2.

Re: brilliant and dangerous?

[Nefarious Wheel]

Pair programming sucks.

Remember that scene in Amadeus where young Wolfie was composing using the billiard table as a desk? All those symphonies in his head, interrupted when someone came in and broke his concentration. The music stopped.

Programming can be an extraordinarily complex, involving activity that works best when you're concentrating, producing and on a roll. It only takes one prick to break the bubble of concentration. And yes, you may extend that metaphor.

If you really want to do the armpit-to-armpit teamwork go back to Yourdon's original structured programming team. You had a senior guy, a junior guy, and a librarian. Today that would be senior guy, junior guy, and documentor. It works in threes, but not in twos for some reason. I think it has something to do with allowing intelligent people to lead design, rather than have to check around to see if what they're doing is ok. In pair programming you have no leader. With no leader you have no direction and thus no progress.

Ok, I may be out of touch -- the half-million lines of code I delivered was a good few years back. But I can't think when people are shouting around me, and I get paid to think.

Re:brilliant or dangerous?

[Peaquod]

Find a guy with a little programming knowledge who can sit in the office next door and write docs for Jim.

Perfect answer. I've worked with several folks like Jim over the years, and consider myself to be in the same vein. Yes, we can and will write documentation if we have management that requires it. But we'd much rather be having fun solving problems, and wise management will make sure that is what we are doing most of the time. Right now I work for a very small research company - the entire tech staff is two engineers (not "software engineers" - computer vision & robotics) plus two programmers. Our code is messy and poorly commented with no documentation - we get away with this because it is research grade code, and because our team is so small. We (the engineers) understand it just fine. The poor programmers who must port it to other languages simply have to put the blinders on and copy the functionality. We could document the code to death, but that wouldn't be any substitute for the fundamental knowledge in physics, statistics and algorithms required to *really* understand the code. When and if we grow into a production environment where many people will have to support (and understand) the code, I trust our management will be wise enough to hire other folks to do the bulk of the documentation, with help as necessary from the engineers. Because there will always be more profitable things for us to be doing, which we actually enjoy.