Nine Things Developers Want More Than Money

Discussion in 'NZ Computing' started by Chris Lim, Nov 3, 2006.

  1. Chris Lim

    Chris Lim Guest

    A pretty good article on what makes a developer tick:

    "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

    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

    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

    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

    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. "
    Chris Lim, Nov 3, 2006
    1. Advertisements

  2. Chris Lim

    Jo Guest

    OK rule Engineers number 1. Treble the estimated time needed and never
    finish in less than 80% of the specified time.
    Jo, Nov 7, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.