

Ask HN: What's a bad programmer? - dothething

About 4-5 times a month the number one topic on HN is a post about how to hire the perfect programmer. For reasons outside the scope of this discussion I find them annoying.<p>I&#x27;d really like to hear experiences with bad programmers - from people who have actually worked with them instead of just interviewed them. Was it personality - passion - tech debt creation - they destroyed your billion dollar empire? Thanks!
======
MalcolmDiggs
I have an anecdote that might be useful:

A few years ago I was coding at a small startup. Everybody was pretty solid.
Then they brought on a new engineer who was very comfortable with a certain
framework...but ONLY that framework. One day, in a product planning meeting,
we were discussing a new feature we wanted to build. It fell in the new
person's domain, so we asked them to give a rough estimate of how much time it
would take. Their response?

"It can't be done in this framework. There's no existing module or extension
for that".

We all sat back in silence. Eventually someone said what we were all thinking:
"We hired you to write code, not install plugins and extensions. Do you
actually know how to write any code?"

The new hire left the company soon after. To me, the glaring problem here
wasn't that they had aligned their process with a certain framework... it was
that they had then closed their mind to other options. They only thought
_within_ the framework, and so had nothing creative to actually contribute to
the team.

------
MichaelCrawford
Verde Technologies was an aerial photograph firm that used the Streamed Image
Transformation Editor (SITE) to process digital framegrabs on Sun 3/160
workstations. Each cost about $40,000.00.

We required about 90 seconds for each step of our calibration process. There
were several steps per image, we shot many images each day and promised our
clients 24-hour turnaround.

So Scott Lydiard, the company president spent $5,000.00 on a Floating Point
Accellerator card, as Sun promised that it doubled the speed of numeric code.
It was a full-size VME bus card with a 68881 in the middle. I'm not real clear
why it needed that much circuitry as Macs just had a single socket where you
could pop in a 68881, much like the 8087 socket on DOS PCs.

So one night I install our new card. To my dismay the calibration time was
reducing only to 85 seconds.

Not wanting to lose my job I discovered just that night what a profiler was.
It turned out that SITE used getc() to read each pixel of an image, and putc()
to write it. This because the "streamed" part was meant for building UNIX
pipelines. You know simple tools that only do one thing.

I patched the code to read all the pixels in one read() system call.

"Hey Mike. Our new FPA is AWESOME! Only five seconds to calibrate an image."

"You made a wise purchase, Scott."

Then a few minutes later...

"Mike, could you explain why calibration now takes ten seconds on the
workstation that doesn't have an FPA?"

"That's because it really does double the speed of numerical code."

SITE was written by a computer science graduate student. It is for this and
many similar reasons that I don't regard a CS degree as being of much use to
computer programmers. Mine is in Physics; among other things, Physicists
figure out the way things work.

~~~
kazinator
getc should in fact be reading all pixels in a single read() under the hood,
and just pulling characters from a buffer. ISO C stdio streams are fully
buffered, when not connected to interactive devices. Moreover, getc is often a
macro which inlines the code of pulling a character out of the stream's buffer
and updating a pointer, triggering the refill as needed. In my experience,
using getc is usually not too terrible compared to writing buffering code to
do the same thing. (I certainly wouldn't say someone was a bad programmer or
academic for writing the code around getc. On the other hand, if they assigned
the return value of getc to a char typed variable, I'd have a different
opinion! :)

------
smartician
I don't mind slow programmers, or programmers who know when a problem is too
difficult for them, or programmers who ask too many questions and need
constant confirmation and hand-holding. They are a bit annoying, granted, but
harmless, and can be a somewhat valuable addition to your team if you give
them the right tasks. Often these guys can do grunt work at reasonable
quality.

The worst ones are those that know just enough to be dangerous, and who
_think_ they know everything. Instead of asking, they make assumptions, and
produce code that _almost_ works. Meaning, it will pass most of the obvious
test cases, but breaks as soon as it hits production.

Example: One guy had to add a meta tag to a web page, with the page's publish
date in ISO format. Instead of using the source data, which had the date as a
DateTime object, he parsed the date from the formatted page output. This
worked for US pages, and European pages where the day of the month was <= 12
(because of the different order of day and month), but broke as soon as the
displayed string was impossible to parse. Ugh. Any half-decent programmer
would wonder, "there must a better way to do this?"

