Introduction
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 part 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 fever.
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 code fever.
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...
Donny Dec
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...
Sam Slick
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 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 structures.
User Groups
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 newbies.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 a mercenary.
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 job?"
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 other professions.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.
Disclaimer
DISCLAIMER |
| The
information in this document is information is presented "as
is",
without warranty of any kind, either expressed or implied, including,
but
not limited to, the implied warranties of merchantability and fitness
for
a particular purpose. The entire risk as to the quality and performance
of the information is with you. Should this information prove
defective,
you assume the cost of all necessary servicing, repair, legal costs,
negotiations with insurance companies or others, correction or
medical
care.
In no
event unless required
by applicable law or agreed to in writing
will the copyright holder, authors, or any other party who may modify
and/or
redistribute the information, be liable to you for damages, including
any
general, special, incidental or consequential damages or personal
injury
arising out of the use or inability to use the information, even if
such
holder or other party has been advised of the possibility of such
damages. If this
is not acceptable to
you, you may not read this information. |
[ Troubleshooters.Com | Email Steve Litt ]
Copyright
(C)2007 by Steve Litt. -- Legal