

How to Keep Crappy Programmers - AmberShah
http://www.codeanthem.com/blog/2010/04/how-to-keep-crappy-programmers/

======
trevelyan
This was a sticking point for me in my last job as a programmer, where the
owners had actually instituted a punchcard system I routinely ignored. I'm
more sensitive to it now that I'm running my own business and hiring people
though. The problem isn't generally having a single person come in late. It's
that this can affect social perceptions of what general work effort should be.
Especially in a small office it is easy for working hours to creep down and
soon everyone is starting work an hour late and leaving half an hour early.

It is easy to say, "I'm only going to hire self-motivated people and if they
can't get the work done they're fired." But the reality is most people aren't
like that. And it's a hassle to have to fire people if they can be productive
with more management.

So I'm not sure what the best way to handle this is, but I think HN would be
better served by an actual discussion of practical solutions rather than rants
by disaffected programmers howling with rage at being asked to keep regular
hours. On the employee side, I still believe doing really good work solves
pretty much all of your problems if you can effectively communicate what
you're doing to the manager (and put in the required time). On the employer
side, giving people a bit of slack (30 minutes), a fair degree of autonomy and
coming down on them hard if/when they miss their deadlines is the best I've
been able to come up with. I'd welcome a better discussion of this since as a
manager I don't want to have to waste my time micromanaging this stuff either.

~~~
dschobel
One thing I've seen work is to make it clear that, while you have the liberty
of working odd hours if you so please, your work product will be under greater
scrutiny to make sure you can "handle it".

Make it clear that it is a privilege which can be revoked. This lets your
alpha programmers who like to work odd hours excel and keeps your mediocre
programmers who might be tempted to mail it in from even trying it (because
there's nothing mediocre devs loath more than heightened scrutiny).

~~~
arethuza
When I managed a team of people who had "unusual" working hours I made a point
of trying to subtly communicate to people who might get upset what was going
on in the team:

"Thanks to Bob working to 3am this morning we are all set to give the demo to
XYZ"

Do that before Bob comes in at lunchtime an he get treated like a hero rather
than being resented. If Bob is always working funny hours then after a while
people accept it and assume that he has _always_ been doing something heroic
when he comes in at lunchtime.

Of course, being the manager of such folks you actually do have to be able to
know that all this is actually worth it from a business perspective.

------
mattmiller
I disagree with part of #3. I really like being included in some of the
business decisions, or at least being aware of why they were made. I don't
want to spend 8 hours a day in customer meetings, but I do like having quick
meetings with BD people on why I am doing what I am doing. A lot of times it
gives reasons to tasks that seem stupid. (ie we are implementing this bad
feature b/c it will give us some sort of negotiating advantage)

~~~
LiveTheDream
Being aware of business reasons behind decisions is very important. I can
think of two main reasons. 1\. Poor translation of customer intent/business
goals can lead to some terrible software because the real purpose of it is
obfuscated. 2\. Ability to comprehend which urgent deadlines are actually
important and which are exaggerated.

~~~
roundsquare
3\. The ability to come up with an even better solution for a business
problem.

In my experience, a lot of business people don't really know what is possible
so their solutions aren't always that good.

Example: "I need to know if I own more than 3% of a company. Give me a report
that tells me what percent I own of each company. " "How about a big flashing
light or warning if you own more than 3% (or set it at 2% so you know when you
are getting close) so that you don't need to spend time each day looking at
the report."

------
hassenben
You have to go through at least one company like that.

It is often the only way to find out what type of "employee" you want to be.
(environments, coworkers, projects, schedule etc.)

Or, it will motivate you to become self-employed or launch your startup and do
things differently :-)

------
mjw
(Posted on the article too, but might be more use here) Nice set of articles,
but a teensy bit one-sided in places.

What about the programmer who comes across as being a prima-donna about
introducing some flavour-of-the-month practise, but who isn’t able to justify
it in terms of measurable impact on the bottom line to (say) a small business
owner. Often they’ll be right, but frequently they’ll be wrong too. I’ve often
been guilty of this as a programmer–I want to change some code to make the
design more elegant, add more tests etc, but if pressed it’s hard for me to
say whether the improvement adds any value for the business. Sometimes it
will, sometimes it won’t. Sometimes despite its value the opportunity cost may
be too high. Either way as a ‘good programmer’ I will feel strongly about the
matter, and it’s my boss’s job to try and temper that programmer “I only want
to work with good code!” gut feel with a bit of business-oriented
practicality.

So yes, the extent to which you indulge the 'great programmer' is always going
to be a tricky call, especially for the non-technical, or even the technical-
but-non-specialist. On the one hand you don’t want to piss off the talent–and
let’s face it, some (not all!) of this stuff really is just that, in the same
way a hollywood producer lays on whatever perks the best actors demand. On the
other hand you need to have confidence that there’s real business value in
activities that are being proposed. Or if not immediately demonstrable value,
a way to measure reasonably objectively over time what impact they’re having.
For example, Google (from what I hear) have an amazing system to measure (in
some reasonably useful sense) the value of every test that gets written.

On top of that, sad truth is that a lot of companies don’t actually need great
programmers. Sure, all else held equal they’d like them, but they’re
expensive, they often want to spend your money bringing you into line with the
latest and greatest–and sometimes it really is sufficient just to keep some
old ball of code ticking along. I wouldn’t really want to work for one of
these places, and doubtless neither would you, but it’s an acceptable deal for
some programmers and some companies, and there’s a more nuanced perspective
available than just to patronise them.

The other thing with great programmers is that if you don’t give us a
sufficiently interesting problem to work on, we’ll often go and invent our own
(whether consciously or not).

