The He-Man Muggle Haters Club for Programmers (part 2)

This is the second article in a two-part series. If you haven’t already, please read Part One first.


 Protecting Our Interests

Although we may be loathe to admit it, we want and need programming to be sufficiently complex to keep the unwashed masses out of our clubhouse. The trouble is, we need a barrier to entry to support our value as programmers. Unlike lawyers and doctors who have expensive degrees and trade associations to protect their earning potential and aura of authority, it is not uncommon for a programmer to make a good living without the benefit of academic credentials or a formal endorsement of an organization. It is the magic of our craft that makes us feel special and separates us from the muggles and wanna-be’s like your boss’s nephew who is really good with computers.


Shhh! Muggles Are Everywhere

Fundamentally, I think this is a quite valid concern and admit that I sometimes succumb to these same territorial instincts. Especially when provoked by ignorant statements that undermine the investment programmers continually make in a Red Queen’s Race to stay on top of their game.





The Salman Rushdie of Programming?

Be Honest. How many of you have the urge to burn  this guy as a heretic?

There’s no reason why office workers, homemakers, professional engineers and pizza delivery persons shouldn’t be able to take advantage of their own hand crafted custom computer programs to work faster and smarter. It shouldn’t take a ‘professional programmer’ (whatever that is) to do the job. You know what needs to be done better than anyone else. You can do it yourself! (And I say this as someone who has spent many years writing programs for other people … ‘professionally’.)
VB Programming for the non-programmer!

Before everyone starts jumping on the VB dogpile in the comments, I should clarify that the referenced article is actually about VBA, and not VB proper. I’m sure, however, that many of my readers will question whether that distinction is meaningful inspiring yet another battle in the platform wars. This brings me back to my point.

 Why do many programmers despise tools like Access and VB, and even those that use VB look down on those who do too much drag-drop programming. The concept of a non-technical person using tools like this to build a useful software drives some of us nucking futs. Why? Shouldn’t we welcome usability to simplify the task of software construction?

Perhaps because it opens that clubhouse door a bit too wide for comfort.


"Sir, you can't let him in here. He'll see everything. He'll see the big board!"- General "Buck" Turgenson

Sir, you can’t let him in here. He’ll see everything. He’ll see the big board!

– General “Buck” Turgenson





Gold Plating The Secret Handshake

It is my contention that this effect has played a role in driving recent trends in programming technology. After years of considerable progress towards simplifying the physical act of programming (ASP.NET), recent developments in technology built for programmers has decidedly shifted towards better implementation of computer science-y stuff like functional programming, MVC and lambda expressions into the more pedestrian programming languages.

Also, the attention of developers is increasingly turning to the haute couture*technology of the day. Ruby? That is so two years ago, don’t you know we are using Scala now? (Haskell)

* The use of haute couture in this blog is not sanctioned by the French Government. For my French or Bostononian readers, please substitute the phrase “Wicked Awesome.”

This seems to drive programmers, who like woodworkers often build their own tools/jigs, to devote our time to constantly moving goalposts rather than reducing the required expertise to build functional software.


The Consequence and My Conclusions

I’m not saying that new programming languages don’t add value, just that this type of progress is more about fine tuning than making programmers generally more productive. My inner pragmatist makes me question the need to sharpen our tools to such a degree when the majority of the programming work seems to be centered on developing CRUD apps.  Additionally, given the very real threat of “low-cost” outsourcing options for programmers, it also makes me wonder if perhaps our priorities are not aligned with our best interests.


Don’t Go Away Angry

I fully realize that I have engaged in some very controversial conjecture in this series, and want to emphasize that the intent of this article is is not to drive a particular agenda. Rather, I’m merely trying to encourage introspection into some aspects of our trade that may have otherwise gone under-examined. I am not certain that I even agree with all of the opinions I have offered here, but found musing on them interesting and hope you will too.

3 Responses

  1. […] The He-Man Muggle Haters Club for Programmers (part 2) […]

  2. You’re spot on with regards to what programmers want, but I think you’re off-base as to why.

    I’m not afraid of making something easy.

    A task is either truly easy/simple or it’s not. If it really is that simple, I want to get as far away from it as I can, because someone *will* write a magic tool (hey, it’s easy!) and then I *will* be out of a job.

    It’s possible some programmers make a living out of easy tasks, and their livelihoods will be threatened by better tools. But I don’t think they’re the reason that programmers don’t have good tools.

    Programmers who write tend to be great programmers, because they are the programmers who know about their tools, care about their tools, and spend the time and energy to actually write better tools.

    So the programmers writing tools are not the ones feeling threatened by magic tools.

    Why aren’t they writing magic tools?

    If a task is not really that easy, oversimplifying it will make things worse. I’ll find myself hand editing auto-generated code and working against my tools. I believe this is why programmers hate drag ‘n drop.

    You need to look at an application over its entire lifetime. Will it need to be extended? Maintained? Wired up to another application? Ported?
    Magical tools can incur great technical debt.

    I’m not resentful of someone who drags ‘n drops. I have nothing against other people being productive. But if what they’re doing actually is complicated enough to be programming, drag n’ drop is not the tool for the job.

    Writing a framework (as opposed to a tool) is more of a programmer’s answer to the problem, and there are lots of frameworks for dealing with CRUD apps.

    A few additional random thoughts:

    Text is portable; source code is an extremely simple (if not greatly usable) representation of a program’s implementation. As a programmer I really, really want to minimize the amount of tool metadata that I need to worry about.
    Tool specific metadata means tool lock-in. (Oracle Forms is a good example)

    I think Ruby on Rails is a very good example of how ‘fine-tuning’ can lead to a *more* inclusive programming environment. If you want to support magical tools, you need powerful languages.

Leave a Reply

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

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

Facebook photo

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

Connecting to %s

%d bloggers like this: