The Old Joel on Software Forum: Part 3 (of 5) - Signs Your Company Has Hired A Bad Programmer

Signs Your Company Has Hired A Bad Programmer

1. Uses AOL for his home email/internet access
2. Doesn't know the difference between an IP address and a MAC address
2a. When you mention a MAC address, he thinks you're talking about Apple computers
3. Was previously unaware that you could have more than one monitor connected to a computer
3a. Asks if multimonitor setups can be used on all video cards by using some sort of y-cable
4. Tries to impress you by mentioning how much time he's supposedly spending at home each night, learning to use a certain programming language. Problem is, he was hired because he supposedly knew this stuff already. But now he's "busting his tail" to learn it. From scratch. And he wonders why you're not impressed. To be fair, this is a fault of my company's hiring practices (which I'm not involved with) as much as it is his fault.
5. Wears a Java shirt even though he can't code in Java (this is not the language I'm referring to in #4)
6. Has breath that smells like a plate of wet tuna fish that's been left in the sun for a while and possibly urinated on. I'm sorry, I know programmers sometimes have little hygiene problems, but if venturing within ten feet of you is a problem, that's taking things too far.
7. Keeps talking to you even though you have donned headphones for the express purpose of ignoring him. No, I DON'T feel like walking you through the "Hello, World" example chapter, you cluess pile of dung.
8. You're building an n-tiered application, and you explicitly and repeatedly inform him that he'll be working on the presentation tier ONLY. He spectacularly fails to understand this, and pesters you with suggested database designs (that suck). Trust me, he's not knowingly overstepping his bounds here. He's absolutely failing to *comprehend* his bounds because he does not understand the concept of separation between the presentation, business logic, and data layers.

...more as I think of them... feel free to add your own.

And remember, *I* was not involved in the hiring of this guy- we have a stunningly inept CTO/co-owner who THINKS he knows technology who insists on evaluating and hiring people himself, with frequently-disasterous results. Like this one.

Poor guy who has to work with this loser
Wednesday, January 28, 2004

LMAO

Michael H. Pryor
Wednesday, January 28, 2004

If you will be judged by the success of this project, not just on your contributions, then you are in an unfortunate position. You should immediately:

1) Give this bad programmer some busywork to destract him somewhere completely unrelated to the success of the project so that his bugs won't ruin your good work.

Tell him to photoshop up some icons. This will take him alot of time.

2) Suck it up and resign yourself to the fact that you're going to be doing his work for him. Just make sure he doesn't get the credit.

If you are confident in the security of your position or your ability to find another job, you will probably want to try and get management to realize their mistake and fire him ASAP or he will continue to drag you down.

Richard P
Wednesday, January 28, 2004

the real shame is that there are plenty of talented, out-of-work developers without jobs. meanwhile, THIS mongoloid gets a paycheck every week.

he's playing a pretty crucial role in a crucial project, too. so we have to pick up his slack. should this project fail, it's not a stretch to say that all of us here will be among the ranks of the unemployed.

Poor guy who has to work with this loser
Wednesday, January 28, 2004

9. They make lists of how all the other programmers suck.

Wednesday, January 28, 2004

richard p, i agree with you totally. we've already given him busy work (documentation, etc) and resigned ourselves to the fact that we're gonna be doing his work and trying to keep him out of our hair.

the management situation is a bit weird. basically, the guy in charge of the project realizes this dude is clueless and that hiring him was a mistake. however, for typical and predictable political reasons, it's impractical to get the clueless dude let go because that would amount to the "CTO" admitting that he screwed up. so we're stuck for now.

(the situation is out of my level of responsibility; i'm not a project lead or manager or anything. if it were up to me, i'd give a big middle finger to "office politics" and fire his ass. this is probably why i'm NOT a project lead, haha)

Poor guy who has to work with this loser
Wednesday, January 28, 2004

I inherited a project from two software developers that left the company in quick succession of each other. They resigned before I joined the company a few months ago.

They had the project for over a year and I've inherited the code they wrote. Basically it consists of little more than a Visual Basic user interface and shards of code underneath at most 20% finished that are either commented out or taken out of the execution path. Basically they did little more than a badly laid out user interface with practically no working code underneath. Before the last software developer left he said the application is at alpha release stage.

Ha. It is somewhat a vast overstatement that a user interface completely incapable of doing 1 sensible thing other than being displayed is an alpha release.

And to think these two software developers pissed around for a whole year on good salaries while I was unemployed and trying to find work.

Last year I implemented working code for a big missing area of functionality underneath their user interface. Now I've chucked everything they spewed up without thought away and am beginning again. I'm making reasonable progress.

Savage
Wednesday, January 28, 2004

9. They make lists of how all the other programmers suck.
------

lol. good point, and possibly truer than you know. i'm actually making this list at a time when i'm supposed to be finishing up some *real* work. okay, break time is over for me... back to work. :-)

