I imagine you've never been the one hiring or interviewing developers, have you?

There is an amazing bit though: there are the ones that you classify as "surely worthless", but then you see they can indeed get some jobs done, so a non-technical manager or HR-person can easily confuse one of those that "can sometimes program computers to do useful stuff or keep things running" vs someone who can do "software engineering".

Oh, and then there's the infuriating third category of those extreeemly smart (IQ through the roof + wealth of knowledge) but extreeeemly unproductive (like even manifesting "negative productivity" and dragging a team down or an entire project into the ground, the "-10x programmer").

People are... complex :)

Lol at the third category - they're at the wrong jobs(for them), perhaps they need to do something on their own, figuring things out themselves!

How did your category-three people drag the project down?

A sub-category I find is the "scientist" programmer vs the "engineer" programmer. With the scientist programmer being these category-three people. An engineer will use existing frameworks, technology, standards, etc. to solve a problem. And a scientist wants to develop new frameworks, technology, standards, etc. to solve a problem.

On larger teams, you want some commonality with your code. You want to be able to look at code written by others and at least have common style, strategy, and idioms. Engineering style devs tend to follow this nicely and it all works fairly well in a team dynamic. Whereas, scientist developers are often looking for new ways to do everything. When they see things done in a common and consistent way, they tend to look for unique solutions and tend to do more of "research" style development.

Don't get me wrong, both styles have their benefits. But on a typical largish development team, the scientist are often a more negatively-impacting developer to the overall productivity of the team.

The really scary thing happens when these scientist type developers become architects. And then you end up with what is often called an "architecture astronaut".

I think there are some infamous examples from the old days of Microsoft. Think of the programmer who insists on using an obscure dialect of Lisp because of all the "clever" things they can do in it. Even if they work, and are genuinely clever, it can be a huge pain for the less brilliant/obsessed people to interact with.

In general, this seems to be a problem that arises when smart, capable people (who are short on common sense and teamwork) become so valuable that they get to call shots no one else can accommodate.

Imagine Mel being on a team of 15 people: http://www.catb.org/jargon/html/story-of-mel.html

Well; what these people have not learned is that the whole purpose of a "programming language" is NOT to tell the computer what to do. It's to tell your team mates what you've told the computer to do.

People who don't get this are really the worst to work with.

John X is assigned to project Y with team A but find it very boring for him. So he overengineers in a way so that it only works by solving a very complicated engineering problem that he wants to solve instead (think "developing your own distributed no-sql db" class overengineering).

John X leaves for a more interesting project, team A can't make modifications to the current over-engineered system so they need do a rewrite of a few key components that incurs a huge delay.

And yes, it was not John X's fault. It was the manager's who assigned it to the wrong team and project, and the team leader's that they didn't have working code review process to be able to give JX feedback early to "write code easier to maintain by a less experienced team even if it's maybe less efficient and takes him a bit longer".

So you're right in insinuating that category-three people don't really drag projects down: it happens when they are assigned to the wrong place and when you have teams with broken processes, so objectively speaking, bad management is actually what's dragging things down in this case. But isn't "bad management" close to a pleonasm anyway?

Often, smart people seek challenges and complexity. This can be dangerous in software engineering, if left unchecked.

Oh if only that were true.

I've worked with people in the past who know just enough to hack together a front end on top of a simple database, but who would completely fall apart when presented with anything more complex than that. These are the sort of people who when asked to build an internationalised website "solve" the problem by copying an entire PHP application into directories called "english" and "german" and then proceed to change the text in the German version.

There's that XKCD about asking how novice users solve computer problems. "I save the video to iCloud, then copy the url into this video downloader, then put the download into this transcription site, then upload that to..."

I think this is a big chunk of explaining how bad programming goes, too. It's not "too incompetent to build a thing", it's "incompetent enough that everything runs on voodoo and evil".

:D

This is an interesting suggestion.

However, it is very easy to cheat your way through college and obtain good grades. My assessed coursework regularly shows up on rentacoder.com and similar. There is an industry out there for writing dissertations. Group work is another mechanism that weak programmers use to avoid getting better: they let the good programmers do all the programming and then do documentation, or UI design, or nothing. In addition, there is a pronounced grade inflation, so even weak students look great on paper.

Not every organisation has the know-how to filter out weak students that look great on paper.

My degree program must have been unusual, then, because my senior project class was the only one where less than 80% of my grade came from in-class tests. Many professors didn't even give a crap whether you actually did the homework or not, because you'd bomb the test anyway if you didn't.

I believe your comment is missing a /s tag.

In my experience, there is enough fluff and non-programming, abstract theory classes in a CS major that people who cannot program their way out of a wet paper bag can complete the degree, and even get high marks. These people can get jobs, and coast along for years at sub-mediocre levels of production, in most cases.

I'm going to be a bit more charitable and say that those people find non-programming jobs in the field.

One person I interviewed stood out in my mind for having completed a Master's in CS, was able to classify the problem I posed her as belonging to a certain type and told me how it should be approached. She still couldn't even begin to write the (simple) code to solve it, however.

This person was obviously smart, and also quite obviously had no programming skill.