------
baccheion
\- Gets in the way

\- Doesn't admit to being wrong

\- Full of it

\- Blindly follows/enforces patterns, standards, and best practices

\- Constantly tries to draw attention to themselves

\- Political

\- Code is sloppy, poorly thought out, bug-ridden, and often doesn't work

\- Obsessed with time, documentation, meetings, best practices, patterns,
testing, and everything else that doesn't matter (not with finishing in a
timely manner, writing documentation if necessary, etc, but with constantly
using these things as an excuse to get in the way, to excuse their sloppy
work, and as a means to insult the ability of other developers and to claim
themselves to therefore be the ones that know what they are doing).

~~~
flippant
Sounds more like a bad employee.

------
codegeek
Note: I will say everything below with the context that you are talking about
programmer working for businesses.

Good and Bad are very relative words. To apply these to a programmer, let us
analyze.

I would say start with this question: What is the Goal of a programmer ? Is it
to write great code OR is it to help a business succeed by creating things of
value OR both OR something else ?

If the goal is to just write great code, then do they need to write great code
along with others ? Or are they ok to write great code just by themselves ? If
the answer is that they need to be able to write great code with others in
collaboration, then you have your first point covered which is "personality"
or I would say "Attitude". If you cannot work well with others, you are bad
programmer.

Now, if the goal is to create value and help a business succeed, then does it
matter if the code you write is technically the greatest ? Perhaps not; other
than the fact it personally is very fulfilling. Gotta love that feeling when
that thing compiles!! But the real question to ask is: can I get the patch the
system quickly if the code fails or the system crashes ? If yes, then you are
a good programmer.

If the business team comes to you for advice on doing something technically
that could help them increase revenue but may not be the best technical
solution at this time, you are a good programmer if you can make that happen.
You are a bad programmer if you tell them you don't want to do it.

That takes to the other point about "passion". I would say that Passion may be
an overused word but it should be more about "Do I like doing what I do even
though I am not crazily obsessed with it" ? If yes, then you are a good
programmer. Why ? Because if you enjoy what you do, you will do it better
(most likely)

The last point "Tech Debt". It is again relative. Tech debt for what ? If my
company is not making any money and I need to put food on the table, does tech
debt matter ? Or does it matter that I need to get paying clients first and
worry about the tech issues later. That is a good programmer who can manage
this tech debt depending on the situation of the company. Oh but they don't
have any documentation in the code, I hate it. Ok then fix it keeping the
business goals in mind. If you have the time to do it and still create
positive outcome for the business, then that is a good programmer.

Everyone else is a bad programmer.

------
bjourne
Someone who writes bad code. I don't like the expression "bad programmer" I
prefer to say someone who is programming badly. Because that makes it clear
that it is the action that is bad and the badness isn't inherent in the
character.

If your next question is "How do you know if someone writes bad code?" then it
is fairly simple for an experienced programmer to see if a piece of code is
bad, good or somewhere in between.

------
greenyoda
For lots of amusing true stories of bad programers and the havoc they cause,
see [http://thedailywtf.com](http://thedailywtf.com)

"Founded in 2004 by Alex Papadimoulis, The Daily WTF is your how-not-to guide
for developing software. We recount tales of disastrous development, from
project management gone spectacularly bad to inexplicable coding choices."

------
austinjp
Anyone who thinks or acts like they're the most important asset to the
organisation.

Applies generally in all walks of life, in most situations. I've seen it in
programming, and I've seen the mess that's left when people ignore that
problem for too long.

------
andersthue
The only bad programmers I know are those who over promise and under delivers.

If a programmer week after week on project after project says he will do x, y
and z and next week he did G then it ruins the team because nobody knows what
to believe and what to count on.

------
paulhauggis
We once had a developer that kept clobbering changes of our main git branch.
We had meeting after meeting where our manager taught us the correct way to do
things, yet it kept happening..for almost 3 months.

I blame management as much as the developer for not getting things figured out
asap, but I did get paid for those 3 months for essentially fixing the same
bugs over and over.