Poor guy who has to work with this loser
Wednesday, January 28, 2004

1. Uses a l337 e-mail address and laughs at my AOL address.
2. Lectures me endlessly about the difference between a MAC address and an IP address.
2a. Laughs at me when I suggest a MAC address might be something my iPod should use.
3. Connects more than 1 monitor to his computer.
3a. Using highly specialized hardware.
4. Isn't impressed by my efforts to better myself.
5. Hates Java.
6. Has good personal hygiene habits.
7. Doesn't want to talk to me.
8. Thinks he's a better programmer than I am and doesn't listen to my suggestions to improve the database design.
9. Writes about me on JoS.

Full name:
Wednesday, January 28, 2004

oh no! i've been discovered! haha

Poor guy who has to work with this loser
Wednesday, January 28, 2004

LMOA Hahahah

vince
Wednesday, January 28, 2004

Speaking as someone who uses AOL as a home email address, I agree with #9.

Andrew Burton
Wednesday, January 28, 2004

"we have a stunningly inept CTO/co-owner who THINKS he knows technology who insists on evaluating and hiring people himself, with frequently-disasterous results."

And he also hired you? (sorry, couldn't resist).

Your Friend
Wednesday, January 28, 2004

Simple. Start a sexual harrassment suit.

Josh
Wednesday, January 28, 2004

A real story:
Working at Qantas (airline) as a contractor.

They hired a permanent "senior" Analyst Programmer. Qantas is heavy into transaction processing, and our area mostly dealed with relational databases (SQL Server and oracle). So it would stand to reason that this guy (with many many years experience) would be comfortable with RDBMS.

He: "A table, thats like a file, right?"
Me: "ahhh... yeah....." <steps backwards towards the exit sheepishly>

My real story. Please don't tell anyone.

Me
Wednesday, January 28, 2004

1) The programmer offers to do work for you without being paid
2) The programmer takes up another job elsewhere and forgets to resign
3) The programmer is more interested in chatting on MSN then doing real work
4) The programmer forgets to shut and locks doors
4b) The only door the programmer remembers to shut and lock is their car door, with the keys inside
5) The programmer forgets to turn off the cold tap in the bathroom
6) The programmer writes more sms's on their mobile phone in a day then writing code

All true... most of them repeated numerous times. Needless to say they don't last very long with us and blow their chances on getting a nice reference for their next job application.

PDF
Wednesday, January 28, 2004

Me, the Qantas story doesn't surprise me. Qantas is the company with the female CIO who looked over the staff list and said there were too many people over 40 or something similar.

I like beaches
Wednesday, January 28, 2004

I always feel vaguely like a cult member when I link to Joel's articles on Joel's discussion board, but... I feel compelled to remind you of #4 (Neutralize the Bozos) on the following article:

http://www.joelonsoftware.com/articles/fog0000000332.html

And I'll add that if the guy's *only* problem is the kind of cluelessness born of lack of exposure, it's remotely possible that if you spend enough time doing "neutralization" stuff to keep him going, he may eventually learn something and become a productive citizen. If, that is, he doesn't get himself fired first, and/or suffer from the congenital form of cluelessness. (=

Sam Livingston-Gray
Wednesday, January 28, 2004

"Qantas is the company with the female CIO"

Yes, fiona is her name. Your expectations are correct.

Me
Wednesday, January 28, 2004

Poor Guy,

Is the 'loser' programmer one of the CTO's buddies or distanct relatives? If nepotism is suspected, then you probably can't do much to get him fired (unless he screws up royally). If things don't shape up, you're better off trying to transfer to another dept or start looking for another gig.

Smitty
Thursday, January 29, 2004

Of course, there are plenty of good programmers, including myself, who aren't familiar with MAC addresses and haven't dealt with multiple-monitor setups. Different programming jobs require the use of different technologies.

Here are my signs of a bad programmer:
1) Requires everything to be explained multiple times.
2) Needs all tasks to be separated into tiny bite-size pieces [and the separation takes longer than writing the code myself].
3) Consistently writes code with obvious bugs noticable after a cursory review.

