Slashdot Mirror


Are Quirky Developers Brilliant Or Dangerous?

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

183 of 1,134 comments (clear)

  1. brilliant or dangerous? by p3on · · Score: 5, Insightful

    why are the mutually exclusive?

    1. Re:brilliant or dangerous? by tgatliff · · Score: 5, Insightful

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

    2. Re:brilliant or dangerous? by Trifthen · · Score: 4, Insightful

      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.

      --
      Read: Rabbit Rue - Free serial nove
    3. Re:brilliant or dangerous? by neapolitan · · Score: 5, Insightful

      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.

      --
      Slashdotter, ID #101. UIDs are in binary, right?
    4. Re:brilliant or dangerous? by h4rm0ny · · Score: 3, Insightful

      why are the mutually exclusive?

      Or related?

      --

      Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
    5. Re:brilliant or dangerous? by Maxo-Texas · · Score: 5, Insightful

      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.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    6. Re:brilliant or dangerous? by Razalhague · · Score: 2, Informative

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

    7. Re:brilliant or dangerous? by Skreems · · Score: 4, Insightful

      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.

      --
      Slashdot needs a "-1, Wrong" moderation option.
      The Urban Hippie
    8. Re:brilliant or dangerous? by tixxit · · Score: 5, Interesting

      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.

    9. Re:brilliant or dangerous? by qbzzt · · Score: 5, Insightful

      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.

      --
      -- Support a free market in the field of government
    10. Re:brilliant or dangerous? by Myrimos · · Score: 5, Insightful

      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.

      --
      Internet scofflaw
    11. Re:brilliant or dangerous? by tedrlord · · Score: 4, Insightful

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

      --
      [insert witty quote here]
    12. Re:brilliant or dangerous? by ClosedSource · · Score: 4, Funny

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

    13. Re:brilliant or dangerous? by homerjs42 · · Score: 5, Funny

      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.

    14. Re:brilliant or dangerous? by bberens · · Score: 2, Interesting

      There's a give and take. In the grander scheme of things it's more important to have a cohesive team than just about any other single factor. At the same time when the proverbial stuff hits the proverbial fan it's that weird/obnoxious genius guy who comes through with the solution that saves the day more often than not.

      --
      Check out my lame java blog at www.javachopshop.com
    15. Re:brilliant or dangerous? by nine-times · · Score: 5, Insightful

      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.

    16. Re:brilliant or dangerous? by Austerity+Empowers · · Score: 2, Interesting

      Bingo. There's never been a shortage of self-absorbed assholes in any line of business, ever. The difference is that in most corps today, management types tend to be very socialized and promoted via american idol like popularity contests such that "Josh" is either THE boss (i.e. runs the company) or he's your coworker. Possibly "Josh" is most synonymous with software because it's a new field and relatively poorly understood...but this is changing.

      The issue is that in most companies Josh is totally unwelcome and short-lived, when in fact Josh is necessary. Quite often Josh is actually smart, and sees things others do not see. He knows that 10 dumb people working together as a group produce 5x the dumb output, the rest is released as waste in the form of donuts and coffee.

      Much like chemotherapy, he may do some good, but many think they would prefer the alternatives because they have less unpleasant side effects. The fact is it takes all types to succeed, and Josh should only be shown the door if in fact he does something so severely wrong there may be legal implications for the company. Otherwise he should be sanctioned appropriately, and for God's sake never promoted to management, but retained. Let him carry the cost of his personality in a stunted career and missed opportunities, and he may eventually grow to be a guiding light rather than a frikken shark with lasers.

    17. Re:brilliant or dangerous? by Imagix · · Score: 5, Interesting

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

    18. Re:brilliant or dangerous? by adrenaline_junky · · Score: 2, Insightful

      Convoluted or obfuscated code is no benefit to anyone and deserves scorn.

      However, there is nothing about being a brilliant programmer that requires one to write convoluted or obfuscated code.

      The best code needs very little documentation because it is immediately obvious to any other programmer what the code is doing, and long comments are only required in sections of the code where the purpose of the code is not immediately obvious.

      It does require a dose of humility to intentionally add minor inefficiencies to a program to make it more clear, though, and it sounds like the Josh in this story was sorely lacking such humility.

      Using five lines of code to show the intermediate assignments in a long calculation instead of doing it all in one line of code can make the logic flow easier to follow by orders of magnitude, but some programmers are unwilling to deface the elegance of their design with such simplicities.

      Ultimately the true genius is the person who can write brilliant code that is also easy to read and modify.

    19. Re:brilliant or dangerous? by Foofoobar · · Score: 5, Interesting

      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.

      --
      This is my sig. There are many like it but this one is mine.
    20. Re:brilliant or dangerous? by thedonger · · Score: 2, Informative

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

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

      --
      Help fight poverty: Punch a poor person.
    21. Re:brilliant or dangerous? by hairyfeet · · Score: 5, Interesting

      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?

      --
      ACs don't waste your time replying, your posts are never seen by me.
    22. Re:brilliant or dangerous? by hondo77 · · Score: 2, Interesting

      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.

      For the record, I worked at a place where we could release SOX-compliant changes within an hour of the need arising. However, our normal release cycle was weekly and we passed all of our SOX audits. If your company's productivity has declined 75%, don't blame SOX.

      --
      I live ze unknown. I love ze unknown. I am ze unknown.
    23. Re:brilliant or dangerous? by Maxo-Texas · · Score: 2, Insightful

      Close.. but not what I'm saying.

      Given a choice of:

      * Definitely 2 to 9 weeks. Over 9 weeks 5% of the time- file a project change with reason at week 7.
      * Definitely 16 weeks. Over 16 weeks 5% of the time- file a project change with reason at week 14.

      Managers choose 16 weeks.

      And if they do have a 2 to 9 week person, they'll tend to let that person sit around doing nothing for 7 weeks (actually vetoing projects because they don't want to "spend money" for a person that will instead sit at their desk doing nothing, worrying about their job. i.e. the money is already frakking spent).

      You have to let go or it will drive you crazy. You just deliver on the deadlines- with all of your paperwork correct (7 documents these days) and the appropriate status reports and weekly meetings attended.

      Any truly brilliant developer will be driven insane by this. The only option in my opinion is for them to go to consultant firms or small companies.
      When I worked at a small company, I was free to change code, put it into production-- on the SAME day. When I worked at a small company, I was free to tell my manager, "Hey I'm not busy right now so I'm going to improve the code". We didn't have to schedule a series of meetings. When I was a consultant, at least I could say, "I'm done- bye" instead of being tied to a desk with no work. And as a consultant, the paperwork was SOOOOO much lower.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    24. Re:brilliant or dangerous? by Miamicanes · · Score: 5, Insightful

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

    25. Re:brilliant or dangerous? by Marillion · · Score: 3, Interesting

      Damn, you beat me to it.

      Never the less, you are spot on. Some quirky programmers are both, some are neither.

      Perhaps it is conceited of me, but I've always thought of myself as brilliant. Enough people have made comments that reinforce that conceit. But, one of the most valuable pieces of advice I ever received was from another brilliant individual who once remarked, "You and I might understand this, but those who follow might not. We need to simplify it." From then on, I've always thought twice about getting "too creative."

      --
      This is a boring sig
    26. Re:brilliant or dangerous? by Rorschach1 · · Score: 4, Insightful

      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.

    27. Re:brilliant or dangerous? by squoozer · · Score: 3, Insightful

      There is a flip side to this though. One place I worked had a habit of trying to make sure any code they wrote was always as flexible and general as possible so that future requirements could be satisfied easily. The problem was that everything took twice as long to develop and was unnecessarily complex. I noticed that the developers were generally fairly poor at predicting what the new requirements would be or when they would be wanted. I'm not advocating that every piece of code should be written as the shortest path from A to B but I think the best solution is somewhere between general and rigid. Your in class example isn't great because you knew up front that there would be new requirements in the near future therefore hinting to you that a flexible base is a good thing. In the real world you rarely get such hints.

      --
      I used to have a better sig but it broke.
    28. Re:brilliant or dangerous? by aurispector · · Score: 4, Insightful

      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.

      --
      I have mod points. The reign of terror begins now.
    29. Re:brilliant or dangerous? by Rumagent · · Score: 2, Interesting

      Amen brother. To quote the great Hoare:

      "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

      It was true then, it is true now and it will remain true in the future.

    30. Re:brilliant or dangerous? by Venik · · Score: 5, Insightful

      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.

    31. Re:brilliant or dangerous? by Maxo-Texas · · Score: 2, Insightful

      I've worked with many brilliant programmers over the course of 25 years.

      Good coding *is* difficult.

      Managers want to think that programmers are a generic goo. Our 2nd to last reorg 3 years ago took everyone away from their areas of competence because some management company said it would be a more efficient allocation of our resources. After suffering with it 3 years (I think because they didn't want to embarrass the executive that backed the plan), we have a brilliant new organizational plan-- we put people in their areas of competence.

      A good programmer can do quality work and quality documentation in 1/10th the time, with less architectural/design issues than a pleasant competent programmer. A brilliant programmer MUST write quality code- sub-standard code and design pisses them off and drives them crazy. You don't want *two* brilliant programmers in the same area. You need a brilliant programmer and 3 to 4 solid pleasant programmers and 1 to 2 eager novices.

      You don't need an asshat like Josh, but you may find your brilliant programmer does his ( I've met some brilliant female programmers recently but the vast majority are male ) best work from 1pm to 1am so you have to focus on project deadlines, not arrival times.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    32. Re:brilliant or dangerous? by tedrlord · · Score: 2, Funny

      Embedded programming is an entirely different beast, I'm sure. The way you talk about it, I think all programmers should be forced to write and maintain embedded code for a year or two before they're allowed to work on anything else.

      --
      [insert witty quote here]
    33. Re:brilliant or dangerous? by jellomizer · · Score: 4, Insightful

      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.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    34. Re:brilliant or dangerous? by NormalVisual · · Score: 4, Insightful

      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.

      --
      Please stand clear of the doors, por favor mantenganse alejado de las puertas
    35. Re:brilliant or dangerous? by mdielmann · · Score: 2, Insightful

      And another Einstein quote I try to live by in my programming career: "Make everything as simple as possible, but not simpler."
      IMO, MS Office ribbons fail on the second part.

      --
      Sure I'm paranoid, but am I paranoid enough?
    36. Re:brilliant or dangerous? by billcopc · · Score: 2, Interesting

      they realize that intelligence is only useful if the person can work with other people or can effectively communicate his work

      So you're essentially saying everyone needs to meet the lowest common denominator, in order to be productive ? Fuck that, some of us do get hired because we "think outside the box" and can pull off feats of mental strength. Should we play dumb just because we share an office with a bunch of glassy-eyed imbeciles ? You're going to have different skill sets and intellectual extents in any office, the not-so-secret trick to being successful is to maximize each player's potential. If one guy is really talented at coding those mind-benders, but sucks at documenting his work in layspeak, you hire an assistant. Let the code wizard write code, and the doc wizard write docs. What's so horrible about that ?

      Do you expect your accountant to be a top lawyer too ? No ? Then why do you expect your programmer to be a top technical writer ? Yeah, we know a little bit about the "other side", the same as your accountant should know the rough guidelines of tax law, but one is never a replacement for the other.

      --
      -Billco, Fnarg.com
    37. Re:brilliant or dangerous? by MartinSchou · · Score: 5, Insightful

      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

    38. Re:brilliant or dangerous? by computational+super · · Score: 2, Insightful

      How do you know you're not a jackass?

      --
      Proud neuron in the Slashdot hivemind since 2002.
    39. Re:brilliant or dangerous? by squoozer · · Score: 2, Insightful

      It's true enough that requirements often change during development but if requirements are changing drastically and / or frequently during development someone has screwed up.

      Like a lot of young developers I used to think that the "best" way to deliver a software project was just to jump straight in and start coding. As I've gained more experience and worked on progressively larger projects I now see that software development is a lot more like civil engineering.

      If you went up to the engineering team that was responsible for the Viaduc de Millau bridge and said I want it in purple half way through the project he would say fine give me X euros to re-paint it. If you instead said I want it to span the straights of Gibraltar you've screwed up with the requirements.

      --
      I used to have a better sig but it broke.
    40. Re:brilliant or dangerous? by Venik · · Score: 4, Insightful

      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.

    41. Re:brilliant or dangerous? by Peaquod · · Score: 2, Informative

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

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

  2. Reiser? by Anonymous Coward · · Score: 3, Funny

    Reiser?
    Couldn't resist.

    1. Re:Reiser? by Chrisq · · Score: 4, Funny

      Reiser? Couldn't resist.

      Neither could he

  3. Dangerous by Hatta · · Score: 4, Funny

    But only if you're married to them.

    --
    Give me Classic Slashdot or give me death!
  4. Can we stop enabling these people? by ivan256 · · Score: 5, Interesting

    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.

    1. Re:Can we stop enabling these people? by Anonymous Coward · · Score: 5, Insightful

      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.

    2. Re:Can we stop enabling these people? by Hozza · · Score: 3, Insightful

      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.

    3. Re:Can we stop enabling these people? by DrLang21 · · Score: 5, Insightful

      if the author has such a problem with this guy, maybe he needs to be skilled enough to replace him

      That's part of the problem. Having irreplaceable people on your staff is bad for business long term. If someone is laughing at you for asking for non-existent documentation that they should have written, they should be fired immediately. The cost to business if this guy were to leave will only get worse with time and probably already outweighs the savings of keeping him on.

      Lesson, you are replaceable. If you are not replaceable, then you are too dangerous to have.

      --
      I see the glass as full with a FoS of 2.
    4. Re:Can we stop enabling these people? by Maximum+Prophet · · Score: 5, Insightful

      If your competitor hires this guy they might be able to outproduce you just long enough to put you out of business. Doing things right is important, but staying in business is the *most* important thing. (It's a gamble, like all of life, you roll the dice and take your chances.)

      --
      All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
    5. Re:Can we stop enabling these people? by Don853 · · Score: 4, Insightful

      That's not true. The guy is refusing to document code and skips work on a whim. He's not dependable but he tries to tie his coworkers to his capricious tendencies. He's arrogant and socially inept. Most of the most brilliant people I've worked with are very confident, but they're not all assholes. This "Josh" doesn't sound like someone I'd want on my team. The code doesn't need documenting? Seriously? Brooks thought that was outdated in 1970.

    6. Re:Can we stop enabling these people? by ivan256 · · Score: 4, Insightful

      For the sake of argument, let's take for granted that nobody else can do what this guy does. Otherwise they'd have replaced him by now. Also keep in mind that he's using an extreme example to make a broad point. We'll take Mr. Speigel's words at face value, since we're to assume that he's not being hyperbolic about the behavior of said employee...

      "Sure, he was whipsmart and could churn out code that saved the company millions"

      His argument is that it's worth millions of dollars to not have to deal with this guy. Who has the bigger ego in this situation?

      If I'm running a business, and a middle manager tells me that the company should spend millions so the team doesn't have to deal with an asshole, I fire the manager, not the asshole.

    7. Re:Can we stop enabling these people? by talldean · · Score: 5, Insightful

      If you can't replace a relatively inexpensive employee, you're one traffic accident away from being out of business entirely. Let your competitor take that risk. "It's a gamble, like all of life, you roll the dice and take your chances." The odds of your competition hiring the guy - through a noncompete clause - and him being the tipping point of sending you out of business? Miniscule. The odds of a daily accident, or family problems, or the employee just leaving for greener pastures? Enormous.

    8. Re:Can we stop enabling these people? by Registered+Coward+v2 · · Score: 2, Insightful

      Translation: Control is more important than productivity.

      I think it would be a lot harder for this guy to have made his point without such an extreme example.

      While I agree the example was extreme, the point was valid.

      It's not about control but about creating a product that is sustainable over the course of its life. That requires code that can be understood and troubleshot by others; not just the author. As was pointed out in TFA; Josh's code may have been the casue of teh problem from teh start.

      The ability to write code that works quickly is not genius, it's the mark of an idiot savant. Real genius is writing tight code that works and can be understood by others.

      Despite the pain of rewriting the code once Josh left I bet the company was better off in the long run because they had fewer customer complaints and when they did they could actually fix the problem without dealing with Josh.

      --
      I'm a consultant - I convert gibberish into cash-flow.
    9. Re:Can we stop enabling these people? by Swizec · · Score: 5, Insightful

      You stop being a quirky genius soon as you declare yourself as one. Since then you're just a wannabe poser.


      See that's why I'm NOT a quirky genius.

    10. Re:Can we stop enabling these people? by __aagmrb7289 · · Score: 5, Insightful

      I have yet to encounter a situation where anyone is THIS good (or where every other employee is THAT bad). And if a business WAS in that situation? Better to put it out of its misery - it'll get killed off sooner or later, regardless.

      I'm not sure why people feel a need to defend the "quirky" walking lawsuit that these "great" programmers are all about. Very few businesses need genius programmers in order to stay in business. And most of the time, these people keep your business one step away from being sued into an early grave - and they don't provide a good product. A good product isn't something that does things in really neat ways. It's a usable product, well documented, that does the job its designed for really well - and can be updated and maintained as necessary. None of these are true of any product worked on by the described programmer.

      I have no interest in pretending that programmers need to wear ties to work and act like your average joe. However, being anti-social and incapable of writing a maintainable product? Not interested.

    11. Re:Can we stop enabling these people? by DrLang21 · · Score: 5, Insightful

      There are many excellent geniuses out there in the tech field that do what they're supposed to do. They document their work so that others can understand it. If they die or quit tomorrow, their company won't have to spend 2 years trying to figure out what they did. Getting a cheap geek to document these people holds its own high risk. What if the geek doesn't understand what they did? If this "genius" can't be bothered to document his own work, what makes you think they can be bothered to review someone else's documentation of their work? Mitigate your risk by paying more to hire a genius who won't put your company at risk of internal collapse.

      --
      I see the glass as full with a FoS of 2.
    12. Re:Can we stop enabling these people? by radtea · · Score: 4, Insightful

      His argument is that it's worth millions of dollars to not have to deal with this guy

      Not even close. This is a complete false alternative.

      First of all, "assume no one else can do what this guy does" is about as sensible as assuming unicorns are going to come charging through your door. The number of people who can do what no one else does is extremely small. And if your company depends on something that esoteric you're doomed anyway.

      More importantly, you could replace this guy with a couple of top-rank developers who might not have his "genius" but who would be able to save the company 90% of those millions, and do so in a sustainable, maintainable way, creating far more value downstream while reducing the churn you experience on the rest of the team because no one can stand to work with this jerk.

      Team skills are empirically known to be the most important predictor of developer productivity, not technical skills. Go look it up in your copy of "Rapid Development".

      It is never "either/or": a better team player with somewhat weaker technical skills is generally a better hire than a guru who can't play nicely with others, and the notion that gurus are so singularly valuable that they can't be replaced is simply false if you are running a viable business in the long-term.

      --
      Blasphemy is a human right. Blasphemophobia kills.
    13. Re:Can we stop enabling these people? by mcvos · · Score: 2, Insightful

      Why do people feel the need to control quirky geniuses who are doing nothing wrong? Seriously, there's nothing in this example that's out of the ordinary, except for the women's t-shirts. That's what you get for having a casual work place. My thought would be that if the author has such a problem with this guy, maybe he needs to be skilled enough to replace him.

      The T-shirts in the example are not the problem (though the hygiene might be). The problem is that he claims his code works and is self-documenting, when in fact it doesn't work the way the customer wants, and other programmers (the chief engineer at least) are unable to read his code.

      That's the problem. That and his anti-social attitude of calling them names instead of helping them to fix his incomprehensible code.

    14. Re:Can we stop enabling these people? by ThrowAwaySociety · · Score: 2, Insightful

      If your competitor hires this guy they might be able to outproduce you just long enough to put you out of business. Doing things right is important, but staying in business is the *most* important thing.

      The last thing you want is for your business to be dependent on one single person. Even if he's not some kind of cowboy/diva/jerk with no social skills, he may get hit by a bus, leave for personal reasons, or just get a better offer.

      Unless you're so small that you absolutely cannot hire another developer, you should start weaning your business off of such a person. Now, while it still has a chance.

    15. Re:Can we stop enabling these people? by tnk1 · · Score: 3, Interesting

      You may have missed the point where it was believed that it was possible that the millions of dollars saved was due to the millions of dollars worth of screw-up in his code, or even actual sabotage, to begin with.

      This guy was the mastermind of his project. If his code needs to be fixed in order to generate millions of dollars in savings, then the company didn't lose anything by losing him, except that which they let him control. If you churn out a high volume of good code and a high volume of crap, your net effect on the company tends to start looking like nil. That's before the millions in sexual harassment awards, of course.

      Don't get me wrong, there is nothing wrong with a "quirky" developer. I know many of them and most of them are harmless. They tend to get a little crabby at being pulled away from code, which is understandable because they like coding and they also tend to have deadlines. Most of them, however, understand the bottom line of the place that employs them.

      Documentation is not optional if you are in a workplace where your code needs to be used and operated on by others. If anything, it keeps people from annoying you later on (if you are of the antisocial mindset).

      Any developer who doesn't believe in documentation, or at the very least, does not even give lipservice to the concept is a long term liability for your company and needs to be corrected or be fired immediately. I mean, how hard can it be for someone who spends their time typing out text all day long to type out some extra text in English that explains things? When I code, its second nature to type a comment inline to make sure I remember my latest stroke of brilliance that was brought on by the hallucinations from the two liter of Mountain Dew I just drank. Those comments can easily be turned into documentation of a rough sort.

      It needn't be a book nor does it have to be flowery prose, that's what tech writers are for. It does have to exist, however.

      I have had to sit on the end of one too many developers who don't believe that their code needed documentation or even comments. I don't know if they saved the company millions or not, but I can tell you that it definitely cost us thousands of dollars in paid time for me to stare at their junk just so I could find the right place to make a simple change to the application.

      That said, you're right. The manager in this case should have been fired, but in addition to the developer. The manager, in all likelihood should have set limits on this person from the get-go instead of becoming dependent for their own performance on a person who doesn't even believe in showing up for work, let alone to help out in a customer situation. Such a manager is a lame weakling that was likely getting run over in more than one situation like that.

    16. Re:Can we stop enabling these people? by fl!ptop · · Score: 2, Interesting

      If you are not replaceable, then you are too dangerous to have

      my dad once told me, "a wise employee works to make him/herself irreplaceable."

      he continued, "a wise company manages their workers so no one is irreplaceable."

      --
      When you recognize love in another and realize how precious it is, everything else seems so insignificant.
    17. Re:Can we stop enabling these people? by mcvos · · Score: 3, Insightful

      You stop being a quirky genius soon as you declare yourself as one. Since then you're just a wannabe poser.

      See that's why I'm NOT a quirky genius.

      Exactly. There's nothing cool about trying to be a quirky genius. But if you happen to be a quirky genius, it's definitely cool to try to be a team player. That's what makes your genius valuable.

      A genius asshole is just another asshole.

    18. Re:Can we stop enabling these people? by nomadic · · Score: 2, Insightful

      As a quirky genius, I have to say, if you don't like the way we do it... go fucking do it yourself. Should be good for a laugh...

      Please let us know what absolute brilliant pieces of programming have come from you so as to show that you are entitled to this attitude. At least let us know what companies you've worked for so we can at least know what world class programs you've helped produce.

    19. Re:Can we stop enabling these people? by Dan+Ost · · Score: 5, Insightful

      If you can't be replaced, you can't be promoted. Hope you like your current job.

      --

      *sigh* back to work...
    20. Re:Can we stop enabling these people? by Anonymous Coward · · Score: 2, Insightful

      What's the net cost?

      Let's accept for a moment the code may save millions of dollars as a line item.

      Does this guy's attitude cause more frequent turnover in his department incurring continual overhead in dealing with recruiters or new employee hire/training costs?

      Does his likely shoot-from-the-hip coding style work for his one use case and break things in ways he didn't bother to test or account for?

      Does he drop code in the repository that's of a huge, "everything's changed" variety which causes downtime as developers have to spend time trying to understand the quirks of his new million-dollar-savings?

      What was the nature of the change? Was it purely an infrastructure or refactoring type change that allowed maximization of existing resources, or did other departments have to message changes to clients? Was there any cost in client or customer service overhead as a result of this change?

      Were there additional refactorings necessary to user interface, help materials, etc as a result of this change that hadn't been budgeted?

      Great developers are awe-inspiring. Truly, I work with a handful of people who blow my mind on a daily basis, unlike anywhere I've ever been. One thing I've seen from all of these guys though is that they communicate their skills because they're smart enough to know that if they *all* know it (to a greater or lesser extent), or at least grok the important points well, they can improve upon it further. Compared with a lot of "superstar" guys I've worked with who couldn't be bothered to deal with people who "couldn't understand their greatness". Rarely are these guys the unmatched geniuses they think they are.

      Toxic employees are a liability... "superstar" is a label that is thrown around way too liberally.

    21. Re:Can we stop enabling these people? by DrLang21 · · Score: 2, Insightful

      I used to believe this. Then I found myself in a dead-end job because I was irreplaceable. I couldn't move up because the company couldn't afford to let me. So I found a new job. Unless you are content to be in one position for the rest of your life, being irreplaceable is bad for everyone involved. Now I contend that a wise employee starts training their replacement from day one.

      --
      I see the glass as full with a FoS of 2.
    22. Re:Can we stop enabling these people? by 0xdeadbeef · · Score: 3, Insightful

      Yeah, and what if the owner of the company declares you one, and it happens in more than one company, and you regularly live outside the traditional chain of command of the company, answerable only to the owners?

      Do you have an equal share of the company as the owners? No? Then I hope the pats on the head are worth it.

    23. Re:Can we stop enabling these people? by oliderid · · Score: 2, Insightful

      Yeah, and what if the owner of the company declares you one, and it happens in more than one company, and you regularly live outside the traditional chain of command of the company, answerable only to the owners?

      It happens especially in little company. I remember a client of mine. They had an "in house" programmer. It was probably the shittiest codes I have ever seen. No logic, redundant functions, etc. I remember a meeting with him, he played the arrogant know it all in front of me. He finally noticed that I was a programmer just like him. The tone changed.

      He thought he was irreplaceable but the management has changed and the reason of my presence was to well outsource his work or to make him less "irreplaceable" due to the difficulties to get things right without crawling in front of him.

      There are a lot of people like him, as soon as they know "a little" more than their fellow co-workers, they feel like genius...Until they meet another professional who didn't past the last ten years sleeping on its knowledge without ever documenting himself about the last techniques/tools.

    24. Re:Can we stop enabling these people? by Hoi+Polloi · · Score: 2, Insightful

      That "millions" number was probably pulled out of thin air but anyway...

      How much would it cost to replace the good coders who might leave for a better work environment? How much would it cost to debug or port that guy's code after he left with no documentation? How much would it cost to defend the company in, say, a hostile workplace lawsuit?

      Even the president of the US can be replaced as the last election showed. No one is irreplaceable, especially a hostile person.

      --
      It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
  5. Nice made up story... by sunking2 · · Score: 5, Interesting

    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.

  6. Lack of Documentation == dangerous by yincrash · · Score: 4, Informative

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

    1. Re:Lack of Documentation == dangerous by Joe+the+Lesser · · Score: 5, Insightful

      Maybe there would be more documentation if you established reasonable deadlines.

      Just sayin' sometimes there's another story.

      --
      "I only speak the truth"
      Karma: null(Mostly affected by an unassigned variable)
    2. Re:Lack of Documentation == dangerous by Samalie · · Score: 4, Insightful

      Now THAT is absolute truth right there...if I had mod points, I'd mod you up.

      I'm a SQL developer (yeah, the pansy-asses of the developer world - I admit it) - and often times my documentation is sorely behind. Of course, if I didn't have 50 projects all due within 10 minutes of the conception by the end user, I'd have time to document everything too.

      That being said, I *still* do my damndest to document my code. Its not perfect, but its better than the renegade who does nothing ever.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    3. Re:Lack of Documentation == dangerous by morgan_greywolf · · Score: 5, Insightful

      Exactly. There's always two sides to a story like this. One reason documentation often gets missed is because "make it work and make it work NOW!" and "we forgot to tell you, it also needs to Z in addition to X and Y!" gets nice'd above documentation.

      If we all had all the time we needed to do everything, the documentation would get done. But this is the real world and in the real world, IT management is definitely going to put functionality well above documentation on the importance scale.

    4. Re:Lack of Documentation == dangerous by Qzukk · · Score: 5, Funny

      It only took you 90 words to say what he did in 11.

      Obviously he had the time to clearly document his thoughts, while the other guy needed to make his post and make his post NOW!

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    5. Re:Lack of Documentation == dangerous by bigdaisy · · Score: 2, Insightful

      it also needs to Z in addition to X and Y!"

      Or my personal favourite: "You know how we said X was critical to the success of the company and how you spent several months of your life implementing it? Well, we changed our minds. Now we think Z is critical. And can you make a few changes to Y while you're at it to make it more like W, so that when we change our minds again next week and resurrect X, Y won't work with X anymore and you'll have to redo X a different way from scratch? Thanks. Oh, and if you can have it on my desk by COB on Monday, that would be good, as I have a status meeting to go before my golf game. How's the documentation coming along? Not good? Nevermind, you can get back to it later."

      OK, so I'm reading a little between the lines, but I get that most weeks.

    6. Re:Lack of Documentation == dangerous by Chris.Nelson · · Score: 5, Insightful

      If there is no documentation, the answer to the question, "Is it ready?" is "No." It's likely that the PHB doesn't know enough about what you're doing to disagree with you and grab your raw code from the repository and use it. If you establish a precedent for being done quickly (without documentation) then you get caught in a vicious cycle of it being expected that you'll be done quickly. It's best when the system supports proper documentation, etc. but if not, sandbag your estimates to give yourself time to do the job right, or at least half right. Over time, your productivity will catch up when you can figure out last month's or last year's code more quickly for a new feature because you took time then to document what you were doing.

    7. Re:Lack of Documentation == dangerous by Hordeking · · Score: 2, Insightful

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

      So let me get this straight:

      If I conveniently don't document my code, I hereby increase my job security, because it'll make it harder to shitcan me because the other developers won't have a clue what I did because there's no documentation. Sweet, all I have to do is make it more expensive for them to shitcan me than keep me. It's pure brilliance!

      --
      Disclaimer: The opinions and actions of the US Gov't are in no way representative of those held by this author or its ci
    8. Re:Lack of Documentation == dangerous by Jaeph · · Score: 2, Interesting

      "Maybe there would be more documentation if you established reasonable deadlines."

      Nonsense. I despise this excuse - you make it sound like documentation is difficult to write. If it's clear in your head, it will take you moments to put down onto paper. If it's not clear in your head, you have a problem.

      I have never understood the so-called geniuses who have time to work overnight on some problem but can't find a spare hour to document and comment. Heck, if you're doing it right you should be commenting as you go anyways, just to keep your own thoughts straight.

      But go ahead, don't listen. Blame the bosses. It's always their fault. The genius hacker is always beat up by evil management in the standard slashdot saga.

      Again, utter nonsense.

      -Jeff

      --
      Please learn the difference between a dissenting opinion and a troll before you moderate.
    9. Re:Lack of Documentation == dangerous by CrazedSanity · · Score: 2, Insightful

      I absolutely agree!

      At one point at a previous job, I was tasked with putting all of our projects into our project management software and prioritize. I built a tree structure with parent projects and sub-projects, where the furthest-out projects needed to be completed before the parent project could be done (so the root projects were easy to understand for the PHB, and we could deal with the smaller bits). Each level was prioritized based on the level, so I could tell what piece should be completed first (I worked that part out with the other developers so we all understood what it all meant, along with figuring out some of the lower-level priorities and building best-guess timelines).

      After a week of prioritizing, arranging, and setting timelines, I brought it to the PHB. I explained the logic of the thing and how much I'd worked with the other developers in order to get it organized as such. He gave me a blank stare, asking why there were so many sub-projects and why he couldn't find the project he was looking for, etc. I explained the organizational logic, and he just gave me that blank, glazed-eye stares and then excused me.

      The next morning I was called into his office, where he showed me (with a huge smile on his face) how he'd rearranged everything. There were no trees (projects with sub-projects) that explained dependencies. The timelines were changed to what he wanted them to be, causing 10-12 projects to overlap on very tight timeframes. EVERYTHING was a project (the sub-projects that were dependencies of parents were suddenly their own projects with incredibly low priority). Only the projects he was interested were prioritized, and there were dozens of projects set with the highest priority.

      The funniest thing? Some time later we had a meeting where he told us adamantly that we should only EVER have ONE priority 1 (highest priority) item and that we shouldn't work on anything else until that priority 1 project was done. *sigh*

      --
      Sanity is like a condom: rather have it and not need it, than need it and not have it.
  7. Funny... by mdm-adph · · Score: 5, Insightful

    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
  8. I'd say most are less extreme by Trepidity · · Score: 5, Interesting

    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.

    1. Re:I'd say most are less extreme by Lumpy · · Score: 4, Insightful

      Honestly....

      I dont care how good you are. TAKE A FRICKING SHOWER AND WASH YOUR CLOTHES.

      Really is it that hard to spend 10 minutes in the morning, EVERY MORNING to bathe yourself??

      and honestly, "really good coders" are not worth it. Give me medicore coders that understand business and can do what they are asked to do over a stinky quirky great coder any day.

      --
      Do not look at laser with remaining good eye.
    2. Re:I'd say most are less extreme by Rene+S.+Hollan · · Score: 5, Insightful
      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.

      --
      In Liberty, Rene
    3. Re:I'd say most are less extreme by Anonymous Coward · · Score: 2, Interesting

      I used to be such a person. Your answer is: Yes, it is that hard.

      You put it as if it is by choice, but in most cases it really isn't. Sometimes I would forget to take a shower or would not remember to brush my teeth. (I'd document the fuck out of everything, though). It was never by choice, and I really wanted to improve myself.

      After about 6 years, I've finally managed to. I designed a rigorous schedule that I follow and must follow to keep "fitting in" so to speak, and despite the fact that I still drop the ball sometimes it has improved my quality of life magnificently.

      I'm not saying you're wrong though, heh. Just that usually, most people aren't doing it by choice (or even aware of it). In most cases it can even be addressed or self-addressed. I think it really comes down to communication in the end.

      My 2c. Take it for what you will.

    4. Re:I'd say most are less extreme by RightSaidFred99 · · Score: 4, Insightful

      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.

  9. Re:Perhaps by Anonymous Coward · · Score: 4, Funny

    Yeah, get him a proper litter box. That should solve the problem.

  10. Stop coddling your little genius by Anita+Coney · · Score: 5, Informative

    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.
    1. Re:Stop coddling your little genius by rolfwind · · Score: 3, Insightful

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

    2. Re:Stop coddling your little genius by Mr.+Slippery · · Score: 3, Insightful

      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.

      Kids who are highly intelligent and gifted are special, by definition. Teachers and caregivers often find that the rules designed for age-group peers should not be applied, because the assumptions behind the rules don't fit. That's not coddling, especially when you consider the additional pressures of expectation placed on them.

      For example, I remember in elementary school (this is around 1975) it was a rule that kindergarteners could not books out of the school library. After all, reading wasn't taught until first grade, so kindergarteners can't read. When they found two of us who showed up able to read, rather than remove the rule entirely or stunt our learning potential, the rule didn't apply to us.

      Now, this has nothing to do with the sort of developer discussed in the article. A smart developer develops elegant and documented code, and is so proud of their work that they love to explain it to others. Someone who's mastered some arcane bit of technical lore and secretively builds convoluted, undocumented code around it, is neither smart nor talented nor an asset to their team. If they further behave like an asshole (not just quirky, but actively rude and abrasive), the only "special treatment" warranted is a swift kick in the ass.

      --
      Tom Swiss | the infamous tms | my blog
      You cannot wash away blood with blood
    3. Re:Stop coddling your little genius by stevied · · Score: 4, Informative

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

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

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

  11. simple economics by circletimessquare · · Score: 3, Insightful

    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
    1. Re:simple economics by TheCarp · · Score: 2, Insightful

      Meh I agree and disagree. I don't think you can put a blanket over all behaviour like that.

      The fact is, most of what we see as normal, is people doing prescribed things because its what everyone else does and whats expected of them. Anyone who has spent a few minutes questioning can see how superficial many of our daily activities are.

      I have seen entirely effective and competent entire teams that don't wear suits or even particularly nice clothes. Tshirts and jeanes. That same group, dark offices, loud music.

      Frankly i think most of what people lable as "eccentric" is just mundane difference. You don't really need people to conform in those ways. You don't need everyone to be a 9 to fiver with a collared shirt...

      what you need is the work to get done, and right, and the docs to be written. You need to make the docs part of the task and not fall for the old "the code is the docs" BS.

      What probably helps the most is integrating such people with others more. More positive social interactions, more work interactions where they can see that other people are important and they contribute.

      Assholes are usually assholes because they don't understand the people they are being assholes too. It comes, often, from judging others by the standards of your own myopic world. "I am the sysadmin, you are an idiot by sysadmin standards, your request makes no sense for a sysadmin".... but you arn't a sysadmin, you are with the helpdesk.

      I think to the studies of what happens in situations of authority (like the prison gaurd experiment), and think this is a lot of the issue... people judging and making decisions for others based on their own requirements. If my requirements and world works best when you are docile and do afraid of me and do as I say.... I treat you accordingly. Hence the "Instant asshole, just add badge" syndrome thats seems so common (at least among younger cops as far as I see)

      -Steve

      --
      "I opened my eyes, and everything went dark again"
  12. Dr. House Syndrome by EastCoastSurfer · · Score: 4, Insightful

    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.

    1. Re:Dr. House Syndrome by java+killed+the+dino · · Score: 5, Informative

      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?

    2. Re:Dr. House Syndrome by russotto · · Score: 5, Insightful

      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.

    3. Re:Dr. House Syndrome by Joe+the+Lesser · · Score: 5, Funny

      He may be an ass, but I agree with the parent that if you cure cancer I don't care if walk around shirtless and speak in Klingon.

      --
      "I only speak the truth"
      Karma: null(Mostly affected by an unassigned variable)
    4. Re:Dr. House Syndrome by ultranova · · Score: 3, Insightful

      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.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    5. Re:Dr. House Syndrome by radtea · · Score: 3, Interesting

      It isn't?

      If you're being an ass, you are not getting the job done. Basic civility is part of any reasonable job description. Generally an implicit one, which people with no social skills are unfortunately too crippled to understand.

      --
      Blasphemy is a human right. Blasphemophobia kills.
    6. Re:Dr. House Syndrome by thhamm · · Score: 2, Interesting

      I find cuddy to be infinitely hotter than 13 or Cameron.

      absofsckinglutely.

  13. Football on Slashdot? by bytethese · · Score: 4, Interesting

    To make an analogy here, he sounds like the TO of coding...

  14. Re:without clowns like this by Red4man · · Score: 5, Funny

    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
  15. right tool by trb · · Score: 5, Insightful

    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.

    1. Re:right tool by Lumpy · · Score: 3, Insightful

      but my knife does not stink, mumble loudly, have action figures cluttering TWO cubicle spaces and refuses to empty that festering experiment of a mini fridge under his desk.

      My knife looks good and does it's job without offending all the other tools.

      --
      Do not look at laser with remaining good eye.
    2. Re:right tool by Burdell · · Score: 2, Funny

      Thanks Bob, Bob. I'll get right on those TPS reports now.

  16. Amazing by WindBourne · · Score: 2, Interesting

    "Josh" is the kind of guy that develops Googles, Yahoo, etc. This idiot is obviously one of those guys who is jealous of any who show better skills then themselves. That does not mean that "Josh" should not be encouraged to change for the better, but a lot of that is simple maturity. OTH, this poster will never be a better coder.

    --
    I prefer the "u" in honour as it seems to be missing these days.
    1. Re:Amazing by Bieeanda · · Score: 3, Insightful

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

    2. Re:Amazing by mcvos · · Score: 2, Insightful

      "Josh" is the kind of guy that develops Googles, Yahoo, etc.

      No he isn't. Well, I don't know about Yahoo, but Google invests in smart, maintainable code. Josh writes convoluted code that nobody else can maintain, and he's unable to work with others. You can't build a company out of that.

      And there are far better coders out there who write self-documenting code that the other coders, the "average" ones, are able to maintain and fix.

  17. team player ? by artg · · Score: 3, Interesting

    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.

  18. They do exist by Maximum+Prophet · · Score: 5, Interesting

    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)
  19. Oh, I've met a few of them... by BlueBoxSW.com · · Score: 4, Insightful

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

  20. Rent-seeking by Baldrson · · Score: 5, Insightful
    "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?

  21. One sided story by oneiros27 · · Score: 4, Interesting

    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.
  22. Wrong choice of words by vlm · · Score: 3, Insightful

    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
  23. Work from home by jlebrech · · Score: 2, Interesting

    wouldn't he be more producetive if he worked from home?

    You now have a performance benchmark, due to him having previous work done in the office.

  24. Re:Perhaps by ultranova · · Score: 5, Insightful

    It's not necessarily "enabling". I've known a lot of people who are just eccentric but incredibly bright (and have been told I'm one, which surprises the hell out of me), and it's probably just part of the territory.

    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.

  25. Josh the lone IU by pohl · · Score: 3, Interesting

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

  26. Re:Perhaps by gmack · · Score: 2, Interesting

    A few years ago I worked for a company that had one such person on the team. Everyone thought he was a genius and tolerated the fact that he couldn't even be bothered to bathe or wear clean clothing. He would come when he felt like it and he would leave when he felt like it

    One day we had issues with his software and the boss went to find him only to find out he wasn't in the office. When the boss woke him up at 1:00 his only reply was "I didn't realize it's monday"

    Needless to say he was replaced and, as the poor new guy quickly discovered, it turns out the reason no one could understand his code was that he was an alcoholic who couldn't organize his code any more than he could organize the rest of his life.

    Being eccentric is not an excuse to be a selfish jerk.

  27. Not worth it by squoozer · · Score: 3, Informative

    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.
  28. Re:Like a former boss said: by mark-t · · Score: 2, Insightful

    There's nothing wrong with clever programming tricks, as long as they are documented so that other people can understand them.

  29. Sucking Productivity from Other Coders by dcollins · · Score: 4, Interesting

    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
  30. Managers Job by edivad · · Score: 2, Insightful

    It's managers job to give the right amount of freedom to talented individuals. Individuals with well over the average IQ, with passion for the job, and that are no afraid to spend extra hours on the task. If it were for me, I'd give up ten of the 9-to-5, dumb, lazy a$$es, weasels, that are unfortunately the fabric of most of US companies, for one talented engineer. You wonder and cry because he has extra privileges than you? Meritocracy, comes not only in form of extra salary, my friend.

  31. Ignore... by autocracy · · Score: 2, Insightful

    Drop down menus should come with an ok button. Undoing "overrated," which should have been "funny."

    --
    SIG: HUP
  32. Re: Seems ridiculous to me as well. by guidryp · · Score: 4, Informative

    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.

  33. Re:management doesn't enable him, they fear him. by LearnToSpell · · Score: 2, Funny

    I put on my robe and wizard hat.

  34. Not just software by cirby · · Score: 3, Interesting

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

  35. Real geniuses aren't arseholes by David+Gerard · · Score: 5, Informative

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

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

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

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

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

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

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

    --
    http://rocknerd.co.uk
  36. Wasn't me! by JoshDM · · Score: 2, Funny

    I take showers.

  37. Re:Perhaps by GMFTatsujin · · Score: 2, Insightful

    Truth.

    I've always considered that the indispensable genius/jerk should be given as many independent entrepreneurial opportunities as possible. As in kicked out the door. Go run your own business, genius.

    I'll happily go head to head with someone who routinely alienates the people around around him and can't get his personal shit together.

  38. Brilliant doesn't have to be dangerous. by crovira · · Score: 5, Funny

    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.
    1. Re:Brilliant doesn't have to be dangerous. by Beardo+the+Bearded · · Score: 5, Interesting

      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.

      --

      ---
      ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
    2. Re:Brilliant doesn't have to be dangerous. by Anonymous Coward · · Score: 2, Insightful

      mh, true and false. a pseudo code for a fast Fourier transform would be undocumentable - extracting radix: wtf is a radix? but a clean call to a method called fft() with a one liner pointing at the algorithm (eg Cooley-Tukey implementation of a fast Fourier transform) would change the mess in a functional block easily testable, replaceable and maintainable

    3. Re:Brilliant doesn't have to be dangerous. by Beardo+the+Bearded · · Score: 4, Insightful

      It's not 1985. Comment space is cheap.

      First, most functionality should be in functions (or methods, depending on your language). You wouldn't put stuff inline because that's a nightmare. However, at some point, you're going to have to write code that actually performs some kind of operation upon the data.

      If you called the function fast_fourier_transform() or fastFourierTransform() (depending on your coding style) it would make it a lot easier on the maintainers and cost you nothing.

      No matter what you called it, you'd still have to document the transforming function so that if you'd made a mistake in it, the next person looking at the code would be able to say, "oh, hey, this is supposed to be multiplied by -1 here"

      --

      ---
      ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
  39. Re:Perhaps by Em+Emalb · · Score: 2, Insightful

    Oh bullshit. Being an adult means not being an asshole to your co-workers.

    As you said, you've all got to get along, so why allow one jerkoff to ruin everyone else's day?

    I have no problem firing people that suck at life. I've never suffered for it.

    Don't let one ass-clown's childish behavior cause issues in the work place. You'll have a more productive work place because of it.

    --
    Sent from your iPad.
  40. simple, really by Tom · · Score: 3, Insightful

    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
  41. Re: brilliant and dangerous? by fugue · · Score: 5, Insightful

    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."
  42. I read the article by br00tus · · Score: 2, Insightful
    First of all, the writer talks about how the coder was not "businesslike", but then goes on to describe him and others as "quirky...weirdest...weird...quirky...prima donna...he was truly crazy...his appearance was like Pig Pen...smells...'offensive' t-shirts...inappropriate...dark, cave office...quirky, crazy, irrational". Now how "businesslike" is it to describe someone like this? He is just slinging mud trying to bias me against this person instead of giving examples of what he has done. So what if his office is darker than the rest of the floor, it's his office, I've had to sit in cubicles where we are practically blinded by the light. And it's his private office, this guy seems to think he's a big boss and can tell people what the lighting level of their own private office is. If he is offended by someone not having a global warming causing office, I wonder what he finds offensive on a T-shirt, "Vote Obama"?

    Amidst all of this mud-slinging, we hear some actual examples of what Josh's supposed failings are. The first one is a developer on his team, who is responsible for implementing and patching version 1.0 of the code, decides to not do his work, and goes to Josh, who is writing version 2.0 of the code, and sounds like the head developer on that, and have Josh do his work for him. Josh tells him to fuck off as he is busy, on a deadline to write 2.0. Then Spiegel walks in. Spiegel is there to reprimand Josh for not pulling off his tight developed schedule, and deal immediately (without scheduling it) with a problem that his own incompetent developer can't deal with. Spiegel is shocked Josh isn't obsequious in the face of this demand. Josh's paycheck is dependent on him getting version 2.0 on time, why should he spend more than the 50, 60, 70 hours a week than he's currently working to dump everything immediately and go deal with a problem due to an incompetent developer who can't handle the work?

    So the story is Spiegel has an incompetent developer on his team who can't figure out code and how to do his job, so the bad guy is the coder who everyone including his manager says is the best, most brilliant coder, who won't drop everything immediately and go work on Spiegel's problem. After which Josh will either miss his deadline or have to work even more hours than he has to, and Spiegel looks like a star for fixing his problem. As far as curtness, I wonder if Josh worked 40 hour weeks, had things scheduled far ahead with reasonable deadlines and a full and competent support staff in place? Why do I have a feeling that was not the case? Spiegel had a developer on his team and mentions the 2.0 team Josh is on. So why didn't his own developer or someone else on the 2.0 team look at it? Because Spiegel wants the star of the 2.0 team to drop everything and fix his problem.

  43. It "depends" on your CEO more than that by Anonymous Coward · · Score: 2, Interesting

    and that seems to be A-OK, doesn't it.

    I mean, that's why he gets ~50x the salary of the workers and a bonus in the millions, yes? Because you MUST HAVE HIM!

    Strange isn't it, that when it comes to executive or director pay, your company pays top dollar "because we must have the best", but when it comes to the people who actually DO the work you sell, it's all "it's a competitive market and we can't afford to spend too much on salary or we'll lose customers".

  44. Josh is payed to do his job, not to be a great guy by Otis_INF · · Score: 2, Funny

    i.o.w.: josh isn't payed to go hold your hand, share funny stories or go to the mall with you and your kids, he's payed to get the job done, whatever it takes.

    If that makes life hell for his co-workers, the company should make a decision: what are we: an organization which purpose is to keep some group of people off the streets or a business? If it's the former, Josh has to go, as he'll force the rest of his coworkers to go back to the streets, however if it's the latter, the rest should either shutup or do their work as well, as they too aren't payed to babble for hours at the watercooler.

    --
    Never underestimate the relief of true separation of Religion and State.
  45. No documentation = not done by fdrebin · · Score: 2, Insightful

    I have a simple policy, for myself and for people who work for me.
    If it isn't fully documented, it isn't done. There are no excuses, period.
    /F

    --
    Stupidity... has a habit of getting its way.
  46. Re:These guys are all right. by somersault · · Score: 2, Insightful

    perhaps brilliant people are angry because life sucks.

    You poor fools who die boring, polite and pointless never realized the tragedy of it all.

    Funny how what you think of as the boring and polite people don't actually think life sucks, eh? I get frustrated at the attitude of some sheeple too, but there is something to be said for being happy.

    Sometimes these people are not actually boring either, just respectful. Speak to them in an informal situation and they might not be as boring as you had previously thought. You don't have to be a jerk to have fun.

    --
    which is totally what she said
  47. The problem with irreplacable... by PinkyDead · · Score: 2, Interesting

    You can be an idiot and be irreplaceable - and of lot of these guys are.

    One clown I came across deleted all the test code, because he thought testing was a waste of time. He was gone a good 8 months when that shit hit the inevitable fan.

    The problem is that they write shit hot amazing code that does the job and impresses the PHBs, but if it is unmaintainable by a team then:
    (a) It's not scalable (in terms of growing the product)
    (b) It's long-term useless

    This is the equivalent of a teenager thinking they are super drivers because they can speed at 130mph with their eyes closed. An experienced driver knows that deer can jump into the road.

    --
    Genesis 1:32 And God typed :wq!
  48. Re:Josh is payed to do his job, not to be a great by taustin · · Score: 2, Insightful

    The first job responsibility in our employee handbook is that we have to get along with other employees. In other words, yes, it is my job (and everyone else's job) to not piss people off. Unless Josh can literally do every job in the company, he's not worth losing other employees over. No matter how productive he is, he's not the entire company.

    Plus, creating a hostile work environment is illegal.

    Any company that tolerates assholes like this will have no other competent employees.

  49. Re: brilliant and dangerous? by Dionysus · · Score: 5, Insightful

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

    --
    Je ne parle pas francais.
  50. Re: brilliant and dangerous? by jellomizer · · Score: 5, Insightful

    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.
  51. Unmaintainable by WED+Fan · · Score: 4, Insightful

    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.
  52. I really want to thank Josh by bugs2squash · · Score: 2

    I rarely shower, wear worn-out filthy clothes, neglect anti-perspirant and have defecated on countless lobby plants as a career building move.

    Now my co-workers consider me a genius because they have been conditioned by people like Josh to presume that only a genius could get away with these things.

    The fact that I can't code worth a crap does not enter into the equation. Perception is reality.

    --
    Nullius in verba
  53. Exaggeration? by MBGMorden · · Score: 3, Insightful

    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
  54. Reiser Drop down menus should've had an OK button by davidwr · · Score: 2, Funny

    Drop down menus should come with an ok button

    Slashdot doesn't allow pictures, but this is what I imagine is one of the drop-down menus on Reiser's last computer:

    Action->
    *Open sandbox for ReiserFS improvements
    *Edit documentation
    *Kill wife

    He meant to edit the docs but his finger slipped.

    An OK button would've really helped a lot here.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  55. Re:Josh is payed to do his job, not to be a great by DaveV1.0 · · Score: 2, Insightful

    Josh is paid to do his job. Part of the job of a programmer is to work with others. Part of most people's job description includes things about hygiene, appropriate work behavior, teamwork, etc.

    If Josh's coding results in ten thousand lines of spaghetti code with no documentation and riddled with single and double character variable names that result in other people not being able to do their jobs, then Josh is not doing his job.
    If Josh and his office smell like a pile of garbage, he is not doing his job.
    If Josh is saying offensive things to people, he is not doing his job.

    In other words, Josh is not doing his job.

    --
    There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
  56. Re:Peter principle? by Maxo-Texas · · Score: 4, Interesting

    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.
  57. Re:These guys are all right. by Weaselmancer · · Score: 5, Insightful

    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.
  58. Re: brilliant and dangerous? by Greg_D · · Score: 4, Insightful

    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.

  59. Re:These guys are all right. by Eunuchswear · · Score: 2, Insightful

    Only sheeple use the word sheeple.

    Baaa.

    --
    Watch this Heartland Institute video
  60. Bureaucracies and software development by coats · · Score: 2, Interesting
    Qualifications: I'm a software systems architect with over twenty years experience in environmental supercomputing. In that time, I've seen a lot of screwed-up code and screwed-up systems.

    In that time, the worst screw-ups have been exclusively codes developed in bureaucratic organizations.

    It seems to me there is a personality type that is in love with structure: it doesn't matter whether the structure is appropriate or not, just that it proliferate. This leads to codes that are not merely baroque, but positively rococo. And this is the personality type that flourishes in bureaucratic environments.

    The first principle of software engineering is Occam's Razor, more flippantly stated nowadays as "Keep it Simple, Stupid."

    My experience says that the lessons Kernighan and Pike teach in The Practice of Programming are de-valued in development-bureaucracies. And DeMarco was right-on in The Deadline about that subject, too.

    --
    "My opinions are my own, and I've got *lots* of them!"
  61. Re: brilliant and dangerous? by Kell+Bengal · · Score: 5, Insightful
    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.

    --
    Scientists point out problems, engineers fix them
    altslashdot.org: The future of slashdot.
  62. Re: brilliant and dangerous? by Dark+Coder · · Score: 2, Interesting

    Try hiring ANY decent coder that works with my former boss's highly impossible deadlines.

    I'm with previous parents. A good fire extinguisher (Asperger's) is handy to have. Deadline gets met, even though the end-result (support and maintenance) sucks.

    Most start-ups are in it for a quick and lucrative exit strategy (post IPO-sale).

  63. Re:Perhaps by agentultra · · Score: 2, Interesting

    Assholes, exactly -- people who are not genius' can act this way too. I've met countless sales people and executives who've had sexual allegations against them and who've siphoned off company money to fund affluent lifestyles; act like complete pricks to everyone they meet; and generally be very "Josh" like. Yet they seem to lack one thing: intelligence.

    I can understand a lot of the "devil's advocate" positions; but the reality is that this editorial is supporting a straw-man argument.

    A genius developer isn't universally predisposed to defecating in public and verbally abusing people.

    They may be eccentric and the scale of their eccentricities vs. their practical value to society will certainly determine how far they go. More often than not, such people will either disappear from corporate life or else end up running it. The worst thing possible for an eccentric genius developer is probably being stuck as a "cog in the machine." They'd probably be more likely to flourish in research, leadership, or academic positions.

  64. Re: brilliant and dangerous? by fugue · · Score: 3, Insightful

    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."
  65. Brilliance is a three-edged sword? by fugue · · Score: 4, Informative

    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."
  66. Re: brilliant and dangerous? by jellomizer · · Score: 5, Insightful

    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.
  67. Re: brilliant and dangerous? by shutdown+-p+now · · Score: 4, Insightful

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

  68. Re: brilliant and dangerous? by jellomizer · · Score: 4, Interesting

    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.
  69. Re: brilliant and dangerous? by julesh · · Score: 3, Interesting

    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)

  70. Re: brilliant and dangerous? by 91degrees · · Score: 5, Insightful

    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.

  71. Re: brilliant and dangerous? by noidentity · · Score: 2, Insightful

    Being required to produce documentation along with one's design often makes the design better, because it encourages a design that's easy to document clearly. The lazyness principle makes you want to avoid tricky things that take pages of documentation. So even if you think the documentation as some crap that goes along with your nice, clean design, think of the task of writing it as no different than a unit test or other QA; it exposes problems you might not otherwise notice.

  72. Re: brilliant and dangerous? by JoeMerchant · · Score: 3, Insightful

    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.

    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.

  73. Re: brilliant and dangerous? by Jherico · · Score: 3, Insightful

    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

    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"

  74. Re:These guys are all right. by cromar · · Score: 4, Insightful
    Overall, I agree, but saying that

    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.

  75. Re: brilliant and dangerous? by Kell+Bengal · · Score: 5, Insightful
    Well, he was employee #1 in the company (both value-wise and chornologically). Since he didn't document at the start, it was much cheaper to hire a post-grad than spare a more expensive employee from actual development work.

    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.
  76. Re: brilliant and dangerous? by Thaelon · · Score: 2, Insightful

    If my code takes more than a few seconds to figure out what it's doing, I keep rewriting it until it doesn't.

    The golden rule of being a truly good programmer is that you write the code that you wish other people would write.

    Write code that is self documenting by way of having very descriptive method and variable names. Because while it may take longer to write, you'll invariably end up reading it ten or more times more than you'll be editing it. So time making it readable & grokable is time exceedingly well spent.

    here's a quick sample of what I mean:

    Instead of this

            if (thingy.getLastTime() - thingy.getCurrentTime() > 3600000) {
                    for (Calendar calendar : thingy.getCalendars()) {
                            calendar.update();
                    }
            }

    write this:

            boolean isChangingTimeZones = hasChangedTimezones(thingy);
            if (hasChangedTimeZones) {
                    updateAllCalendarsWithTimeZoneChange(thingy);
            }

    It's debugger friendly (you can see the value of isChangingTimeZones before you step into the if-then-block, and the logic is described via the variable name which has a corresponding method that can be easily unit tested) and all the names are descriptive as hell. Not to mention the action is decoupled from the logic, and could easily be more so. Either could be modified without ever changing that particular code. And yes, the boolean method should use a constant for that magic number. You can probably infer what that constant is, but why waste people's time making them infer when you can very easily tell them explicitly?

    --

    Question everything

  77. Re: brilliant and dangerous? by sfcat · · Score: 2, Insightful
    And you are 100% wrong. Programming is 100% technical. Working in an IT shop might be 40% technical and 60% people but that just means that you only spend 40% of your time programming.

    But here's the catch, someone must write the code in the end. And someone must maintain it. And the code that is written is of varying quality. If someone is simply a better, faster programming, then their code will be cheaper to maintain because it will break less often and scale better (or whatever your metrics are for code quality). I find that a "nice programmer" might be easier to work with, but those Saturday night production outages make me hate that person all the same. And I'm much more likely to fire him at that point because I think that person is unlikely to have to skills to keep the code working.

    Finally, I think this entire argument is a bit of a crutch. I've seen people who match Josh's description, but usually the best programmers are just crabby because so much of the work falls to them. Then they get painted with "Josh's brush" and labeled as having bad people skills. When really, they are just tired and overworked. If the people with "people skills" had to deal with even 1/10th the work, they would go on a killing spree within a week.

    --
    "Those that start by burning books, will end by burning men."
  78. I myself am a quirky yet briliant programmer by MichaelCrawford · · Score: 5, Interesting
    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. 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.

    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 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.
  79. The fundamentals of being a good engineer by DomainDominator · · Score: 3, Informative

    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.

  80. Re:These guys are all right. by Weaselmancer · · Score: 2, Interesting

    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.

    None taken.

    I'm not suggesting that no struggle matters - quite the contrary. What I am saying is that there are struggles that can make a difference to you, and there are those that can't. Being a perpetual outsider because the whole world sucks is an example of just such a pointless struggle.

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

    Boring was from the OP, I was quoting. I'm happy with my lot.

    I'm not placing more value on my life than anyone else's. In the end, we're all just about twenty bucks worth of water and salt anyways.

    What I am saying is that using pain and alienation to make your life meaningful is a waste. Stop carving My Chemical Romance lyrics up your arms up and enjoy what you've got.

    Life ends. Surprisingly quickly, too. So make the most of what you have.

    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'm not even vaguely bitter - I think we're arguing at cross purposes here. I'm saying be happy because life is short. Too short to waste it with useless meaningless teenaged angst. I have friends in their late 40's who are still clinging to it. All it buys them is suffering. There isn't any meaning to it. There isn't any point to it. Or any beauty or truth either. It's just pain and you don't need it.

    If you want to go out and help people, do it. If you want to grow roses, do that. Do whatever you can to wring as much joy out of your short years as possible. What worked for me was to stop fighting things and join the human race.

    I have never been as happy and fulfilled as I am right now. When I look down my street and see people going about their lives I don't see drones, or sell-outs, or mindless zombies. I see people who are probably as happy and blessed as I am. And rather than cook up a list of reasons why they suck, nowadays I think they're probably a lot like me. And hopefully just as happy, too.

    --
    Weaselmancer
    rediculous.
  81. What happened to "Diversity?" by Virtucon · · Score: 2, Funny

    After reading this I thought "humbug." What ever happened to "Diversity" and accepting people for who they are. Most brilliant programmers I've come across in my career weren't very sociable. Some could be jerks but at times aren't we all? I worked with a guy like that who was involved in some of the early days of computing, eclectic yes, arrogant, sometimes...

    Or is it that we only pay lip service to "Diversity" just to be inclusive of race or sexual preference so companies can push us to the lowest common denominator? Ahh yes, strive for mediocrity, that's what the MBAs want. Don't stir the pot, sit down and shut up.

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
  82. Re: brilliant and dangerous? by shutdown+-p+now · · Score: 2, Interesting

    I dont hear anyone bitching about executive pay or perks.

    You've got to be kidding...

    If their code is so useful in the first place (and it is by virtue of the fact that most companies would rather hire one talented developer than several mediocre ones), why not ensure they stay?

    Because it is usually quite possible to hire developers that are just as good, but that are not jerks. They may be slightly less brilliant, but they make up for it because they can actually work well in a team.

    By way of disclosure I am one of those developers - and I argue to have things taken off of my plate (documented, designed etc) outside of my scope specifically because I dont know what will happen tomorrow (hit by a bus, food poisoning etc) and a team of people like u most likely will take over.

    First of all, you assume that I'm one of the "rank and file" devs. In practice, I had been in the role of "star developer" in my division in the past, so I know how that works from the other side. But note that we aren't talking about this phenomenon in general, but about a very specific subset of such people, who are "good" (for some definition of it) on the technical side, but are arrogant and uncooperative with other people whom they perceive to be lesser.

    The number of times I've told management "yes its possible but do you really want me to responsible for the well-being of your company, if I drop dead where will that leave you?" cannot be counted.

    See now, if you ever told that sort of thing to your manager, TFA is not about you, and neither are any of my comments above. You seem to understand the bigger picture, which isn't just about you.

    Your requirements for (excessive) documentation is a direct transfer from my finite amount
    of time available on this earth (solving problems) subsidizing your mediocrity. GROW!

    Why do you assume that I require "excessive" documentation? When I say "bad docs", I mean stuff like 50 kLoC of code that has not a single comment in it; not forgetting to fill in the "detailed description" in the documentation comment for a private method!

    By the way, regarding the "finite amount of time" - that's all well and good when you solve problems for your own sake. But when you're at work, the time is not "yours", really - it's bought by the company you work for, and you should use it in a way that's more efficient for the company. Sometimes that means being more patient when it comes to dealing with abilities of people around you, even when they're lower.

    I was in that position as a senior dev who got promoted to lead very fast, and had to learn to manage a small team of my own. I had to struggle with that "if you want to do things right, do it yourself" attitude. Yes, I could do it better than my juniors could, and faster as well. But you know what? Once I've learnt to delegate appropriate tasks, and, when coding, to keep in mind that I may later want to assign the mainenance of that bit of code to one of the juniors, and dumb things down sometimes, or at least comment the "smarter" pieces even when they would be obvious for myself, I've found that the overall productivity of the team increased - precisely because I could offload those maintenance tasks to them, and keep working on new code that truly required more knowledge and experience to be done right.

    If you keep writing more and more code that only you can maintain, then, eventually, you'll end up doing nothing but maintaining that code - and that is usually not fun (and at that point, people often pack up and leave to find a more "fun" place to work at, and start writing "fun" code there as well... and cycle repeats - and the old place is left with unmaintainable "smart" code, and no-one able to deal with it). And it doesn't matter whether it's because you're being too much of a smartass, or because the people around you are truly idiots - the end result is the same. Worth keeping that in mind for one's own sake.

  83. And this is why.. by magamiako1 · · Score: 2, Funny

    Reading these comments make me realize the sad state of the tech industry.

    Look, who gives a damn if the guy is a "people person" or not. When they come to you and say that they're not paid to document or be a people person, that's correct. They did not go to school, spend their lives learning how to "be a social butterfly", they went to school for coding.

    Their job description, in this case, says "programmer" not "social worker".

    I'm sure if you took the time to ask "Josh" about what he's doing he would be more than willing to tell you, but only if you're not sitting there trying to derail the conversation to bullshit about fantasy football the whole time.

    I should know..I'm this type of person. I'm not the crazy genius that many people here have been discussing, but I'm "that guy". I've always pretty much been "that guy".

    That doesn't mean I'm "that guy" for every computer-related incident, but I certainly know my shit and far more than most of my peers.

  84. Re: brilliant and dangerous? by Nefarious+Wheel · · Score: 3, Informative

    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
  85. Re: brilliant and dangerous? by wrook · · Score: 2, Interesting

    Programming can be an extraordinarily complex

    Sometimes this is true. If you have to do a lot of math, for instance, it can be true. But, if I look back on my career of 20 years of application programming I can think of only 1 or 2 instances where the problem I was working on was difficult. The rest of the time it was the code that was difficult.

    If you find that programming is extraordinarily complex a substantial amount of the time, then you have some problems. It's only that way because you or your team have created complexity when you really don't need it. Pair programming with somebody who is extremely good at refactoring can help you learn how to improve.

    I know this is hard to believe. Especially when you are used to being the superstar programmer on the team. You are able to deliver when others can't. And your code is probably better than other code you've seen, so you think it must be really good.

    But there's a whole new level you can get to. I'm not saying this to put you down. I'm still working hard to improve myself. But with the approach you are taking, you'll hit a glass ceiling pretty quickly where you can't get any better (from the sounds of it, you've already hit it). I just want to encourage you to look at other methods so that you can break through the place you're in now.

    When you do get through it, you'll find that programming extraordinarily simple, but that "good taste" is difficult to refine. And that refinement requires conversations with other programmers (both in code and in human speech). These conversations require give and take, not leadership; learning and sharing, not enforcing direction. I hope that helps (but even if it doesn't, good luck anyway :-) )

  86. Re: brilliant and dangerous? by stephanruby · · Score: 3, Insightful

    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.

    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.

  87. Re: brilliant and dangerous? by fractoid · · Score: 4, Funny

    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.