唯有仰望是真实的: 2006年11月

Liu 的个人资料唯有仰望是真实的照片日志列表更多

工具

帮助

<< 第一页 < 上一页下一页 > 最后一页 >>

2006/11/27

interesting image from coffee

21:14 | 添加评论 | 阅读评论 (1) | 固定链接 | 写入日志

2006/11/18

腹肌培养项目启动

为了将最近日渐堆积的小肚子消下去，恢复之前比较好点的体型，从今天开始要找个地方做仰卧起坐，将腹肌培养项目优先级提高。

22:49 | 添加评论 | 阅读评论 (8) | 固定链接 | 写入日志

2006/11/14

想笑来伪装掉下的眼泪
点点头承认自己会怕黑
我只求能借一点时间来陪
你却连同情都不给
想哭来试探自己麻痹了没
全世界好像只有我疲惫
无所谓反正难过就敷衍走一回
但愿绝望和无奈远走高飞
天灰灰会不会让我忘了你是谁
夜越黑梦违背难追难回味
我的世界将被摧毁也许事与愿违
累不累睡不睡单影无人相依偎
夜越黑梦违背有谁来安慰
我的世界将被摧毁或许颓废也是另一种美

想哭来试探自己麻痹了没
全世界好像只有我疲惫
无所无所谓反正难过就敷衍走一回
但愿绝望和无奈远走高飞
天灰灰会不会让我忘了你是谁
夜越黑梦违背难追难回味
我的世界将被摧毁
也许事与愿违
累不累睡不睡单影无人相依偎

2:31 | 添加评论 | 固定链接 | 写入日志 | 乱

2006/11/11

她走在美的光彩中(Byran)

她走在美的光彩中,
像皎洁的夜晚繁星满天.
明与暗最美妙的,色泽,
在她的容颜和秋波中闪现:
融成一片淡淡的莹辉,
那柔光在白昼无从看见.
多一道暗影,少一缕光芒,
都会损伤这难言的优美;
美波动在她乌黑的秀发上,
又轻柔地映照她的面庞;
愉悦的思想在这里颂扬,
心灵寓所的纯洁、高尚.
啊,在脸颊上,在眉宇间,
如此温和、平静,又脉脉含情;
那迷人的微笑，那容颜的光彩,
都在说明一个善良的生命:
她的灵魂安于世间的一切,
她的心充溢着纯真的爱情！

23:02 | 添加评论 | 固定链接 | 写入日志 | 乱

2006/11/10

Just For Fun: Quicksort in 3 lines(zz)

http://aspn.activestate.com/ASPN/Cookbook/Python/R...

Title: Just For Fun: Quicksort in 3 Lines
Submitter: Nathan Gray (other recipes)
Last Updated: 2001/08/07
Version no: 1.3
Category: Searching

Description:

OK, 4 lines if you count wrapped lines. :^) This is a rather naive implementation of quicksort that illustrates the expressive power of list comprehensions. DO NOT USE THIS IN REAL CODE!
NOTE: Due to an annoyance in the ASPN submission filters you must manually remove the space after the '\' character in the third line if you intend to use the code. Otherwise you will get a syntax error.

def qsort(L):
    if len(L) <= 1: return L
    return qsort( [ lt for lt in L[1:] if lt < L[0] ] )  +  \ 
              [ L[0] ]  +  qsort( [ ge for ge in L[1:] if ge >= L[0] ] )


# IMHO this is almost as nice as the Haskell version from www.haskell.org:
# qsort [] = [] 
# qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
#                 where 
#                   elts_lt_x = [y | y <- xs, y < x] 
#                   elts_greq_x = [y | y <- xs, y >= x]

# And here's a test function:
def qs_test(length):
    import random
    joe = range(length)
    random.shuffle(joe)
    qsJoe = qsort(joe)
    for i in range(len(qsJoe)):
        assert qsJoe[i] == i, 'qsort is broken!'

Discussion:

