Another way to think about geeks and repetitive tasks

The other day Tim Bray tweeted a Google+ item entitled Geeks and repetitive tasks along with the comment: “Geeks win, eventually.”

Here’s the chart posted on Google+ by Bruno Oliveira:

A couple of things bothered me about this. First, there’s the adversarial tone. The subtext is a favorite geek quotation:

First they ignore you, then they laugh at you, then they fight you, then you win.

That gem is often attributed to Gandhi. Wikiquote disputes that and finds a close variant in Nicholas Klein’s 1918 speech to the Amalgamated Clothing Workers of America. Either way it’s the story of a persistent underdog overcoming an oppressor.

In geek ideology the oppressors are pointy-haired bosses and clueless users. Geeks believe (correctly) that clueless users can’t imagine, never mind implement, automated improvements to repetitive manual chores. The chart divides the world into geeks and non-geeks, and it portrays software-assisted process improvement as a contest that geeks eventually win. This Manichean worldview is unhelpful.

But the chart also fails to capture the reality of repetition and automation in the realm of information systems. Here’s an alternative world view that I choose to imagine and strive to create:

In this view of the world, tasks that involve data manipulation (as so many modern chores do) are undertaken by teams. There is an infinite supply of manual chores. Everybody tackles them. Ideally there is one member of the team I call the toolsmith. Working shoulder to shoulder with the team, the toolsmith spots an opportunity to automate some piece of the work, writes some code, deploys it, observes how it gets used (or doesn’t get used), assesses its impact (or lack of impact), and then iterates on the code. Meanwhile the toolsmith keeps working alongside the team, chipping away at the never-ending and always-evolving list of manual chores, looking for more opportunities to automate, and exploiting them in an incremental and collaborative way.

Software-assisted automation of repetitive work isn’t an event, it’s a process. And if you see it as a contest with winners and losers you are, in my view, doing it wrong.