That might be a plus for someone like Google, or sometimes for some kinds of
start-ups, but not so much for some more pedestrian smaller businesses.

Or perhaps behaving like this makes one not a great programmer, depending how
you define it. It's not a one-dimensional quality I suppose.

~~~
strlen
> _The other thing with great programmers is that if you don’t give us a
> sufficiently interesting problem to work on, we’ll often go and invent our
> own (whether consciously or not). > That might be a plus for someone like
> Google, or sometimes for some kinds of start-ups, but not so much for some
> more pedestrian smaller businesses._

If you actually _like_ programming (as oppose to pursuing it for the money),
you should _only_ seek to work at places where you, as a technologist within
your particular field will make a difference.

Problem is that it's tricky to tell such places apart from the rest. Everyone
calls themselves a "technology company". Mission of the company isn't a good
heuristic: there are e-commerce retailers that are run like "IT shops" and
there is Amazon (a true technology company). Nonetheless, from this message I
can tell that _something_ is different here and better here:

[http://groups.google.com/group/mi.jobs/msg/d81b6c1fa8f361fc?...](http://groups.google.com/group/mi.jobs/msg/d81b6c1fa8f361fc?pli=1)

In most other cases it isn't so clear; you have to read between the lines. Job
descriptions only asking for years of experience with specific technologies,
non-technical interview questions or interview questions that only involve
language syntax and APIs but don't touch on algorithms and data-structures,
inflexible working hours, mandated technology stacks (with no exceptions for
new projects or experimental code) are a way for an employer to signal
"hackers not wanted". Fortunately these are very easy to spot and avoid, but
I've been surprised when people (who have other options) choose to work at
companies that require them in their seat at 8:30 and clearly under-use their
talent.

On the other hand, I am afraid excessive commitment to methodology (e.g.,
daily stand-ups, inability to write any code without meetings + permission of
the "scrum master" + index cards, pair programming, mandated test coverage
percentages and "always write tests first") is another such sign, but
unfortunately I am in minority.

~~~
yummyfajitas
Some good signs in a job description:

    
    
        Send us your resume in raw text format. Word resumes will be discarded.
        Experience with an OO language (Java, C++, etc) is required. 
        In your cover letter, tell us about a non-mainstream technology you love.

------
chc
This applies to so much more than just programming. Almost any skilled
production job has the same properties. Quality of output should be any
manager's highest priority, and when it isn't, you've created a lousy work
environment where the only people who will be happy are people who don't care.

(Just to clarify, I'm not saying punctuality is unimportant. Something that
isn't in on time to be useful should not be considered high-quality work. That
that's different from requiring a specific set of ass-in-chair time.)

------
dschobel
I'm surprised he didn't touch on "give your devs decent hardware & tools".

This should be such a no brainer but it's far and away the most common
complaint I hear.

$900 on a workstation every 2 years -> happier, more productive devs.

~~~
rythie
What if they want Macs though?

------
etherael
The most depressing thing about this series is that they seem to be
reflections of standard operating procedure at the median corporation.

~~~
digitallogic
I've only worked for small companies/teams, and I've experienced everyone of
those traits from various managers/team leads. A coralary to "You can write
Fortran in any language" could be "You can manage poorly in any environment."

------
steveklabnik
Ugh, I just watched this happen to one of my friends. Actual quote: "I know we
discussed that you like to come in at 11 and stay late at the interview, but
the adjustment period is over now. I don't care how good your work is, I care
that you're at the office by 8:30."

Luckily he got the hell out of there. I'd fear for his sanity.

~~~
ido
I had a boss (years ago) who would _scream_ (!) at me if I came even 10
minutes after 9am.

I would also occasionally notice him standing behind me looking at my monitor
over my shoulder (he was a 'hands on' kind of manager).

He was really surprised when i quit after a few months.

~~~
dantheman
I'm surprised you lasted that long -- there is no reason for anyone to scream
at anyone unless they do something incredibly dangerous or careless; you only
do this so they understand the severity of their action. For example smoking
next to flammable materials, improperly handling chemicals, etc...

~~~
ido
He had a lot of idiosyncrasies like that.

Another example:

one day he told me I shouldn't leave windows (on the computer, not physical
windows) open when I go home at the evenings because it looks like I left work
in the middle of doing something.

After that I made sure I minimized all the windows before leaving.

------
euroclydon
I guess I'm a crappy programmer since I'm not _always yammering on about
wanting to test something_

~~~
Glide
I think it's mostly the yammer about testing to actual yammering ratio.

You also have to look at how many conversations you can bring up testing in.
If you can do it for at least 90% of your conversations you're doing pretty
good. It's probably not worth it to cover 100% of conversations though.

~~~
j_baker
TDY (test driven yammering) would suggest that you always shoot for 100%
coverage of your yammering.

------
alttab
This sounds like everyone that was still at IBM when I left.

------
jrockway
How to write bad blog posts: Make your readers understand 4 levels of double
negatives.

~~~
WilliamLP
The sarcastic tone of articles like this seems entirely unnecessary and
detracts from their effectiveness to me. It should have been simply something
like "Management mistakes that drive away good programmers".

~~~
erlanger
Some weekend comedians think less is at stake if they make the joke easy.
Going for the joke and accepting that many people will not get it takes some
guts.

------
SandB0x
"Use Lotus Notes"

~~~
synnik
Hey, I've built an entire career on decommissioning Lotus Notes platforms. It
is a lovely niche...

------
johnl
The article might add that having lots of department meetings is also a
excellent way to keep crappy programmers.

------
xiaoma
6) Pay well above the market norm

Crappy programmers are well-known for choosing money over career development,
intellectual challenge and cultural fit.