I cooked up this function after finding the wonderful Haskell quicksort at http://www.haskell.org/aboutHaskell.html (which I've reproduced above). After marvelling at the elegance of this code for a while I realized that list comprehensions made the same thing possible in Python!
Both implementations pivot on the first element of the list and thus have worst-case performance for the very common case of sorting an already-sorted list. You would never want to do this in production code! Since this is just a recreational excercise, though, it doesn't really matter. :-)
Since list comprehensions were introduced in Python 2.0 this code will not work on any earlier version.

Refinements, Raymond Hettinger, 2002/02/28
Here is a slightly less naive version. Pivot selection is random to make worst case performance less likely. Pivots are counted to handle degenerate cases with many equal elements. Filter is used for rapid partitioning.
def qs(ds):
    if len(ds) <= 1: return ds
    pivot = random.choice(ds)
    return qs(filter(lambda x: x < pivot, ds)) +
           [pivot]*ds.count(pivot) +
           qs(filter(lambda x: x > pivot, ds))
Add comment

Just For Fun: Quicksort in 1 Line, Christophe Delord, 2002/08/25
Of course this must not be used in real code too!
q=lambda x:(lambda o=lambda s:[i for i in x if cmp(i,x[0])==s]:len(x)>1 and q(o(-1))+o(0)+q(o(1)) or x)()
This lambda expression is just a rewriting of this function:
def q(x):
	if len(x)>1:
		lt = [i for i in x if cmp(i,x[0]) == -1 ]
		eq = [i for i in x if cmp(i,x[0]) == 0 ]
		gt = [i for i in x if cmp(i,x[0]) == 1 ]
		return q(lt) + q(eq) + q(gt)
	else:
		return x
Add comment

Bug in quicksort long form..., Jeremy Zucker, 2003/01/15
def q(x):
	if len(x)>1:
		lt = [i for i in x if cmp(i,x[0]) == -1 ]
		eq = [i for i in x if cmp(i,x[0]) == 0 ]
		gt = [i for i in x if cmp(i,x[0]) == 1 ]
		return q(lt) + q(eq) + q(gt)
	else:                  ^^^^^   
		return x
Running q(eq) will infinitely recurse. Use eq instead of q(eq)

23:31 | 添加评论 | 固定链接 | 写入日志 | code monkey

2006/11/7

love poem

还没享受够故都的秋，寒冷的冬天就在嗖嗖两天风中毫不留情的来了。
那天回家在勺园到办公楼的路上听到前面的小朋友说，在燕园这个园子
里，冬天脱光的特别多，夏天尤其是毕业生分手的特别的多，呵呵。
在公司拼命的赶进度，又是眼瞅着光光节的到来，今天开始每天贴诗吧。

The Way You Make Me Feel

You make me feel special,
You make me feel new,
You make me feel loved,
With everything you do.

You hold me close when I am sad.
You wipe the tears from my face.
Every time we are together,
It seems like the perfect place.

My eyes light up when you enter a room.
I smile when we are together.
No matter how bad things are,
You always make them better.

I love the way you kiss me,
The way you hold me tight.
I love the way you touch me,
I could be with you all night.

I love the way you can make me laugh
For absolutely no reason at all.
I love how no matter what I do,
You will be there to catch me when I fall.

I just want you to know,
That even though we sometimes fight,
I will always love you!
No matter what, day or night.

- Amanda Standridge -

22:44 | 添加评论 | 固定链接 | 写入日志 | 乱

555...

那天去剪头发，给我剪的大哥说，给你个小建议，你头顶的头发稍有些稀了，注意稍微修饰一下。
555, 惨啊，还什么都没那啥呢，怎么能......
不知道是否睡的太少有影响，早睡早睡，嗯嗯，以后要每天提前3个小时睡，提前半小时起.

2006/11/6

Hash Crash Course(zz)

Published on Perl.com http://www.perl.com/pub/a/2006/11/02/all-about-hashes.html
See this if you're having trouble printing code examples

Hash Crash Course
By Simon Cozens
November 02, 2006

