Why do so many developers suck?

[Cogman]

I've been in the business professionally since 1990, and started programming in 1975. In that time I can count the number of really good developers I have worked with on both hands and have some fingers left over. I think it's that way in almost any business: you have those who love what they are doing and excel at it; and you have those for whom it's just a day job. I believe programming, by its nature, stretches the gap between those two poles such that the really good developers are much more productive than the average developers.

I thought I would start a new thread for this just because it is an interesting topic that really doesn't belong in a discussion about c vs c++ in embedded systems .

So Mark, where do you think the disconnect is? Is it just the way we teach programming in general? IMO this is one of the bigger problems, we do a lot to enable monkey programmers and punish those that would dare break out of the system.

For my school at least (At least in the starting classes, it kind of weans away in the upper level, however, they instead focus on team effort rather then individual ability) we focus so much on getting a program that EXACTLY fits the mold that we are given. Yeah, we are given the freedom to come up with our own function names, but any creativity is generally punished or just not encouraged (not that the assignments allow for much creativity). For example, we had to make a calendar program for one of my first classes that was able to print out a calendar given a date. So, I researched the subject of making calendars and found/implemented the doomsday algorithm. My teacher made me go back and do it the dumb way (IE loop through from some starting date calculating how many days are in the month and when the new starting date was, or something along those lines).

Stuff like that happen too frequently IMO. Rather, I think starting classes should set the bar higher. So what if a lot of kids drop out, they do anyways after about their sophmore year (Our school has about 120 students that start in the CS program, They graduate around 5).

IDK, IMO programming isn't THAT hard. If you follow the rules you write, everything works. When you break the rules, everything falls apart. It seems, however, that many approach it like a manufacturing plant. They want to take all pre-written code, slap it together with as minimal work as possible, and call it a product.

IE

if (thing1)
{
  doSomething(thing1, 1);
}
else if (thing2);
{
  doSomething(thing2, 2);
}
else if (thing3);
{
  doSomething(thing3, 3);
}

I see statements like this ALL the time. Even in upper level classes.

 

[brandonb]

I think alot to do with it is that people don't understand the scope of what programming is. They probably think of the classic program:

10 PRINT "HI"
20 GOTO 10

They think that's about all that is involved and they're going to get paid alot because programmers in general make decent wage. People like to take classes in school which are in demand, get them jobs, and pay well. Most of the time, they have no idea what's involved, but at a certain point they are "pot commited." (Poker term). They invested all this time and money into something, they might as well see it through and see what happens. Even though they have no idea what's involved, and frankly, just isn't cut out for them.

I think alot of people are naturally wired to be able to program, and others are not. People are different, some get it, other's don't. I'm a programmer but I'd make a very poor bill collector. I'm too laid back and easy going, not assertive enough. I tried it once and realized it just wasn't for me. Unfortunately some people just don't realize it in a timely fashion that they made a poor choice and continue to make poor choices.

But to answer your question. I think some people have the drive to force themselves over the hurdles they run into. They work good independantly, can look in MSDN documentation (such as yourself), and work themselves through the problems, other's just give up and throw in the towel. Programming can take alot of hard work, and when people get discouraged it takes a special breed of person to just struggle through it.

I find it more of a personality trait rather than how people are taught in schools. I think Mark hit the nail on the head with his comment:

I think it's that way in almost any business: you have those who love what they are doing and excel at it; and you have those for whom it's just a day job.

Some are just willing to put in the effort and overcome their lack of knowledge by looking in books, trying to code on their own and learn new things, and other's just aren't willing to put in the effort. I have a gal at work that is learning how to program one of the other guys is training her, and one day he was sick, instead of her just playing with code, or reading a book, looking things up on google, she was reading cosmopolitan magazine all day... She is going to fail, I already know, but she has only been doing this 3 months, so it's too soon to throw in the towel on her behalf at the moment, I have to give her more time to figure it out on her own that isn't just not up her alley.

 

[Ken g6]

For my school at least (At least in the starting classes, it kind of weans away in the upper level, however, they instead focus on team effort rather then individual ability) we focus so much on getting a program that EXACTLY fits the mold that we are given. Yeah, we are given the freedom to come up with our own function names, but any creativity is generally punished or just not encouraged (not that the assignments allow for much creativity). For example, we had to make a calendar program for one of my first classes that was able to print out a calendar given a date. So, I researched the subject of making calendars and found/implemented the doomsday algorithm. My teacher made me go back and do it the dumb way (IE loop through from some starting date calculating how many days are in the month and when the new starting date was, or something along those lines).

