Forgot your password?
typodupeerror
Programming IT Technology

Are Quirky Developers Brilliant Or Dangerous? 1134

Posted by CmdrTaco
from the hey-wait-a-minute dept.
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?"
This discussion has been archived. No new comments can be posted.

Are Quirky Developers Brilliant Or Dangerous?

Comments Filter:
  • by p3on (1245484) on Monday March 16, 2009 @10:15AM (#27209629)
    why are the mutually exclusive?
    • by tgatliff (311583) on Monday March 16, 2009 @10:28AM (#27209837)

      Exactly... To the average layman, the thought of a "Dr House" type principle always applies. For the people who actually do high end development or research work, however, they realize that intelligence is only useful if the person can work with other people or can effectively communicate his work. Also, documentation of that work is essential...

      In short... it is only mutually exclusive if you are in a room full of a bunch of business MBAs who apparently as a whole still think that solutions come out of some magic hat somewhere...

      • by neapolitan (1100101) on Monday March 16, 2009 @10:38AM (#27209965)

        Agreed totally. I wish more people realized this and thought like you.

        I, too, can write obfuscated code and appear "genius-like." It is a whole lot harder to bring *everybody* along than to rocket yourself ahead, make yourself appear to be esoteric and "invaluable," and, in a sense, bully everybody else into compliance. Now, we don't have enough details on the particular story to know if his colleagues actually were bad.

        However, I spend a good deal of every day helping people that may be not as quick or sharp as me in many ways, but that is my job.

        Finally a point regarding documentation -- I'm sure that every programmer here has come back to code that he/she wrote, and thought, "Man, this guy (me) is a genius. However, it just took me 30 minutes to understand how I did this!"

        Early on in my programming life, I thought this was indicative of my awesomeness as a programmer. Now, I just think it is poor documentation, and largely a waste of time. If I can't figure out how I did something a year ago, it would take other people twice as long... They may appreciate the clever implementation, but in the large scheme of things that is not efficient, nor awesome.

        • by Skreems (598317) on Monday March 16, 2009 @11:21AM (#27210717) Homepage
          Exactly. I'm always amazed by people who think that writing impenetrable code is "advanced". Any jackass can write something convoluted and obscure that nobody else can understand (or maintain) -- what takes actual talent is condensing complicated logic into code that's simple enough a ten year old would understand it. If you can write a complex system such that a teammate can open any random code file and think "what's so hard about that?", then you deserve some of the appreciation that "Josh" made a grab for.

          People like Josh, on the other hand, should be fired on the spot. I can't tell you how many hours I've spent cleaning up the mess left by people who thought that sheer volume of output was the measure of a good programmer, and I'm betting I'm not alone in that.
          • by fugue (4373) on Monday March 16, 2009 @11:43AM (#27211121) Homepage

            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.

            • by Dionysus (12737) on Monday March 16, 2009 @11:55AM (#27211345) Homepage

              Sometimes you need a solution NOW, and you will have time to clean it up (or re-implement it more carefully) later.

              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).

              • by Kell Bengal (711123) on Monday March 16, 2009 @12:48PM (#27212257)
                I've been in exactly this situation: we were an custom GPS electronics company where one very talented electrical engineer built the hardware from the ground up (and he and a whole team of software guys did the code). I signed on as his lackey to do additional electronics development on the side because his time was 'so valuable' and they needed more stuff done besides

                .

                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.

              • by shutdown -p now (807394) on Monday March 16, 2009 @01:25PM (#27212919) Journal

                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).

            • by jellomizer (103300) on Monday March 16, 2009 @11:58AM (#27211373)

              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.

            • by Greg_D (138979) on Monday March 16, 2009 @12:13PM (#27211651)

              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.

              • by fugue (4373) on Monday March 16, 2009 @01:17PM (#27212775) Homepage

                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.

          • by Imagix (695350) on Monday March 16, 2009 @11:54AM (#27211333)

            Exactly. I'm always amazed by people who think that writing impenetrable code is "advanced". Any jackass can write something convoluted and obscure that nobody else can understand (or maintain) -- what takes actual talent is condensing complicated logic into code that's simple enough a ten year old would understand it.

            I'm reminded of two quotes.

            One from Einstein: "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

            The second from Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

          • Unmaintainable (Score:5, Insightful)

            by WED Fan (911325) <[akahige] [at] [trashmail.net]> on Monday March 16, 2009 @11:59AM (#27211387) Homepage Journal

            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.)

          • by hairyfeet (841228) <bassbeast1968@NOspaM.gmail.com> on Monday March 16, 2009 @12:09PM (#27211575) Journal

            But then there are also the flip side to the problem. I did some temp work with a company that had a "Josh", lets call him Jim, and hell, everybody really liked the guy. He could whip off code like you wouldn't believe and solve problems that others had been stuck on for weeks in minutes. So what was the problem?

            It was, for lack of a better description, what I like to call the "head too full" syndrome. The guy knew how to write badass code in what seemed like every language from BASIC to the latest language o' the day, but trying to get docs out of the guy(hell trying to get comments you could actually understand out of the guy) was nearly impossible because he had already moved on to the next problem in his head by then. I spent about a week setting up his new machines the way he liked them and talking to the guy. Afterwards one of the higher ups stopped me and said "You always seem to have good ideas about things. What would YOU do to make Jim's work day easier?". I could tell the company would frankly fall apart without Jim so I said "Honestly? Find a guy with a little programming knowledge who can sit in the office next door and write docs for Jim. Because every time someone asks him for an explanation or docs you are going to throw him "off his groove" and it will take him a day to get his groove back. Let him do what he does best and let somebody else follow behind him writing the HOWTOs."

            So I would say, yes some are quirky because they are frankly asocial asshats. But I'm sure there are plenty like Jim who just have "heads too full" that are just not thinking like we think. I mean, I would be having a conversation with the guy about the old days of Commodore and Atari programming when he eyes would glaze over and he would smile and then suddenly he would just blaze out this huge complicated mess of code that frankly WAS brilliant and would have taken anyone else weeks to cook up. Did he mean for it to be complex or weird? Not really, that was just how his brain worked. And expecting him to fit in the cubicle mentality would have just had the guy frustrated for a couple of weeks until he got tired of it and quit.

            So I guess what I am trying to say is that you really have to base how you handle a "Josh" based on the situation. Are they acting the way they do because they are asocial? Or because their brains really don't work that way? Because as we know Einstein had to have his address stuck on his coat when he was working on a problem because he would wander off deep in thought. I'm sure that most that ran into him would have thought him rude for not engaging them in conversation. But he wasn't TRYING to be rude, his "head was too full" to give even a moment's attention to anything but the problems in his head. And that was Jim to a T. Nice guy though. Maybe that is what makes the difference between a Jim and a Josh?

            • by aurispector (530273) on Monday March 16, 2009 @12:38PM (#27212053)

              The key difference is the willingness to work well with others. In any organization you need cooperation or long term it just won't work. Coding strikes me as a task that's particularly vulnerable to long term maintenance issues if it isn't properly documented/commented.

              You can blame management for putting up with difficult people, though perhaps they simply don't understand the depth and breadth of the problem. Sometimes all it takes is for someone to confront the person in question with a set of expectations - and be willing to pull the trigger if the standards aren't met.

          • by Venik (915777) on Monday March 16, 2009 @12:42PM (#27212141)
            It is equally amazing how programmers of average ability insist on branding brilliant code they have trouble understanding as convoluted and obscure. The only thing that matters here is the bottom line. If Josh produces code that makes the company millions, then this is all that matters. It is entirely irrelevant if some of Josh's obtuse co-workers with a pronounced inferiority complex think that his code is convoluted. Most managers I know would rather fire every idiot complaining about Josh's shenanigans, than to fire their obnoxious but talented cash cow. I had the privilege of working with a couple guys like Josh. Understanding their work and their methods may be challenging, but it is also rewarding. Most can't stand brilliant co-workers, but not because of their alleged eccentricity. Bell curve riders feel inadequate and threatened working with talent. They demand endless meetings, ceaseless telecons, and detailed documentation, as if reading documentation would actually make them understand genius. People like Josh rarely get fired: they just get tired working every day with the same morons and go for a better-paying job elsewhere.
            • by jellomizer (103300) on Monday March 16, 2009 @01:04PM (#27212561)

              The reasons that the "Josh" usually doesn't get fired is because the company has a small enough Dev Team that makes him the big fish in the little pond. And most of the people don't know that he is actually quite bad. His code may make millions but the truth is someone else can write code that will make the millions too, and make change over that much smoother. So they keep him as they know the mess it would be when he leaves and hopes they can change jobs before it falls on their head.

            • by NormalVisual (565491) on Monday March 16, 2009 @01:13PM (#27212703)
              It is entirely irrelevant if some of Josh's obtuse co-workers with a pronounced inferiority complex think that his code is convoluted.

              Until he quits, is hit by a bus, or otherwise becomes unavailable to maintain the undocumented, uncommented spaghetti mess that usually comes from these kinds of people. When the total cost of writing and maintaining "brilliant" code exceeds that of "average" code that provides adequate performance, then there's a problem.

              On the other hand, I've also had the pleasure of working with developers that are far and beyond my skills, but also are decent people to work with and document their work so that it's understandable without having to spend a week tracing through it. Such people are worth their weight in gold.
            • by MartinSchou (1360093) on Monday March 16, 2009 @01:44PM (#27213317)

              I'd place myself as slightly behind the bell curve (out of practice) at the moment (slightly ahead when up to speed). I'm quite capable of recognizing brilliant code. I'm also able to recognize code that makes absolutely no sense to me. At times those two are the same thing (meaning that the code is doing things way above my comprehension, not that the code doesn't work).

              The thing is - if that brilliant code turns out to have a subtle flaw or needs to be redesigned, how can you be certain that the originator is still with the company or the project? Sure, that brilliant code may have saved your company millions, but when the flaw allows people to siphon money directly from your bank account, how would you rather go about fixing it? Stepping through convoluted code or reading the documentation? Sure, "my code just works" is a nice reponse. I'm also certain that Einstein was a lot smarter than most of the Josh' out there, and if he'd just said "E=MC^2 - trust me" people would have told him to fuck off and come back when he'd shown the math that proved it.

              I've worked with people quite a few rungs above me. All of them are capable of writing documentation that I can understand. Documentation that cuts the time spent on my comprehension of how their code works by 90+%.

              Their job isn't just whipping out code. It's also showing that it works. How it works. The upside is I don't ask them nearly as many "stupid" questions, because while their code still in Klingon - but it comes with subtitles. It also means that once I've looked through this Klingon enough times, it'll start making sense. I might actually learn how to write some stuff in Klingon by reading what they've written (with subtitles). But in the software industry that's just a waste of time - who needs people actually learning stuff at work?

              Imagine the following scenario:
              Ed is a brilliant engineer and architect. He comes up with a way for us to build a trans atlantic maglev train route that runs under water in essentially vacuum tubes. He's even figured out how to make it cheap enough that trip from London to New York city will cost you 200$ and will take about two hours. His brilliance even allows the project to scale, so that if we swing the tubes upwards and really punch it, we can send stuff into orbit for a price of 1000$/ton.

              Now, instead of writing up the designs, specs for the materials, how to build the materials and so on, Ed's just going to tell the people involved how to do it by phone. Because of Ed's absurd brilliance and genius, this actually works for a full week, and his super human skills in JIT means we're now 12 miles into this tunnel.

              The 8th day however, Ed's rather unfortunate. Seems he decided to drop by the post office the same day that Dan the mail man went postal and killed everyone in the office. Including Ed.

              Since noone else knows how any of this stuff is supposed to work, we now have to give up on the tunnel project while we siphon through the few things Ed actually left behind.

              Now, in the real world Ed's demise would be somewhat of a setback, as we've now lost the lead engineer on the project. However, since Ed was a good engineer and architect, he knew he was supposed to put all these things down on paper before we started the project and put billions or trillions of dollars on the line.

              Now, in the software industry, we're very fond of calling ourselves engineers and architects. Unfortunately most of us (even in companies) really don't reach that level of excellence - we don't document what we do, either because we're too lazy or because the companies don't want to spend money doing that. That's fine - just don't consider yourself or what you're doing software engineering.

              I've actually had the pleasure of working for an engineering company as the only software developer/programmer. Imagine how flabbergasted I was when my boss asked me for documentation as well as actual schematics for the software I was making. Schematics as in fl

              • by Venik (915777) on Monday March 16, 2009 @02:37PM (#27214313)

                Interesting analogy but probably not applicable here. You see, Ed didn't just tell you how to build the train - he actually built it for you. True, the bastard hasn't produced a shred of documentation. And now, after Ed's unfortunate demise, you and your team of average engineers are scratching your heads, trying to figure out how to extend Ed's design to reach Tokyo. And the reason for your predicament is obvious: as an employer you lucked out to have a truly talented engineer working for you, but, being an idiot, you made no attempt to understand his work. You should have been searching high and low for engineers capable of understanding Ed's designs and working with him, however difficult that might have been. Instead, you hired some random guys off the street and let Ed work alone. Your problem is entirely your own fault.

                Talented people get bored easily. Something that you or I may find intellectually stimulating, they find obvious and prosaic. This is why, as the fortunate employer of a genius, you hire capable people who complement his talents. You don't make soup out of your goose just because he won't document the process of laying golden eggs.

        • by tixxit (1107127) on Monday March 16, 2009 @11:22AM (#27210739)

          One of the best courses, I think, during my undergrad was a practicum course. We started off with a fairly simple project. The teacher gave us some requirements, but told us that for the rest of semester, each assignment would simply be new requirements to the original project and that, as we are developing it, we must keep that in mind.

          Some people in the class just brushed it off, did the usual homework thing and just rushed it out as fast as they could. Others spent a little longer on the first assignment, trying to anticipate future requirements, and make it general enough that they could add them if needed. After each assignment (there were 4), she'd ask people how long they had spent implementing the new features. In the end, it turned out that saving an hour on the first assignment, cost you about 2 hours on the second assignment and, unless you basically rewrote the first assignment, it just got worse as time went on.

        • by crovira (10242) on Monday March 16, 2009 @11:31AM (#27210915) Homepage

          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.

          • by Beardo the Bearded (321478) on Monday March 16, 2009 @11:53AM (#27211287)

            I once wrote a coder / decoder for control messages for a radio system.

            The code itself was about 30 lines. With comments explaining WTF was going on, it was about 150. There were backsteps, cycling through arrays, multiple search trees, etc. Part of the comments included basic theory on the decoding mechanism.

            There was no way good variable names or "self-explanatory" code would have worked there.

        • by tedrlord (95173) on Monday March 16, 2009 @11:34AM (#27210965)

          They may appreciate the clever implementation, but in the large scheme of things that is not efficient, nor awesome.

          Whenever I hear the word "clever" relating to code, I cringe. I generally use it as an insult. In any professional project, clever code generally means "unmaintainable."

          • by Rorschach1 (174480) on Monday March 16, 2009 @12:24PM (#27211805) Homepage

            Generally true. Sometimes clever is necessary, though. I do most of my programming these days on embedded systems, where size and speed are absolutely critical. I'll occasionally do something horribly non-standard and convoluted (usually to avoid writing even more annoying inline assembly code), but I've learned to allow about a 3-to-1 comment to code ratio in those cases. Even something not that complicated but just unusual (casting a char array to a function pointer and calling it because that particular buffer is the only one available to hold the flash programming code that has to be copied down to RAM, for example) warrants a clear, concise description of what the hell is going on.

            No matter how sure I am that I'll remember how something works and why I did it, I still try to always comment it. I'm sure everyone here (who's been programming for more than 3 years anyway) has gone back to code they wrote 3 years ago and thought "what the hell is this, and what was I thinking?". In my experience that's usually followed by a quick correction, and then after a few hours of chasing down some obscure bug that subsequently appeared, remembering why you did that in the first place and putting it back the way it was.

        • by homerjs42 (568844) on Monday March 16, 2009 @11:38AM (#27211021)
          I've also encountered the corollary -- I find some absurdly written ridiculous piece of code and wonder what moron wrote it only to find my own initials in the comments.
      • by Maxo-Texas (864189) on Monday March 16, 2009 @11:05AM (#27210405)

        The problem is that smart people get very irritated working with fools.

        Our corporation has now cut our productivity by 75% in the last 5 years due to SOX related procedural changes. It takes 45 days to put a 1 line code change into practice.

        The smarter developers got irritated, then angry, then acted out, then most of them left. The few who remained were mostly burdened with debt and couldn't afford to take the risk. So they take anger management courses and let the corporation destroy them as people.

        There are appropriate places for smart developers-- in projects where they save millions of dollars.

        There are fewer and fewer jobs for smart developers. Corporations prefer predictable pleasant programmers over brilliant good programmers. They would prefer that a project *definately* take 16 weeks instead of taking 2 to 9 weeks.

        Even tho I was smart enough to move out of programming and into management, the culture slowly driving me insane as well. As far as I can see after a few promotions is that it is is turtles all the way up and the problem is coming from somewhere above 5 levels of management above me.

        • by ClosedSource (238333) on Monday March 16, 2009 @11:35AM (#27210979)

          "They would prefer that a project *definately* take 16 weeks instead of taking 2 to 9 weeks."

          I've obviously been working for the wrong companies for the last 25 years. They would prefer that a project definitely takes 1 week.

        • by nine-times (778537) <nine.times@gmail.com> on Monday March 16, 2009 @11:47AM (#27211197) Homepage

          The problem is that smart people get very irritated working with fools

          Of course, really extremely smart people can outsmart fools into getting them to do what they want. Really smart people get more irritated working with other smart people who have opposing agendas.

          There are fewer and fewer jobs for smart developers. Corporations prefer predictable pleasant programmers over brilliant good programmers. They would prefer that a project *definately* take 16 weeks instead of taking 2 to 9 weeks.

          I don't do software development, but as a manager, yeah, I'd generally rather work with pleasant people who do their jobs "slow and steady" rather than the "brilliant" but unreliable guy. The real issue is often not the uncertainty about exactly how long a project will take, but uncertainty about whether you can trust what you're being told how long a project will take.

          What I mean is, yes, I'd rather have someone working for me who says, "I can get this project done in 2-9 weeks" and gets it done in <9 weeks then someone who says, "I can get it done in 16 weeks" and gets it done in 16 weeks exactly. 9 weeks is shorter, that's an easy call.

          The problem is dealing with someone who says, "I can get it done in under 9 weeks," and then sometimes it takes 2 weeks, sometimes it take 9 weeks, sometimes it takes 23 weeks, and sometimes it never gets done. I'd generally rather take the steady 16 weeks over that sort of thing. A steady-16-weeks allows me to make other plans, make promises to other people, and set other deadlines. With the theoretically-9-weeks-but-who-knows answer, everyone would actually be better off being told, "I have no clue how long it will take," because at least then there would be no false expectations.

          All of this is just to say, I'd rather have people that I can rely on than theoretically brilliant people who are just going to do whatever the hell they feel like.

          • by Miamicanes (730264) on Monday March 16, 2009 @12:20PM (#27211749)

            > The problem is dealing with someone who says, "I can get it done in under 9 weeks," and then
            > sometimes it takes 2 weeks, sometimes it take 9 weeks, sometimes it takes 23 weeks, and sometimes
            > it never gets done.

            In most cases like that, here's what really happens...

            Mgt: "How long do you think this will take?"

            Programmer: "Er, I guess 3 months or so, assuming nothing major goes wrong along the way."

            Mgt: "That's too long! We need it in 8 weeks. Can it be done?"

            Programmer: "I doubt it. Maybe if god parts the skies and makes a miracle happen."

            Mgt: "It's really, really important. In fact, it really needs to be done in 6 weeks."

            Programmer: "You're insane. There's no way in hell it's going to happen."

            Mgt: "OK, I'll allocate 8 weeks."

            Programmer: (sigh) "Whatever."

            8 weeks later ...

            Mgt: "Is the program done?"

            Programmer: "No. We'll probably be done in another month, maybe two at worst."

            I think you see where this is going. The programmer had a decent idea of how long it would take, and could have probably given a more realistic estimate within a few days had he been encouraged to identify the riskiest parts of the project (specifically, third-party libraries and things constrained by real-world hardware/network performance) and try to tackle them *first*. However, if management twists his arm backwards, or keeps pressuring him for a "better" (ie, shorter) estimate, he'll eventually get disgusted and throw them the number management wants... rationalizing that it's not *quite* a lie since miracles occasionally happen, and absolving himself of any moral responsibility for actually agreeing to a deadline he views as ridiculous since he was coerced into it.

            That, IMHO, is the root of more miscommunication between management and developers. Far too many managers don't quite understand that programmers *hate* interpersonal conflict, and will casually agree to just about *anything* if they think it will get the person to quit bothering them. The constructive way to deal with it is to begin by asking the programmer for a range (best case vs likely worst case), then ask him to identify the riskiest factors influencing the range, then nudge him to tackle those factors first so a better estimate can be refined quickly. Just don't make him feel like you're twisting his arm or browbeating him, because estimates are like information from interrogation -- torture will get you the answer you want quickly, but the answer itself will likely prove to be worthless.

      • by qbzzt (11136) on Monday March 16, 2009 @11:22AM (#27210743)

        Paraphrased from something I read.

        Walking on water is nice - but to really bring value you need to freeze it, so other people will be able to follow behind you.

    • by Trifthen (40989) on Monday March 16, 2009 @10:35AM (#27209919) Homepage

      I was going to moderate this "funny," but thought the same thing myself. My answer to the OP's question was "Yes." Because anyone, really, can be these things, and we need to stop with the fallacy that only IT people can be self-absorbed assholes.

      Anyone can be brilliant. Anyone can be a jerk. Sometimes these two things overlap. I'm not convinced that there's a higher penetration of this in IT than any other profession.

    • by h4rm0ny (722443) on Monday March 16, 2009 @10:46AM (#27210117) Journal

      why are the mutually exclusive?

      Or related?

    • by Myrimos (1495513) on Monday March 16, 2009 @11:32AM (#27210917)

      TFA is confusing "quirky" with "asshole." I love working with quirky people -- people who look at the world in entirely different ways, people who solve problems in a different manner, and people whose idiosyncrasies make them genuinely fun to be around.

      I can't say that I enjoy working with assholes, though. It doesn't matter how good your code is or how quickly you put it together, I can find somebody almost as good who's a lot less of a pain to work with. The extra little bit of efficiency isn't worth the metric cockton of assholery.

    • by Foofoobar (318279) on Monday March 16, 2009 @12:03PM (#27211471)
      Here's one reason why... I was Bipolar II which meant I was mostly manic. As a result I was easily angered, very enthusiastic, easily empassioned and highly creative. My brain went a MILLION miles per hour in that state and I had brilliance that I couldn't contain at times. I already have an IQ of 160 and during that state it was up 5-10 additional points (when I could stay focused).

      Tack onto that the boundless energy the condition gave me and the fact that I never slept in that state and you have exactly what you described. I felt untouchable and alive like no one could imagine. So why did I go on meds? Well, that's the trick. How do you get bipolars or other people who have a self destructive disorder that makes them feel superior or more intelligent go on a med that dumbs them down or slows them down?

      I hit that point where I realized my condition was isolating me and shutting me off from everyone else around me. When I examined my life, I realized I had no one to blame but myself; I burnt people out like matches but couldn't see that I was the one common factor in all the damaged relationships. More exactly, my condition.

      I eventually got better and now write my own documentation, get along with others, don't have mood swings at work, etc etc. It took me years and lots of hard work and effort to get over old emotional habits... the meds don't do it alone.

      But I guess what I am trying to say is that sometimes brilliance comes with madness. Sometimes it's just madness, sometimes it's both. Getting them to help themselves though can be almost impossible though.
  • Dangerous (Score:4, Funny)

    by Hatta (162192) on Monday March 16, 2009 @10:19AM (#27209687) Journal

    But only if you're married to them.

  • by ivan256 (17499) on Monday March 16, 2009 @10:19AM (#27209689)

    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.

    • by Anonymous Coward on Monday March 16, 2009 @10:26AM (#27209813)

      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.

    • by Hozza (1073224) on Monday March 16, 2009 @10:27AM (#27209827)

      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.

  • by sunking2 (521698) on Monday March 16, 2009 @10:20AM (#27209713)
    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.
  • Funny... (Score:5, Insightful)

    by mdm-adph (1030332) <mdmadph.gmail@com> on Monday March 16, 2009 @10:22AM (#27209737) Homepage

    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?

    • They do exist (Score:5, Interesting)

      by Maximum Prophet (716608) on Monday March 16, 2009 @10:29AM (#27209849)
      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.
    • by guidryp (702488) on Monday March 16, 2009 @11:16AM (#27210613)

      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.

  • by Trepidity (597) <delirium-slashdot@h a c k i sh.org> on Monday March 16, 2009 @10:22AM (#27209761)

    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.

    • by Lumpy (12016) on Monday March 16, 2009 @10:28AM (#27209839) Homepage

      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.

      • by Rene S. Hollan (1943) on Monday March 16, 2009 @10:55AM (#27210269)
        Really is it that hard to spend 10 minutes in the morning, EVERY MORNING to bathe yourself??

        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.

      • by RightSaidFred99 (874576) on Monday March 16, 2009 @12:59PM (#27212465)

        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.

  • by Anita Coney (648748) on Monday March 16, 2009 @10:23AM (#27209769) Homepage

    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?

    • by rolfwind (528248) on Monday March 16, 2009 @10:58AM (#27210299)

      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?

      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 [youtube.com]
      http://www.youtube.com/watch?v=izE4_Jd2dOw [youtube.com]
      http://www.youtube.com/watch?v=f3XeRCAAkZY [youtube.com]

    • by stevied (169) * on Monday March 16, 2009 @11:20AM (#27210707)

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

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

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

  • simple economics (Score:4, Insightful)

    by circletimessquare (444983) <circletimessquare&gmail,com> on Monday March 16, 2009 @10:23AM (#27209771) Homepage Journal

    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

  • Dr. House Syndrome (Score:5, Insightful)

    by EastCoastSurfer (310758) on Monday March 16, 2009 @10:23AM (#27209775)

    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.

    • by java killed the dino (935800) on Monday March 16, 2009 @10:26AM (#27209809)

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

      It isn't?

    • by russotto (537200) on Monday March 16, 2009 @10:38AM (#27209967) Journal

      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.

      Right. And that must be stopped. Because extraordinary results shouldn't result in extraordinary rewards. Genius developers who can solve problems in an hour which could take the rest of your team a month or more should get the same cubicles and be subject to the same strictures as everyone else.

      Sorry, I'm not buying it. It's hard to compensate a quirky genius developer. You can pay them well (and usually have to), but that only goes so far -- they generally aren't like CEOs for whom money is the end rather than a means. Perks like an office rather than a cubicle are perfectly reasonable incentives, and so is "slack". If your genius developer doesn't document his code, a lesser developer can document it in far less time it would take any number of lesser developers to write and document it, or at least one of them isn't worth his salt.

      Spiegel has rigged the question by choosing, embellishing, or inventing out of whole cloth a "quirky developer" who Spiegel claims caused most of the problems he solved and went beyond what any company could tolerate (open sexual harassment). But just because his probably-fictional "Josh" wasn't worth the trouble doesn't mean it's a good idea to treat your best developers like interchangable code-monkeys for whom following procedures is more important than brilliance.

      • by ultranova (717540) on Monday March 16, 2009 @11:08AM (#27210463)

        Genius developers who can solve problems in an hour which could take the rest of your team a month or more should get the same cubicles and be subject to the same strictures as everyone else.

        Genius developers like that should be employed as designers, not coders. By the time you start writing code, there should be no problems left that take even an afternoon, much less a month, to solve. Besides, to put it bluntly, I sincerely doubt you are more than 160 times more productive than an average developer. Finally, dunno about the article, but the summary didn't talk about someone getting rewarded, it talked about someone going out of his way to be an asshole; and that should never be tolerated, since it will lower everyone's productivity.

        If your genius developer doesn't document his code, a lesser developer can document it in far less time it would take any number of lesser developers to write and document it, or at least one of them isn't worth his salt.

        Except it's more difficult to understand someone else's code than to write it in the first place. This is especially true if the code is "brillant" - meaning it has hacks and abuse of language features that make strong men cry - and even more so if it's actually brilliant, since that means it uses concepts and solutions the lesser developer could never even imagine.

        The smarter the original developer is, the more important it is that he properly documents his code, since it's less likely that your average coder will understand the underlaying idea and be able to produce meaningful documentation.

  • by bytethese (1372715) on Monday March 16, 2009 @10:26AM (#27209805)
    To make an analogy here, he sounds like the TO of coding...
  • right tool (Score:5, Insightful)

    by trb (8509) on Monday March 16, 2009 @10:28AM (#27209833)
    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.
  • team player ? (Score:4, Interesting)

    by artg (24127) on Monday March 16, 2009 @10:29AM (#27209847)
    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.
  • by BlueBoxSW.com (745855) on Monday March 16, 2009 @10:33AM (#27209879) Homepage

    ... 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).

  • Rent-seeking (Score:5, Insightful)

    by Baldrson (78598) * on Monday March 16, 2009 @10:33AM (#27209887) Homepage Journal
    "What documentation?"

    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?

  • One sided story (Score:5, Interesting)

    by oneiros27 (46144) on Monday March 16, 2009 @10:34AM (#27209899) Homepage

    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.

  • by vlm (69642) on Monday March 16, 2009 @10:37AM (#27209951)

    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)

  • Josh the lone IU (Score:4, Interesting)

    by pohl (872) on Monday March 16, 2009 @10:43AM (#27210083) Homepage

    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.

  • Not worth it (Score:4, Informative)

    by squoozer (730327) on Monday March 16, 2009 @10:57AM (#27210285)

    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.

  • by dcollins (135727) on Monday March 16, 2009 @11:03AM (#27210365) Homepage

    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.

  • by David Gerard (12369) <slashdot@@@davidgerard...co...uk> on Monday March 16, 2009 @11:22AM (#27210729) Homepage

    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 [paulgraham.com]:

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

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

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

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

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

  • by MichaelCrawford (610140) on Monday March 16, 2009 @03:57PM (#27215577) Homepage Journal
    I have been a software engineer for twenty-one years, at one time having the role of "Debug Meister" as a system software engineer at Apple Computer - this because I'm a wizard at assembly debugging and reverse engineering.

    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 [geometricvisions.com]. 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 [vancouverdiaries.com] 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.

    But Wait, There's More!

    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 [zyprexa.com] 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.

"The value of marriage is not that adults produce children, but that children produce adults." -- Peter De Vries

Working...