When I teach about hashes, I do what most Perl tutors and tutorials do: I introduce the hash as a "dictionary": a mapping between one thing and another. The classic example, for instance, is to have a set of English words mapped to French words:

    %french = (
        apple  => "pomme",
        pear   => "poivre",
        orange => "Leon Brocard"
    );

Yet the more I look at my code--and more often, the more I look at how to tidy up other people's code--I realize that this is perhaps the least common use of a hash. Much more often, I use hashes in particular idioms which have very little in common with this concept of a mapping. It's interesting to consider the ways that programmers actually use hashes in Perl code.

Counting

Many of the uses of hashes are to "answer questions about lists." When you have an array or list of values and you need to ask about its properties, you will often find yourself using a hash. Start simply by counting the number of particular elements in a list. Here's the naïve approach:

    my $count = 0;
    for (@list) {
        $count++ if $_ eq "apple";
    }

You can smarten this up with the use of the grep function:

    $count = grep $_ eq "apple", @list;

... but when you need the number of pears in the list, then you have to do the same again:

    $count_apples = grep $_ eq "apple", @list;
    $count_pears  = grep $_ eq "pear",  @list;

Now there are two passes over the list, and the situation isn't going to get any prettier from here. What you want is basically a histogram of the data, and you can get that with a hash:

    my %histogram;
    $histogram{$_}++ for @list;

This hash associates each individual item with its count, and it only traverses the list once.

In a recent case, I was looking at a list of tags associated with various photographs. To lay out the data for display, it was useful to know how many different tags there are in the list. I could get that simply from the number of keys in the histogram:

    $unique = keys %histogram;

I could also delete the duplicates and end up with a list of the unique tags:

    @unique = keys %histogram;

Finally, I could show the five most popular tags from the list:

    @popular = 
        (sort { $histogram{$b} <=> $histogram{$b} } @unique)[0..4];

This sorts the list of unique tags based on their popularity in the original list, and pulls out the top five.

Uniqueness

Another idiom to get the unique elements from a list is a variation on the "counting things" idiom; but this time you don't care how many of each item there is, just that there's at least one. This allows you to say:

    for (@list) { $unique{$_} = 1 }
    @unique = keys %unique;

which reduces to:

    %unique = map { $_ => 1 } @list;
    @unique = keys %unique;

You can take this a stage further with a slightly non-standard idiom to do the whole thing in one operation:

    @unique = keys %{{ map { $_ => 1 } @list }};

keys requires a hash, so this funny-looking line creates an anonymous hash ({ map ... @list }) and then turns it into a real hash (%{ $hash_ref }) to feed it to keys.

The advantage of this trick is that you can use a variation of it to work with lists which include objects as well as ordinary scalars. Here's an example of the problem:

    my @tags;
    push @tags, Memories::Tag->retrieve_random for 1..10;

This should get ten random Memories::Tag objects. However, some of them might be the same, and, assuming that you want to see the unique ones:

    %unique = map { $_ => 1 } @tags;
    @unique = keys %unique;

Unfortunately, if you then try to do anything with the tags, it all goes horribly wrong:

    print $unique[0]->name;

    # Can't locate object method "test" via package "Memories::Tag(0x1801380)"

What's happened is that hash keys can only be strings; once you put the object into a hash as the key, then it's not an object any more. Perl turns it into a string. There's no (easy) way to get the strings back into an object. What you need is some kind of data structure to map these broken strings into the original objects. Thankfully, there is one in the form of the hash itself! So the code becomes:

    %unique = map { $_ => $_ } @tags;
    @unique = values %unique;

First, map the object--which Perl will smash into a string--with another copy of the object, which will retain its object-ness. Then instead of getting the strings out of the hash, which are useless to us, you get the objects.

Of course, this doesn't quite work, because even if retrieve_random retrieves the same tag name twice, it will return two different objects with the same data. (That's true unless the underlying database abstraction layer uses caching, which is another good use for a hash.)

