Forgot your password?
typodupeerror
Businesses The Almighty Buck

Coders, Your Days Are Numbered 305

Posted by timothy
from the yes-but-in-what-base dept.
snydeq writes "Fatal Exception's Neil McAllister argues that communication skills, not coding skills, are a developer's greatest asset in a bear economy. 'Too many software development teams are still staffed like secretarial pools. Ideas are generated at the top and then passed downward through general managers, product managers, technical leads, and team leads. Objectives are carved up into deliverables, which are parceled off to coders, often overseas,' McAllister writes. 'The idea that this structure can be sustainable, when the US private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.' Instead, companies should emulate the open source model of development, shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code. And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'" Update: 04/04 19:52 GMT by T : InfoWorld's link to the archived version of the story on open source development no longer works; updated with Google's cached version.
This discussion has been archived. No new comments can be posted.

Coders, Your Days Are Numbered

Comments Filter:
  • by Jane Q. Public (1010737) on Saturday April 04, 2009 @03:25PM (#27459571)
    Proponents of Agile development and similar philosophies have been saying exactly this for many years now. Where have you been?
    • by ushering05401 (1086795) on Saturday April 04, 2009 @03:35PM (#27459641) Journal

      The subject is being revived by the current economic situation, so not as stale as one might think.

      • Re: (Score:3, Interesting)

        by julesh (229690)

        I wouldn't say agile development as a field is stale; it has been gradually attracting interest over the last 10 years, and is more popular now than ever. Yes, this kind of thinking might help it along. But it doesn't really _need_ that help.

        • I'm not saying it's stale at all... in fact that is part of my point. Agile is still quite popular and well. And the message hasn't changed. Therefore, author just wrote about this stuff as though he thought they were original ideas. They aren't.

          Repeat: where has he been?
          • Agile is so last year.
            • by ShieldW0lf (601553) on Saturday April 04, 2009 @07:06PM (#27460967) Journal

              Agile is about keeping coders dumb by not allowing them to look more than two feet in front of their nose. It's about protecting managers from being cut out of the decision process entirely. Which they should be.

              As for the actual article, seems to me that it's the managers whose days are numbered. Coders who have people skills will become managers, coders who don't will remain serfs, and managers who have no technical skills will become unemployed. It won't happen overnight... some existing businesses will continue to employ those managers. But that choice will kill those businesses, because they're basically putting blind men in charge. It'll take time though...

            • Re: (Score:3, Interesting)

              The highest-rated and highest-paid development shops in the U.S. right now are Agile. So what if it's last year? It's this year too.

              If you can think of something better, let's hear it. I'm not seeing any other methods making people rich just lately.
              • Re: (Score:3, Insightful)

                by wisty (1335733)

                That's because there are no Pointy Haired Managers, and no dumb coders.

    • by HangingChad (677530) on Saturday April 04, 2009 @07:27PM (#27461103) Homepage

      Where have you been?

      Same question crossed my mind. The last place I worked, coincidentally a Windows shop, was rife with bureaucratic decision making and process for the sake of process. Tasks that could be accomplished for thousands and take weeks ended up taking years and costing millions. The ironic justification for all the process was that the customer did not feel the old agile environment was providing good value for their development dollars. So they took the vague suspicion and turned it into a massive reality.

      The new contractor manager brought in an army of unproductive people. Including one with the spiffy title Configuration Control Manager. I never did figure out exactly what she did, other than act bossy, look stressed out and pretend to be busy all the time. Busy digging sand. They spent money on Rational licenses but not on training and no one ended up using it. Tried to fit development into a process that lost contact with the actual application users. They brought in five people to maintain an application built by two, instead of keeping the two who built it. What made this mass insanity more than passing amusement while I looked for another job was they were squandering taxpayer dollars. It was Iraq for IT.

      The days of massive IT development projects are over. They've actually been dead for several years but like a zombie those massive projects still limp aimlessly across the IT landscape looking for additional funding blood.

    • by Mycroft_514 (701676) on Saturday April 04, 2009 @08:45PM (#27461625) Journal

      This same bit of rhetoric happens ever time there is a downturn in the IT economy. It never happens the way it is predicted because coding ends up being harder then the authors think.

      As for Agile - another fad, this too shall pass. (We called it prototyping last time around and it failed then too.)

  • yup (Score:2, Funny)

    by Hognoxious (631665)
    tru dat
  • by rlanctot (310750) on Saturday April 04, 2009 @03:26PM (#27459585)

    ...let the inmates run the asylum. I for one welcome our monkey-poo-flinging overlords!

  • by antifoidulus (807088) on Saturday April 04, 2009 @03:29PM (#27459611) Homepage Journal
    where links are checked before they are submitted/published? Or are you just relying on the open-source crowd to tell you that you get a 404 when you click on the 2nd link?
  • by Gorobei (127755) on Saturday April 04, 2009 @03:30PM (#27459613)

    So, I might do well if:

    1) I can actually communicate with the people that are paying me.
    2) I can write code that doesn't suck.
    3) I actually understand the business needs for the code I'm writing.

    Wow. I'll be much more effective now. Thanks.

    • Re: (Score:3, Funny)

      You should have used HTML bullets.

      • by jez9999 (618189)

        No, he should've made a Powerpoint presentation and linked to that.

      • Re: (Score:2, Funny)

        by rthille (8526)

        Could you redo that in a Word 2009 doc, that I can't read and am forced to upgrade because of?

        Thanks,

    • by bigman2003 (671309) on Saturday April 04, 2009 @04:33PM (#27459967) Homepage

      Sadly, the HR departments of the world have no understanding of this. All they care about is matching up the acronyms and buzzwords.

      I've been turned down for jobs because of this bias by the hiring group.

      "What is your greatest strength?"

      My method is to understand the business process, communicate with users, and develop code to achieve the business goals.

      "Oh, we're looking for a senior advanced journeyman JAVA coder."

      Well eff me. Offshore the job and write me a letter when your system doesn't do what you wanted it to.

      • by Gorobei (127755) on Saturday April 04, 2009 @04:53PM (#27460101)

        That's why we don't let our HR department do anything more than post ads, collect resumes, run background checks, type up offer letters, deal with lawyers, and handle workplace issues.

        If you let these people get their well-meaning tentacles into your business, you are screwed. These people are the code-monkey version of management: willfully proud of knowing nothing about the actual business needs, and inordinately satisfied with their mad HR skills. Only thing worse than an HR "specialist" is an MBA who works on his MBA skillz rather than learning the business he is being paid to support.

        We flushed out a lot of the middle-management parasites twenty years ago. Now they seem to be back with new job titles.

        • Re: (Score:3, Interesting)

          by timeOday (582209)
          And yet HR is very able to evaluate candidates in terms of what this headline claims is the most important - people skills. This draws the premise of the article into question.

          I am involved with hiring and firing where I work. I can tell you, for certain, we have gotten rid of numerous people with good soft skills, whom I personally liked, because I gave them specific technical tasks and they couldn't produce. Sure, the best people have both technical and social skills (and they move up almost too fast

    • by Z00L00K (682162)

      I would say that your list should be the other way around and the most important factor is to understand and communicate not with the people that are paying you. They are often just accountants and similar people with little insight in how the customer actually behaves.

      The essential point here is that if you can understand the need of the customer really well then you are already ahead of the crowd. Every customer has their own semantics, business language and methods no matter how similar their products ar

    • 3) I actually understand the business needs for the code I'm writing.

      It's often business end people who don't understand the business needs for the code, and don't want to hear it.

  • by azgard (461476) on Saturday April 04, 2009 @03:33PM (#27459633)

    What he argues is either trivial or bullshit. I don't understand what he says, to be honest, so there are 3 possibilities:

    1. He says that everybody needs to learn communicate. That's trivial. Everybody, even manual workers, need to communicate. You can excel, but if you cannot cooperate, you cannot work in modern society.

    2. He says that communication, not other skills, is where real money/power is. This is also trivial. To scale beyond the abilities of a single person, you have to control other humans, and for that, you need people skills more than other specific skills.

    3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.

    • by julesh (229690) on Saturday April 04, 2009 @03:49PM (#27459725)

      1. He says that everybody needs to learn communicate. That's trivial.

      Trivial or not, there are many so-called "professional" programmers out there who don't seem to understand it. They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it. The focus is on the implementation, not the communication. It should be the other way around.

      3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.

      Did you read the same article as me? I seriously don't see where it says this. What it says it that lead-from-the-top teams where jobs are parcelled out by an architect with a vision and are implemented by junior programmers will go the way of dinosaurs; it says that everyone is going to need to understand the whole product they're implementing it, the business reason why it's necessary, and to interact with the eventual users of the system to ensure that what they're implementing is the right thing.

      This isn't news to some of us, but there are still a lot of people out there who don't seem to understand this.

      • by phantomfive (622387) on Saturday April 04, 2009 @04:17PM (#27459887) Journal

        Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone".

        Yeah right, that's just the reaction on the outside. On the inside the guy is thinking, "He wants me to do pair programming? He's an idiot. Maybe I'll give him tons of reasons and he'll go away." If you have decent programmers, pair programming is a waste of resources. Much better to have team programming, where each person is working on the different parts of the same project. Then when you have problems, you can discuss them with your partner, not on every single line (should we use a while loop or a for loop here?)

        Incidentally, he is right. When I code, I don't think in words, I think in code. If someone speaks to me while I am coding, it can take a second for me to get back into English mode. A similar effect happens when I'm thinking in Spanish and someone unexpectedly says something to me in English. Or when I am playing the piano and someone talks to me.

        And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

        • by Anonymous Coward on Saturday April 04, 2009 @05:52PM (#27460453)

          I'm sorry, but as someone who has recently been exposed to pair programming I can say you're talking out of your backside. If a programmer can't deal with pair programming them they're a very poor programmer. Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution. If you can't do it then it's likely that your ego is taking over and you're ignoring better solutions.
          Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.

          I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.

          • by H0p313ss (811249)

            Damn... where are my mod points when I need them. MOD PARENT UP

          • by AuMatar (183847) on Saturday April 04, 2009 @07:02PM (#27460945)

            As someone who has done pair programming- you're wrong. Wen I have to constantly talk and discuss my work while I'm thinking my output falls by more than 50%. On top of that, almost no bugs other than trivial spelling bugs are caught by the pairing process- the type of bugs that the compile catches anyway. Pair programming doesn't work.

            There are only two situations in which pairing makes sense. One is mentoring- an experienced dev trying to train up a young engineer. The training for the young guy will speed up the learning process and be worth the temporary loss of productivity to the older programmer long term. The second is debugging obscure issues, where it may take multiple people's knowledge of the code to solve it. In any other situation, you'll get less than half, usually less than a quarter of the work you'd get out of having two programmers work independently.

          • by Daniel Dvorkin (106857) * on Saturday April 04, 2009 @08:04PM (#27461353) Homepage Journal

            I'm sorry, but as someone who has recently been exposed to pair programming I can say you're talking out of your backside. If a programmer can't deal with pair programming them they're a very poor programmer.

            Or maybe they just don't want to deal with insulting twits who think that the latest and greatest buzzword is the One True Way to write code.

        • by Have Brain Will Rent (1031664) on Saturday April 04, 2009 @05:52PM (#27460461)

          And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

          It's much older than that - IIRC "The Mythical Man Month" first formalized the idea that N programmers do not produce working code N times as fast as 1 programmer, and that's essentially what is happening with paired programming.

          The real problem was discussed long ago in "Programmers and Managers" by Kraft. Two skilled programmers operating independently will indeed produce good code faster than two programmers paired. The problem lies with the idea that there is a large supply of "skilled" programmers. There aren't and most of software development methodology for the last thirty or forty years has been aimed at creating processes by which mediocre programmers can produce reasonable quality code in a reasonable time. Unfortunately nothing will ever change the fact that the productivity range of programmers spans an order of magnitude, possibly two depending on who you listen to.

          Want good quality results? Hire 5 good programmers, not 15 mediocre programmers. That means that you'll probably have to pay them pretty good coin and treat them well and that is management's real problem. Management dreams of cheap replaceable labor working on an assembly line. After all assembling cars and developing highly sophisticated software have so much in common!

          As for the comments on disturbing concentration - absolutely! Any significant chunk of code is highly complex and detailed. It needs to be kept in the head as a whole, in an organized fashion and in detail. It is nothing short of mind boggling that anyone can imagine that a process that requires being continually interrupted and distracted will aid that task. This is nothing but another doomed attempt to take the bottom 10% of the talent pool and try and squeeze some productivity out of them.

          • The skill range is actually infinity, as there are people who just cant program.

            Of those that can 100:1 is normal

            The US is going to have to grow up, and get educated again, or other places really will eat their lunch. Fortunately Obama seems to realise this, but neither Mainstreet or the rest of the world will put up with the MBA/Wall street culture again.

            If you listened to the G20 proceedings you will realise just how surely the game is up
          • Re: (Score:3, Interesting)

            by mikael (484)

            Management dreams of cheap replaceable labor working on an assembly line. After all assembling cars and developing highly sophisticated software have so much in common!

            Trying to remain an experienced software developer seems to be like a Sumo wrestling match. You are trying to remain in the center of the ring, constantly gaining skills to feed the family and pay the mortgage. All the time, shareholders (investment companies/bankers) and directors are all trying to reduce costs by trying to turn skills into

        • Re: (Score:3, Interesting)

          by Gorobei (127755)

          Hmm, a lot of different programming models are optimal because there are a lot of different business models.

          Independent, decent programmers works great for the "grip it and flip it" model of getting software out the door.

          I've got 10 million lines of production code, and I want every single change to make that codebase better, not worse. So, yes, you check in a while loop when it should be a for loop, at least two people are going to tell you to fix it before it's considered for production. I bitch about p

        • by julesh (229690) on Saturday April 04, 2009 @06:54PM (#27460895)

          And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

          That's one study. I imagine the one you're talking about is "All I really need to know about pair programming I learned in kindergarten" by Williams and Kessler. This study has been criticised for its focus on performance over and above accuracy. I'd suggest you look at some of the broader studies that have been published since that one, e.g. Williams, L. Kessler, R.R. Cunningham, W. Jeffries, R. "Strenghtening the case for pair programming" (IEEE Software), finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently, but more importantly a 13-17% reduction in the number of bugs discovered after signoff, whereas you would usually expect an increase with two programmers working independently. Nosek 1998 (also a Communications paper) found a 41% speedup, which is less than you would expect from two programmers individually, but also found a 43% increase in evaluations of code readability and a 33% increase in evaluations of resulting functionality of the software developed.

          So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code, the code produced during pairing is more likely to solve the problem that it was actually required for, and will be more maintainable afterwards. And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on, thus helping the team maintain the software at a later date, or that most programmers find they can keep up pairing for longer periods of time than they can code by themselves, or that job satisfaction is generally higher for programmers who pair.

          And your description of how you think when you code betrays that you have dismissed this without trying it. You think differently when you're pairing. It's just as effective (if not more so), and the interruption is not a problem.

        • by bertok (226922) on Saturday April 04, 2009 @08:15PM (#27461443)

          And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.

          I once tried pair programming for a few days, and I found the exact same thing. Yes, together, we were more efficient. I could catch bugs the other guy missed while he was typing, which saved him some debugging time. However, it wasn't a huge improvement, I'd say something like 50%, but it took 100% more manpower, so it was a net loss.

          What few people realize though is that pair programming is boring for the person without the keyboard. It's mind-numbingly boring. It's like watching someone do mathematics homework for a whole day. I enjoy programming, but watching other people code is a lot less fun.

      • Re: (Score:2, Insightful)

        by mdwh2 (535323)

        They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming

        I think this is one extreme to the other - I think pair programming is bad for many reasons, but that doesn't mean I can't communicate. It's important to be able to write documents, communicate with other developers, managers, customers, and so on. But that doesn't mean I want to have to be conversing 40 hours a week for everything I do.

        I might as well t

      • Re: (Score:3, Interesting)

        by murdocj (543661)

        Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it.

        I'm often complimented on my ability to communicate ideas and document clearly. I also hate pair programming, pretty much for the reason listed above. The way I like to work is to cycle between talking to one or two people hashing out the ideas, and designing / coding. But when I'm trying to read code in detail, or lay out the details of code, the last thing I need is someone interrupting me every time I'm about to do something. That just doesn't work for me. I have sat with people to pair on particula

        • by AuMatar (183847)

          It's really about fixing flaws in the rest of XP. In XP, you're supposed to skip desig an div straight into coding. So when you code, you're doing design and implementation at the same time. Given that, it makes a lot more sense- using another programmer as a sounding board in design can be very helpful. So pair programming is necessitated by the lack of design- if there's an obvious design flaw its more likely to be caught. Of course, the real problem is you completely skipped an important stage of d

  • by TheNarrator (200498) on Saturday April 04, 2009 @03:40PM (#27459669)

    I think the anti-pattern I see in most companies that are weak in the technology area is the guy at the top is great at landing deals, public speaking, and sales but he can't figure out what those damned pesky nerds are doing and why they need to get paid so much money.

    As a general rule, most successful tech companies are started and run by people with engineering and/or cs backgrounds (Google, Paypal, Ebay, Microsoft to name a few). Many companies these days, which are in the information handling business (finance, etc), have little competitive advantage over their competition except for their technology platform and are thus essentially tech companies, even though they might not know it yet. Now with the down economy they actually have to be better than the competition and can't just survive by endlessly rolling over credit lines. Hence, the greater need for engineers who can create a technological vision for the company instead of just doing what they are told to do by clueless bosses.

    • Re: (Score:2, Interesting)

      by phantomfive (622387)
      The problem is, eventually all technology becomes a commodity. Open Source is a big driver on this. For an example, take word processing: there are tons of good word processors, some are better and some were better than Microsoft Word. A word processor isn't even worth money, you can get it free. Yet why is Microsoft Word the defacto standard? Because Microsoft has the sharpest business skills. Microsoft isn't at the top of the heap because they know technology, it's because they have good business pe
  • by blueforce (192332) <clannagael@nOSpAm.gmail.com> on Saturday April 04, 2009 @03:41PM (#27459671) Homepage Journal

    I'm always amused when I read stories like this about how X or Y is the only possible future of development.

    What works for one application or company doesn't necessarily work for the next. This isn't a one-size-fits-all industry. If it were every company would be using the same languages with the same methodologies.

    Meh.

  • Partially right (Score:5, Insightful)

    by TrailerTrash (91309) * on Saturday April 04, 2009 @03:44PM (#27459689)

    Leaving development decisions to core programmers can lead to chaos in development priorities. A hard core coder may spend large amounts of time chasing down just that little bit of latency in the process scheduler; but what the business needs is a rewrite in order to simplify processes.

    This is why the OS model has a hard time living in the corporate environment. Many times what needs to be done for the business is tedious programming driven by idiots (== users). No one wants to do that. So a core group of programmers ends up adding a plethora of new features that are elegant in implementation, advanced in design, and useless for users.

    The other major factor in corporate America (can't speak for the other 96% of the world) is the vast armies of "business analysts". These people allegedly have communication skills with both users and coders. In reality, however, they are incented to drag out projects in requirements and testing phases in order to make their own functions seem more useful. Many projects I've worked on have burned upwards of 3/4 of the hours billed to business analysts.

    The remedy? Coders who can speak Business, are WILLING to speak Business, are willing to let the needs of the users drive their projects, and the ability to code. In that order. These people are far and few between, sadly.

    • by Stiletto (12066) on Saturday April 04, 2009 @03:56PM (#27459759)

      I've seen my share of products fail miserably because nobody brought in the business analysts or consultants to gather functional and end-user requirements and spec out the system, and, generally, drive the project. Consequently, the engineers are left with an incomplete or incorrect idea of what to build or of what the acceptance criteria should actually be.

      • by Burnhard (1031106)

        I've seen my share of products fail miserably because nobody brought in the business analysts or consultants to gather functional and end-user requirements and spec out the system, and, generally, drive the project. Consequently, the engineers are left with an incomplete or incorrect idea of what to build or of what the acceptance criteria should actually be.

        Well that's where communication comes in. It's easier in small teams, where the people in contact with the customers are easy to reach when a subtl

      • Japanese always work in groups. The boss is the coach who negotiates with the team and goes over the business requirements. The team is rewarded or penalized based on results. The coach minimally is but not to the crazy extend as it is in American culture where the CEO gets credit for everything.

        Engineers need to make technical decisions and work together in a high performance work group and leaders for different things in the code base will alternate on their own depending on respect and who knows more in

    • by thaig (415462)

      I think that the more layers of people that there are between developers and users, the less appropriate or useful the product will eventually be.

  • News? (Score:5, Interesting)

    by drolli (522659) on Saturday April 04, 2009 @03:46PM (#27459701) Journal
    Coding skills are still a necessity. However they never have been sufficient (as the Example of the Reiser vs. Kernel developers shows). If you look in many completely failed projects of the past, and you read the story carefully, a lack of communcation is a very likely reason for *big* trouble (Read the Commodore story....).
    • Re: (Score:3, Funny)

      by MichaelSmith (789609)
      Actually I always thought that communication was the main problem between Hans and the Kernel team.
      • Actually I always thought that communication was the main problem between Hans and his wife.

        FTFY.

  • by anomalous cohort (704239) on Saturday April 04, 2009 @03:47PM (#27459711) Homepage Journal

    There is a lot to be said for the bazaar model of intellectual work. The open source model is certainly an early adopter but by no means does it have a lock on this approach.

    There is a whole new crop of innovation management tools [blogspot.com] that use crowd-sourcing techniques as a better way to work.

    May I humbly submit some of my own tools in this field as examples here? Take a look at this general purpose problem solving platform called Cogenuity [dynamicalsoftware.com]? Cogenuity currently uses a challenge based approach with a heavy emphasis on social networking and collaboration.

    Another tool that I wrote is Code Roller [code-roller.com] which is a collaborative software development project life cycle management solution. It combines software engineering deliverables, process and workflow with project management practices, social networking features, and a crowd-sourcing style recommendation engine.

    Both of these tools are free as in beer.

    Oh, by the way, the infoworld link from the original submission here is broken.

  • Blame open source (Score:5, Interesting)

    by clarkkent09 (1104833) on Saturday April 04, 2009 @03:48PM (#27459723)
    The problem wouldn't have arisen in the first place if the programmers have not as a rule undersold their skills (not least by happily working for free) to the point where they are treated like shit and paid accordingly. The way to do it is to emulate lawyers (as a rule less intelligent than programmers, but not when it comes to money) and sell themselves as highly skilled practitioners of a mystical craft that can only be performed in high priced suits with gold rolexes and not for less than 300K/year
    • by Stiletto (12066) on Saturday April 04, 2009 @04:07PM (#27459829)

      Lawyers can charge what they do and sell themselves as highly skilled practitioners because they passed the Bar exam, which acts as both a hurdle to keep everyone and their uncle out, and as an indicator of some standard level of performance.

      "Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled. So, the field is flooded with tons of mediocre and unskilled coders, punctuated by the rare skilled programmer. This drives salaries down. Everyone in the field is forced to undersell themselves lest they be underbid by one of the many who are all talk and no skill.

      What software engineers need are credible and selective certification programs so that the few very talented professionals who pass can authoritatively show themselves to be skilled. This would definitely help weed the field of posers and amateurs and bring salaries up to where they should be.

      • Re: (Score:2, Insightful)

        by Dragonslicer (991472)

        "Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled.

        You mean my MCSE doesn't make me a skilled software engineer?

        • Re:Blame open source (Score:4, Interesting)

          by mysidia (191772) on Saturday April 04, 2009 @04:27PM (#27459927)

          A MCSE does not certify a software developer. It's an entry-level certification for Windows technician skills.

          MCSD comes a little closer -- it certifies the ability to utilize certain development tools; however, it doesn't really certify engineering skills.

          The best certification I know of for software development skills is to have been the main contibutor and maintainer for a successful open source project for 12 months. Where 'main' contributor is defined as having written at least 30% of the code.

          And 'successful' means you have a (PROGRAMNAME)-users mailing list or forum with at least 100 active subscribers, who have all downloaded the product, and you can measure your number of downloads of any new version of the software in the hundreds of thousands.

          • Re: (Score:3, Insightful)

            by Microlith (54737)

            And 'successful' means you have a (PROGRAMNAME)-users mailing list or forum with at least 100 active subscribers, who have all downloaded the product, and you can measure your number of downloads of any new version of the software in the hundreds of thousands.

            Wow, that's an incredibly arrogant and impossibly high bar to meet. I guess you want to limit the number of "certified" software developers to what, 300? And do what with the rest, fire them all?

            • Re: (Score:2, Interesting)

              by mysidia (191772)

              No, they can still be software engineers. Just not with that particular certification. In computer-related fields, people have a lot of flexibility and no one-cert is the be-all end-all that everyone has to have.

              Just like you can still be a computer security professional, even if you don't have a CISSP cert.

              You can still manage networks without a cisco cert.

              You can still admin Redhat systems, even if you don't have a RHCE, or Apple systems without a ACSP.

              You can be elected city mayor without passing

      • I'm too tired to go into a real sociological discussion about this, but those sorts of things tend to bring wages up but also ensures it costs more to enter into the profession and weeds out talented individuals who just don't have the capital.

      • Re:Blame open source (Score:4, Interesting)

        by Rakishi (759894) on Saturday April 04, 2009 @07:03PM (#27460955)

        Lawyers don't get paid a lot, some lawyers get paid a lot. Just passing the bar exam gives you more or less nothing.

        You have to go to a good school, rank highly at that school, do well on the bar exam, join a well known law firm, work your backside off for 80 hours a week and so on.

      • Can't Tame the Exam (Score:3, Interesting)

        by Tablizer (95088)

        The problem with an "IT BAR exam" equivalent is that software engineering is not yet subject enough to the scientific process to make an objective exam. Can anyone really objectively *prove* that OOP is better than functional or visa versa? That Java is "better than" Lisp? That static typing is better than dynamic? Even objectively proving that goto's are "bad" has been difficult. There's a large psychological aspect to code design.

        At best such a test can verify that one is aware of and skilled at different

    • not for less than 300K/year

      Your ideas are intriguing to me and I wish to subscribe to your newsletter

  • Reading this article I suddenly have the urge to watch Steve Balmer's Developer rap.
  • Turf battle (Score:3, Funny)

    by oldhack (1037484) on Saturday April 04, 2009 @03:55PM (#27459751)
    Guess this is meant for CEOs and CIOs. Interesting ammunition for office politics, but it's CYA time these days - not the best timing.
  • by mikael (484) on Saturday April 04, 2009 @03:56PM (#27459757)

    Even back in the late 1980's it was obvious that thin pyramid management structures were being toppled through downsizing. Some of my relatives took early retirement from companies due to this. Long chains of management over 15 levels deep were definitely going out of fashion: director, assistant director, senior manager, assistant senior manager, supervising manager, project manager, assistant project manager, team leader, lead programmer, senior programmer, programmer, junior programmer and intern.

    Start up companies just a far simpler structure: director, software/hardware architect, team leader, senior programmer and programmer.

    Everyone knew about the hazards of "dead man's shoes" and how important it was to keep your skills up to date or lose your career.

    • Start up companies just a far simpler structure: director, software/hardware architect, team leader, senior programmer and programmer.

      Everyone knew about the hazards of "dead man's shoes" and how important it was to keep your skills up to date or lose your career.

      That is far too many levels. Cut out the software/hardware architect, they are pretty useless with a skilled force anyway. Then have a group that includes strong people skills, strong architectural skills, good system programming, good organization skills and make sure everyone except perhaps one or two is a strong programmer. Then have everyone code (perhaps only a few hours each week for 1-2 people), everyone help out with customer interaction and Bob's your uncle ;) Of course, budget and such needs to be

  • by weston (16146) <westonsd&canncentral,org> on Saturday April 04, 2009 @03:59PM (#27459779) Homepage

    And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'

    I think an equal question is where they're going to find more managers who aren't the habit of seeing coders as black boxes into which their decisions go in and desired code comes out.

    People like to talk about the archetype of the "techie" who is, of course, good with technology but doesn't understand much else. I suppose I've met people who embody this, but generally, my experience is a little different: I frequently meet programmers who are three dimensional people who may be good at writing, music, presentation... even sales. So I wonder sometimes where this persistent stereotype of the "techie" comes from.

    Mind you, this happens the other direction as well: I see programmers who are convinced the "soft skills" of other professionals are easy to pick up and practice and they could be doing any job in the company.

    • Yeah, people like that [today.com] are why female geeks leave the industry. Developers who think they're brilliant communicators until they actually have to talk to a human.

      ...

      The number of female IT professionals in the UK is falling, according to the British Computer Society, despite similar or superior academic scores and recruitment in the sector as a whole having risen in the same timeframe. The lack of flexibility offered by employers is blamed.

      "It's a free market world," said Ubuntu Linux developer Hiram Nerdboy. "It's about competence and getting the job done. Working sixteen hours a day on a project you really love is par for the course. That we're all eighteen to twenty-five is from the accelerated Internet-based learning of the new generation, not exploitation of young workers who donâ(TM)t know any better."

      Over a third of women in IT had complained of sexism up to sexual harassment at work. "Itâ(TM)s women who just don't have social skills," said Nerdboy. "They object to the guys freely choosing to all go down the strip club after work. Theyâ(TM)re just not team players."

      Open source projects have worse figures than industry, with male to female ratios approaching fifty-to-one. Many women cite gross sexism on mailing lists and IRC. "In my experience, women just don't have a working sense of humour and canâ(TM)t take a joke. My girlfriend thought it was funny! Even leaving helpful comments on their blogs didnâ(TM)t work. 'Political correctness' is no exaggeration. Anyway, I met my girlfriend online!"

      "...," said his girlfriend, RealDoll Ada.

      "And it's not like you can get the applicants," added Nerdboy. "We can hardly get any girls to apply for a job here. They're obviously naturally not good enough geeks. It must be evolutionary. We need more pink computers."

    • Re: (Score:3, Insightful)

      by Anne Thwacks (531696)
      I wonder sometimes where this persistent stereotype of the "techie" comes from.

      Dont you watch the mass media? The media are run by people who failed basic science, and assume that, because they are clueless about sci/tech, that anyone with sci/tech understanding must be as clueless about the rest of the world as they are about sci/tech.

      Not only that, they often have a huge personal comittment to protraying techies as "wierd" because it justifies their own willful ignorance.

  • There are 4 basic types of people in the world: Bean-counters, arm-wavers, geeks and outlaws. This piece was obviously written by an arm-waver.
  • Yeah, right (Score:4, Insightful)

    by thethibs (882667) on Saturday April 04, 2009 @04:10PM (#27459849) Homepage

    Switch to the open source model of development where the only things that get implemented are the things the developers are interested in. With all due respect, this would be a return to the bad old days of mainframes when users had to put up with whatever the data processing department built and be happy that they had any automation at all.

    One of the dumbest ideas I've seen on my screen in one devil of a long time.

  • I'm set.... (Score:5, Funny)

    by feepness (543479) on Saturday April 04, 2009 @04:33PM (#27459975) Homepage
    Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
  • I'm nominally a coder. I know the application I'm extending VERY well, but I have only the vaguest idea what the users require. This leads to me working on areas where the application is inefficient, but often working on an item that should be at the bottom of the priority list.

    The solution is good communication with the users (I try) and explaining to management what I think needs to be done and why.

    I can't imagine that people who are experts in business needs, work flow, and applications all at the same

  • by syousef (465911) on Saturday April 04, 2009 @04:43PM (#27460031) Journal

    Instead, companies should emulate the open source model of development

    1. Your mother's basement isn't large enough for the whole company
    2. There may be liability issues if you put your company on a diet of pizza and coke
    3. Employees want to be paid.
    4. It's hard to ship product when all you do is squabble and pull the project in different directions
    5. Most of your employees will prefer to shower.

    If you mod this as troll you have no sense of humour whatsoever

  • If managers are to be the nation's greatest asset, then we're all doomed. There will be nobody left without any technical skills. Sure you can outsource that work, but this causes a disastrous increase in the already epic trade deficit and the Asians are already finding out that they don't actually need the fat manager cats abroad at all. Only engineers and artists can create things of value. There rest, especially management, exists only to support the people that actually know how to make something.
  • The author states that code improvements should be driven by "the developers with the deepest architectural understanding of the code, the closest interaction with the code, and the most responsibility for the code". However, this is a programmer biased perspective and not at all how a business operates.

    A business is focused on making money. For the founders, the owners, the stakeholders with the most financial resources invested, that is what it comes down to. That is why if they find an employee that can

  • Well, yes. And? (Score:2, Interesting)

    by prefec2 (875483)

    I have worked with people who can be categorized as coders. Some of them are good in writing down code blocks some of them are not so good at it. However, most of them arm poor in communicating, contributing in the design phase, or shutting up and implementing the stuff they're asked to do.

    The problem is, that they like to code, but not to plan. But without proper planning no project ever gets finished. So the first problem is that they do not really contribute to the high-level design (if they are invited)

  • Will working Saturdays save me, or should I take the rest of the day off and enjoy the weather?
  • Hey, fifteen years ago it was supposed to be in five years computers wouldn't need code monkeys because they'd program themselves. Ten years ago it was Nural networks that were going to put coders out of work. Five years ago it was "eveyone will know how to code". Now it's elbonia putting us out of work. You ever work with an elbonian coder? Ever notice how everything you ask them to do comes out slightly (or not so slightly) wrong?

    Not that I care - I quit coding for a living years ago. Now I hold hands for

  • For example, today is 04/04/2009. It's a very useful technique, maybe Slashdot just wanted to let us the power at our fingertips?

    • today is 04/04/2009.

      Or, in most of the world, 2009/04/04.

      To be sure its a great idea that America needs more Chiefs and fewer Indians. Isn't the real problem: too many cowboys!

  • I sometimes do a bit of gaming with a group of Thai students at my university. Thai is, of course, the dominate language, though they switch randomly between Thai and English. One amusing thing that I've noticed is how strongly English has influenced gamer culture in other languages. There's just something funny about hearing a stream of incomprehensible Thai with the occasional 'noob' or 'rematch!'

    Incidentally, I love fish fillets (French), have to fix glitches in my code (Yiddish), use wikis (Hawaiian), l

  • 'The idea that this structure can be sustainable, when the U.S. private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.'

    I don't see how the employment figures affect organisational structures and/or development methodologies.

  • Step aside Waterfall, move over Extreme Programming, there is now a software development process that is popular as it is effective. Yes, Avalanche Development Process will be sure to bring your project to a conclusion quickly and effectively. Read on to learn about this new and upcoming development methodology.

    The Avalanche software development process occurs though several stages. In some ways this is similar to Waterfall, but more aggressive. Instead of a calming waterfall we want a Avalanche of producti

  • by Anonymous Coward

    Now I don't mean to be incendiary, but I notice a lot of arrogance on the parts of most so-called coders. Disparaging talk of 'manual labors' and exalted speech on the superlative intelligence of coders over other complicated and nuanced professions (i.e. lawyers) seems prevalent in this thread.
    But at the end of the day, coders are the manual laborers of the software world, and that is not a bad thing. Anyone who has worked a physical job will be able to immediately tell you the difference between a skilled

  • by shrikel (535309) <hlagfarj.gmail@com> on Saturday April 04, 2009 @07:32PM (#27461135)

    So the best way to make sure you'll still be not only hirable, but desirable?

    Learn Hindi.

  • Programmers are neither abstractly creative nor socially comfortable by default; in my experience it is usually the reverse. To be blunt, they are the worst spellers, often haven't read a book (not text, paper or graphic novel...'book') since high school, and have the communication skills of, well, that chubby guy sitting in the corner staring at the ceiling.

    Besides, you only need *one* guy on a team who doesn't sweat like the proverbial whore in church every time he/she has to speak in front of a crowd.

    • Re: (Score:3, Informative)

      by Secret Rabbit (914973)

      Stereotypes aside, that's basically true. Except for the programmers being poor spellers, etc. It's not programmers. It's really pretty much everyone that's graduated in the past decade or so. That might be some hyperbole, but it's not far from the truth. I mean, just look at how the 30+ crowd writes, and then compare that to today's high school graduates. It's chilling.

  • Matrix Layout (Score:3, Interesting)

    by owlman17 (871857) on Saturday April 04, 2009 @10:57PM (#27462343)

    Does anyone remember Matrix Layout (which later became Objects Layout) from the early 90s? You made flowcharts from ready-made blackboxes. The whole thing was drag and drop. It was pretty impressive during the days of DOS. You had a choice of generating EXEs, or C++, Pascal and BASIC (if you wanted to fine-tune your code). An ad in Byte magazine read: "Not a single damn line of code ever again!" And I had thought back then that the days of mainstream coding would be over by the next decade.

  • by DrXym (126579) on Sunday April 05, 2009 @05:16AM (#27463951)

    I work for a company which has development groups in lots of countries including India. For reasons that might have sounded great in theory, they farmed off a lot of maintenance development to India - hey it's 1/3rd the price!

    As a principal / architect I would often be tasked with overseeing their work, or trying to direct their solutions. That experience was incredibly frustrating for multiple reasons:

    a) Cultural differences. Indian developers were the most passive bunch I have ever worked with. They never took the initiative on anything, never offered alternative or better ways to do something, never took time to understand *why* they were asked to do something. Basically if a requirement or design said X they would implement X even if it was ambiguous or nonsensical from a business or coding point of view. Other groups in other countries would push back and the process would improve. This meant the devs had to be closely supervised and all changes reviewed and approved. Tasks took 2-3 times as long to complete which negated any cost savings and also pushed out roll-out times.
    b) Language issues. Email was fine. Phone communications were a complete nightmare. Many Indians simply couldn't be understood on the phone. Verbal communication is a critical skill for any programmer. I recognize English is not their first language but its still a requirement and many other countries manage it just fine.
    c) Revolving door development. Turnover in India was crippling and every fix or update was handled by different people. This made it impossible to imbue business knowledge, or good coding standards or common practice. Development took longer and the code rapidly becomes a mess of hacks and unsafe techniques.

    I'm not saying work can't be farmed out but there has to be a core team of long-term developers. Developers who have business knowledge, developers who will speak out when some requirement is bullshit, developers who have some vested interest in the quality of their code. If you treat developers as an interchangeable commodity you will get back complete shit for your efforts and quality will go down the tubes.

We have a equal opportunity Calculus class -- it's fully integrated.

Working...