Reactions to NeoVictorian Computing

One of my inspirations as a professional is a man named Kelly Mehler, the father of a childhood friend of mine, who runs a small furniture-making shop and teaches woodworking. He’s eschewed mass production and has made a successful and profitable career out of hand-making furniture that is beautiful both in its visual appeal and its utility. Though he certainly can’t produce furniture as cheaply as a large operation in a lower-wage country, his business model is under no threat from such competition. And he can be proud of his work every day. These are things I’d love to be able to say about my own career.

So, it’s with that context that I stumbled upon Mark Bernstein’s recent posts exhorting a NeoVictorian movement in computing. (No, I wasn’t searching for cosplay photos.) Suffice it to say that I’m sympathetic to his central thesis that the rhetoric and practice of computing in “the enterprise” can be alienating for the practitioner and detrimental to the practitioner’s creativity. Writing software within a large corporation is not always subject to the criticisms that Bernstein makes, but the risk is there.

For many software engineers the solution is to participate in open-source projects which allow them to work on ideas that their dayjob doesn’t give them a chance to do. For others, the solution is to take a run at a startup idea of their own. And then there’s Bernstein’s approach, suggesting that perhaps the whole target of enterprise computing is flawed. I think that he’s right to suggest that there exists a whole class of software that might be built for the individual knowledge worker, and which offers ISV’s the opportunity to exercise their creativity.

However, it’s clear also that the core of enterprise computing will always offer a lot of unique engineering challenges and pay a lot of software engineers’ salaries. I think that, at a minimum, working in that environment successfully requires:

  • actually caring about the business/industry in which you’re working
  • being part of a talented, collegial and motivated team
  • knowing what you want to work on and being direct about it
  • being agile (small ‘a’) enough to not get too rattled by the fickle nature of business requirements
  • having the guts to speak up (diplomatically) when you think an idea is just completely wrongheaded

Clearly, some of those attributes are social rather than being strictly technical. And some of them are attributes of the organization itself. So we as software engineers need to pick our employers carefully, and recognize that that we need social skills as well as technical ones.

Leave a Reply

Your email address will not be published. Required fields are marked *