28 thoughts on “Another way to think about geeks and repetitive tasks

  1. James

    Just a random thought: software should also be able to identify opportunities for automation, by spotting repetitive processes.

    Not sure sure how far away we are from this, and whether there are any low-hanging fruit.

    I recall the magic/replace that had some capabilities along these lines, though I never used it myself.

    Reply
      1. Madushan

        lol… have to say, not all software are automated. XD

        does this think got a ‘Like’ button ?

  2. Journeyman

    I’ve always wanted to be that Toolsmith, the guy that continually refines the “manual process” by automating parts of it, improving the lives of my coworkers.

    I’ve yet to find a company that wants to employ that person. They’d rather identify big budget projects to completely rewrite the process from scratch, and hire a team of developers to do that job. Improvements happen, but it takes years to filter out and usually adds new pain points (while removing others, granted).

    Reply
    1. Ethel

      I’d like to mention that software testing often has lots of roles for relatively lone-wolf “toolsmiths” to aid and abet testing in a company that otherwise relies on manual testing. I’ve more or less aimed for this role myself. Network admins often have a strong “tool-smith” as well.

      IME, though, the role is generally a side-task of a larger development role. I often see the more senior developers “tool-smithing” for other developers on the side of their more official work (e.g., fine-tuning the build-and-deploy system; writing a quick script to check an item off of the sprint or operations backlog; etc.). I work at a company where the devs split their time between developing tools to generate data and for clients to access that data, and working as a team to “tool smith” for internal employees who work between the clients and our tools, essentially filling in the roles that our system doesn’t yet automate or those jobs that may always require a human expert to accomplish. However, I see devs and other techies often “tool smithing” individually on the side as well, handling easy one-offs quickly and discreetly or fine-tuning their own internal processes (setting up a continuous build server that automatically runs tests on check-in, anyone?).

      Reply
  3. Gavin B

    I like that new diagram – now we have not only HCI we also have HGI – the Human Geek Interface!

    nice post Jon!

    Reply
  4. Tom Hunt

    My auto industry executive father told me that his fellow executives respected UAW union founder Walter Reuther because he was the best tool and die man in Detroit. Every year the auto factories would shut down for a week or two while the tool and die crew would setup the assembly line for the new models.

    Reply
  5. danmondy

    It’s not that I don’t agree with everyone getting along, but looking at your new and improved chart tells me that the geek is staying late and still getting the raw end of the deal. I hope he is at least getting payed more, but this is far less motivating for a geek than the original.

    I think somewhere the chart should at least contain: Geek offers to sell script to non-geek and requires non-geek to bow and surrender cool-status + hot girlfriend to geek. Call me old-fashioned.

    Reply
  6. Jon Udell Post author

    I hope he is at least getting paid more, but this is far less motivating for a geek than the original

    I hope he or she is getting paid more too.

    FWIW, participating in a virtuous cycle of improvement, with rapid iteration based on user feedback, and many opportunities to see how your evolving code is helping people, is /highly/ motivating.

    Reply
  7. Pingback: Another way to think about geeks and repetitive tasks « Another Word For It

  8. Tom West

    Indeed, it’s really hard for most companies to handle people writing tools to automate jobs, but part of that is because it then means that they are required to keep a toolsmith on the team to maintain the tools, especially if people become dependent upon the tools (which they quickly do).

    This reduces worker fungability to such an extent that many companies prefer not to allow any deviation from the manual procedure rather than risk being dependent on something they don’t control.

    As an inveterate toolmaker, it’s painful and boring to not automate, but I do understand the business case for blocking the toolmakers.

    Reply
    1. Jon Udell Post author

      As an inveterate toolmaker, it’s painful and boring to not automate, but I do understand the business case for blocking the toolmakers.

      Really good point. My hope is that the cloud can be our friend here. The most fear-inducing kind of tooling is the kind that’s idiosyncratic and of uncertain provenance. As we begin to develop tools out in the open, that legitimate concern might be mitigated.

      For example, I’ll soon need a tool that renames tags in batches of tagged resources. If there were a service that does that, on a JSON-in-JSON-out basis, I’d use it. (Is there?) If I can’t find one I’ll create one but it’ll be a) open code, and b) openly hosted for anyone to use (just because I can).

      (And in this era of Javascript ascendance, hosting can be a very lightweight and decentralized thing.)

      Reply
  9. zzzuperfly

    I have a big problem with this geek thing, in my view everyone is a geek – it is part of humann nature, it is just that some types of geeking are more socially accepted than others.

    I really think that the software creator community should let go of that image.

    Or the other way of looking at your chart – the non-geek embraces his geek side and eventually turn into a eh geek…

    Reply
    1. Tom West

      in my view everyone is a geek – it is part of humann nature, it is just that some types of geeking are more socially accepted than others.

      At the risk of a semantic disagreement over what ‘geek’ means, I’d have to disagree here. If we’re defining geek as it’s archetype, then it’s essentially a tendency towards systematizing. That’s a talent and as such, it goes from very little to lots. However, the ‘lots’ isn’t all that common. (And obviously training and practice increases anyone’s expression of that talent.)

      I’d say the same for another talent – sales. There are those who have a lot of that talent and those who have a little. Saying that everyone is and can be a salesman is, to be honest, trivializing that talent (although, yes, we can all be *better* salesmen through training and practice).

      Honestly, I don’t have a problem with recognizing people’s talents rather than pretending we all have the same.

      (And lastly, using a script may increase *or* decrease the amount of geekery involved in a job. I’ve been accused of de-skilling a job (half-seriously) by automating a lot of the (to me) boring bits. In the end, the people performing the job could be a lot less geeky (systemizers) than before. Of course, many times using a script saves time, but requires that the user have a better grasp of the system, in other words, making the job more geeky.)

      Of course, if you’re using a different meaning for geek, feel free to disregard this post :-).

      Reply
      1. Jon Udell Post author

        it’s essentially a tendency towards systematizing.

        Well said. I wish the colloquial term for that cognitive style weren’t pejorative.

  10. Pingback: The Ambrosini Critique » Blog Archive » Help wanted: incrementalist systems builder

  11. IDAllen

    “And if you see it as a contest with winners and losers you are, in my view, doing it wrong.”

    In other words, you’re a loser? Perhaps even the author needs to change his mindset from right/wrong to something more collaborative that doesn’t also use the vocabulary of right/wrong and winners and losers?

    Reply
  12. codea

    In my point of view we have to promote the usefulness of these tools to employers. Employers want to save time and make money. It is US that need to change our mind and not tell it takes time but tell we have to do it to improve speed and reliability to our tasks. I tried It a couple of times and it works well. they understand.

    I don’t know why but we tend to say programming tools takes time and its bad… (false for me !)

    Note: I like your post ! I have placed your chart on one of my blog post with a link to your site. If it bothers tell me…

    Reply
  13. Evan Williams

    Hi Jon,

    thanks for the thoughtful (as ever) post. As someone who is part time tool smith in a large enterprise, I can definitely relate to this.

    One observation though – both charts seem to be addressing the X axis really as “time” – even though it’s marked as “task size”.

    I think the “time” label makes more sense – since the chart as a whole shows the progression of automation over time – for a given size task.

    No doubt that there are “different” instances of these charts – for each kind of task size – where the gradient and inflection points will change.

    In my experience, the difficulty is to make it known that there *is* an alternative to the “non-geek” way.

    cheers,
    Evan

    Reply
  14. charles ross

    I like the first picture better, it has primary colors, is much cleaner, in sympathy with User Friendly or Dilbert.

    As a tool-head myself, our workplace process tends more toward your picture, which is more pastel and less visually striking.

    There are of course a few more aspects to this topic

    1. The best tool-head knows how to Find (buy, download, borrow or imitate) and quickly adapt existing tools. I guess that’s just part of automating.

    2. Another part of the timeline is where the pointy headed boss notices work is caught up, folks have relaxed and then someone’s job is eliminated (just saying). Similar comments in the Oliveira thread.

    3. We toolmakers are hired to be job-killers. At heart we don’t want to kill jobs, because we feel that we are freeing people from drudgery so that they can make fewer mistakes and have more time for the interesting and valuable work. But our masters don’t always think that way. We know they don’t because a lot of us lost jobs due to better tools, cheaper workers from abroad and cheaper systems, a la Yourdon.

    4. All this reminds me of a very vague germ of a theory, my answer to The Singularity. My version of the singular event is not the reaching of some sort of machine intelligence, rather it’s about a point where humans tool themselves up to the point nobody can figure how we built the tools. There have been occasional ideas to retreat a few steps and restart, such as RISC and the recent “everything in JavaScript” impetus. But the tool layers continue to mount, while we have backups that can’t be restored and arithmetic and penmanship skills decline.

    Reply
  15. Pingback: 3 Ways to Code Faster | Industrial Programming Tips

  16. Pingback: Another way to think about geeks and repetitive tasks | Jon Udell | linkstream2 microblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s