Entries from October 2006 ↓

Nine Things Developers Want More Than Money

Many of the developers I know have been programming since they were in junior high. Whether it was building text-based games on an Apple IIe or creating a high school football roster app in Visual Basic, it’s something they did for the challenge, for the love of learning new things and, oh yes, for the ladies. Ladies love a man who can speak BASIC to his Apple.


College graduates face a sad reality when they leave the protective womb of a university and have to get their first real job. Many of my friends found jobs paying around $25k out of school, and were amazed that the starting engineering and computer science salaries were nearly double that. But the majority of the engineers in my class didn’t become engineers for the money; we did it because it touched on a deep inner yearning to tinker and impress their friends. And did I mention the ladies?

Money is a motivating factor for most of us, but assuming comparable pay, what is it that makes some companies attract and retain developers while others churn through them like toilet paper?

Hygiene and Motivation
In the 1950s a researcher named Frederick Herzberg studied 200 engineers and accountants in the US. He asked them a few simple questions and came up with what is one of the most widely-accepted theories on job satisfaction called Two Factor Theory.

His theory breaks job satisfaction into two factors:

  • hygiene factors such as working conditions, quality of supervision, salary, safety, and company policies
  • motivation factors such as achievement, recognition, responsibility, the work itself, personal growth, and advancement

Hygiene factors are necessary to ensure employees don’t become dissatisfied, but they don’t contribute to higher levels of motivation. Motivation factors are what create motivation and job satisfaction by fulfilling a person’s need for meaning and personal growth.

Think of a large financial company like Countrywide or IndyMac. Although I’ve never worked for either, the stories I’ve heard indicate the hygiene factors are well taken care of: working conditions are good, supervision is reasonable, salaries are decent, they have good benefits, etc…

However, the motivation factors are, shall we say, incognito. As Herzberg noticed, this scenario leads to employees viewing the job as little more than a paycheck, which is probably all right for companies like Countrywide and IndyMac.


Take the flip side: a tiny startup in a dingy office with no windows, crappy benefits, little supervision (because the CEO’s on the road making sales), and no company policies (because the CEO’s on the road making sales). But the constant rush of learning, being responsible for the company’s success or failure (almost single-handedly at times), and believing in the company’s future growth makes this job much more desirable for many developers.

One of my early programming jobs was for a web consulting startup during the dot-com boom. There were 7 of us (we grew to 17 during the height of the boom) shooting each other with water pistols, throwing Nerf footballs around the office, and cranking out insane amounts of caffeine-driven code. We learned a new language every project and were always on the cutting edge.

I remember thinking that a company across town could have offered me a $15,000 dollar raise and I wouldn’t have taken it. The motivation factors were overpowering.

On the flip side, the benefits were terrible, the office was a series of tiny cubicles, gray from years of neglect – Smurf-blue network cables hung from the ceiling, and supervision was…well…non-existent. And although hygiene factors were lacking, developers flocked to work for this company and only one left while I was there. She was interested in a more stable work environment and better benefits, and went to work for a large financial institution much like IndyMac.

Rob’s Criteria for Keeping Your Developers Happy
If you want to collect a paycheck for 25 years and retire with a gold watch and a pension then go for companies that have the hygiene factors nailed. Stroll in at 8, head for the door at 4:59, and count the years until you’re kicking up your feet on a beach bar in Costa Rica.

Big Building

But if you’re reading this, odds are that you aren’t the kind of person who never thinks about code after 5:01; you’re more likely to have a collection of DVDs that come up in an Amazon search for “Silicon Valley.” You’re probably one of those people who needs motivation factors or you go crazy with restlessness, and when the motivation factors are in place you’ll work ridiculous hours for low pay just because it’s so damn fun.

I talked to a dozen colleagues and pored over my own experiences to arrive at this list of nine software development motivation factors – Rob’s Criteria for Keeping Your Developers Happy.

There’s only one rule when determining your score: your vote doesn’t count unless you’re a developer. If you’re not in the trenches writing code then forward this article to someone who does and ask for their opinion. In addition to keeping management from making an unfair assessment, my greater hope is that this inspires conversation and forces management and developers to talk about these issues so we can get them out in the open.

Without further ado, here they are:

1. Being Set Up to Succeed
It’s a sad reality, but most software projects are set up to fail. Every developer has their horror stories; the “anti-patterns” of software project management.
I’ve seen an architect given documentation for a legacy system that he pored over for week while designing a new interface for the product. After the design was complete he found out that the documentation was three years old and didn’t reflect several major changes the system.

