Joel Spolsky said something interesting in his critique of Java-oriented Computer Science eduction.
Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer
This is so true. Great geeks understand the importance of the mental ducking and diving and wheeling and loop-the-looping up and down the layers of abstraction. The Geek's job is to see at all levels so that the requirements of one level can be solved by implementations further down.
But now consider the perenial Suit complaint of the Geek : that he starts getting bogged down in unnecessary technical details when he should just be giving a high-level progress report or talking to the customer about her problems.
He doesn't "understand business" the Suit thinks.
How tragically, irritatingly wrong. The Geek's job is to make the abstraction levels fit together. Of course the only way to achieve this is with an understanding of both the higher and the lower levels : simultaneously. And the easy shifting from one to another.
But Suits love to keep the levels separate. Their whole reason for existence, their positions depend on the notion that the levels are distinct. The rigid company hierarchy is the reification of non-traversable levels of abstraction.
It is obvious to them that "business" can be understood through the abstraction of accounting. And that the senior managers make visionary plans which require highly abstract inferences about strategic relations but don't require understanding the gritty details of technology.
To the Suit, Geek thinking, that swoops between the layers of abstraction, that claims the right to think of the problem from any perspective, is anathema.
4 comments:
Inversely, I've seen many Suits fail to do their job completely because they're the other way around - they fail to understand that the devil is in the details: page response times, interface tweaks, or what features (or combination of them) will rapidly descend into chaotic, unmanageable systems.
I think there's now an interesting "clash": coding has emerged from an "optimisation" perspective, where pointers, memory allocation, loop optimisation, etc are all a hugely important art. Business, on the other hand, is about weighing up risks, investments, and returns. In other words, CS is ready to apply a 50%+ effort to squeeze 10% extra out of the system. Business won't have this, business sees not the code, but also the coder as a resource, or an asset, to be managed. Business code is about reducing Risk, and reducing Cost. If coders can be outsourced, so much the better, even if the code runs less efficiently. Processors are cheap compared to coders.
Of course, seeing things from an economic point of view - "efficiency", if you will - means you avoid investing in risky/"innovative" technology. And I think that's why the really interesting stuff is coming from individuals, and why businesses are choosing to make data available, rather than invent.
The really depressing thing is that the same thing is true of government, who want a similarly "efficient" solution to, well, everything. Ho hum.
A rambling riff inspired by this post.
Alternative thoughts:
"Efficiency" is all too prominent in the geek's view, in fact. And very much less so from the Suit's perspective.
Consider that geeks are effectively "confined" to working within particular frameworks - Java, MS, Hibernate, Google APIs, relational databases, Ruby on Rails, etc - all of these are technologies designed to optimise a certain aspect of a job, such as shuffling huge amounts of data, making slick user interfaces, or what-have-you. You invest time and money in a particular set of technology, and you disregard others because they're not relevant to your job. As a geek, you choose which functionality is important to you, and you choose the tools to make this implementing this functionality easiest.
But from a Suit's perspective, "Technology" is something different - it's a "philosophy", rather than a toolset; something to be managed, rather than something to be bought In the eyes of a non-geek, technology is magic, and it can do anything. When something breaks, it can be fixed. Processes are instantly optimised, because that's what technology does.
In a happy sense, it's good that this is how people see Technology - it means tech producers are doing something right, and are setting expectations high. But the difference here is that geeks see this "it works!" aspect as a damned miracle, while suits see it as a norm.
But once you start abstracting away from the technology like that, you can no longer be "efficient" in a business sense, because what may seem like a small change may actually involve the shifting of a software tools' entire founding philosophy. It's much harder to curse at task-sharing in Outlook at work, for example, if you realise that it's not designed as a collaborative workplace tool, but as an organisation tool for an individual.
So geeks are "efficient", but in a different way. Suits are "efficient" in a different way again. A lot of companies fail because they try to do everything, and end up spreading themselves thinly, and the same thing is true of software, so I guess they have something in common.
David Schmaltz had a recent series on management abstraction/distance and its effects.
http://webseitz.fluxent.com/wiki/z2008-07-09-SchmaltzManagementScientism
Post a Comment