Sounds like you had a bad teacher. The only one I had that was at all close to that was in high school, and he just wanted to make sure I didn't introduce my partner to stuff that was too advanced. (Loops! ) But practically every other programming teacher I've had appreciated individual innovation.

Stuff like that happen too frequently IMO. Rather, I think starting classes should set the bar higher. So what if a lot of kids drop out, they do anyways after about their sophmore year (Our school has about 120 students that start in the CS program, They graduate around 5).

I've wondered what happened to the weed-out class. I don't think I ever had one. Then again my graduating class of CS students was the biggest they'd ever had, something like 60, where they'd had 10-20 before. It was like 4 years after the dot-com boom started, and many may have been there just for the money. So I suppose many of my classmates are those developers who suck. :$

IDK, IMO programming isn't THAT hard.

Some would disagree.

It seems, however, that many approach it like a manufacturing plant. They want to take all pre-written code, slap it together with as minimal work as possible, and call it a product.

And many times there's nothing wrong with that. I've heard it said that good programmers are lazy - though perhaps "efficient" is a better word. I want to have the most effect I can on solving a problem, while doing the least work necessary to do it. If pre-written code can be slapped together and make a useful solution, I don't see that as bad. It's not a really interesting problem either, but it's not bad.

if (thing1)
{
  doSomething(thing1, 1);
}
else if (thing2);
{
  doSomething(thing2, 2);
}
else if (thing3);
{
  doSomething(thing3, 3);
}

I see statements like this ALL the time. Even in upper level classes.

I'm not precisely sure what's wrong with that code until you tell me what thing1-3 are. It can't be written as a switch unless they're comparisons with the same variable. An associative array could associate a number with a thing, but that's kind of pointless if they're very different things.

 

[KIAman]

You will have to define a "good programmer" before anybody can even take a position on why there aren't many. According to Mark's quote, he feels that a good programmer is one who love programming and "excel" (which also needs clarification) at it, and those aren't necessarily attributes which are always mutual.

So Mark could come and clarify the meaning of "excel" and the OP can clarify his definition of "good programmer."

Heh, I seem to remember this very topic not so long ago.

 

[Cogman]

Sounds like you had a bad teacher. The only one I had that was at all close to that was in high school, and he just wanted to make sure I didn't introduce my partner to stuff that was too advanced. (Loops! ) But practically every other programming teacher I've had appreciated individual innovation.

I've wondered what happened to the weed-out class. I don't think I ever had one. Then again my graduating class of CS students was the biggest they'd ever had, something like 60, where they'd had 10-20 before. It was like 4 years after the dot-com boom started, and many may have been there just for the money. So I suppose many of my classmates are those developers who suck. :$

Some would disagree.

And many times there's nothing wrong with that. I've heard it said that good programmers are lazy - though perhaps "efficient" is a better word. I want to have the most effect I can on solving a problem, while doing the least work necessary to do it. If pre-written code can be slapped together and make a useful solution, I don't see that as bad. It's not a really interesting problem either, but it's not bad.

I'm not precisely sure what's wrong with that code until you tell me what thing1-3 are. It can't be written as a switch unless they're comparisons with the same variable. An associative array could associate a number with a thing, but that's kind of pointless if they're very different things.

The problem I was trying to show with the code is that the entire statement could have been taken care of with a loop and an array. It isn't just that, code that looks like this

if (statement1 && statement2 && statement3 && statement4 && statement5 && statement6 && statement7 && statement7 ...)

is all too common. I know that in some situations it is unavoidable, but in many, it points to deeper code structuring problems.

pre-written code isn't bad, but I just feel it is necessary to have at least a base understanding of what the pre-written code does before you use it. I don't know the exact black magic that goes on under the hood when I use windows sockets, but I have a basic understanding of how sockets work, and if I didn't, I know how to type into google "winsock" to find out.

I think that brandonb hit the nail on the head. I've even heard the saying "A good programmer is a lazy programmer", and perhaps most people really take it the wrong way. Most bad programmers are lazy, so lazy that they won't read up on programming techniques or have any interest beyond the last homework assignment in programming.