I’ve spent hours preparing a detailed technical estimate only to be told that the real deadline, already set by product development, gives me half the time I need.

Realistic deadlines are a huge part of being set up to succeed. Developers want to build software that not only works, but is maintainable; something they can take pride in. This is not in-line with product development’s goals, which are for developers to build software that works, and nothing more.

The first thing to go when time is tight is quality and maintainability. Being forced to build crap is one of the worst things you can do to a craftsman. Delivering a project on-time but knowing it’s a piece of crap feels a heck of a lot like failure to someone who takes pride in what they build.
It’s critical to have buy-in to do things the right way, and not just the quick way. As one developer I talked to put it “Quality is as important as feature count and budget.”

Schedule is not the only way a project can be set up to fail, but it is the most common. Others include: being forced to use cheap tools (be it software or hardware), working with a partner who doesn’t deliver, bad project management (see #2, below), changing scope, and unspoken expectations, among others.

2. Having Excellent Management
Excellent management, both for projects and people, is a must-have motivation factor. This means no micro-managing, the encouragement of independent thinking, knowing what it takes to build quality software, quick decision making, and a willingness to take a bullet for the team when product development tries to shorten the schedule

These are the traits of an amazing software manager; the traits of a manager whose team would bathe in boiling oil to defend her, and work all-nighters to prove her right. When a manager takes bullets for the team, good developers tend to return the favor and then some. It creates an almost cult-ish loyalty, and the results are not only motivated developers, but insanely good software.

3. Learning New Things
Behavioral research indicates we’re happiest when we’re learning new skills or challenging old ones. A recent article cites a study by two University of Columbia researchers suggesting that workers would be happy to forgo as much as a 20% raise if it meant a job with more variety or one that required more skill. This research suggests that we are willing to be paid less for work that’s interesting, fun, and teaches us new skills.

This is why companies using Ruby can find experienced programmers willing to work for less than their typical salaries.The learning factor is huge when it comes to negotiating compensation.

Every developer I know loves playing with flashy new technologies. It was Perl and HTML in the mid-90s, ASP, PHP and Java in the late-90s, ASP.NET and XML a few years ago, and today it’s AJAX and Ruby (and in some circles ASP.NET 2.0). Give someone a chance to use these toys and they’ll not only be able to impress their friends, but fulfill that piece inside of them that needs to learn.

Keep a developer learning and they’ll be happy working in a windowless basement eating stale food pushed through a slot in the door. And they’ll never ask for a raise.

4. Exercising Creativity and Solving the Right Kind of Problems
Developers love a challenge. Without them we get bored, our minds wander, we balance our checkbook, check our email, hit Digg and Slashdot, read a few blogs, hit the water cooler, and see if any of our friends are online so we can once and for all settle the debate surrounding your uncle, the IDisposable interface, and that piece of toast shaped like the Virgin Mary.


I’ve watched developers on multiple occasions stay up until sunrise to solve a technical problem without being asked and without extra pay. The best developers are addicted to problem solving. Just drop a Sudoku in the middle of a group and watch them attack it.

Faced with the right type of challenge many developers will not stop until it’s fixed, especially if it requires a particularly creative solution. Faced with the wrong type of challenge and they’re back on instant messenger describing the toast.

The right type of challenge is a technical challenge that teaches a new skill, preferably one everyone’s talking about. One example could be: “Consume these five RSS feeds, aggregate the data, and display the headlines on a web page…and figure out how to use AJAX to make it cool.”

The wrong types of challenges are things like: “Fix that other guy’s code. You know, the one we didn’t fire because we were afraid he might cause problems. Well, he wrote a really crappy system and now we need to fix it and make it high-quality and maintainable. Oh, and you have until tomorrow.”

If your business doesn’t provide challenging work to developers, figure out how you can start. If there is no chance you’ll ever be able to provide challenging work, find developers who are into hygiene factors, because developers who need motivation factors won’t stay long.

5. Having a Voice
Developers are in the trenches, and they’re the first ones to know when a system or process is not working. One developer I spoke with told me:

“[I want] someone to listen to my problems and actually take them seriously. I’ve worked at a few places where more RAM, more hard disk space, or faster/dual CPUs were simply not a priority for the company, but it was incredibly aggravating to the point of impeding my work. At one place I worked, every time I wanted to compile the software I had to clear all my temporary files because I needed more disk space. Talk about asinine. Being forced to work using outdated technology is really frustrating.”

When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act…quickly.

6. Being Recognized for Hard Work
As engineers we love building things that impress ourselves and our friends. At least the ones who realize how hard it is to write a Perl compiler. From scratch. In FORTRAN. On a Vic 20.

Building something great is fun, but it’s much more fun when someone’s there to pat you on the back, throw you a party, sing your praises, or buy you a steak dinner. Most developers enjoy hearing praise and receiving recognition for hard work, but even the ones who don’t need it are somehow soured when they don’t receive it (or worse yet, someone else receives recognition for your work).

Recognition is one of Herzberg’s core motivation factors and it applies to software developers as much as the engineers originally interviewed.

7. Building Something that Matters
Even though we’re not medics in Bosnia or food carriers in Sudan, most people want to feel like we’re somehow doing our part to make the world a better place, both technologically and socially. Some of us might think we do it just for the sake of technology, but in the back of our minds we see ourselves as part of a grand scheme.

For instance, a friend of mine works for a financial company and cherishes every time they launch a product that helps the under-served financial community.

An Albertsons inventory software developer enjoys coming to work every day because his work ensures, via complex supply and demand algorithms, that the baby cereals are always available on the shelves.

Building something that matters makes an L.A. Times software engineer ecstatic that the trucks are now saving over 30% of their mileage and fuel costs due to his shortest path finding software implementation for newspaper delivery.

On the other hand, writing an interface to a buggy API that’ll be used a total of 15 times in the next year doesn’t seem like it matters much.

Copying and pasting an entire application and changing a bunch of labels isn’t as exciting as it might sound.

And hacking in a few more case statements in a ridiculously complex stored procedure in order to service yet another customer without creating a proper data structure somehow doesn’t seem to fulfill that part of us that wants to build something that matters.


8. Building Software without an Act of Congress
I was a contractor for three years starting in 2001, and during that time I built a ton of web applications. Since much of my development was off-site I became accustomed to writing software really quickly once we knew what to build. Another developer and I built insane amounts of software over the course of two years.

When I got my next full-time job it felt like I was dragging 50-pound weights. For every page I wanted to build I had to call a meeting with six people. Any change to the database required three approvals. It was nuts, and applications took 5x longer to build. Talk about frustrating.

The authority to make project decisions without calling a meeting is huge.

9. Having Few Legacy Constraints
No one likes developing against buggy interfaces, crappy code, and poorly-designed data models. Too many legacy constraints kill creativity, require an act of congress to modify, and generally sucks the fun out of building software (see several of the previous points for why this is bad).

If you have gobs of legacy liability, try to figure out a way to minimize its impact on future development. If you can’t, look for people who value hygiene factors, because motivation factor developers are not going to maintain the same poor-quality applications for very long.

Determining Your Score
Let’s face it, the bar has been set pretty low when it comes to motivating developers. How many companies can you think of that would score even as high as a 3?

Since this test hasn’t been administered to companies across the globe there’s no basis for comparison, but that’s where you come in. I’d like to do an informal survey so we can get an idea of how things are in the real world. Please post your company’s score in the comments (you don’t have to post the company name).

Most large companies I can think of would be lucky to score a 1. Google would probably score an 8 or a 9.

Wrap Up
If you’re a manager, when was the last time you asked your developers about these issues? If you’re a developer, when was the last time you respectfully raised one of these issues, providing examples and a possible solution?

If the answer is “a long time ago” then you have some work to do. Send this article to a few of your colleagues and start discussing how to enact change.

add to DiggDigg thisadd to RedditRedditadd to del.icio.usdel.icio.us

If you liked this article you’ll also like my article Personality Traits of the Best Software Developers.

Thanks to Jeremy Lukensmeyer, Curtis Fields, Rick Kopitzke, Adnan Masood, Mike Taber, and a few others for their input into this article.

Special thanks to Mike Taber for reading a draft of this article.

Are you a developer, tech lead, manager, or other?

I’d like to find out more about you, dear Software by Rob reader, so I’m going to post a few polls to the site over the coming weeks. I appreciate you taking the time to participate – I will use the information to help write articles more tailored to your interests.

Please click here to answer the question for today: Are you a developer, tech lead, manager, or other?

Custom ASP.NET Search Engine Launched – Courtesy of Google Co-op

Google Co-op allows you to create a custom search engine by compiling a list of related sites.

I’ve created an ASP.NET search engine that includes the most popular and authoritative ASP.NET-related sites.

The beauty of the engine is there’s an option to “search the entire web but emphasize included sites,” so if the emphasized sites don’t return any results, Google will search the rest of the web.

The url is www.searchaspnet.net.

Feel free to contact me to suggest additional sites.

37signals Releases Free HTML Version of their Getting Real eBook

Previously only available for $19 as a PDF, 37signals very successful eBook Getting Real, that describes a smaller, faster, better way to build software, is now available for free in HTML format here.

It’s a good read, even if you don’t buy into every bit of their methodology.

Moon River Software Has a Job Opening in Worcester, MA

To celebrate the fact that today is the one year anniversary of hiring its first employee, Moon River Software is hiring again. If you’re interested, here are the details of the open position.

If you haven’t heard of Moon River, it’s the company started by software entrepreneur and blogger Mike Taber. If you’re into software startups you should check out his blog.

Media Temple Offering Grid Shared Hosting – $20 for 100GB and 100 Sites

Media Temple is offering a new shared hosting service called Grid Server that costs $20/month. For this, you get 100GB of storage, 1 TB of data transfer and up to 100 individual sites.

In addition, the service will grow along with you since you are not hosted on a single machine. Instead, your sites are located on a grid of hundreds of clustered servers that can handle traffic spikes, performance problems, and all other sorts of headaches we experience with today’s shared hosting packages.

Like Google did with Gmail, Media Temple has created a new paradigm in shared hosting. Look for others to follow.

Email Subscription Form Fixed

I found out late last week that the email subscription form at the bottom of each post (and the right navigation) hasn’t been working. Due to ASP.NET requiring the entire page to be enclosed in a form, the nested form used by the email subscription HTML wasn’t firing properly. Sigh.

It’s working again after a minor JavaScript workaround. If you’ve tried to subscribe in the past and never received an email, please try again and let me know if you have any problems.

Becoming a Better Developer Part 10: What Do Your Colleagues Think of You?

This is part of an ongoing series centered on becoming a better software developer. For other posts in the series, see the Becoming a Better Developer heading in the right navigation.

In the book Joy at Work, the former CEO of an $8 billion energy company describes an experiment where he allowed a business development group to determine their own salaries over the course of two years.

The first year everyone chose their own salary but the numbers were kept private. The result was that the best people paid themselves too little, and the average and under-performing people paid themselves too much. This is in line with Paul Graham’s quote: “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

The next year the company set a total budget for the department’s salaries and repeated the exercise, except this time all of the employees had to submit their proposed pay to their colleagues for comment – not to be approved or rejected, simply for comment. When everything was said and done the department was only slightly over budget, and upon closer inspection the company determined one person was highly overpaid based on the salaries of his colleagues with similar abilities. This person had not listened to the feedback of his co-workers who had told him he was overpaying himself. After being informed of this, he reduced his salary and they met their budget.

What does this tell us?

First, people who think they are underpaid are probably not very good at what they do.

Second, people who think they are overpaid are probably pretty good.

Finally, the people you work with are the best judge of your abilities. Yes, even better than you.

If everyone at work thinks you’re abrasive, it’s time to take a serious look at your interpersonal style.

Have you ever seen yourself give a speech or teach a class? Every time I see footage of myself I’m shocked at how I look when I’m in front of a group. I’m appalled at my posture and nervous ticks I didn’t know I had.

Your colleagues are the video camera that can see your ability to write code, deal with stress, communicate your ideas, write clearly, and a whole slew of other things that are critical to our jobs as software developers. If you’re not using them as a resource you are overlooking a powerful tool that can help improve both your technical and non-technical abilities.

The moral: If you are genuinely interested in improving as a developer, ask your colleagues what they think of your abilities. Not just your development skills, but your writing skills, interpersonal style, ability to deal with stress, etc…

Then ask them again and tell them to be honest.

For Sale: FeedShot, The Blog Directory Submission Service

In my copious spare time I like to work on software that’s fun to build that people will actually use.

About a year ago, noticing I had to hand-submit my blog to a number of blog search engines and directories I created a tool to accomplish it and that became FeedShot. FeedShot submits to around 15 sites that require an up-front hand-submission of your blog or RSS feed, all for the bargain price of $1.99.

Due to recent changes in my life (my first child), I am selling FeedShot. Full information is available here, but the site has pulled in about $65/month for the past 11 months, and I spend about 1 hour per months maintaining it. It’s ASP.NET 1.1 over SQL 2000 and is on a shared hosting account. I launched FeedShot for the fun, not the profit, so I imagine someone who wanted to wring more money out of it could easily do so.

Visit the FeedShot Blog for traffic and other information, or email support@feedshot.com if you’re interested in making an offer. Sold!