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?
Reiser?
Couldn't resist.
But only if you're married to them.
Give me Classic Slashdot or give me death!
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.
It should ensure that lots of bored IT people with god complexes flock to his article and dream about how important they really are. Of course the reality is that just about everyone could get hit by a bus and within 2 months their names will be forgotten and the company will be just fine.
Lack of documentation only chains you more to a developer. It makes it that much harder for someone else to maintain the code base.
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
Most quirky developers don't defecate in the lobby or egregiously insult coworkers. They just have poor social skills, may have poor hygiene, may perform poorly on teams, and so on. In those (by far more common) cases, I've almost never seen a situation where the company would be better off without that person in some capacity. Usually it just requires moving them off some team project to a big one-person project that's been festering on the TODO list.
It's actually pretty hard to find really good coders, so I'd say unless they actually are so terrible in other ways that it's screwing everything else up, if it were my company, I'd try to find somewhere to put them that plays to what they're good at while minimizing any potential friction.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Yeah, get him a proper litter box. That should solve the problem.
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?
If someone says he and his monkey have nothing to hide, they almost certainly do.
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.
To make an analogy here, he sounds like the TO of coding...
The office females already notice you.
Right before they say things like "Oh dear God that THING.. that mouthbreather is looking at me again. I wish he'd just go away. Ewww gross, look how sweaty his palms are. Think he's ever heard of a shower?"
Sock Puppets: damn_registrars=pudge_confirmer=jimmy_slimmy=raiigunner=cml4524=a_klavan=red4men=ronpaulisanidiot
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.
It's up to management to apportion work to where it's done best. Some people work well in teams, some better as individuals. Make use of people's strengths and give them the work that suits them. Rudeness is not necessarily an offence (though harrassment of e.g. female coworkers is) - it's just part of the price. If it's not worth the cost, then don't employ him. Similarly with obscure code and prima-donna behaviour: if the overall cost of writing and maintenance is lower when it's all done by easily-managed people, then that's who you should employ. And make sure the same test is applied to the CEO.
I worked for a small company that severely underpaid it's employees. As a result, most were people who were just out of college (me), couldn't get a job elsewhere, or didn't want to move because of family connections in the area. Many employees quit right after a spouse graduated from the nearby University.
One of the programmers was brilliant, but actually insane. He could look over your shoulder and debug the page on your terminal in a few seconds. That is, when his meds were working. He would check himself into the local mental hospital for weeks at time, during which he was truly unavailable. They kept him around because they couldn't afford to hire real programmers.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
... 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.
I've been pushed hard on projects before -- and been told that documentation wasn't a priority, that getting the code out was. (I had a sign on my wall that said 'Documentation is Phase 2', a direct quote from my manager).
Now, "Josh" seems like he has some personality issues, sure, but don't bitch about the documentation thing. If anything, I find that documentation can be harmful (if it's not kept updated as the code is), and that it's often best when it's written by someone _other_ than the coder who already knows everything (so they don't bother documenting all of the 'obvious' stuff that's only really obvious to them).
If this "Josh" were worth the cost of 4+ "normal" programmers, assign someone extra to follow behind his commits and document what's going on. The lack of documentation is a company problem, not just one programmer's.
Build it, and they will come^Hplain.
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.
Since the article was written from the perspective of someone who is upset with Josh, and therefore prone to paint him in a negative light, I'd like to offer some words that may balance the perspective. I'm no fan of people like Josh, so the following is the devil's advocate perspective:
By way of metaphor, it seems like Josh is the only Integer Unit in a CPU burdened with processing lots of integer-heavy code. He is a resource for which there is a lot of contention. Someone tried to have someone else on the team (say a floating point unit) solve an integer problem, and all they could muster was to go to the Integer Unit, who is already bogged down, and beg for help. Apparently, in this organization, Integer arithmetic is deep voodoo that nobody else can do. Everything flows through Josh. The odds that someone will relieve him of his duties long enough to generate a HowTo on adding two ints are pretty small.
Odds are that the project managers around him aren't thinking in terms of resource contention and how to alleviate it. They may make noises that sound like they understand that task B, with a lower priority than task A, will be starved until A is completed - but then tomorrow they'll still be asking why B isn't done, knowing full well that A is still in queue and they set the priorities themselves.
Even if they do understand priorities, they'll probably constantly adjust priorities eating Josh's productivity with lots of context switching and pipeline stalls.
They need more people who can do what Josh can do. Once he's no longer the only Integer Unit, he won't be able to afford to be a douche-nozzle. If this outcome is worth it to them, they'll pay for it. If it isn't, they'll whine in an editorial.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
"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.
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.
I used to have a better sig but it broke.
The couple of "hero" coders like this I've seen in the past are, to a large degree, sucking productivity directly from other coders. Their complete lack of documentation, zero time spent naming variables/functions with whatever gobbledygook ran through their head momentarily, etc., winds up bringing other coders' work to a complete screeching halt. Intentionally or unintentionally, they arrange it so they're the only person who can manipulate the codebase. So the whole "hero worth millions" idea is really just a facade.
Example from this month's Game Developer Magazine: Near the end of a production cycle, one game is way over memory budget. Entire staff (engineers, artists) spend weeks cutting stuff out: reducing polygons on models, downgrading textures, etc. Everyone sweats it out and comes up 1.5 MB short. On the last day a senior coder goes in to where he'd hidden a 2MB string allocation at project start (completely unused), snips out the one line, and is hailed by everyone as having "saved" the project at the last minute. That's the kind of bullshit going on with these sociopath coders.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
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.
A while back, I worked in a video production place where the lead engineer was an asshole. He was rude to everyone, and made a point of telling everyone how irreplaceable he was in every way.
Meanwhile, he spent most of his day sitting in his office, looking through hardware catalogs - and never bought anything useful. Once in a while, some computer or video box would arrive, he'd have me unpack it and set it up, and then he'd berate the poor people who had to use them for not knowing how (he bought a really cool SGI workstation and dumped it on a girl who had never even seen one - she was a Photoshop artist).
He used to set really long schedules for simple things, too - he told me I had to come in for a couple of months on weekends to put connectors and labels on a bunch of prerun video cables. It took me four hours. So he got mad, and told me I had to come in anyway, because he'd already set the schedule, and it was my fault for working too fast (and he also complained about paying me overtime, instead of thanking me for doing it fast and correctly).
Yes, these people do exist...
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:
http://rocknerd.co.uk
I used to comment my code's 'intent' and document what I was trying to make it accomplish. (Instead of, and I kid you not, writing shit like "C = C + 1; /* add one to C */" [What was C counting, you fucking butt munch? There's terse and then there's stupid.] )
Then and only then, after documenting the intent, would I feel free to write the code.
I ended up giving courses to the other programmers because I was doing things in CICS Command Level COBOL that they had never heard of (like dynamic memory allocation to take a data structure and stand it on its ear.)
There were two ways to approach the problem.
I choose NOT to be a cock-biting ass-hole about it.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
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."
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
I will be if I get promoted one more time.
The two levels above me have no clue (they were reorganized over our department but really don't know who anyone is or what anyone is doing or what is important and what is trivial).
I was always a leader type (lead sports team, lead online guilds, organized groups) so being a low level manager is fun. I was a solid intuitive maintenance programmer. I was not a brilliant developer but after loading the code, I could figure out problems in a non-logical fashion.
I'm solid at building morale, coaching programmers how to game the system better so they get promotions and raises, and running programmers and projects so they arrive on time without the programmers having to work overtime.
And I have carpal tunnel so I can't do head's down coding any more.
I'm good at where i am- but if I were moved another level up, I'd be another clueless manager.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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.
.
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.
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."
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 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).
Software development is 40% technical and 60% people. Even though he my get twice as much technical done his bad people skills are affecting his usefulness, and still needs at least 20% people skills to be useful, however to balance him you will need to hire someone who is like 10% technical and 90% people skills just to support him. So you are in essence paying twice as much to get slightly less then twice output. You are better off with 2 people who can do 40/60 balance. As you will get twice the output without the risk.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
The folks who do extreme programming have a metaphor for this; they call it "technical debt", and point out that if you don't pay your debt down pretty quickly after running it up, you're going to get into trouble. Generating technical debt, they say, is an inevitable consequence of programming. But good programmers immediately clean up at least most of that debt as soon as they've finished implementing whatever they're working on.
The metaphor works. Managers are quite able to understand it, and it does seem to help in explaining what it is that's wrong with the kind of programmer we're talking about.
(They also have something else that might help in this situation: pair programming)
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.
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.
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.
For example, I was once able to give Microsoft the exact byte offset in Word's binary where their bug lay, that would cause a very rare, difficult to reproduce system crash - this was way before Mac OS X, so application faults would hang the whole machine.
I have Bipolar-Type Schizoaffective Disorder. Because it's just like being manic depressive and schizophrenic at the same time, it is one of the very worst mental illnesses that one can have.
It is very rare, poorly understood and notoriously difficult to treat. My symptoms include depression, which has been suicidal at times - I've attempted in a serious way twice - a profoundly euphoric state called mania, auditory hallucinations and, in my case, visual hallucinations that coordinate with a profound paranoia that leads me to believe that a shadowy, secret law enforcement agency I call The Thought Police are coming, not to arrest me, but to kill me.
I call them The Thought Police because they are The Police Inside My Head. You see, I know very well that they're not real. Unfortunately, just knowing that one is paranoid doesn't make the paranoia go away. When I look directly at my attackers, I can see that they're not there, but when I turn away I can feel their presence again.
There are Five Axes of psychiatric diagnosis. That is, one's Madness is a point in a sort of five-dimensional vector space.
Schizoaffective disorder, schizophrenia and manic depression are all biochemical axis diseases; they are caused by screwed up brain chemistry. They are thought to be genetic, although there is some evidence that schizophrenia can be caused by infectious disease when one is either in the womb or very young.
Biochemical axis illnesses are generally incurable, but their symptoms can often be relieved with medication. I know very well what would happen to me should I ever weary of my life on the run and decide to turn myself in to The Thought Police - and so I am very diligent at taking my daily dose of the powerful, expensive, mind-altering drug which gives me the comfort of staying a step - but just a step - ahead of Them.
There is also a neurotic axis. Neuroses are purely psychological in origin and are usually caused by some kind of unresolved trauma, usually experienced as a child such as sexual abuse, but it can arise in adults too, as with the war veteran's Post-Traumatic Stress Disorder.
Ironically, many neurosis originate as adaptive strategies, that enable the neurotic to survive their terrible ordeal. Thus the soldier who learns to dive for cover at every sharp sound survives the war, but is unable to return to civilian life after returning home - because he still feels the need to dive for that safety.
The little girl who survives her pedophile by imagining his advances to be courtship by a handsome prince my not find her Castle in the Sky such a wonderful place to live when she grows up, gets married and has children of her own.
The neurotic axis illnesses can all be cured, and through "talk therapy" alone, without the use of any drugs - in fact, using drugs to relieve one's symptoms can actually relieve one of the need to ever get better.
Unfortunately, the cure generally takes many years and is collossally expensive. In my case I estimate that I paid just one therapist sixty thousand dollars for thirteen years of weekly psychotherapy sessions.
Request your free CD of my piano music.
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.
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.
Do not mock my vision of impractical footwear
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.
That's because while you're pair programming, you spend 80% of your time programming and 20% of your time talking about it. When you're solo programming, you spend 80% of your time reading slashdot and 20% of your time programming.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.