The solution is to make the list unique based on a property of the tag, such as its name. This time, the code is:

    %unique = map { $_->name => $_ } @tags;
    @unique = values %unique;

Okay, now you have a list of objects which you've retrieved randomly, but which have unique names. The only problem is that you retrieved ten of them to start with, and then whittled the list down to get rid of duplicates. What if you actually wanted 10?

The solution is to keep track of ones that you've already seen, so that you don't create any duplicates in the first place. The question "Have I seen this before?" is easy to answer using another hash-based idiom:

    my @tags;
    my %seen;
    while (@tags < 10) {
        my $candidate = Memories::Tag->retrieve_random;
        next if $seen{$candidate->name}++;
        push @tags, $candidate;
    }

Once again you're collecting unique values by putting them into a hash. Suppose that the first candidate tag that comes along is japan. At this point the hash is empty, and so $seen{japan} is zero. Because it's zero, the code continues through the loop with next, but still increments the hash value. Now $seen{japan} stands at 1, and the tag goes into the list. If japan comes past again, $seen{japan} will be positive so the next code will activate, and the tag will not go into the list again. (Don't try this if you have fewer than 10 distinct tags, of course!)

Caching

A special case of "have I seen this before?" comes when you want to create a cache: if I have seen this before, what was the answer I saw last time? Here's how to do that.

I mentioned that the underlying database abstraction layer in the tags example might cache look-ups and return the same object if you requested the same tag multiple times:

    my %cache;

    sub retrieve {
        my ($self, $id) = @_;
        return $cache{$id} if exists $cache{$id};
        return $cache{$id} = $self->_hard_retrieve($id);
    }

This checks to see if it has seen the $id before; if so have, return the value from the hash. If not, work out what the value should be, then store it in the hash for next time, then return the whole lot.

Of course, for heavy-duty applications like a database abstraction layer, you need to do a little more work, such as pruning the cache to make sure it doesn't get out of date or get so full of data that it eats all your memory. The Cache::Cache suite of modules from CPAN takes care of all of this for you, and the core Memoize module adds this kind of caching to a function without you specifically having to write the cache-getting and -setting code.

Searching

Finally, you can use hashes for searching.

If you've done any computer science, you'll probably know about a couple of common searching algorithms. (Even if you haven't, they're so common that you've probably reinvented them without knowing it.) One is linear search, where you start at the beginning of a list and work your way toward the end, looking for the target item:

    my $index;
    for $index (0..@chambers) {
        last if $chambers[$index] == $bullet;
    }
    print "Found at index $index" if $index < @chambers;

Another is binary search, where you start in the middle of a sorted list, and work out whether you should go higher or lower than the current element, like players in some demented version of Card Sharks. This is basically the way to look up names in a phone book--it's faster, but a bit more complicated to implement:

    my @names = qw(Able Baker Charlie Dog ...);
    my $index;

    my $target = "Roger";

    sub search {
        my ($lower, $upper) = (0, $#names);
        while ($lower <= $upper) {
            my $index = ($lower + $upper) / 2;
            if ($names[$index] lt $target) {
                $lower = $index + 1;
            } elsif ($names[$index] gt $target) {
                $upper = $index--1;
            } else { return $index }
        }
        # Not found!
    }

This starts in the middle, at "Mike". "Go higher!" shouts the crowd, so it goes half-way between there and the end, to "Tare". Then it needs to go lower, so looks half-way between "Mike" and "Tare" and gets to "Peter". Now it needs to go higher again, between "Peter" and "Tare", and finds "Roger".

That takes four comparisons, which is not bad. Can you do it any better? How about... oh, none?

    my %search = map { $names[$_] => $_ } 0..$#names;
    print $names{"Roger"};

Now I'm cheating somewhat here because setting up the hash requires iterating over the whole array, but once you've done that, the searches are basically free.

Of course, if you need to look up an array index by its contents, then maybe you're doing something wrong in the first place, and should have used a hash to start with. Consider, for instance, in a configuration file:

    force-v3-sigs
    escape-from-lines
    lock-once
    load-extension rndlinux
    keyserver wwwkeys.eu.pgp.net
    keyserver the.earth.li

(Yes, that's from GnuPG.) Each line has a key and optionally a value, but you can have multiple values for each key. At the end of the day, you might want to look through and say "tell me all the keyservers"--but not just the keyservers, you want to read the whole config in and be able to say that about any key. That's a search problem, and a tricky one. Here's one solution:

    while (<>) {
        chomp;
        my ($key, $value) = split /\s+/, $_, 2;
        push @config, [$key, $value];
    }

Now you have to say:

    @keyservers = map { $_->[1] } grep { $_->[0] eq "keyserver" } @config;

This is actually a linear search in disguise. (grep does a linear search for you.)

With hashes, the issue is much simpler:

    while (<>) {
        chomp;
        my ($key, $value) = split /\s+/, $_, 2;
        push @{$config{$key}}, $value;
    }

This treats every key as a separate array reference, and pushes values into that array. Now to retrieve the list of keyservers, just look up the array inside the hash:

    @keyservers = @{$config{"keyservers"}};

This process is very remniscient of the final pattern--using a hash as a portable symbol table.

Dispatch Tables

Instead of having the configuration reader create a bunch of arrays--@keyservers, @load_extension and so on--I created a hash which held the arrays so as to look them up indirectly but more efficiently. In effect, instead of using the Perl symbol table, you can use a hash as a portable symbol table.

Suppose you have a script that does several related things: it manages your to-do list by adding, editing, listing, and deleting to-do items:

    % todo add "Email Samuel about photos"
    Todo item 129 created
    % todo done 129
    Item 129 marked as done

You might expect the script to look like:

    my $command = shift @ARGV;
    if    ($command eq "add")  { add(@ARGV)  }
    elsif ($command eq "list") { list(@ARGV) }
    elsif ($command eq "done") { done(@ARGV) }
    elsif ($command eq "edit") { edit(@ARGV) }
    ...
    else { die "Unknown command: $command" }

That is quite tedious; you need to edit the program in several places every time you add a new command. You could use symbolic references--that is, tell Perl to call a function named $command:

    my $command = shift @ARGV;
    sub AUTOLOAD { die "Unknown command: $AUTOLOAD" }
    no strict 'refs';
    &{$command}(@ARGV);

But that's somewhat crazy. It allows the user to get at any subroutine in the main package, which you may not want, and to keep any error checking you have to assume that any undefined subroutine call comes from the command line.

The middle way is to copy the commands into a hash, mapped to a function reference:

    %commands = (
        add  => \&add,
        list => \&list,
        edit => \&edit,
        done => \&done,
    );
    my $command = shift @ARGV;
    if (!exists $commands{$command}) { die "Unknown command: $command" }
    $commands{$command}->(@ARGV);

This keeps strict happy, it's safe in the way it restricts what subroutines users can call, and it allows for error checking that doesn't mess everything else up. Mark Jason Dominus' Higher Order Perl shows how you can define commands at runtime if you use dispatch tables, something you can't do if you hard-code your dispatch.

Conclusion

I've explored some of the most common hash-based patterns: using hashes for counting, uniqueness, searching, and dispatch--rather a lot more than just mapping from one thing to another. Of course, that is what a hash does at one level, but the uses of such a data structure are a lot more diverse than just that.

That's how you improve your Perl programming--you take elements of the language which ostensibly do one thing, and you find that they're great for more complicated uses as well. Maybe after these ideas you'll be able to find a few more hash idioms of your own!

23:49 | 添加评论 | 固定链接 | 写入日志 | code monkey

2006/11/4

Nine Things Developers Want More Than Money(zz)

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 chicks. Ladies love a man who can speak BASIC to his Apple.

Code

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 chicks?

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.

Football 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.
Wheat
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.

Droplets

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."
Speaker

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.

Library

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.

20:01 | 添加评论 | 固定链接 | 写入日志 | 乱

日志