IDK, maybe it is just a personality thing. I've always been fascinated with computers and read up as much as possible (Heck, I've been programming since I was about 12, I'm 24 now). Others just don't have that drive at all.

 

[MrChad]

There are a number of problems.

1. This may have changed in recent years, but many computer science programs focus around algorithms, languages, coding techniques, etc. My computer science program had a single upper level course on Software Engineering. In my professional career, requirements gathering, design, error handling and monitoring/support are just as important if not more important than the core code logic. This is a huge failing of many comp. sci. programs.

2. Peter Principle. Employees promoted to their level of incompetence. Many developers end up moving away from development and into management or other fields. I think the best developers have a broad vision of the how their system will integrate into an organization. Too often these people become managers, architects or other roles that are removed from the actual coding process.

3. Software engineering is still a developing process. Consistently developing quality, maintainable and well-performing code is not an easy process to codify and repeat. There are all sorts of theories and methodologies.

4. Good software development requires thorough and deliberate (read: slow) preparation and planning. This is often at odds with business demands for rapid development cycles.

 

[Markbnj]

The disconnect? I'd say that software consumers, most importantly corporate consumers, and by extension many of the developers they hire, haven't got a farking clue what software development is. If you get me started on this topic we may not stop for awhile.

My feelings and thoughts align with those of Jack Reeves, whom I've mentioned here before. In a nutshell: programming is a design process, not a production process. A design, by definition, contains all the necessary information to reliably produce an end product. The design is not the end product. Our source code is a design that the compiler and build tools translate into an end product. That is the production part of the process, and it is essentially free and inconsequential. So software as a process is 99.99% design, and .01% production.

Corporate software consumers cannot handle this idea, because where production is predictable and reproduceable design is expensive and risky. They can't tolerate risk, so they have created this fantasyland where once they tell you what they want, everything else is supposed to be this predictable process of converting hours of effort into operating code. Which of course simply glosses over 90% of what needs to be done and pretends it doesn't exist. This flawed thinking is what has resulted in the notion amongst management types that software is a commodity that can be outsourced to the lowest bidder. You can outsource production, but outsourcing design is a lot harder. Therefore software must be production so we can keep these geeks in their place, shackled to their workbenches.

Unfortunately a lot of otherwise smart people buy into this stuff and support it because, frankly, they need something to sell to all those corporate PMs and software VPs, and nothing I said above is saleable to those people. So we get one bullshit silver bullet "solution" to the "problem" after another, whether it is agile, waterfall, scrum, pair programming, blah, blah, ad infinitum ad nauseum. The main problem is really the one they have no interest in solving, which is that most of them should not be writing software any more than the average fast food restaurant should be fixing jet turbines.

 

[Cogman]

You will have to define a "good programmer" before anybody can even take a position on why there aren't many. According to Mark's quote, he feels that a good programmer is one who love programming and "excel" (which also needs clarification) at it, and those aren't necessarily attributes which are always mutual.

So Mark could come and clarify the meaning of "excel" and the OP can clarify his definition of "good programmer."

Heh, I seem to remember this very topic not so long ago.

Good programmer, one who programs well.

I don't know how to define a good programmer, But I definitely know how to pick out a bad one.

Here are a few standards I have.

1. They should be able to READ code.
Most of my classmates can't read code. They can't even read the code that THEY wrote. One too many times they have asked me for help, I've been able to read their code and in 2 seconds figure out what is going wrong. (commentless and all).

Heck, I've even sat down, wrote out an entire program in like 30 minutes in a "team" effort. I tried with the guy I was working with to get him to comment on what is going on, get him to give suggestions, ect. But to no avail. I explained step by step everything that I was writing. He saw me write, heard what I was thinking, ect, and he STILL didn't know what the heck was going on.

I may not be perfect, but I tried my best to keep him involved and to keep asking him questions. Even after he had a copy of the code for several days he had no clue. which leads me to my #2

