The NYTimes recently publised a long semi-autobiographical article written by Michael Crawford, a University of Chicago Phd graduate who is currently employed as a motorcycle mechanic. The article is partially a somewhat standard lament about the alienation and drudgery of modern corporate work. But it is also very much about rationality. Here's an excerpt:

As it happened, in the spring I landed a job as executive director of a policy organization in Washington. This felt like a coup. But certain perversities became apparent as I settled into the job. It sometimes required me to reason backward, from desired conclusion to suitable premise. The organization had taken certain positions, and there were some facts it was more fond of than others. As its figurehead, I was making arguments I didn’t fully buy myself. Further, my boss seemed intent on retraining me according to a certain cognitive style — that of the corporate world, from which he had recently come. This style demanded that I project an image of rationality but not indulge too much in actual reasoning. As I sat in my K Street office, Fred’s life as an independent tradesman gave me an image that I kept coming back to: someone who really knows what he is doing, losing himself in work that is genuinely useful and has a certain integrity to it. He also seemed to be having a lot of fun.

I think this article will strike a chord with programmers. A large part of the satisfaction of motorcycle work that Crawford describes comes from the fact that such work requires one to confront reality, however harsh it may be. Reality cannot be placated by hand-waving, Powerpoint slides, excuses, or sweet talk. But the very harshness of the challenge means that when reality yields to the finesse of a craftsman, the reward is much greater. Programming has a similar aspect: a piece of software is basically either correct or incorrect. And programming, like mechanical work, allows one to interrogate and engage the system of interest through a very high-bandwidth channel: you write a test, run it, tweak it, re-run, etc.

New to LessWrong?

New Comment
12 comments, sorted by Click to highlight new comments since: Today at 9:53 AM
  • Programming, mechanical work = single-player games
  • Management, politics = multi-player games

I think the appeal of single-player games is clear. Besides the latency issue in multi-player games (i.e. having a delayed feedback on your actions), they are just harder than single-player games, as in NP-Hard. Human beings probably do have dedicated neural circuitry to deal with social situations, which makes them a little easier, but those weren't adapted for deep hierarchies like the ones in modern corporations.

This reminds me of an article on management that was linked to somewhere on OB:

The strange thing about my utter lack of education in management was that it didn’t seem to matter. As a principal and founding partner of a consulting firm that eventually grew to 600 employees, I interviewed, hired, and worked alongside hundreds of business-school graduates, and the impression I formed of the M.B.A. experience was that it involved taking two years out of your life and going deeply into debt, all for the sake of learning how to keep a straight face while using phrases like “out-of-the-box thinking,” “win-win situation,” and “core competencies.” When it came to picking teammates, I generally held out higher hopes for those individuals who had used their university years to learn about something other than business administration.

Also, social outcomes in general aren't Pareto-optimal under asymmetric information, even assuming perfect rationality. This is frustrating for someone with a mindset for optimization and problem solving. It's tempting to retreat into a smaller world where an optimal outcome is possible as long as one works hard enough, or thinks smart enough.

People are part of "reality" too, and social success is hard to fake. The nominal objectives leading to social success aren't exactly faked. It' s more accurate to say that no-one bothers to precisely name (and one of the objects is not to do so except in certain narrow circumstances) what they are.

Reality is not very harsh when all you're dealing with is a broken motorcycle or a program that won't compile. When you're dealing with public policy, which even in its best form is usually social triage, deciding who gets what and who will be left unemployed, poor, sick, in debt, unfunded, oppressed, or dead, the facts have a much greater sting.

And, as MichaelVassar points out, political success is usually pretty clear cut, at least in the long run. Just ask Walter Mondale or John McCain.

It's not the severity of the consequences that matters, but the distance. If a program or a motorcycle is broken, you can see that almost immediately. If a public policy is broken, it may take years for the problems to become clear, by which time the thought processes that lead to the bad decision will be long forgotten and cannot be connected to their consequences.

Understood. I should've made it clear I was responding specifically to

A large part of the satisfaction of motorcycle work that Crawford describes comes from the fact that such work requires one to confront reality, however harsh it may be. Reality cannot be placated by hand-waving, Powerpoint slides, excuses, or sweet talk. But the very harshness of the challenge means that when reality yields to the finesse of a craftsman, the reward is much greater.

Nearly a year late, but the reality that motorcycle mechanics must adhere to is the selfsame reality which justifies their job: the continued operation of the motorcycle. In contrast, the politician must adhere to many factors - public opinion, party loyalty, fundraising, etc. - which are only weakly related to the reality which justifies their job: public well-being.

This is indeed one of the things I love about programming, in a private capacity. Sadly, it doesn't prevent programming managers and career climbers from arguing in advance over which pet methodology is more likely to lead to correct code, making power plays via engineering process proposals, and mounting all manner of blustering, persuasive, politically-motivated initiatives, usually without any actual data to back any of it up.

Then, when the code is done and testable, those people can credit/blame the successes/failures to whatever suits them.

Great article.

Being a computer programmer myself I also sometimes think about working with my hands. There is an additional gratification there that you don't have with intellectual only work. Sure, a programmer hits the keyboard with his fingers, but it's not the same as doing actual work. And I think it's good for the mind if the body is moving and actually doing something instead of just sitting the whole day.

Also I came to the realization that a lot of blue-collar works offer enhanced job opportunities. Like, suppose you are an electrician and are traveling overseas and need some money. Well, there is always someone needing to rewire some cables in his house who would be willing to pay for it. As a programmer it's not that easy, usually there are no two-day projects.

It is indeed much harder to "fake it" in Programming, and mechanical work, etc.

It's easier to fake it at more fuzzy things like management, but those can also require tough thinking and be even harder challenges. There's less immediate and explicit feedback, but that only makes it harder to be fully rational.

Games also feature immediate, explicit feedback on success and failure (which one of the reasons we enjoy them), but that doesn't make them more valuable than fuzzy, ambiguous real life.

i agree, though in stuff like management faking it isn't just easier, it can also be more of a requirement (for political reasons, etc).