Julian
Thursday, January 29, 2004

The real lesson in this thread is the insight it provides into programmer culture and the continual readiness to challenge people who should be colleagues.

You just don't get discussions like this among lawyers or medicos. You get bitch sessions, but they're quite different.

Thursday, January 29, 2004

> 1) The programmer offers to do work for you without being paid <

I had this happen after my last hiring cycle. It was embarassing for both me and the potential hire. At one point he asked "if it's free, what do you have to lose?" and I had to explain that we needed to furnish him with a computer, and a place to work, and someone to spend time training him, and about a million other little things that make a "free" programmer cost money we didn't want to spend on someone who was placed on the "no hire" list.

I wish people would take "no" for an answer.

Tim Sullivan
Thursday, January 29, 2004

That's because of the heavy mentorship and practical exposure that goes into the education of new doctors and laywers. So after graduation or shortly after, most doctors and laywers are at least minimally capable of doing their job.

I don't think you can say the same for programmers. I think the average software shop (at least in the IT, in-house world) has very few developers who are really capable of developing a reasonable volume of software, sufficiently well designed and implemented so that it doesn't cause major headaches for others on the team.

Rob Meyer
Thursday, January 29, 2004

A. Doesn't write design docs unless you explicitly say so, every single time.

B. Treats every peer review as a personal insult.

C. Thinks a test case is something to do with the law.

D. Knows the law on grievance & disciplinary procedures in suspicious detail.

E. When you explain what they are doing wrong say 'no, its my IDE/environment/source control/you/her perfume'.

F. replicate the source control system on their workstation because its 'broken'.

G. Uses the 'there is this ancient code without documentation, why should I bother' route out of criticism.

H. Uses the 'someone else made the same mistake once, so you can't criticse me' route out of criticism.

I. Uses the 'you made a spelling mistake in your work design doc so I haven't any work for a week' route out of criticism.

J. Gets fed up with the peer review process & management process because it is designed to get at them personally and starts putting guerilla fixes in the build.

K. Look surprised when you finally walk up to their workstation, pull out the power and say, please go with this security guard . . .

You Are Not Alone
Thursday, January 29, 2004

Specialisation is one thing - developing vs. sys admin'ing, designing vs coding, etc, etc.. But don't you guys think that everyone in the IT line should have some grasp of knowledge from outside of their respective specialties?

I'm dismayed when I hear programmers say they have no idea how to do this or that in the OS - simple things that could be learned by a little bit of adventurousness and curiousity.

Or when you ask them about their workstation specs and they give you that blank deer-frozen-by-headlights look...

Coder-at-arms
Thursday, January 29, 2004

I understand what you mean about people not understanding what goes off in some area just outside their own area of expertise.

I pride myself in having a broad understanding of computers (yes, including MAC addresses and things) as well as greater depth in particular areas. I have noticed that the people who don't understand the broad principles are those for whom development/whatever is *just* a job, they leave work, go home, and don't go near another computer until the next morning.

The rest of us came into computers from an early age with an interest in what they do and how they work and that followed through into the work place as we got older. We are fundamentally different from the previous mentioned sort.

However we can become nerds if we're not careful, whereas the former tend to have "real lives" whatever that is :-)

Thats my take on 17 years of working in IT.

whattimeisiteccles
Thursday, January 29, 2004

> K. Look surprised when you finally walk up to their workstation, pull out the power and say, please go with this security guard . . .

Where do you work again?

I like beaches
Thursday, January 29, 2004

Here is one I encountered:

When he gets a runtime error, his first hunch is that there must be a bug in the C++ compilers handeling of "for" loops (major vendor compiler used by millions of programmers worldwide on daily basis).

Just me (Sir to you)
Thursday, January 29, 2004

I think everyone should give everyone a chance.

Philip Albert
Thursday, January 29, 2004

Me: "A table is like a file right?"

Coming from an AS/400 development environment which is designed specifically for transactional processing you would definitely have to make this association because DB2/400 tables are referred to as files. Everything in OS/400 land is stored in a file which is actually a DB2 table. Maybe the guy in question has this kind of background which actually isn't a bad thing at all. Many of these types of developers are very strong at DBMS and transactional software design and would have the same association problem. Then again maybe the guy actually is a moron. Who knows.

