Nine Things Developers Want More Than Money

A pretty good article on what makes a developer tick:

http://www.softwarebyrob.com/articles/Nine_Things_Developers_Want_More_Than_Money.aspx

"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 been 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 system 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. "

 

OK rule Engineers number 1. Treble the estimated time needed and never
finish in less than 80% of the specified time.