How Hard?

When working on behalf of others one must always consider how hard they are willing to work to meet other's expectations.

Taylor claimed there is one best way to perform any job and it is the employer's responsibility to discover that and insist work proceed that way. This may have applied to building steam engines with immigrant labor at the dawn of the industrial age.

I argue that in creative work one's shortest path to exceeding expectations rarely goes through meeting expectations.

I have often entered status meetings with only one of three things asked of me completed. This would appear to be underperforming except that the one thing deliverers unexpected delight. Attention shifts to opportunities thus exposed and a total disregard for work undone.

In the realm of programming the naive approach of doing whatever is expected has huge detrimental consequences largely based on compounding complexity. Specific development methods emerge to address this but all ring of Taylor's one best way.

Requirements analysis suggests first clarifying the ask.

Agile development suggests small steps and refactoring.

Open source suggests volunteers scratch their own itch.

A methodologist will study a process, find weaknesses, and prescribe improvements. To even speak of improvement one must accept that there is a goal along some dimension like saving time or making money.

When we accept that modern work involves more decisions than we can possibly enumerate we revert to discussion of goals and especially alignment towards goals. We align employee motivation with organizational goals, often monetary goals, often induced with bonuses, options, or similar incentives.

But neither method or alignment deliver all that is possible.

Computer programming shares some properties with science and mathematics. One of these is that it is still possible for an individual to be motivated by curiosity. When we refer to the "art of programming" we acknowledge that self-motivated expression can, at times, produce startling accomplishments.

A scientist builds things to learn while an engineer learns things to build. We engage engineers to bring knowledge to the task at hand. The task is ours, the knowledge theirs. Engineers work for hire. Look more to the scientist's motivation for the limits of possible.

Where are we to find the most delight in computer programs? Can we make a program beautiful? Beautiful for whom? When?

Alexander claims that beauty is rooted in a human ability to recognize utility without understanding its basis. The light on two sides of a room or the low hanging roof solve problems that we may not know we have, or may not have been known to anyone, ever.

Alexander's interests were in the built world where timeframes are months, years and sometimes decades. He sought methods to shorten this by, say, walking the land and placing bricks at future building corners so as to experience the possibilities.

A curious programmer can create in days, hours and sometimes minutes. Curiosity wanes quickly though because our computing infrastructure and consumer expectations demand tedious integration before use.

This then is the challenge: create an environment, an ecosystem, where hard work is optional but delivery still possible.

I was once asked by a graphic designer if wiki had to be so ugly? The question hadn't occurred to me but I knew the answer had to be yes. In order to admit beauty.

Beautiful works will come from those who allow themselves to be directed by their own curiosity, who have mastered techniques to manage complexity, and who have empathy with, but not necessarily direction from, their users.