Clifton Craig
Thursday, January 29, 2004

Did I hear someone say VSAM?

AC
Thursday, January 29, 2004

I once worked on a project where they (it's always
them) hired that C++ specialist. I gave him a simple
task and when he wasn't finished after two or three
days with it, I wondered if he needed some help.

And indeed, he needed some help. He didn't know that
a C++ programm needs a main().

rm -Rf /
Thursday, January 29, 2004

1. He writes crappy code that doesn't work
2. He is unable to fix the crappy code that doesn't work
3. Someone else has to rewrite his code because it is crappy and doesn't work.

name withheld out of cowardice
Thursday, January 29, 2004

Me: "A table is like a file right?"

I worked a Qantas for a brief time, and like most big glossy companies, all their tech is old.

I don't know specifics (and I don't care) but what Clifton Craig said covers it fairly well. Probably COBOL on IBMs.

The joy of working in a 5-storey building with only 1 window...

AJS
Thursday, January 29, 2004

Is this topic in bold simply because of the title? Cause the content is pretty lame....

Jorel on Software
Thursday, January 29, 2004

Poor guy:

Number 1 is irrelevant. Maybe it's AOL for broadband. Maybe he can't afford something different.

I think you're mixing up "inexperienced" and "bad": 2, 2a, 3, 3a.

Number 4 is not his fault unless he lied to HR or they miscommunicated the requirements. In fact, I think it's great he's taking the effort to learn it.

