• brian (unregistered)

    code complete is a solid book

  • Zak (unregistered)

    Maybe it's time for a new site feature: Better Than Success, that highlights extraordinarily good code.

    CAPTCHA: atari

  • Ryan H (unregistered)

    Plain and simple, the barrier to entry for this profession is too low. No other respectable profession tolerates this much mediocrity. If one could go to school for 4 years as a political science major all the while teaching himself to write Java and land a job at a development shop, the system is broken. Nobody could go get a liberal arts degree and hang out a shingle that had "doctor" or "lawyer" or even "architect" on it. These people all had to study and pass BOK (body of knowledge) exams that prove they at least have half a clue what is going on. But no, not software developers. And the poorly educated developers of ole' have become the managers of today, interviewing and hiring the poorly educated developers of today. When we stop accepting mediocrity in this profession, it will become just that, a profession.

    Note: I'm sure some whiney poli-sci major who is a spectacular architect is going to gripe and groan about my post. All I'm saying is that I've seen more people without formal CS education from whom I'd like to revoke the authorization to develop software than not. Formal CS education isn't an indicator of developer competency, but it can be a predictor.

  • Matt (unregistered)

    I like Code Complete, but "seminal"? Really? That's a word I'd reserve for the likes of Knuth and Dijkstra.

  • Corporate Cog (unregistered)

    I haven't done a ton of it, but when I have made suggestions (blogs, Code Complete) it has fallen on deaf ears. And those ears needed badly to hear...

    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the only thing that matters.

  • Brainslugs83 (unregistered)

    Yeah, so I have this book called 202 high paying jobs you can get without a college degree, and there's a whole section on computer programming, web site designer, etc...

    no joke.

    captcha: bathe

  • Economics (unregistered) in reply to Corporate Cog

    You guys are ignoring the reason why mediocrity exists in our profession.

    Companies don't want to pay for good developers. They want to pay shit wages to compete with India and China.

    They also probably don't want you to be a genius at your job because you will see how much better you are at your job than others and start asking for more money. Or you will leave.

    Pretty soon you will all be bitching about the WTF code coming from India and China that you are supposed to sit over here and maintain on-site in America, and companies won't care.

    You better just keep ahead of those who are cheaper than you to ensure your job security in the future. If you can write better code than the Indians, you will have a job because you'll be able to fix the shit of theirs that doesn't work, but unfortunately you won't be able to rewrite the entire application.

    So in essence, code quality and the job market is going to get a lot worse ladies, so make sure you are either great at your job, or you have a backup plan.

  • KattMan (cs) in reply to Corporate Cog
    Corporate Cog:
    I haven't done a ton of it, but when I have made suggestions (blogs, Code Complete) it has fallen on deaf ears. And those ears needed badly to hear...

    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the only thing that matters.

    Hear hear! I had a manager once that always tried to win arguments with the ole "I've got 20 years in this field, I know what I'm talking about!" The problem is that he hasn't learned anything new in the past 15 years.

    But alas, I doubt this will be fixed anytime soon. The bar will never be raised until we all as developers demand much higher salaries. Higher salaries would mean stricter guidelines on qualifications, just like the doctor makes a lot so he better have passed some minimum competency test.
    The problem with this is that if we demand higher salaries we will be out of work because there are far to many out there that can do "good enough" to get by. Salaries will remain low and as such so will the qualifications.

  • Brian (unregistered)

    Maybe YOU write bad code, but MINE is perfect!

  • Economics (unregistered) in reply to Economics

    I meant to say, "So in essence, code quality and the job market is going to get a lot worse before it gets better ladies, so make sure you are either great at your job, or you have a backup plan."

  • Joshua Starr (unregistered)

    <Nelson Voice>: HA-HA

  • seline (unregistered)

    Seriously, it was the right decision not to post this initially.

    Sometimes you gotta go with your gut and not second guess yourself.

  • oGMo (unregistered)

    We don't all write bad code. You may write bad code, and all the people you know may write bad code. But quite a few of us also write good code. And we don't just read this site to laugh... we read it to commiserate over the crap we have to deal with from people who are writing the crap code (or being crap managers, or doing whatever job they do so badly that it's absurd).

    If you're writing crap code, go find another job.

  • bullseye (cs)

    I think that more and more people are beginning to realize that there is a problem in the software development industry with non-standardization. Unfortunately, most of those people are in the industry themselves, and are not the clients that are supplying the work.

    If I need a civil engineer or structural architect, I wouldn't place an ad in the paper or on a website. While I might send out the equivalent of an RFP to various firms, I certainly would want to see credentials backing up the proposals that I received. I highly doubt that any building project was ever awarded to a guy no one had ever heard of, with no proof of an ARE or other equivalent certification. Yet, this happens everyday in our field. People would think you were nuts if you placed ads for doctors or lawyers in this manner, but it happens all the time for software developers. Even worse, we would never let an eye doctor perform a brain surgery, yet "developer" tends to be sufficient to cover just about every computer project.

    Part of the problem is the expectation of the work. There is no standard set of deliverables for a software project, allowing many "developers" to get away with a sub-par development cycle. Not so amazingly, that sequence of events produces much of the material we read on this site. Until the client reaches the point that some of us have been at for a while, we'll continue to lose projects to someone's nephew or cousin who can do it for a third of the cost. Fortunately, we sometimes get a second shot at it when the project fails.

  • The cow says... (unregistered) in reply to Matt
    Matt:
    I like Code Complete, but "seminal"? Really? That's a word I'd reserve for the likes of Knuth and Dijkstra.

    I would say "seminal" is fair. McConnell on one hand and Knuth and Dijkstra on the other were talking about different disciplines. Both are necessary, but programming is only one part of software development.

    Code Complete covers the pragmatic side of software development as a collaborative pseudo-engineering discipline in a way that The Art of Computer Programming never did. Programmers certainly need to understand big-O analysis, the intricacies of different data structures, the properties of different classes of algorithms as exemplified by the detailed treatment of sort and search in TAoCP, but that alone is not enough to develop complex systems.

    As banal as it seems at first glance, McConnell's detailed discussion of how to organize modules for easier maintenance and parallel work, how to name variables, how to judiciously comment, integration and planning strategies for developers, etc. is critical to being to develop a system with ten or fifty or one hundred developers rather than being limited to one or two before the team churns out more spaghetti than Little Italy on Columbus Day.

  • Sgt. Preston (unregistered) in reply to Ryan H
    Ryan H:
    Note: I'm sure some whiney poli-sci major who is a spectacular architect is going to gripe and groan about my post. All I'm saying is that I've seen more people without formal CS education from whom I'd like to revoke the authorization to develop software than not. Formal CS education isn't an indicator of developer competency, but it can be a predictor.
    As a software developer who has a political science degree (among others) I appreciate your adding this caveat.
  • ObiWayneKenobi (unregistered)

    The problem is twofold: #1 - Companies don't want to pay squat for good programmers because it's all about how little you can offer, and #2 - Companies don't care about the code quality, they care about how it works. I don't know how many times I've basically hacked together some code that "just works" to meet a deadline or appease some Pointy-Haired Boss that understood jack sh*t about technology but somehow was running a company breathing down my neck for some neat feature that had already been promised to the customers. Sometimes code quality has to suffer in order to get things done, or otherwise you'll end up out of a job because you took too long making sure your code was right instead of producing "results"

  • KattMan (cs) in reply to Ryan H
    Ryan H:
    All I'm saying is that I've seen more people without formal CS education from whom I'd like to revoke the authorization to develop software than not. Formal CS education isn't an indicator of developer competency, but it can be a predictor.

    And I have seen more than my share of "programmers" with a formal CS education that shouldn't be allowed near a PC let alone an actual compiler.

    A formal CS education means absolutely nothing after the first few years because what they teach these days has little to no relevance to actual modern practices.

    Granted if I were to hire someone with no experience, I would hire someone with at least some formal education in the field over someone with absolutely none. But if I wanted someone with ten years experience I care not if they have a ten year old degree because that information is mostly meaningless now and the basic theory should be understood by both the degree holder and the one without.

    The problem with the above scenario is it now becomes hard to determine which one is really the better programmer. Degree or certification really can't show that.

  • fennec (cs)

    The Daily WTF is now dead to me. Please join in a moment of silence.

         v.v    
  • ObiWayneKenobi (unregistered)

    To add one more thing (why isn't there an Edit Feature? Now that's a WTF!), the bigger problem IMO is that companies don't want to pay. Where I live, most entry-level programming jobs pay around $26k a year and the company thinks that's being generous. Senior positions offer more but they also expect around 15+ years in the field.

  • packrat (unregistered)

    I'm a Java Technical Lead. I have the following people working for me. Try to match the qualifications with the title.

    "Coding Machine" takes vague design, sucessfully implements it. Firm believer in the "junior developer 2 am page fix in 4 hours" rule.

    "Cowboy Tony" takes a design, reads it, decides he knows a better way, then codes it however he feels. Likes to rewrite existing code just because he can.

    "Silent Bob" takes detailed design, implements it. When he discovers issues, he suggests a good solution. Spends free time programmer testing or studying java books.

    "Mary" takes very detailed design and impliments it to the letter. Assignments must build upon one another or code example provided. Spends free time studying.

    qualifications person 1 - CS degree and 3 years experience in VB. No Java work experience. Returning to work after 7 year absence. ( Okay this is the easy one)

    person 2 - 3 years college. Ex mainframe programmer. 8 years professional experience 6 years of java.

    person 3 - non cs degree. Sun Certified Java Developer. 4 years current position. 5 years elsewhere. 4 years Java

    person 4 - cs degree. Sun Certified Java Developer. 20 years programming experience. 1st Java position. Less than 2 months java.

  • Galelasa (cs)

    Do I sometimes write bad code? Unfortunately, yes... Do I mean to? Of course not...

    The fact is, like any other profession, real world experience counts. Never mind a B.Sc, I tumbled out of a career college with a certificate in Programming in just 16 months; a new concept introduced about every 2 weeks and a 4 month internship to top it all off.

    And into the world they then sent us with their best wishes...

    Looking back now on some of the code I wrote just 2 years ago makes me want to cringe. The happy news is that I've learned from those mistakes, including (hopefully), how to avoid making them again. My code gets better every day.

    The point is that while bad code can be amusing, frustrating to maintain and sometimes just downright scary, it doesn't make me despair for the industry. We all had to start somewhere. It's all just a learning curve.

  • jedifreeman (cs)

    Long time lurker, first time commenter, I just have to say one thing about all the people claiming they never ever write code that is "bad" in some way or another.

    Bullsh*t.

    No one is perfect, do not claim you always write good code. Sure, we all attempt and strive towards writing good code, but everyone ends up writing something they look back on and go "what was I thinking?"

  • KattMan (cs) in reply to packrat
    packrat:
    I'm a Java Technical Lead. I have the following people working for me. Try to match the qualifications with the title.

    "Coding Machine" takes vague design, sucessfully implements it. Firm believer in the "junior developer 2 am page fix in 4 hours" rule.

    "Cowboy Tony" takes a design, reads it, decides he knows a better way, then codes it however he feels. Likes to rewrite existing code just because he can.

    "Silent Bob" takes detailed design, implements it. When he discovers issues, he suggests a good solution. Spends free time programmer testing or studying java books.

    "Mary" takes very detailed design and impliments it to the letter. Assignments must build upon one another or code example provided. Spends free time studying.

    qualifications person 1 - CS degree and 3 years experience in VB. No Java work experience. Returning to work after 7 year absence. ( Okay this is the easy one)

    person 2 - 3 years college. Ex mainframe programmer. 8 years professional experience 6 years of java.

    person 3 - non cs degree. Sun Certified Java Developer. 4 years current position. 5 years elsewhere. 4 years Java

    person 4 - cs degree. Sun Certified Java Developer. 20 years programming experience. 1st Java position. Less than 2 months java.

    Do we get an answer key at the end of this?

    My Guess: Person 1 = Coding Machine Person 2 = Silent Bob Person 3 = Mary Person 4 = Cowboy Tony

  • Jimbo (unregistered) in reply to ObiWayneKenobi

    I'm in that exact situation. I went 2 years after college washing dishes, to an entry level job paying .50 cents an hour more that I had to fight for. Around other parts of the country I hear rumors that the situation is getting better, however the idea that I'll be forced to leave my friends and family to work in this field is a little harsh to me.

  • spamparranoid (unregistered)

    But I'm an EXPERT

  • KattMan (cs) in reply to jedifreeman
    jedifreeman:
    Long time lurker, first time commenter, I just have to say one thing about all the people claiming they never ever write code that is "bad" in some way or another.

    Bullsh*t.

    No one is perfect, do not claim you always write good code. Sure, we all attempt and strive towards writing good code, but everyone ends up writing something they look back on and go "what was I thinking?"

    I agree.

    I actually had shrink wrapped software on the market up until last week. Took it off the market after a five year lifespan. It was so successful it was still getting sold and recommended but the market it targeted has had so many advances that it was getting to costly to support new users.

    Remember I say this was a successful and highly recommended product. I dove into the code again recently trying to track down a new incompatibility with another product that was only a month old and looking at my class structure I was thinking, "Why the hell did I do that?"

    At the time I thought it was the right way and yes it worked effectively and flawlessly given the environment at the time. These days I wouldn't have done something like that. Come to think of it, since it is now a "dead" project I may pull some of my own WTF's out and share them here.

  • VGR (cs) in reply to Corporate Cog
    Corporate Cog:
    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the *only* thing that matters.
    This is sadly true. In general, there is no recognition of "good software." There is only "finished" and "not finished."

    Since there's no standard for what constitutes good software, it's not much of a surprise that few people in the world are capable of recognizing a good developer or designer. You're right, it's all about how many years you've been doing it. And this makes me want to scream, because I have known so many people who just tune out the computing world's advancements and program exactly as they did twenty or thirty years ago. They have the flight time, but virtually no experience has been gained during that time.

    The original post asks what we can do to remedy the situation. Clearly, one thing that's needed is a standardized concept of good software. Just as SEI provides standards regarding good process, I would like it if some multi-partisan organizational body came up with a definition of good software, both at the user interface level and at the code level. I don't expect such a standard would be quick to write, but then, if it were easy, it would have been done already.

    Once that standard exists, I believe customers will gravitate to it of their own volition. Corporate customers and government entities will start asking for compliance with it.

  • themagni (cs) in reply to bullseye
    bullseye:
    I think that more and more people are beginning to realize that there is a problem in the software development industry with non-standardization. Unfortunately, most of those people are in the industry themselves, and are not the clients that are supplying the work.

    If I need a civil engineer or structural architect, I wouldn't place an ad in the paper or on a website. While I might send out the equivalent of an RFP to various firms, I certainly would want to see credentials backing up the proposals that I received. I highly doubt that any building project was ever awarded to a guy no one had ever heard of, with no proof of an ARE or other equivalent certification. Yet, this happens everyday in our field. People would think you were nuts if you placed ads for doctors or lawyers in this manner, but it happens all the time for software developers. Even worse, we would never let an eye doctor perform a brain surgery, yet "developer" tends to be sufficient to cover just about every computer project.

    Part of the problem is the expectation of the work. There is no standard set of deliverables for a software project, allowing many "developers" to get away with a sub-par development cycle. Not so amazingly, that sequence of events produces much of the material we read on this site. Until the client reaches the point that some of us have been at for a while, we'll continue to lose projects to someone's nephew or cousin who can do it for a third of the cost. Fortunately, we sometimes get a second shot at it when the project fails.

    I posted something like this on Jeff's blog as well:

    Software Engineers are coming.

    The CCPE and the various provincial authourities have endorsed "Software" as an official branch of Engineering. It's the same as Civil, Electrical, Computer, etc. You go through a 4-5 year program to get a degree, then you work under another Professional Engineer for four years. You write a few exams, keep your skills current, and you can call yourself a Software Engineer. (How's that for a barrier to entry? 8-9 years of academic and hands-on experience.)

    The problem is that there are a lot of loopholes that people and companies can use. If the code isn't for public safety, then you can call everyone a "Designer" and not worry about credentials.

    There's also no penalty for failure. What's the worst-case scenario when code fails? (For me, it could be retranqing a tiger, worldwide recalls, or human death, but that's not typical.) Normally, you put out a patch, or you blame the users, or you release a new version.

    Any hotshot idiot who sits at his desk for 50-60 hours a week is considered a superstar no matter what crap gets put out. That's it. That's the only thing that gets measured in software - how many hours do you put in per week, on average?

    When there are no rewards for neither success nor failure, then the industry is problematic to the core. It's really the complete and total lack of long-term planning. Results are only important in the short-term. If the product has an expected shelf life of 1 year, does it matter what will happen to it on two? If not, then why bother putting quality into it when nobody will care enough to complain? That's the real problem. People are so used to software being buggy that they don't bat an eye.

    And Jeff, just for the record: Unplug two of your monitors, use a $30 chair, board up your windows, move three more people into your office, cut your pay down to $45k, and see how it's done by just about everybody else in the world.

    Oh, and thanks for the sticker. ;)

  • themagni (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    (why isn't there an Edit Feature? Now that's a WTF!),

    For unregistered commenters? That would be a failure.

    When registered, you get 5 minutes to edit, then you have to "Append".

  • MyKey_ (unregistered) in reply to Zak
    Zak:
    Maybe it's time for a new site feature: Better Than Success, that highlights extraordinarily good code.

    CAPTCHA: atari

    I totally agree with you. I'd love to read some really beautiful code once in a while. And Jeff, great article, as always!

    PS: Could any one PLEASE tell those "I'm a perfect developer"-kids not to post unless they have something to say.

  • Riznar (unregistered)

    Things aren't quite all gloom and doom. I'm an entry level developer at a private company that is HQ'd in the great plains of the USA. I get paid well, extremely well if you consider that the cost of living here is ridiculously low. I have a formal education in Computer Science and this is my very first full time job.

    I write decent code I guess. I know enough to know that I don't know anything and that the code I write today will be bad compared to the code I write a few months from now. To my great relief I managed to land on a good team that insists on doing things well, one of my very first assignments was to help with a major refactoring project. As I understand it many places don't do this at all.

    For a personal WTF, last week I was ordered by an internal client (They're all internal here) to put two revolting animated gifs up on the front page of the user center. I felt dirty and realized that dammit, I take pride in my work and that is completely unprofessional for a business site.

  • tieTYT (unregistered)

    At my previous job I'd say 50% of the people were bad developers and for 100% of them I can say on occasion that "nobody's perfect".

    But generally I've found the bad programmers aren't bad because they're ignorant: They're bad because they don't care and it often benefits them not to. In my experience, the bad programmers always finish their task first and get a ton of bugs later. If you work for a shitty company, that approach to problems may make you look better than doing it right the first time and taking more time to do it.

  • John (unregistered)

    Here's my theory:

    The vast majority of coders suck at coding. It's undeniable. Why, though? The .com boom certainly didn't help. A lot of people were in high school during the boom, and were told that computers were where the money is, and subsequently decided to go for it for the money, whether they were really suited for it or not (and most weren't).

    The typical American school system doesn't help. At the three schools I attended, they graded on a curve, and everyone knew it. Tests with more than half the questions wrong were graded as A's, simply because no one did any better. I ended up skipping entire classes and not even looking at the books, and still ended up with a perfect average. Why would I waste my time in boring lectures trying to perfect my skills, when you can do a half-assed job and get a perfect grade?

    So it's for reasons like this that bad coders graduate, and get jobs.

    Of course, then the .com bubble burst, and jobs started disappearing. This went a long way towards weeding out the truly bad from the people who could at least code. But then companies realized something... code can be bought for cheap if you outsource it to India (or bring the Indians over here). So now companies can still maintain their massive workforces of coders for significantly less money.

    But here's the rub. A typical manager at a software dev company doesn't have a clue about proper coding practices. Sure, they may have, 20 years ago, but they've been managing for so long that none of their tech knowledge is useful anymore. To a manager, all they see is the shiny GUI of the latest project, and they think it's done well.

    Even if they opened up the hood (which they usually don't), they wouldn't be able to tell that the entire thing was hacked together using stolen code from codeproject.com, and none of it was commented. They see the GUI and say "Awesome!".

    So meanwhile, Indian universities are churning out droves of workers who seem to be taught that everything can be solved by copying code from the web, management thinks its great since they get their shiny GUI for less money. Then when the maintainence nightmares come down the line, the managers usually try to blame the tools for the problems, and not actually realise that the vast majority of people who are writing code shouldn't even be allowed near a compiler. I had a manager blame a projects failure on .NET once, and said that it wouldn't have failed if it was in Java. No it couldn't have possibly been those outsourced workers who didn't even speak english and got paid $5/hr to create enterprise software.

    There's a reason why overseas workers are so much cheaper: you get what you pay for.

  • trianglman (unregistered) in reply to packrat
    packrat:
    I'm a Java Technical Lead. I have the following people working for me. Try to match the qualifications with the title.

    "Coding Machine" takes vague design, sucessfully implements it. Firm believer in the "junior developer 2 am page fix in 4 hours" rule.

    "Cowboy Tony" takes a design, reads it, decides he knows a better way, then codes it however he feels. Likes to rewrite existing code just because he can.

    "Silent Bob" takes detailed design, implements it. When he discovers issues, he suggests a good solution. Spends free time programmer testing or studying java books.

    "Mary" takes very detailed design and impliments it to the letter. Assignments must build upon one another or code example provided. Spends free time studying.

    qualifications person 1 - CS degree and 3 years experience in VB. No Java work experience. Returning to work after 7 year absence. ( Okay this is the easy one)

    person 2 - 3 years college. Ex mainframe programmer. 8 years professional experience 6 years of java.

    person 3 - non cs degree. Sun Certified Java Developer. 4 years current position. 5 years elsewhere. 4 years Java

    person 4 - cs degree. Sun Certified Java Developer. 20 years programming experience. 1st Java position. Less than 2 months java.

    I definately would like to see the answer too.

    My guesses:

    1. Mary
    2. Machine
    3. Bob
    4. Tony
  • KattMan (cs) in reply to VGR
    VGR:
    I would like it if some multi-partisan organizational body came up with a definition of good software, both at the user interface level and at the code level. I don't expect such a standard would be quick to write, but then, if it were easy, it would have been done already.

    Once that standard exists, I believe customers will gravitate to it of their own volition. Corporate customers and government entities will start asking for compliance with it.

    For the UI, that standard already does exist. It does define the difference between radio buttons and check boxes and their intended purpose. Customers have gravitated to it as they know exactly what the difference is even if they can't explain it. Even with this, I have had arguments with one particular manager (yes the one with 20 years experience) about why making check boxes work like radio buttons was a bad idea. He just didn't get it. In the end of course he won, he had 20 years over my 15 after all. So I spent days writing an entire javascript library to modify every checkbox array on a webpage to work like radio buttons.

    Not long after, we had check boxes that needed to work like check boxes. Did we remove the library and change the previous ones back to radio buttons? No, the recommendation was to use a naming standard so the library would know if it should treat them differently (differently meaning like normal check boxes).

    I left shortly after that. Unemployment was preferable to fighting that level of incompetence.

  • John K (unregistered) in reply to Riznar

    You are absolved, my son. A) you were only following orders and B) no code was actually involved so the crime is much less than you think.

    ;)

  • E (unregistered) in reply to Ryan H
    Ryan H:
    Plain and simple, the barrier to entry for this profession is too low.

    Isn't this by design? After all a main selling point of VB is that it makes it easy to develope apps in windows.

  • VGR (cs) in reply to KattMan
    KattMan:
    For the UI, that standard already does exist. It does define the difference between radio buttons and check boxes and their intended purpose. Customers have gravitated to it as they know exactly what the difference is even if they can't explain it. Even with this, I have had arguments with one particular manager (yes the one with 20 years experience) about why making check boxes work like radio buttons was a bad idea. He just didn't get it. In the end of course he won, he had 20 years over my 15 after all. So I spent days writing an entire javascript library to modify every checkbox array on a webpage to work like radio buttons.
    Out of curiosity, who is the source of this UI standard? Are you talking about the W3C? The UI style guides of Apple, Microsoft, Sun and Gnome?
    KattMan:
    Not long after, we had check boxes that needed to work like check boxes. Did we remove the library and change the previous ones back to radio buttons? No, the recommendation was to use a naming standard so the library would know if it should treat them differently (differently meaning like normal check boxes).

    I left shortly after that. Unemployment was preferable to fighting that level of incompetence.

    You are not the first to leave over unspeakable UI decisions. I ended up adding half an hour to my commute due to changing jobs. And I'm not sorry.

  • Ben (unregistered)

    The great thing about this, for me, is that I accidentally discovered coding horror long ago as a TDWTF newb while trying to remember wtf that damn bad code website url was ...

  • snoofle (unregistered) in reply to VGR
    VGR:
    Corporate Cog:
    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the *only* thing that matters.
    This is sadly true. In general, there is no recognition of "good software." There is only "finished" and "not finished."

    Since there's no standard for what constitutes good software, it's not much of a surprise that few people in the world are capable of recognizing a good developer or designer. You're right, it's all about how many years you've been doing it. And this makes me want to scream, because I have known so many people who just tune out the computing world's advancements and program exactly as they did twenty or thirty years ago. They have the flight time, but virtually no experience has been gained during that time.

    The original post asks what we can do to remedy the situation. Clearly, one thing that's needed is a standardized concept of good software. Just as SEI provides standards regarding good process, I would like it if some multi-partisan organizational body came up with a definition of good software, both at the user interface level and at the code level. I don't expect such a standard would be quick to write, but then, if it were easy, it would have been done already.

    Once that standard exists, I believe customers will gravitate to it of their own volition. Corporate customers and government entities will start asking for compliance with it.

    ou said the magic word - tie quality standards to SOX compliance and watch it take hold when CEO's butts are on the line...

  • snoofle (unregistered) in reply to VGR
    VGR:
    Corporate Cog:
    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the *only* thing that matters.
    This is sadly true. In general, there is no recognition of "good software." There is only "finished" and "not finished."

    Since there's no standard for what constitutes good software, it's not much of a surprise that few people in the world are capable of recognizing a good developer or designer. You're right, it's all about how many years you've been doing it. And this makes me want to scream, because I have known so many people who just tune out the computing world's advancements and program exactly as they did twenty or thirty years ago. They have the flight time, but virtually no experience has been gained during that time.

    The original post asks what we can do to remedy the situation. Clearly, one thing that's needed is a standardized concept of good software. Just as SEI provides standards regarding good process, I would like it if some multi-partisan organizational body came up with a definition of good software, both at the user interface level and at the code level. I don't expect such a standard would be quick to write, but then, if it were easy, it would have been done already.

    Once that standard exists, I believe customers will gravitate to it of their own volition. Corporate customers and government entities will start asking for compliance with it.

    ou said the magic word - tie quality standards to SOX compliance and watch it take hold when CEO's butts are on the line...

  • snoofle (unregistered) in reply to VGR
    VGR:
    Corporate Cog:
    Here's another challenge: finding someone in the position to make a hiring decision that gives a rat's arse about a code monkey focused on quality code. It seems that the number of years experience in a given technology is the *only* thing that matters.
    This is sadly true. In general, there is no recognition of "good software." There is only "finished" and "not finished."

    Since there's no standard for what constitutes good software, it's not much of a surprise that few people in the world are capable of recognizing a good developer or designer. You're right, it's all about how many years you've been doing it. And this makes me want to scream, because I have known so many people who just tune out the computing world's advancements and program exactly as they did twenty or thirty years ago. They have the flight time, but virtually no experience has been gained during that time.

    The original post asks what we can do to remedy the situation. Clearly, one thing that's needed is a standardized concept of good software. Just as SEI provides standards regarding good process, I would like it if some multi-partisan organizational body came up with a definition of good software, both at the user interface level and at the code level. I don't expect such a standard would be quick to write, but then, if it were easy, it would have been done already.

    Once that standard exists, I believe customers will gravitate to it of their own volition. Corporate customers and government entities will start asking for compliance with it.

    You said the magic word - tie quality standards to SOX compliance and watch it take hold when CEO's butts are on the line...

  • snoofle (unregistered) in reply to snoofle

    Damn - first no resopnse, then three copies of the same post - sorry!

  • phaedrus (cs) in reply to packrat

    Here's my guess:

    packrat:
    I'm a Java Technical Lead. I have the following people working for me. Try to match the qualifications with the title.

    [... snip ...]

    person 1 - CS degree and 3 years experience in VB. No Java work experience. Returning to work after 7 year absence. ( Okay this is the easy one)

    Cowboy Tony.

    person 2 - 3 years college. Ex mainframe programmer. 8 years professional experience 6 years of java.

    Silent Bob.

    person 3 - non cs degree. Sun Certified Java Developer. 4 years current position. 5 years elsewhere. 4 years Java

    Mary.

    person 4 - cs degree. Sun Certified Java Developer. 20 years programming experience. 1st Java position. Less than 2 months java.

    Coding Machine

    How wrong did I get it?

  • poochner (cs) in reply to Joshua Starr
    Joshua Starr:
    <Nelson Voice>: HA-HA

    Earlier, much lesser known example. Funny movie, though.

  • David Sokol (unregistered)

    Geez, way to bum me out on a Friday.

  • Gsquared (cs)

    I see a lot of "coding should have entry requirements like doctors or architects or engineers". I have to disagree with it in most cases.

    In very few coding situations will a simple mistake result in loss of human life.

    If a doctor makes a mistake, it's very possible for someone to die. (How easy do you think it would be to accidentally put someone on a blood thinning agent who routinely uses aspirin for headaches? How does that mistake compare to using "=" for both assignment and comparison?)

    If the architect of a large building makes a mistake, it's possible for hundreds of people to die when the building catches fire or collapses. How does that compare "select * from largetable1, largetable2" causing your network to suffer from bandwidth problems?

    Keep in mind also that doctors and lawyers and such have to spend a huge percentage of their income on various versions of malpractice insurance. So much so that there have been problems with people leaving the medical profession or closing down clinics because they could no longer afford the insurance costs. (These were not doctors who messed up, they were doctors who paid higher insurance rates to cover the legal costs of other doctors who did mess up. That, after all, is what insurance is.)

    And, even with all these safeguards (6 years in school and then more as an intern, high-cost insurance, government regulation of quality, etc.), you still get doctors who overproscribe various high-profit-margin drugs by factors as high as 700% (per FDA and Elli-Lilly studies in 2001-2002). So, it doens't even solve the problem that you are seeking to solve. It just raises costs for people who want to get into the field.

  • evanm (cs)

    This is going to be a long one...

    Firstly, about the purpose of the site. For me, there is far more here than just laughing at other people's code. While yes, that is a (admittedly large) part of it, this whole site (well, except maybe Error'd) is also a place where I can learn on so many level. There's a piece of code, what's wrong with it (sometimes right down to the low level analysis), and how do you improve it? It's also a reasonable place for me to give a quick test of my skills. Looking at some random piece of code, can I i) Recognize the language? and ii) determine what it's purpose is?

    Lastly, we will all write WTF code at some point. But maybe someone wrote similar code before us, and we can learn from others mistakes. Seriously, ask people (individually) about the YAWN (Yet Another Way to Negate) and Negativity Tests (Check if a Number is positive or negative), and see how many different answers you get. Even the senior developers out there can get these ones wrong some days because of a brain fart.

    As for the "value" of our profession, and the need for professional qualifications / standards, take a step back from it all and think about it for a second. As a developer, we truely have two roels that need to be filled. One on hand, we need high level of analysis and skill to code that is able to solve unique problems. On the other hand, there is a large amount of code that needs to be written that has been solved many times before, is repetitive, and generally uninteresting. So here's the $1,000,000 question: as a highly skilled developer, do you really want a job where you spend large portions of your time coding if (x) then Reponse.Redirect ("boring.aspx") ?

    Well, the vast majority of the code that needs to be written is the boring kind, automating simple business processes, rather than code that's trying to solve unique high-level problems. But since we didn't want to force our senior developers to code if statements all day, tools were developed to make the process of writing simple code even easier, and the junior developers were hired.

    But, where's the line between the code that needs to be written by an experience, highly skilled developer, and one that is not? Where does the skilled developer push something down the line, or where does the novice push something up?

    I'm betting that more often then not, code is getting pushed down rather than up. The fact that there's so much WTF code out there is a testament to that. Combine this with the fact that many businesses don't need senior developers optimized code, just developers that can implement their business logic leads to a large population of low-skilled developers being employed and finding themselves writing code for a higher level then they are "trained".

    He's the other part that I think is really key: how does someone become a good developer? One only needs to do a search on Slashdot to find the true problem to our learning problems: "Read other people's code", "Write your own code for fun", "Take part in an open source project", etc. When I look at these options, I find that there's one huge part that's missing: Mentorship.

    The more that I think about it, what's truly missing in the development field is a clear indication of what type of job they really are. The high level developers, the ones that design the data structures, application models, etc., they are the professionals of our field. They are the engineers, designing that which gets implemented. But what about the junior developers writing if statements day in and day out. I think we can agree that they aren't "professionals" at the same level as our senior guys.

    But, if they aren't "professionals", what are they? this is the part that no developer out there actually wants to admit, because of stereotypes and stigmas: The junior developers are the plumbers, the welders, the carpenters. At the end of the day, they are labourers in a trade skill.

    I don't think it is until we accept this fact that we're going to see an improvement of the quality level of our labour pool. For centuries, the other trade skills have had a pretty well defined system: Apprenticeship. Working directly with someone, learning from them on the job.

    We look at a piece of string comparison code, and we scream to ourselves "OMG, Why didn't he use regular expressions?". Really, the question you should be asking yourself is "OMG, where did the education system fail him, and not TEACH him about REs?".

    ... Done for now...

  • Tom (unregistered)

    I write LOTS of bad code. Luckily peer code reviews, debugging, and testing find most of it before I check it in.

Leave a comment on “Guest Article: Our Dirty Little Secret”

Log In or post as a guest

Replying to comment #:

« Return to Article