This Troubleshooters.Com subsite is titled "Steve Litt's HR Tips".
Tips. Not bible. Tips. This article is a tip about one aspect of staffing one
employee type. The employee type is the software developer. The one
aspect is motivation. The tip is simply this: Don't hire software
developers who are in it for the money.
I was a full-time software developer from 1984 through 1998, and still develop software
time. I know my own motivations, as well as the motivations of the
scores of developers who worked with me. To me, one pattern asserted
itself over and over again -- the excellent developers did it for the
love of the sport; the mediocre developers did it for the money. As an
Human Resources professional, when a developer applies for a job (actually before he
or she applies for the job), you must have a way to determine whether
that developer's in it for the money, or for the love of the sport.
This article gives some tips.
Source Code Fever
Here's an example of someone in it for the love of the sport. As a matter of fact, the developer is me...
I became a developer after taking a microprocessor class. While the
rest of the class struggled to add a memory location to the
accumulator, I wrote a music playing program, connected the
microprocessor trainer to an amplifier, and got it to play music. That
was the beginning of a two decade (and counting) bout with source code
The job market for developers was bad back in those days, so after 6
months knocking on doors I got in one door by lowballing on price --
$7.00 per hour. This was low even by 1984 standards. So what -- I got
to program computers every day. I wrote medical management software all day
on a DEC PDP11, and then wrote Turbo Pascal all night on a Kaypro 2x
bought for $1400.00. Sleep -- who needs it, I had source code fever.
Within three months the head developer told me, privately, that I was
his best junior developer and took me under his wing. Meanwhile, during every
lunch break I read the first edition of Kernighan and Ritchie's
"The C Programming Language". The second edition of that book was
a much easier read, but the first edition was so terse and dense a
single page could take hours to master. Didn't matter -- I had source
A few months later, the DP manager asked me to create a program to
merge all their accounts so that when checks came in, they could be
checked against one alphabetized list instead of 40 customer lists. It
would save them many clerk-hours of labor and many boxes of paper. She
had absolutely no authority to ask this of me, but she and I had a
great working relationship, so my answer was "I'll see what I can do."
Three days later she had her merge program. I'd worked faster on my
official project while whipping up her project, so my boss never knew
I'd "cheated". Until, that is, my boss was congratulated on Steve
Litt's spectacular merge program, which saved the company many clerk
hours of labor and many boxes of paper. Got another project? Steve Litt
is ready! He has source code fever.
I started getting a lot of the best projects in the shop, and whipped
them out quickly and bug free. Word was out -- if you want something
done, give it to Steve Litt. I liked it that way, because programming
was my hobby. I'd have done it for no money at all. While riding my
bike around Los Angeles, I dreamed of new data structures. While
skateboarding on Venice beach, I figured out new algorithms. Source
code fever was tenacious.
A year after the merge program, my boss came with an offer I
couldn't refuse. He'd give me a $500.00 bonus if, in two weeks, I could
create a DOS based front end to the VAX hosted corporate eligibility
program. I'd have done it for free -- the bonus was just incentive to
do it fast.
My front end would go in forty doctors offices. The front end would
need to read and write the proprietary commands of the VAX via phone based serial
line, display it, put it in a local PC-Focus database, and enable the
user to change the local database's data.
The first two days were spent in analysis, where I determined the structure of the system. It looked something like this:
I didn't know how to code the character to serial port interface, so I
used ready-made Turbo-Async for that purpose. Turbo-Async required a
ring buffer, which in this structure, needed to exist independent of
the front end program, meaning it had to be buried in memory. It had to
be a TSR program, and I didn't know how to do that. So I found an
assembly language programmer to do it in about 30 minutes. I knew how
to code the front end and the matching PC Focus programs, so two weeks
later the boss had his program. It immediately cut eligibility searches
from 1/2 hour to a few seconds, and kept the info up to date.
This front end client, querying the VAX server, was written before the word "Client-Server"
existed. The VAX database query interface wasn't SQL, but instead an
arcane proprietary command interface. This project wasn't rocket
science, but consider that it was analyzed, designed, integrated and
written by a junior programmer with two years experience.
But not just any junior programmer. A junior programmer with source
code fever. A junior programmer working 80 hours a week for the simple
reason that he could think of nothing else. A junior programmer whose
every waking moment was spent thinking about the project. A junior
programmer doing it for the love of the sport.
I could walk you through my development career from 1984 to present,
showing many such miracles, but you're interested in good staffing
decisions, not in Steve Litt. I'm just an example. Let me show you
other examples. Read on...
Once upon a time (1987) I worked part time as a salesman for a nationally
recognized DEC (Digital Equipment Corporation) expert. Let's call him
Donny Dec. He had written software to multitask a VAX running VMS, and I was
selling the daylights out of his program part time when I wasn't
programming. As a developer, I wanted to be part of Donny Dec's world
and absorb his knowledge.
Everyone in the DEC world knew Donny Dec was a genius, but I didn't
know his true ability and motivation until working for him. He worked
out of his apartment. Many of his developers worked in the same
building. These guys created a DECnet network by stringing wires across
the courtyard between their apartments. Donny's living room was a
jungle of salvaged minicomputers.
Having to arrive at 6am to phone customers on the east coast, I got to
observe Donny wake up. Donny had suspended, with wires, a VT100
terminal 3 feet above
his head. Every morning when Donny awoke, he'd open his eyes, yawn,
reach his arms up, and start coding.
Donny lived the life -- he was in it for the love of the sport. Those
who met him at trade shows saw a knowledgeable, well mannered, handsome
man in a suit, never dreaming the extent to which his life, friendships
and surroundings were focused toward writing code.
Donny made a lot
of money with
his multitasking software, yet his lifestyle changed little. He wasn't
in it for the money -- the money was just a nice side effect.
The Ex Secretary
Starting a new contract at a large company, the IT director assigned me
to help a developer write RBase code to operate a printer. The
developer admitted she was new at programming -- she was promoted from
secretary to developer 6 months before.
That developer was at the company for every one of the ten years the
company was my client. Except in extreme emergencies, she worked 8
hours a day. She was satisfied to let others lead projects and dictate
specifications to her. She was in it for a paycheck -- a better
paycheck than she got as a secretary.
Let me say this right up front. This woman was an excellent, dependable
employee. I'd recommend her to anybody for run of the mill programming.
She got her assignments done on time.
But as I remember, she seldom instantiated projects. All around her,
developers in it for the love of the sport dreamed up new ideas, got
managment to buy into new projects, and boosted the profit of the
company. Then those sparkplugs gave her specifications and a few basic
ideas how to do it, and she coded small parts of it. When I left Los
Angeles ten years after helping her with that printer program, coding
gurus had come and gone, technologies had changed three times
over, but she was still turning tight specifications into code.
To her, development was a paycheck. She did excellent work, within the
framework of turning specs into code. She outlasted generations of
gurus. As an Human Resources person, you'd do well to hire her, as long as you had
other developers to view the system at a high level and split it up
optimally. Those gurus would be in it for the love of the sport.
She's actually a reasonable advertisement for hiring someone in it for
the money. Such people don't always turn out so productive...
We had three developers on a sizeable project, and it was obvious we
needed help. Management gave the OK to hire someone else, and the head
programmer began interviewing. Being an outstanding guru, head
programmer and leader, he let the other two developers, one of whom was
me, sit in on the interviews.
One of the interviewees was a guy who I'll call Sam Slick. He came in
with a working copy of the project he was working on for another company, installed it on a
computer, and put it through its paces. We asked him questions about
what parts he actually did, and he did a half decent job of explaining.
He knew the buzzwords and sounded knowledgeable. He was hired.
Sam Slick couldn't program his way out of a paper bag. Every fifteen
minutes he came to me with a question that he should have figured out
himself. He constantly questioned the other two team members also.
Month after month, he never learned. He didn't care. He got his
paycheck either way.
Most insulting, he came in at 9am and left at 5pm. He saw the project
falling hopelessly behind. He saw the corners we had to cut to make
deadline. He saw the bags under the eyes of his three project mates.
That was their problem -- he felt he'd fulfilled his responsibility
just putting in the face time.
The saddest thing is that we three original developers could have
finished the job on our own. We'd have had to work 60 hours a week for
a few months, but we could have done it. Once Sam Slick came on board,
the babysitting we needed to do wrecked our focus.
The project bombed. I don't know the cost of the failure, but imagine
it would have been in the mid to high six figures. The company threw
out their old technology, became an ever more Microsoft shop, and
started outsourcing more and more of its work. The company's core of
excellent developers were eased out. Some of the development savvy that
had helped this company differentiate itself began to evaporate.
From what I hear, Sam Slick was eventually fired, after a drawn out,
by-the-numbers Human Resources
process, to get rid of him legally and without a lawsuit.
Don't Make the Big Mistake
If you want to avoid outcomes like that caused by Sam Slick
avoid "developers" in it just for the money. The mercenary crowd can
spout buzzwords and even display code, but you can quickly find them
out. Just get them to brag.
In the interview process, sit down with the interviewee and a top notch
developer from your organization. Ask the interviewee about previous
projects, and be enthusiastic about the response. Have your developer
ask questions, as if extremely interested and impressed:
- What was your object hierarchy?
- How did you structure the system?
- What did you use for interprocess communication?
- Can you draw me a diagram?
- How did you think of doing that?
The code-loving interviewee will show excitement. Her interviewee
defensiveness will break down. She'll answer those questions
enthusiastically. Your developer will easily gauge the credibility of
The diagramming question is especially important as an end-run around
buzzwords. A fast-talker can spout buzzwords, but it takes a developer
familiar with the problem domain to draw a diagram of part of a system.
Likewise, the "How did you think of doing that?" question is essential.
A real developer lovingly remembers the project, but to the mercenary
the project was just another job.
While performing this exercise, it's important to remember that even
the most non-mercenary developer will forget several implementation
details. After all, she's participated in several projects since then.
However, years after the project, the real developer will still
remember the overall architecture and high level structure and data
Another way to separate the enthusiasts from the mercenaries is to view
their user group activities. Developers in it for the love of the sport
typically participate in a user group for their programming language.
They propose new object and data structures and new algorithms. They
cross polinate ideas from other groups. They give advice and mentor
Many mercenaries aren't in user groups at all, and the ones who are
often act differently. "Does anyone know where I can get a job in
language X?" is their most frequent question, followed by "How can I
program task Y in language X?" After they buzzworded themselves into
the job, programming task Y is a little more work than they want to do,
so they ask for the solution.
I'm not saying that enthusiasts don't ask about jobs and solutions.
They do. But when you see on a person on a mailing list repeatedly
asking about jobs and solutions without assisting others or adding to
the intellectual content of the discussion, this person is most likely
As a matter of fact, if you want to proactively staff the right
developers, attend user group meetings and note the interactions. There
will be a core of members determining the discussion and putting on the
presentations. These are the people you want. There are others who,
after the presentation, break up into discussions about the technology.
These people are good too. Then there are those whose repetoir consists
of "is there a good market for language X", or maybe "where can I get a
Not at your shop.
What About Prima Donnas?
We've all met them -- prima donna developers. They diss network and
database administrators. They treat computer repair people like
idiots. They tell management the software will be ready when they make
it ready. They're morale and productivity vampires, and they're
usually programming for the love of of the sport.
You don't want them.
One might even make an argument that the developer in it for the money
"fits in" better than the prima donna developer in it for the love of
the sport. Indeed, over the last few decades, several "solutions" to
the "prima donna" problem have been proposed.
Remember "egoless programming?" Developers were asked to do their job
without pride of workmanship. It didn't work because without pride
there was no workmanship.
Then there was the "software factory" idea, in which developers worked
like assembly line workers bolting on necessary objects to build a
piece of software. Didn't work -- the holy grail of "code reusability"
has yet to be accomplished beyond a few niches.
The answer to prima-donna-ism isn't to make development just another
job. It isn't just another job -- it's design. Somebody must translate
user and company needs into program design, and that person and/or
others must translate the program design into code. These are design
activities, and design has never been successfully put on an assembly
line nor performed by a disinterested party.
So first screen out the mercenaries, and then screen out those with
team-wrecking personality problems. What you have left is a core of top
notch people to give your organization an IT department to set you
apart from your competitors.
This Document is About Software Developers
As stated in the introduction, this document pertains to software
developers. Software developers who are in it for the money are usually
low producers, nonproducers or worse. This is not necessarily true of
I repaired consumer electronics for several years and was very good at
it. It was a job done for a paycheck. Sure, it was more palatable than
most jobs, but it was still a route to a paycheck. I just did the job.
You can't really expect bookkeepers and accountants to be excited about
their job. They have GAAP and other principles and procedures to govern
their work. They just do the job.
Software development is something special. As of 2007 no set of
procedures or policy, no development methodology, no software
framework, nor any development environment has removed the necessity of
imagination and inspiration from software development. Judging from the
failures, in these areas, during the last 30 years, I doubt imagination
and inspiration will be removed in the next 30 years.
Software development is different.
information in this document is information is presented "as
without warranty of any kind, either expressed or implied, including,
not limited to, the implied warranties of merchantability and fitness
a particular purpose. The entire risk as to the quality and performance
of the information is with you. Should this information prove
you assume the cost of all necessary servicing, repair, legal costs,
negotiations with insurance companies or others, correction or
event unless required
by applicable law or agreed to in writing
will the copyright holder, authors, or any other party who may modify
redistribute the information, be liable to you for damages, including
general, special, incidental or consequential damages or personal
arising out of the use or inability to use the information, even if
holder or other party has been advised of the possibility of such
is not acceptable to
you, you may not read this information.
Top of Page
Steve Litt ]
(C)2007 by Steve Litt. -- Legal