So what about the Java shirt (#5)? He thinks Java is cool. More power to him. Do you think everyone with a Lakers jersey can play basketball well?

Number 6 is completely irrelevant to how good a programmer he is. If you care that much, send him an anonymous email or leave some mints on his chair.

If you don't feel like helping him through the chapters (#7), then (1) you're selfish and (2) just *tell* him you're too busy, instead of expecting him to take the hint.

As far as number 8 goes, I admire his interest in the different aspects of the project.

Really, now. I can see how the situation might be annoying. But none of us was born knowing this stuff and this kid is displaying an earnest desire to learn and contribute, the hallmark of a future *great* programmer.

Joe
http://www.joegrossberg.com

Joe Grossberg
Thursday, January 29, 2004

"Is this topic in bold simply because of the title?"

No. It is just one of Joel's subtle hints to Michael.

Just me (Sir to you)
Thursday, January 29, 2004

Interesting ideas that made me reflect upon what I know. Granted I am still new at this game < 4 years programming, but I have a fairly broad knowledge base.

Then I starting thinking about it more and relized that what I know about computers isn't really related to my programming. The majority of my hardware/networking knowledge was from gaming and troubleshooting my own PC.

I have met programmers that know computers like the back of their hands and they were terrible programmers. I have met programmers that couldn't tell you where to plug in a ethernet cable and they were amazingly good at programing.

I don't really see the tie, but then again maybe that is just me.

TJ
Thursday, January 29, 2004

The programmer's past time was boxing. You could always tell when it was fight night. Usually easier to tell the day after.

Zekaric
Thursday, January 29, 2004

"Really, now. I can see how the situation might be annoying. But none of us was born knowing this stuff and this kid is displaying an earnest desire to learn and contribute, the hallmark of a future *great* programmer."
----------------------
I think you're right- definitely the hallmarks of a future *great* programmer. However, this "kid" is in his early 40's, and has a lot of high-profile programming and IT work on his resume. He advertised himself as a senior programmer, and applied for a senior programming position.
He's absolutely failed to deliver the sort of technical knowledge I'd expect to see from even an intern.

Part of the problem is that he's a decent guy, but his experience is on the old mainframes and things like that, and his skills just aren't remotely current or applicable. Essentially he BS'd his way through the interview, and the person whose responsibility it is to hire him absolutely failed.

Most of the blame falls on our company for placing him in a situation where he just can't function and contribute. It's not necessarily his fault, although do I think that some share of the blame lies upon him for exaggerating his skills in the area he was hired to work in.

Poor guy who has to work with this loser
Thursday, January 29, 2004

"I pride myself in having a broad understanding of computers (yes, including MAC addresses and things) as well as greater depth in particular areas. I have noticed that the people who don't understand the broad principles are those for whom development/whatever is *just* a job, they leave work, go home, and don't go near another computer until the next morning."

Very, very true. I simply can't comprehend when a programmer doesn't know some basic area of computer literacy. I don't know if a programmer needs to know what a MAC address is, but a lot of them don't even have a basic understanding of networking concepts, which is something that's pretty vital to understand in today's world. When I see a programmer who's never opened up the case on her computer to add some RAM or just play around with it a bit, big warning sirens go off in my head. I don't expect every programmer to understand the latest video card specs or know how to set up a fibre channel RAID-5 array with redundand power supplies (I sure don't) but when I see a programmer who can't plug in a single hard drive, I know it's probably "just a job" for them and not an area of genuine interest- which I think is pretty vital to being a great programmer.

There are exceptions, of course. Lots of brilliant programmers have never touched a personal computer, working instead on high-powered networks in scientific or academic settings. Even in the personal computer world, there are good programmers who couldn't change a stick of RAM, and good programmers who just loooove their AOL.

However, I'm sticking by my initial list of signs. There are exceptions to every one of them, but can anybody who's worked with a lot of programmers deny that they *tend* to be true, more often than not?

Poor guy who has to work with this loser
Thursday, January 29, 2004

Poor guy, the alleged failings on your list are relatively trivial. I think your reaction to the age of the alleged poor performer, evidenced above, is more telling.

I think you probably have a narrow area of expertise and are a bit uncertain about it, but have probably been in an environment where you commanded and demanded unwarranted respect.

You resent this new guy because he doesn't see you as the local genius.

I like beaches
Thursday, January 29, 2004

"Coming from an AS/400 development environment which is designed specifically for transactional processing you would definitely have to make this association because DB2/400 tables are referred to as files."

Well spotted. That was infact the case.

However, he did claim to have a lot of experience with oracle and SQL server at least. In any case, I have worked with a lot of brilliant AS400 guys (just like you said) but I was shocked that he didn't have any curiosity to look outside the AS400 world (like he claimed he did).

Me
Thursday, January 29, 2004

Yeah. You guys are right. I'm wrong. He really *is* a good employee, despite the fact that he can't do any of things he was hired to do. I've been imagining the late nights that the rest of us have been working to make up for his dead weight on the team.

What was I thinking? Thanks for showing me the light.

Poor guy who has to work with this loser
Friday, January 30, 2004

IMHO, bad programmers do not doubt.
They always say "You command, I do" or "I command, you do".

Bad programmers do not have the love for improvement, innovation, new tools.

As a project leader, I hate to hear the programmers say "Bosses, Clients, Managers are always right" or "I do not understand , I just follow you" or "I will do anything if you ask for".

Here are some true stories happened to me:
1. One interviewer asked me to write a demo motion picture program using MFC in half an hour.
But he gives me only a cracked VC6.
NO MSDN!
NO internet access!
I finished in one hour and lose.

2. Some one told me that I would not equal to some "VB experts" because they drag the controls so QUICKLY.

reguard
http://www.d2ksoft.com

redguard
Sunday, February 1, 2004

None of the things you listed qualifies this person as a "bad" programmer. I know many people who have led successfull careers as Software Engineers, who buy houses, put their kids through school, etc. who, based on your criteria listed are "bad" programmers. Yet these folks are successfull in their own domain. It sounds like there is a personality clash here. This guy obviously never has worked in an environment like yours. One way to maybe turn this around is to inquire about the environments/projects that he has worked under. If he can make you understand what he has been used to, maybe you can relate things on his new project in terms that he can relate to. This would help ease his transition as well as your frustration. Of course, if he can't explain the what/why/how of what he's worked on, then you have a problem Houston.

Brian
Tuesday, February 3, 2004

One breathe during sleep with harsh, snorting noises caused by vibration of the soft palate.

Jerry
Wednesday, February 4, 2004

He's been hired for an e-commerce UI developer position and he shows you his home page that has a tiled background, a hit-counter, yellow foreground blinking text, and proudly admits he built it in a day with frontpage.

christian romney
Thursday, February 5, 2004

I've had many similar experiences with lots of totally worthless programmers. They made me a bitter man ;) .. Dont let it happen to you !

- Make you views clear.
- Don't, under any circumstances, accept poor code.
- Take up your issues with management and at development meetings.
- Insist on code reviews before every check in.

Anything less and it will come back and bite you in the ass.

Nicolai Kollner
Thursday, February 5, 2004

Le Ngoc Khoa
Wednesday, February 11, 2004

1. The programmer isn't me.

Bailey Hankins
Tuesday, June 8, 2004