2. A good programmer should be motivated.
This guy had no ambition what so ever. While I read up on documentation, he sat with his thumb up his rear. Heck, in a different project with him and another guy, they told me "Your really good at the programming stuff, so we'll handle the hardware stuff if you will handle the software stuff." That was fine by me. Sadly, even after discussing with them how we where going to set things up, even after telling them how I was interfacing with the hardware, even after SHOWING them how to wire up the hardware. They still screwed it up. I ended up having to do both the hardware and the software. I don't know how I could have been more clear, I gave them exact pin numbers of which wire goes where, and they still wired it up backwards. They didn't even check to see if they had wired it up backwards, they just assumed that they where done and that I would take care of everything else.

A good programmer should at least be motivated enough to, I don't know, Check and see if his work ACTUALLY works. (I know, this example is more of a hardware issue, but it is still there).

3. A good programmer is able to figure out how to do things/comes up with new ideas.
This is kind of the point I was trying to get across earlier with my factory example. Many programmers just aren't creative at all. If a problem doesn't exactly fit into their cookie cutter collection of problem solving skills. They freak out and can't handle it.

Heck, early on, that was the biggest complaint of most of the younger guys have for a teacher that I really respect. He wouldn't show them exactly how to program, so they were freaking out. Rather, he discussed the concepts they needed to get the job done, described the job to be done, and let them figure out how to do it themselves.

4. A good programmer can debug code on there own.
I'm not knocking team support here. Often people can see problems in your code faster then you can. But come on. You should at least be able to arrive at a solution to a problem in your code in under 4 hours (ok, I realize that isn't reasonable for all situations, for the simple coding problems that we have been given, it is).

5. A good programmer can write good code fast.
Programming fast isn't a virtue in itself, but writing good clean code, fast, is. Generally it takes me half the time, if not less, to accomplish the exact same problem as all my class mates. After the problem is done, I start adding features ect. One of our assignments is to add a controller onto bzFlag. It took me a total of 1 hour to write the code, wire up the controller, test it, and get it working. Others reported that it took them over 12 hours. And that is without features such as an analog joystick. (I've spent the rest of my time adding cheats to bzFlag... )

This isn't meant to be a comprehensive list. but it is some of the quality that I think of when I think of a good programmer. I know some overlap, that is probably more due to my frustration with team projects that I've recently experienced. I'm basically the guy that has to do all the work because my "team" was composed of a couple of brain dead monkeys.

 

[Modelworks]

Part of the problem with upcoming programmers is the overall trend towards very short attention spans. They don't want to learn why something works, just that it does and how they can get to the goal line the fastest. Programmers once got excited by just printing something to the screen, now programmers are bored by that, they want to type some lines of code and turn out the next killer application. I have never seen such a generation of programmers that relies on existing libraries and macros to write a program. It is like you are speaking Greek if you tell some c++ programmers to create a new library to do what they need. I told one guy he could do a part of his program faster if he put some ASM code in place of what he had written in C++, the response was 'you can do that ?' Programming has gotten easier but along with that has come tools that enable people to turn out code without actually understanding it.

 

[KIAman]

Honestly, it sounds like you are differentiating between dumb people and smart people. I had a similar discussion with my co-workers and we all eventually came to the conclusion that the "good" programmers can be "good" at anything they feel like getting into because the attributes of what makes them "good" at programming applies to pretty much anything out there barring physical requirements (sports, etc.)

This is also why sometimes Peter Principle work well because those same "good" programmers have the quality attributes and mentality to be a "good" manager as well, now as to whether they enjoy their new responsibilities or not is up in the air, thus affecting their ability to manage.

I started professionally programming about 10 years ago but after the 5th year, I went into a marketing focused development position, which ended up being a highly-paid marketing analyst with minimal programming. During that time, I excelled at all things marketing, I dove into the materials, studied every facet of the beat and ended up being one of the best marketing analyst until I got suckered (paid) back to development again. In the meantime, the tools, analysis, processes I brought to marketing has paid off 10 fold and allowed them to layoff a third of their staff because of all the automation tools I built while there. Although, I'll be honest and consider myself an average programmer, I am an all-in-one solution where there is no need for specialized programmer but I do consider myself a "smart" person with enough creativity to occasionally "think outside the box."

 

[Cogman]

Honestly, it sounds like you are differentiating between dumb people and smart people. I had a similar discussion with my co-workers and we all eventually came to the conclusion that the "good" programmers can be "good" at anything they feel like getting into because the attributes of what makes them "good" at programming applies to pretty much anything out there barring physical requirements (sports, etc.)

