Slashdot Mirror
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?"
why are the mutually exclusive?
I've never met one of these coders in real life. For that matter, I've never been with a company who's internal politics would even allow such a person to exist.
What cyberpunk novel does this hypothetical "Josh" live in?
It is by my will alone my thoughts acquire motion; it is by the juice of the coffee bean that the thoughts acquire speed
i remember a book from the dot com boom days claiming that a company in san francisco hired a network engineer who stipulated in his contract that he:
1. would only work in the middle of the night
2. got to work completely nude
he got away with it, because it was simple economics: his services were needed badly
any employee who has quirky behavior that is somehow provocative to fellow employees gets away with their oddball offenses to the extent that their services are needed that badly. beginning and ending of issue. you don't have any power or influence over the guy if he is that valuable. you just don't. so accept his behavior. you can moan all you want, but if you want the guy to disappear or act more uniformly, then just hope for a sudden influx of really good programmers from some magical place. thats the only way his behavior becomes a liability
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Sounds like Dr. House for developers. People think because they are smart and/or great at their craft they can basically do anything they want. This ties back to the /. article about the younger generation being more narcissistic than ever. 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.
As an antisocial mindshare person, I resent this topic. Because perpetuation of my antisocial liberties is the precise reason I developed subject matter expertise in the first place.
Translation: Control is more important than productivity.
Err..No that doesn't really match what he's trying to say. By being so belligerent "Josh" was controlling the whole process.
So the choice is: control by a passive-aggressive mentant who refuses to talk to you, or control by management , who should (in theory) be much more approachable.
Of course, if you management team has fewer social skills than an unwashed anti-social 16 year old, then go with the mentant every time.
If you need to cut, there's no tool as good as a sharp knife. If you need to turn a screw, a sharp knife probably isn't the right tool. If you have a guy who's a sharp knife, and you're using him to turn screws, maybe the problem isn't him. Maybe the problem is you.
Honestly....
I dont care how good you are. TAKE A FRICKING SHOWER AND WASH YOUR CLOTHES.
Really is it that hard to spend 10 minutes in the morning, EVERY MORNING to bathe yourself??
and honestly, "really good coders" are not worth it. Give me medicore coders that understand business and can do what they are asked to do over a stinky quirky great coder any day.
Do not look at laser with remaining good eye.
if the author has such a problem with this guy, maybe he needs to be skilled enough to replace him
That's part of the problem. Having irreplaceable people on your staff is bad for business long term. If someone is laughing at you for asking for non-existent documentation that they should have written, they should be fired immediately. The cost to business if this guy were to leave will only get worse with time and probably already outweighs the savings of keeping him on.
Lesson, you are replaceable. If you are not replaceable, then you are too dangerous to have.
I see the glass as full with a FoS of 2.
... but they always seem to self-destruct on their own.
They either:
1) Take of too much work because they never know how to balance things, and burn themselves out.
2) Stop working on needed projects, and only focus on the fun ones, which loses their value in the company
3) Get Hooked on drugs and/or alchohol, and mess up their own future (MODERATION, people, moderation).
4) Piss off management by sh!tting one to many times in the lobby.
5) Get shown-up by some newbie coder who knows less than them, but is willing to learn new things (Josh doesn't like to learn new things, because it would imply that he wasn't a master of everything in the universe).
The story ends there. "Josh" is no coding genius. He's a business genius. He understands that business nowadays is all about rent-seeking. Rent-seeking is looking for a parasitic niche from which you can milk the system with impunity, until the system collapses.
How could anyone learn any other lesson from the goings-on in Washington, D.C. and Wall St. nowadays?
Seastead this.
If your competitor hires this guy they might be able to outproduce you just long enough to put you out of business. Doing things right is important, but staying in business is the *most* important thing. (It's a gamble, like all of life, you roll the dice and take your chances.)
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
Maybe there would be more documentation if you established reasonable deadlines.
Just sayin' sometimes there's another story.
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
That's not true. The guy is refusing to document code and skips work on a whim. He's not dependable but he tries to tie his coworkers to his capricious tendencies. He's arrogant and socially inept. Most of the most brilliant people I've worked with are very confident, but they're not all assholes. This "Josh" doesn't sound like someone I'd want on my team. The code doesn't need documenting? Seriously? Brooks thought that was outdated in 1970.
What a piece of journalism.
Quirky = rare habits and/or rare hobbies and/or rare background/culture that bring a smile to co workers faces or make them interesting to talk to, at least compared to an average drone.
vs
guy in the article = a-hole that everyone hates but has the redeeming characteristic of being somewhat productive (at the cost of ruining everyone elses productivity)
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
A guy who mutters to himself while working is eccentric. A guy who insults his co-workers is an asshole. And a guy who smirks while informing others that documentation doesn't exist is just plain malicious.
Assholes should be kicked out of any team, because no matter how bright they are, they won't be able to compensate for the lowered productivity of everyone else who has to waste their time and energy to deal with their little power games. As an added bonus, it makes every other employee happy, thus making the world a bit better place. Profitable and morally right, firing assholes is a win-win situation. Even the asshole might benefit from the wake-up call.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Now THAT is absolute truth right there...if I had mod points, I'd mod you up.
I'm a SQL developer (yeah, the pansy-asses of the developer world - I admit it) - and often times my documentation is sorely behind. Of course, if I didn't have 50 projects all due within 10 minutes of the conception by the end user, I'd have time to document everything too.
That being said, I *still* do my damndest to document my code. Its not perfect, but its better than the renegade who does nothing ever.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
For the sake of argument, let's take for granted that nobody else can do what this guy does. Otherwise they'd have replaced him by now. Also keep in mind that he's using an extreme example to make a broad point. We'll take Mr. Speigel's words at face value, since we're to assume that he's not being hyperbolic about the behavior of said employee...
His argument is that it's worth millions of dollars to not have to deal with this guy. Who has the bigger ego in this situation?
If I'm running a business, and a middle manager tells me that the company should spend millions so the team doesn't have to deal with an asshole, I fire the manager, not the asshole.
"Josh" is the kind of guy who thinks he can develop the next Google, and that the shit he's taking in the lobby planter smells just like the rest of the roses. He's already missed the boat if he's in the workplace and still hasn't figured how to network himself properly.
Exactly. There's always two sides to a story like this. One reason documentation often gets missed is because "make it work and make it work NOW!" and "we forgot to tell you, it also needs to Z in addition to X and Y!" gets nice'd above documentation.
If we all had all the time we needed to do everything, the documentation would get done. But this is the real world and in the real world, IT management is definitely going to put functionality well above documentation on the importance scale.
My blog
Agreed, I've got extensive real world experience with this. I've both been the quirky developer and now manage multiple quirky developers.
I was definitely the arrogant whiz kid when I was younger, but my infractions were usually showing up late to work, wearing torn t-shirts, etc. Still, getting away with that stuff and still being fawned over by management makes everyone resent you. The fundamental shift came when I realized that although management viewed me as a great developer, I was never going to get promoted because they didn't trust my social skills at all. After that I put a great deal of effort into developing social skills (which was really hard) and stopped acting as if the rules didn't apply to me. Once that happened my career took off.
I now hire plenty of the same "whiz kids" as I myself was, because I value their talent. But I do try to indoctrinate them in the ways of the real world. I try to make them have the same epiphany that I had, and show them that IQ and income/career trajectory are not proportional, and having a high IQ and being arrogant about it is a huge dead end. This is not something you can convince them of in one sitting, you have to keep pushing this idea on them for months. If it sinks in, the developer becomes a rock star at work. If not, they stay stuck at the bottom, or if their behavior is egregious enough, I fire them. But their talent is undeniable, so being dismissive of them as a manager is immature and cranky. You have to give them a shot.
If you can't replace a relatively inexpensive employee, you're one traffic accident away from being out of business entirely. Let your competitor take that risk. "It's a gamble, like all of life, you roll the dice and take your chances." The odds of your competition hiring the guy - through a noncompete clause - and him being the tipping point of sending you out of business? Miniscule. The odds of a daily accident, or family problems, or the employee just leaving for greener pastures? Enormous.
Translation: Control is more important than productivity.
I think it would be a lot harder for this guy to have made his point without such an extreme example.
While I agree the example was extreme, the point was valid.
It's not about control but about creating a product that is sustainable over the course of its life. That requires code that can be understood and troubleshot by others; not just the author. As was pointed out in TFA; Josh's code may have been the casue of teh problem from teh start.
The ability to write code that works quickly is not genius, it's the mark of an idiot savant. Real genius is writing tight code that works and can be understood by others.
Despite the pain of rewriting the code once Josh left I bet the company was better off in the long run because they had fewer customer complaints and when they did they could actually fix the problem without dealing with Josh.
I'm a consultant - I convert gibberish into cash-flow.
Sometimes, when you've spent the past 48-72 hours working to solve some crisis that some moron left and you have to clean up, yes.
You look like shit, smell about as bad, and have a cranky attitude to match.
But, shipping on time and avoiding a $250,000/day contract penalty can sometimes justify the hell (Ah, contracts with separate "code complete" and "QA Pass" dates.)
Some coders don't shower all the time because they haven't gone home.
In Liberty, Rene
One of the pure group psychology shows I really like watching is Dog Whisperer. It's left unspoken, but I think a lot of it applies to kids and even adults in power situations.
However, I don't think it's the gifted children that are specifically the problem, I think any type of kid treated with gloves becomes that way. The one that can't perform are merely arrogant losers as adults. While the ones that can become like Josh. The brilliant ones without the anti-social problems don't use their brilliance as a excuse and often don't call attention to it in the first place and may be skipped over as merely above average (which the Josh of the world may be but play it up, afterall, when you aren't hamstringed by stupid bullshit rules, you can do things more freely and eventually do things others never thought of in the box they've been confined in).
But as a counter, I have to bring in the brilliant George Carlin:
http://www.youtube.com/watch?v=w7LOCg4uKAg
http://www.youtube.com/watch?v=izE4_Jd2dOw
http://www.youtube.com/watch?v=f3XeRCAAkZY
There's nothing wrong with clever programming tricks, as long as they are documented so that other people can understand them.
File under 'M' for 'Manic ranting'
You stop being a quirky genius soon as you declare yourself as one. Since then you're just a wannabe poser.
See that's why I'm NOT a quirky genius.
I have yet to encounter a situation where anyone is THIS good (or where every other employee is THAT bad). And if a business WAS in that situation? Better to put it out of its misery - it'll get killed off sooner or later, regardless.
I'm not sure why people feel a need to defend the "quirky" walking lawsuit that these "great" programmers are all about. Very few businesses need genius programmers in order to stay in business. And most of the time, these people keep your business one step away from being sued into an early grave - and they don't provide a good product. A good product isn't something that does things in really neat ways. It's a usable product, well documented, that does the job its designed for really well - and can be updated and maintained as necessary. None of these are true of any product worked on by the described programmer.
I have no interest in pretending that programmers need to wear ties to work and act like your average joe. However, being anti-social and incapable of writing a maintainable product? Not interested.
There are many excellent geniuses out there in the tech field that do what they're supposed to do. They document their work so that others can understand it. If they die or quit tomorrow, their company won't have to spend 2 years trying to figure out what they did. Getting a cheap geek to document these people holds its own high risk. What if the geek doesn't understand what they did? If this "genius" can't be bothered to document his own work, what makes you think they can be bothered to review someone else's documentation of their work? Mitigate your risk by paying more to hire a genius who won't put your company at risk of internal collapse.
I see the glass as full with a FoS of 2.
It's managers job to give the right amount of freedom to talented individuals. Individuals with well over the average IQ, with passion for the job, and that are no afraid to spend extra hours on the task. If it were for me, I'd give up ten of the 9-to-5, dumb, lazy a$$es, weasels, that are unfortunately the fabric of most of US companies, for one talented engineer. You wonder and cry because he has extra privileges than you? Meritocracy, comes not only in form of extra salary, my friend.
Kids who are highly intelligent and gifted are special, by definition. Teachers and caregivers often find that the rules designed for age-group peers should not be applied, because the assumptions behind the rules don't fit. That's not coddling, especially when you consider the additional pressures of expectation placed on them.
For example, I remember in elementary school (this is around 1975) it was a rule that kindergarteners could not books out of the school library. After all, reading wasn't taught until first grade, so kindergarteners can't read. When they found two of us who showed up able to read, rather than remove the rule entirely or stunt our learning potential, the rule didn't apply to us.
Now, this has nothing to do with the sort of developer discussed in the article. A smart developer develops elegant and documented code, and is so proud of their work that they love to explain it to others. Someone who's mastered some arcane bit of technical lore and secretively builds convoluted, undocumented code around it, is neither smart nor talented nor an asset to their team. If they further behave like an asshole (not just quirky, but actively rude and abrasive), the only "special treatment" warranted is a swift kick in the ass.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I'm with you, I love to make my code full of documentation, but when you are given unreasonable deadlines and expected to meet them sometimes good habits just get thrown out the window.
Drop down menus should come with an ok button. Undoing "overrated," which should have been "funny."
SIG: HUP
His argument is that it's worth millions of dollars to not have to deal with this guy
Not even close. This is a complete false alternative.
First of all, "assume no one else can do what this guy does" is about as sensible as assuming unicorns are going to come charging through your door. The number of people who can do what no one else does is extremely small. And if your company depends on something that esoteric you're doomed anyway.
More importantly, you could replace this guy with a couple of top-rank developers who might not have his "genius" but who would be able to save the company 90% of those millions, and do so in a sustainable, maintainable way, creating far more value downstream while reducing the churn you experience on the rest of the team because no one can stand to work with this jerk.
Team skills are empirically known to be the most important predictor of developer productivity, not technical skills. Go look it up in your copy of "Rapid Development".
It is never "either/or": a better team player with somewhat weaker technical skills is generally a better hire than a guru who can't play nicely with others, and the notion that gurus are so singularly valuable that they can't be replaced is simply false if you are running a viable business in the long-term.
Blasphemy is a human right. Blasphemophobia kills.
it also needs to Z in addition to X and Y!"
Or my personal favourite: "You know how we said X was critical to the success of the company and how you spent several months of your life implementing it? Well, we changed our minds. Now we think Z is critical. And can you make a few changes to Y while you're at it to make it more like W, so that when we change our minds again next week and resurrect X, Y won't work with X anymore and you'll have to redo X a different way from scratch? Thanks. Oh, and if you can have it on my desk by COB on Monday, that would be good, as I have a status meeting to go before my golf game. How's the documentation coming along? Not good? Nevermind, you can get back to it later."
OK, so I'm reading a little between the lines, but I get that most weeks.
I think the number of brilliant genius delicate hothouse flowers of programming genius are pretty rare. So rare, in fact, that it isn't even worth discussing (sorry Taco).
I think a FAR larger cohort of programmers fall into a category of people who have been in one place a long time, know the systems (AND business processes) really well and have done little to no documentation.
These people have you by the balls (as evidenced by me posting AC). If they leave you have to, in a lot of ways, start at square one. One can easily acknowledge that this was a management problem but even IF you try to institute best practices NOW these people will resist it because they know they hold power as operators of the Black Box. Every line of documentation removes a little bit of their power and leverage and it is the rare (and perhaps stupid) person who does that voluntarily.
Yes, I suppose the ubercoders are a problem too but I think it is a much smaller, and different, problem than the one I described. If a company is depending on a coding wunderkind then they are probably on the cutting edge of SOMEthing and bad documentation is something of an expectation in that arena.
If there is no documentation, the answer to the question, "Is it ready?" is "No." It's likely that the PHB doesn't know enough about what you're doing to disagree with you and grab your raw code from the repository and use it. If you establish a precedent for being done quickly (without documentation) then you get caught in a vicious cycle of it being expected that you'll be done quickly. It's best when the system supports proper documentation, etc. but if not, sandbag your estimates to give yourself time to do the job right, or at least half right. Over time, your productivity will catch up when you can figure out last month's or last year's code more quickly for a new feature because you took time then to document what you were doing.
Why do people feel the need to control quirky geniuses who are doing nothing wrong? Seriously, there's nothing in this example that's out of the ordinary, except for the women's t-shirts. That's what you get for having a casual work place. My thought would be that if the author has such a problem with this guy, maybe he needs to be skilled enough to replace him.
The T-shirts in the example are not the problem (though the hygiene might be). The problem is that he claims his code works and is self-documenting, when in fact it doesn't work the way the customer wants, and other programmers (the chief engineer at least) are unable to read his code.
That's the problem. That and his anti-social attitude of calling them names instead of helping them to fix his incomprehensible code.
If your competitor hires this guy they might be able to outproduce you just long enough to put you out of business. Doing things right is important, but staying in business is the *most* important thing.
The last thing you want is for your business to be dependent on one single person. Even if he's not some kind of cowboy/diva/jerk with no social skills, he may get hit by a bus, leave for personal reasons, or just get a better offer.
Unless you're so small that you absolutely cannot hire another developer, you should start weaning your business off of such a person. Now, while it still has a chance.
Lack of documentation only chains you more to a developer. It makes it that much harder for someone else to maintain the code base.
So let me get this straight:
If I conveniently don't document my code, I hereby increase my job security, because it'll make it harder to shitcan me because the other developers won't have a clue what I did because there's no documentation. Sweet, all I have to do is make it more expensive for them to shitcan me than keep me. It's pure brilliance!
Disclaimer: The opinions and actions of the US Gov't are in no way representative of those held by this author or its ci
Truth.
I've always considered that the indispensable genius/jerk should be given as many independent entrepreneurial opportunities as possible. As in kicked out the door. Go run your own business, genius.
I'll happily go head to head with someone who routinely alienates the people around around him and can't get his personal shit together.
You stop being a quirky genius soon as you declare yourself as one. Since then you're just a wannabe poser.
See that's why I'm NOT a quirky genius.
Exactly. There's nothing cool about trying to be a quirky genius. But if you happen to be a quirky genius, it's definitely cool to try to be a team player. That's what makes your genius valuable.
A genius asshole is just another asshole.
As a quirky genius, I have to say, if you don't like the way we do it... go fucking do it yourself. Should be good for a laugh...
Please let us know what absolute brilliant pieces of programming have come from you so as to show that you are entitled to this attitude. At least let us know what companies you've worked for so we can at least know what world class programs you've helped produce.
If you can't be replaced, you can't be promoted. Hope you like your current job.
*sigh* back to work...
What's the net cost?
Let's accept for a moment the code may save millions of dollars as a line item.
Does this guy's attitude cause more frequent turnover in his department incurring continual overhead in dealing with recruiters or new employee hire/training costs?
Does his likely shoot-from-the-hip coding style work for his one use case and break things in ways he didn't bother to test or account for?
Does he drop code in the repository that's of a huge, "everything's changed" variety which causes downtime as developers have to spend time trying to understand the quirks of his new million-dollar-savings?
What was the nature of the change? Was it purely an infrastructure or refactoring type change that allowed maximization of existing resources, or did other departments have to message changes to clients? Was there any cost in client or customer service overhead as a result of this change?
Were there additional refactorings necessary to user interface, help materials, etc as a result of this change that hadn't been budgeted?
Great developers are awe-inspiring. Truly, I work with a handful of people who blow my mind on a daily basis, unlike anywhere I've ever been. One thing I've seen from all of these guys though is that they communicate their skills because they're smart enough to know that if they *all* know it (to a greater or lesser extent), or at least grok the important points well, they can improve upon it further. Compared with a lot of "superstar" guys I've worked with who couldn't be bothered to deal with people who "couldn't understand their greatness". Rarely are these guys the unmatched geniuses they think they are.
Toxic employees are a liability... "superstar" is a label that is thrown around way too liberally.
Oh bullshit. Being an adult means not being an asshole to your co-workers.
As you said, you've all got to get along, so why allow one jerkoff to ruin everyone else's day?
I have no problem firing people that suck at life. I've never suffered for it.
Don't let one ass-clown's childish behavior cause issues in the work place. You'll have a more productive work place because of it.
Sent from your iPad.
I used to believe this. Then I found myself in a dead-end job because I was irreplaceable. I couldn't move up because the company couldn't afford to let me. So I found a new job. Unless you are content to be in one position for the rest of your life, being irreplaceable is bad for everyone involved. Now I contend that a wise employee starts training their replacement from day one.
I see the glass as full with a FoS of 2.
Yeah, and what if the owner of the company declares you one, and it happens in more than one company, and you regularly live outside the traditional chain of command of the company, answerable only to the owners?
Do you have an equal share of the company as the owners? No? Then I hope the pats on the head are worth it.
There's absolutely nothing specific to developers here. You have the same kind of people in every other job.
The one question you need to find an answer to is this: Teamwork or solo heroes?
If, for whatever reason, your project needs a team to work, say you want to support it for years to come and can not 100% guarantee that the one developer is still on board by then, or it is simply so large that you need more than one person to do it, then you absolutely can not use asocial people. Any and all attempts to somehow fit them into the team, or build the project around this inherent conflict will fail. You can't go faster than the speed of light, it really is that simple.
However, there are projects where you need a lone hero. A crash project that needs to be done with next week, and can be shut down the week later, but it absolutely must be there during that time, and there's absolutely no way you can get it done while following procedure. Or - the more common case - you inherited a project that only this one dude even understands, and you don't have the manpower to replace it or reverse-engineer it. And sometimes, you have a project you want to fail spectacularily, and absolutely no team will give you the same show for your money that a fanatical lone hero can bring.
So if you need a hero, then enable him, empower them, and suck it up. If you need a team, kick out the hero and make sure your team knows who to thank for it. Just don't try to have both. You can't. Been there, survived it, and I did, in fact, get a T-Shirt.
Assorted stuff I do sometimes: Lemuria.org
People like Josh, on the other hand, should be fired on the spot.
I don't think so. They can just be recognised for what they are, and treated accordingly. Think of him as a fire extinguisher--a pain in the ass to clean up after, but from time to time invaluable. Sometimes you need a solution NOW, and you will have time to clean it up (or re-implement it more carefully) later. Perhaps your expectations for him were too high. Understand your resources and learn to use them appropriately.
"The biggest problem with communication is the illusion that it has taken place."
Amidst all of this mud-slinging, we hear some actual examples of what Josh's supposed failings are. The first one is a developer on his team, who is responsible for implementing and patching version 1.0 of the code, decides to not do his work, and goes to Josh, who is writing version 2.0 of the code, and sounds like the head developer on that, and have Josh do his work for him. Josh tells him to fuck off as he is busy, on a deadline to write 2.0. Then Spiegel walks in. Spiegel is there to reprimand Josh for not pulling off his tight developed schedule, and deal immediately (without scheduling it) with a problem that his own incompetent developer can't deal with. Spiegel is shocked Josh isn't obsequious in the face of this demand. Josh's paycheck is dependent on him getting version 2.0 on time, why should he spend more than the 50, 60, 70 hours a week than he's currently working to dump everything immediately and go deal with a problem due to an incompetent developer who can't handle the work?
So the story is Spiegel has an incompetent developer on his team who can't figure out code and how to do his job, so the bad guy is the coder who everyone including his manager says is the best, most brilliant coder, who won't drop everything immediately and go work on Spiegel's problem. After which Josh will either miss his deadline or have to work even more hours than he has to, and Spiegel looks like a star for fixing his problem. As far as curtness, I wonder if Josh worked 40 hour weeks, had things scheduled far ahead with reasonable deadlines and a full and competent support staff in place? Why do I have a feeling that was not the case? Spiegel had a developer on his team and mentions the 2.0 team Josh is on. So why didn't his own developer or someone else on the 2.0 team look at it? Because Spiegel wants the star of the 2.0 team to drop everything and fix his problem.
I have a simple policy, for myself and for people who work for me.
/F
If it isn't fully documented, it isn't done. There are no excuses, period.
Stupidity... has a habit of getting its way.
perhaps brilliant people are angry because life sucks.
You poor fools who die boring, polite and pointless never realized the tragedy of it all.
Funny how what you think of as the boring and polite people don't actually think life sucks, eh? I get frustrated at the attitude of some sheeple too, but there is something to be said for being happy.
Sometimes these people are not actually boring either, just respectful. Speak to them in an informal situation and they might not be as boring as you had previously thought. You don't have to be a jerk to have fun.
which is totally what she said
Yeah, and what if the owner of the company declares you one, and it happens in more than one company, and you regularly live outside the traditional chain of command of the company, answerable only to the owners?
It happens especially in little company. I remember a client of mine. They had an "in house" programmer. It was probably the shittiest codes I have ever seen. No logic, redundant functions, etc. I remember a meeting with him, he played the arrogant know it all in front of me. He finally noticed that I was a programmer just like him. The tone changed.
He thought he was irreplaceable but the management has changed and the reason of my presence was to well outsource his work or to make him less "irreplaceable" due to the difficulties to get things right without crawling in front of him.
There are a lot of people like him, as soon as they know "a little" more than their fellow co-workers, they feel like genius...Until they meet another professional who didn't past the last ten years sleeping on its knowledge without ever documenting himself about the last techniques/tools.
"Josh" is the kind of guy that develops Googles, Yahoo, etc.
No he isn't. Well, I don't know about Yahoo, but Google invests in smart, maintainable code. Josh writes convoluted code that nobody else can maintain, and he's unable to work with others. You can't build a company out of that.
And there are far better coders out there who write self-documenting code that the other coders, the "average" ones, are able to maintain and fix.
The first job responsibility in our employee handbook is that we have to get along with other employees. In other words, yes, it is my job (and everyone else's job) to not piss people off. Unless Josh can literally do every job in the company, he's not worth losing other employees over. No matter how productive he is, he's not the entire company.
Plus, creating a hostile work environment is illegal.
Any company that tolerates assholes like this will have no other competent employees.
Except, cleanup (or re-implementation) never happens. What will happen is layer upon layer to work around bugs and problems. Because you can (almost) never justify to upper management that you need to reimplement something that works and the finish product is basically the same you started out with (with cleaner code, maybe).
Je ne parle pas francais.
Um no.
Because there are a lot of good people who can do the work and better and be a company player too. You are assuming that Josh's skills are irreplaceable. And that a good employee cannot do what he does. I am sorry, he is replaceable, and you can get a more professional guy to so the same job just as well, if not better because he is not so high on himself. I too have cleaned up messes after people like him. And let me tell you I have never seen any work by these guys that make me go wow this guy is my superior, in programming. Usually after a couple week I figure out the flow and I am just as productive as the guy was before, except people are willing to talk to me. Ask questions and raise problems that the other guy made them to afraid to mention.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
My local "Josh" is a genius, has gone from Athiest to American Indian to Christian to converted Jew (the last because he doesn't believe the miracles that Christians talk about), has a habit of telling the most inappropriate jokes, shows up when he wants, leaves when he wants, cannot/will not explain his code, will not code with others, insists the DB be designed to his standards, and produces code that does the job very well, but is utterly unmaintainable.
He also collects the bonuses and gets the trips and training money. (The last, training trips and seminars that he usually ends up walking out of because they don't go along his lines of thinking.)
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
I wonder to what degree "Josh" here is an exaggeration. I'll say that I'm probably the "Josh" of our office - to some degree. I don't wear offensive t-shirts, but I don't normally do suit/tie (normally a polo and jeans - though often the polo is untucked). I am regarded as one of the few "people persons" in IT though (contrary to the "Josh" example).
But, I am the odd ball out at work. I typically embrace new versions of software much quicker compared to many of our older workers who must be dragged kicking and screaming into an upgrade. I'll code stuff in whatever language I feel suits my mood and the requirements of a particular problem. I keep up to date with the latest technology trends.
The "documentation" thing is one that I hear a lot. I try to document what I do. But some people can be unreasonable. For instance, I setup an amavisd-new email filter. Now, amavisd-new is a well known open source tool. It's ALREADY documented. Is that enough? Nope. I'm expected to write NEW documentation for the tool so that the rest of the IT department (who doesn't understand much Unix) can use it. I don't mean a diagram as in "here's how I setup the system", as in I'm expected to produce documentation on "How to release a quarantined message" when it already exists.
Not to mention that when you look at how some of these people code and/or setup systems/databases, it's obvious just WHY they need so much documentation. The darned things don't make any sense. Without some ancient codex you can't make heads or tails of the system. So rather than do a clean and logical implementation, they'll do something that makes no sense and then go about it as if everything is OK so long as there's a written explanation of the kludge on file somewhere.
I think far too often "Josh" might simply be getting mud slung his way due to the shortcomings of his peers.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Productivity without control is like an accelerator without a brake. On a less extreme note, I worked with a guy who could crank out what seemed like klocs per day. Yet, when you looked at his code it mostly worked but had some dangerous problems, like servlets with member variables that had race condition issues.
I inherited his code and told my boss I would need at least 4 weeks to clean it up, otherwise every little change would take a couple of weeks. The previous developer had a good mental map of the horror show that was his code so he could fix it in a day or two.
My boss swallowed hard and I did the cleanup. I probably ripped half the code out and I reworked the rest into something approaching quality code. With the code base half as large, and appropriate javadoc comments, combined with a static class diagram, any idiot following after me should have been able to maintain it.
And that's what being an engineer is. That's what makes engineering different from a guy tinkering in his garage. The guy tinkering in his garage may be able to bolt stuff together and make a gizmo, but it's a one of a kind only he understand how to make. An engineer may take weeks to do the same thing but it's a repeatable process, with standard instructions, that can be replicated and repaired as necessary.
Josh is paid to do his job. Part of the job of a programmer is to work with others. Part of most people's job description includes things about hygiene, appropriate work behavior, teamwork, etc.
If Josh's coding results in ten thousand lines of spaghetti code with no documentation and riddled with single and double character variable names that result in other people not being able to do their jobs, then Josh is not doing his job.
If Josh and his office smell like a pile of garbage, he is not doing his job.
If Josh is saying offensive things to people, he is not doing his job.
In other words, Josh is not doing his job.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Yeah, I was all angsty in my 20's too. I had long frizzled hair and wore an army jacket with patches all over it, and hated the world and all the stupid morons in it.
I'm now in my 40's. I have a haircut, I'm sitting in an office cube wearing a polo shirt.
And I've got some news for you. It's *all* pointless. The end is the same for everybody. We're all worm food. Doesn't matter if you rage against the machine or oil its gears. In a hundred years, I promise you it won't matter one whit.
What does matter is what you do with the time your have. And I'll say this - I'm happier now at 40 with a nice job, nice house, nice car and a family I love dearly - however boring and polite it may be - than I *ever* was at 20 running around rebelling against everything mocking the stupid sheeple.
My advice would be to take whatever brilliance you may have and apply it to your own life, if you're able. Solve your own problems. Find whatever happiness you can. Because sitting around picking at your own wounds to keep them fresh doesn't do a single bit of good.
I have friends who never "sold out". They're miserable. Most are too poor to fix their missing teeth. If you sit around and tend a harvest of misery your whole life, then that will be your reward.
To sum up, life only sucks if you work at making it suck. Let it go.
Weaselmancer
rediculous.
They should be recognized as douchebags and fired on the spot.
Proper management and planning means you don't need a Josh on your team. 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.
There are very few irreplaceable workers in this world, and none of them work on code.
mh, true and false. a pseudo code for a fast Fourier transform would be undocumentable - extracting radix: wtf is a radix? but a clean call to a method called fft() with a one liner pointing at the algorithm (eg Cooley-Tukey implementation of a fast Fourier transform) would change the mess in a functional block easily testable, replaceable and maintainable
Only sheeple use the word sheeple.
Baaa.
Watch this Heartland Institute video
.
The -very- first thing they had me do when I arrived was produce page after page of documentation on how the hardware actually worked so that the software guys could understand it. It wasn't ground-breaking design, it wasn't super complicated, but it was subtle and you couldn't get the whole idea of what was going on without being able to speak Engineer (specifically the EE dialect). A lot of people in the company were terrified that he'd walk out one day and get hit by a bus and the company would have to spend a fortune it didn't have for a team of engineers to come in and tell everyone else how their own system worked.
When I asked him why there was no documentation (or very poor documentation when there was) the answer was a combination of "You shouldn't need documentation" and "I'm not paid to document things."
Well, actually... you are.
A few early experiences counseled me very strongly to enforce good documentation practices in my code and hardware design. Any design more complicated than a blinking LED (the hardware equivalent of 'Hello World') requires it - if you aren't documenting, you're not doing what you're paid to do. As TFA says, End of Story.
Scientists point out problems, engineers fix them
altslashdot.org: The future of slashdot.
It's not 1985. Comment space is cheap.
First, most functionality should be in functions (or methods, depending on your language). You wouldn't put stuff inline because that's a nightmare. However, at some point, you're going to have to write code that actually performs some kind of operation upon the data.
If you called the function fast_fourier_transform() or fastFourierTransform() (depending on your coding style) it would make it a lot easier on the maintainers and cost you nothing.
No matter what you called it, you'd still have to document the transforming function so that if you'd made a mistake in it, the next person looking at the code would be able to say, "oh, hey, this is supposed to be multiplied by -1 here"
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
Well, it's a myth that these great coders are valuable, as well. High level software development requires more than the ability to manage complexity. You won't find any Josh's developing high quality, vast enterprise applications. You won't find them developing a modern RDBMS, or anything that's _truly_ complex in terms of architecture, scope, and interaction with other systems.
You'll find Josh's hacking away on some custom application developed by a small or medium sized company and it'll be their one trick pony.
The reason is simple - to develop a large system it takes many people, you can't have a one-man show on large software products.
That "millions" number was probably pulled out of thin air but anyway...
How much would it cost to replace the good coders who might leave for a better work environment? How much would it cost to debug or port that guy's code after he left with no documentation? How much would it cost to defend the company in, say, a hostile workplace lawsuit?
Even the president of the US can be replaced as the last election showed. No one is irreplaceable, especially a hostile person.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
Because there are a lot of good people who can do the work and better and be a company player too.
Um no.
The article was about someone who can do an incredible amount of coding in a very short time. Indeed, more coding in less time than most anyone else.
It isn't that they weren't smart. In every case, these "great" developers were the most talented in the group. Their intellectual abilities and problem solving capabilities were unparalleled.
Obviously, if there are a lot of people who are equally fast and one can't work with teammates, then fire the asshole. But that wasn't the question. The question was how to deal with one asshole who can churn out more code faster than everyone else. You can tell me you're as good as anyone else until you're blue in the face--in which case your employer is lucky to have you--but that's not what the article was about. It was about someone who was much better than you (for a certain very circumscribed--but potentially useful--definition of "better").
Sure, if you spent sufficient time and money, you could find someone better than Josh. And ideally you do. There's always someone better on the market, out there, somewhere--especially in this economy. But if you have a limited budget for finding and hiring the best of the best, then an acceptable compromise is learning how to use the people you have. Understand what he is, and isn't, good for, and offer him what he's worth to the company. And learn to use him wisely.
"The biggest problem with communication is the illusion that it has taken place."
Having Asperger's isn't a good excuse to do a poor job or to be anti-social, or unprofessional. Yes you may have hard time following the right non-verbal queues. But things such as dressing appropriately for work, using the bathroom in the right spots, and a lot of the quarks that happen are due to bad behavior that people even with serious Asperger's can work one and minimize and be at a professional level. I don't take the idea, that I have a disability so you need to deal with my Crap mentality, it is basically reinforcing that they can behave badly, without having them work on improving themselves.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Except, cleanup (or re-implementation) never happens. What will happen is layer upon layer to work around bugs and problems. Because you can (almost) never justify to upper management that you need to reimplement something that works and the finish product is basically the same you started out with (with cleaner code, maybe).
Agreed; which is why this statement from TFS: "... could churn out code that saved the company millions" - is nonsense. It may look that way on the surface, but when accounting for all the code maintenance pains that inevitably follow, I've yet to see a single such "genius" that wasn't a net loss. What's worse, the expenses are quietly swept under the rug, or, even worse, shouldered by the rest of the team who gets flak when they can't keep up with the "genius" (because they're cleaning up after him).
The article was about someone who can do an incredible amount of coding in a very short time. Indeed, more coding in less time than most anyone else.
Because all he was doing was writing code. He took an hour to solve a problem that took the team 2 days. "The team" must have been at least 3 people. So that's occupying 6 programmer days. 40-45 hours. It would have taken him less than an hour to document or explain what the solution was. Is he really worth 40-45 times as much as the other programmers?
If the guy produces a lot of unmaintainable code then he's costing almost as much as he's making for the company. His personality problems will increase staff turnover, and he will eventually leave. Nobody lasts forever. When he leaves everything that he wrote will have to be documented or replaced at considerable cost.
Most programmers will be able to do most tasks. There are some highly specialised tasks that will require an expert in that area, but you can always find the appropriate expert. Anything else can be learned. You'll lose a developer for a few days while he learns but you'll gain a developer with extra knowledge, and the half decent ones will be happy to stick with a company that allows them to develop.
Being required to produce documentation along with one's design often makes the design better, because it encourages a design that's easy to document clearly. The lazyness principle makes you want to avoid tricky things that take pages of documentation. So even if you think the documentation as some crap that goes along with your nice, clean design, think of the task of writing it as no different than a unit test or other QA; it exposes problems you might not otherwise notice.
Except, cleanup (or re-implementation) never happens.
I'd say that's clearly not Josh's fault. If you hire a team of paratroopers to build you a bridge, then you try to use it as critical infrastructure for the next 30 years, it won't be the paratroopers' fault when a bunch of trucks fall in the river.
I absolutely agree!
At one point at a previous job, I was tasked with putting all of our projects into our project management software and prioritize. I built a tree structure with parent projects and sub-projects, where the furthest-out projects needed to be completed before the parent project could be done (so the root projects were easy to understand for the PHB, and we could deal with the smaller bits). Each level was prioritized based on the level, so I could tell what piece should be completed first (I worked that part out with the other developers so we all understood what it all meant, along with figuring out some of the lower-level priorities and building best-guess timelines).
After a week of prioritizing, arranging, and setting timelines, I brought it to the PHB. I explained the logic of the thing and how much I'd worked with the other developers in order to get it organized as such. He gave me a blank stare, asking why there were so many sub-projects and why he couldn't find the project he was looking for, etc. I explained the organizational logic, and he just gave me that blank, glazed-eye stares and then excused me.
The next morning I was called into his office, where he showed me (with a huge smile on his face) how he'd rearranged everything. There were no trees (projects with sub-projects) that explained dependencies. The timelines were changed to what he wanted them to be, causing 10-12 projects to overlap on very tight timeframes. EVERYTHING was a project (the sub-projects that were dependencies of parents were suddenly their own projects with incredibly low priority). Only the projects he was interested were prioritized, and there were dozens of projects set with the highest priority.
The funniest thing? Some time later we had a meeting where he told us adamantly that we should only EVER have ONE priority 1 (highest priority) item and that we shouldn't work on anything else until that priority 1 project was done. *sigh*
Sanity is like a condom: rather have it and not need it, than need it and not have it.
First off, sometimes there is a time basis that cannot be avoided and a solution, however dirty, is required right away in order to complete a contract or open a web storefront or the like. In these cases the original statement is literally true, millions could be made or lost depending on whether you can flip the on switch tommorow or next week. At that point, you're making money in the long term, regardless of whether you have to reimplement.
Of course companies are usually, imo, too focused on the here and now results anyway and this is a double edged sword. It can get you to market quicker, but I have time and again seen companies shopping for development libraries or other similar tools go against the selection of one vendor by EVERYONE who was going to use the product and go for another cheaper vendor that no one liked because it saves the company 100k right now, even though the cost of developing locally all the missing functionality from the cheaper solution will easily end up costing more that the saved amount in the long run.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
It's *all* pointless. The end is the same for everybody. We're all worm food.
is a great plan for mediocrity. There are struggles that are worthwhile and there are struggles that are pointless, but to say that no struggle matters is speaking from both ignorance and arrogance. I mean no offense, we're all ignorant and arrogant to some extent.
Doesn't matter if you rage against the machine or oil its gears. In a hundred years, I promise you it won't matter one whit.
I'll just give a few examples of why this isn't true: Martin Luther King, the Buddha, Jesus, Krishna (to whatever extent those last three are flesh and blood historical figures), Ghandi, US founding fathers, those who participated in the Tiannamen square incident, etc., etc., etc. All these people have had and will continue to affect life for humanity.
So, while it's true that blindly "raging against the machine" is pointless, just because you have
a nice job, nice house, nice car and a family I love dearly
doesn't make you any better or make your life more worthwhile or valueable than someone who can't afford to fix their teeth. Their pain and alienation may be far more meaningful than your "boring life" (your words).
All I'm saying is you don't have to settle for assimilation, blind hate, futility, alienation, mediocrity or ambivalence or comfort. Do something with your life and make the world a better place, but don't "sell out" or become so bitter that you are divorced from the world. It's not worth it for you or anybody else.
I wonder if perhaps there's an argument for pairing senior employees who do the critical design work with fresh hires to document the what and why of it. That way, the higher-up engineers don't have to write anything down and the junior engineers get to absorb some of their insight by osmosis.
Scientists point out problems, engineers fix them
altslashdot.org: The future of slashdot.
If my code takes more than a few seconds to figure out what it's doing, I keep rewriting it until it doesn't.
The golden rule of being a truly good programmer is that you write the code that you wish other people would write.
Write code that is self documenting by way of having very descriptive method and variable names. Because while it may take longer to write, you'll invariably end up reading it ten or more times more than you'll be editing it. So time making it readable & grokable is time exceedingly well spent.
here's a quick sample of what I mean:
Instead of this
if (thingy.getLastTime() - thingy.getCurrentTime() > 3600000) {
for (Calendar calendar : thingy.getCalendars()) {
calendar.update();
}
}
write this:
boolean isChangingTimeZones = hasChangedTimezones(thingy);
if (hasChangedTimeZones) {
updateAllCalendarsWithTimeZoneChange(thingy);
}
It's debugger friendly (you can see the value of isChangingTimeZones before you step into the if-then-block, and the logic is described via the variable name which has a corresponding method that can be easily unit tested) and all the names are descriptive as hell. Not to mention the action is decoupled from the logic, and could easily be more so. Either could be modified without ever changing that particular code. And yes, the boolean method should use a constant for that magic number. You can probably infer what that constant is, but why waste people's time making them infer when you can very easily tell them explicitly?
Question everything
But here's the catch, someone must write the code in the end. And someone must maintain it. And the code that is written is of varying quality. If someone is simply a better, faster programming, then their code will be cheaper to maintain because it will break less often and scale better (or whatever your metrics are for code quality). I find that a "nice programmer" might be easier to work with, but those Saturday night production outages make me hate that person all the same. And I'm much more likely to fire him at that point because I think that person is unlikely to have to skills to keep the code working.
Finally, I think this entire argument is a bit of a crutch. I've seen people who match Josh's description, but usually the best programmers are just crabby because so much of the work falls to them. Then they get painted with "Josh's brush" and labeled as having bad people skills. When really, they are just tired and overworked. If the people with "people skills" had to deal with even 1/10th the work, they would go on a killing spree within a week.
"Those that start by burning books, will end by burning men."
That metaphor can be extended to a surgical team, where you have one chief surgeon and everyone else around the table has a specific role and is there to assist. Or it could be extended to the 911 phone operators, where there is usually one operator on the line, and two assistant operators listening on the call and following the directions of the first (although, that part is almost never shown on 911 reenactments).
Personally, I have no problem letting another programmer take the lead when pair programming, my only two requirements are that we set some time aside for debriefing each other beforehand (so that I know where we're going) and that we set some time aside for debriefing each other afterward. I don't usually interrupt (unless I have to), and besides I take copious notes when sitting shotgun -- this is a trick I use to keep on paying attention -- while keeping the things I say to a bare minimum until later.
I find it also helps to let the person typing make their own mistakes, a typo, or what have you. Usually the guy typing will correct himself without interruption needed on my part. So if I see an error, I take a quick note of it in the margin of my notebook, and it's only after 10 or 15 seconds or just before the compile cycle, that I'll point out the errors as tactfully as I can.
That being said, that Amadeus reference you cited scares me. Most programmers are not at the Amadeus-level, and yet most programmers think that they are. And I can't tell you the number of times I've had to stop a fellow programmer from coding because he had no clue where he was going, and no clue on how to get there, he just wanted to make himself feel better by coding something -- anything -- right away.