This is also why sometimes Peter Principle work well because those same "good" programmers have the quality attributes and mentality to be a "good" manager as well, now as to whether they enjoy their new responsibilities or not is up in the air, thus affecting their ability to manage.

I started professionally programming about 10 years ago but after the 5th year, I went into a marketing focused development position, which ended up being a highly-paid marketing analyst with minimal programming. During that time, I excelled at all things marketing, I dove into the materials, studied every facet of the beat and ended up being one of the best marketing analyst until I got suckered (paid) back to development again. In the meantime, the tools, analysis, processes I brought to marketing has paid off 10 fold and allowed them to layoff a third of their staff because of all the automation tools I built while there. Although, I'll be honest and consider myself an average programmer, I am an all-in-one solution where there is no need for specialized programmer but I do consider myself a "smart" person with enough creativity to occasionally "think outside the box."

Sadly there are a lot of dumb people that are upcoming class. Even as I'm typing this, one of the students in my class is saying "Uhhhh.... I don't know how the variable changed, I think the compiler changed it." Seriously, he is complaining that the COMPILER is changing his code.. unbelievable.

 

[dighn]

Part of the problem with upcoming programmers is the overall trend towards very short attention spans. They don't want to learn why something works, just that it does and how they can get to the goal line the fastest. Programmers once got excited by just printing something to the screen, now programmers are bored by that, they want to type some lines of code and turn out the next killer application. I have never seen such a generation of programmers that relies on existing libraries and macros to write a program. It is like you are speaking Greek if you tell some c++ programmers to create a new library to do what they need. I told one guy he could do a part of his program faster if he put some ASM code in place of what he had written in C++, the response was 'you can do that ?' Programming has gotten easier but along with that has come tools that enable people to turn out code without actually understanding it.

Personally I don't see a problem with doing more with less. A human being is limited, even if all you wanted to do were programming, there isn't the time to get down to all the nitty-gritty details if you want to get things done, not with the current level of sophistication of software and the expectations in terms of scheduling, features, aesthetics etc. It all comes down to trade offs, putting in the effort where it really counts and saving time when possible. Though I'll agree that it probably sets the bar even lower for what qualifies as a "programmer".

Anyway as for the original topic, I think it's just that programming is something a lot of people can do, but not all of them can do it well. People compare it to art and I think that's true. There are so many ways to accomplish the same thing and to the end-user, they see none of that unless things break, and even that isn't always so apparent if it's once in a while. So you have a lot of "good enough" programmers who in the eyes of skilled programmers actually aren't "good enough".

 

[Apathetic]

One thing I've noticed over the years is that a good programmer will ask LOTS of questions about what needs to happen when things go wrong where as a crappy programmer won't even consider the possibility that things can and will go wrong.

Dave

 

[degibson]

This entire thread makes me very glad I've worked either alone or with strictly competent people for the past three years.

 

[sourceninja]

Part of the problem with upcoming programmers is the overall trend towards very short attention spans. They don't want to learn why something works, just that it does and how they can get to the goal line the fastest. Programmers once got excited by just printing something to the screen, now programmers are bored by that, they want to type some lines of code and turn out the next killer application. I have never seen such a generation of programmers that relies on existing libraries and macros to write a program. It is like you are speaking Greek if you tell some c++ programmers to create a new library to do what they need. I told one guy he could do a part of his program faster if he put some ASM code in place of what he had written in C++, the response was 'you can do that ?' Programming has gotten easier but along with that has come tools that enable people to turn out code without actually understanding it.

I understand what you are saying, but sometimes you also have to know when to not recreate the wheel.

Example: I'm writing a twitter application. I can't find one that I like for OSX. The air one's use too much in the resource department, and the native ones are all half of what I want and half annoying.

So I did some research. I found that oAuth is the new twitter approved way to do authentication. I also found that there are no pre-existing libraries for twitter written in objective-c that do oAuth (well there are a few that feel hacked together). I also felt that the existing twitter 'engines' were more complicated then I wanted mine to be.

So my solution became two fold:
1) Write my own library to access twitter
2) Use the existing oAuthConsumer framework for objective-C

I could find no good reason to not use oAuthConsumer. It seems well written, it works, and it will save me a shit load of time.

I see a lot of the opposite being done with my interns, they don't do any research into what is already out there. I have had a few students create very complex objects to solve problems that are already solved perfectly with a google for the appropriate jquery plugin.

That's great for learning, but not so good when we are short for time and on a schedule.

 

[PhatoseAlpha]

Hm. Interesting. So many developers suck, but never the ones who are speaking. Curious.

I suspect the reality is that most devs simply have their own very specific mindset on what a dev is supposed to be, and anyone who takes a different approach is considered sucky in spite of any and all actual concerns of quality.

Given the zeal with which proponents of open source attach themselves to their methods, it certainly seems within reason to at least suggest the real problem is developer elitism towards methods other then their own.

 

[Cogman]

Hm. Interesting. So many developers suck, but never the ones who are speaking. Curious.

I suspect the reality is that most devs simply have their own very specific mindset on what a dev is supposed to be, and anyone who takes a different approach is considered sucky in spite of any and all actual concerns of quality.

Given the zeal with which proponents of open source attach themselves to their methods, it certainly seems within reason to at least suggest the real problem is developer elitism towards methods other then their own.

No, there really are crappy developers out there, and a lot of them. Its not a matter of "We think differently so everyone is a winner!" People just plain suck at writing code.

The examples I gave above should be proof enough, these guys, even after having every single line of code explained to them, still had no clue how or what was going on, let alone how to write code with similar functionality themselves.

I don't claim to be some sort of super coder, but I do claim to be mostly competent.

 

[Rangoric]

Hm. Interesting. So many developers suck, but never the ones who are speaking. Curious.

I suspect the reality is that most devs simply have their own very specific mindset on what a dev is supposed to be, and anyone who takes a different approach is considered sucky in spite of any and all actual concerns of quality.

Given the zeal with which proponents of open source attach themselves to their methods, it certainly seems within reason to at least suggest the real problem is developer elitism towards methods other then their own.

http://www.thedailywtf.com

They Exist.

 

[PhatoseAlpha]

Oh, I'm sure that some bad developers exist. Some bad anything exists.
But in the percentages being suggested?

 

[Cogman]

Oh, I'm sure that some bad developers exist. Some bad anything exists.
But in the percentages being suggested?

Do you or have you worked in the software development industry? There is a reason it is so dang hard to land your first job in software development, there are a lot of crap fish in the sea.

Think of how many artists there are out there, now think of how many good artists there are out there. I would say the ratio of good/bad developers is probably about in the same category as the ratio of good/bad artists.

 

[JACKDRUID]

The problem I was trying to show with the code is that the entire statement could have been taken care of with a loop and an array. It isn't just that, code that looks like this

if (statement1 && statement2 && statement3 && statement4 && statement5 && statement6 && statement7 && statement7 ...)

.

I thought the problem with the previous code was that it doesn't have a general condition aka "else" statement, so a condition99 would generally skip the whole statement.

 

[SunnyD]

I personally consider software development more like art. I tell people, day in and day out that in software development there's no one right way to do anything. I love what I do, but I don't take it home with me. I would, except my home life is completely non-conducive to trying to get anything done at this point. I don't accept it, but there's nothing I can do.

The main problem in the entire business world though, to address that point, isn't with programmers. It's with the bottom line. This holds true for every industry out there, not just software. In the end, Wall Street or some private equity firm is pushing for a profit margin, and programmers are part of that cost/revenue stream. As such, the programmers are held accountable, and have to take the fastest routes possible to achieve those goals. We don't have the luxury to be creative much of the time, and that's where the reliance on pre-built tools and "in-the-mold" programming comes in. It's also the same thing that spawns all of these development methodologies - all in the name of efficiency, expedience and cost management. Simply put, being creative and innovative is inherently expensive and risky in the business world, and as such the business world seeks to quash such behavior in favor of rapid development. Rapid development leads to obvious code. Obvious code diminishes the need for "a better way".

People are fixated on the dollar, whether it's your paycheck, or your company's revenue, or the stockholder's profit. This one thing transcends nearly every facet of employed life, which in turn directly impacts the way things are done.

Don't blame the bad programmers. Don't blame the teachers. Blame Wall Street.

 

[heymrdj]

http://www.thedailywtf.com

They Exist.

Like the site author. IT != CS