Cote’s Weblog

Scott Sehlhorst has a thorough reply to the Document Mobile example in one of last week’s posts.

I like his re-thinking of the cynical idea that layers of docs are a way for non-technical people to hide-out. Indeed, the docs do provide a sort of “common language” for the technical and non-technical people to talk in.

In fact, Sehlhorst’s post serves well as a “what you should be doing” reply to the problem of Document Mobiles.

Non-Technical People

As I’ve discussed these ideas with people over the last few days, I’ve realized that my definition of “non-technical” is broader than most folks think. For example, I don’t expect a “technical” person to know how to program, or even debug a hairy system problem. Those types of things are what “programmers,” or, at least, “system administrators” do.

What Do Technical People Know?

I do expect “technical” people, for example, to know things like:

• Right clicking on a web page is an extreamly weird and uncommon thing: like a 3 wheeled car.
• Changing the wording on a screen isn’t a big deal.
• When to use a GUI vs. a web app.
• Most aspects of web app usability and design, e.g.: methods of text overflow controlling and scrolling issues, or what “AJAX” means for making web apps more dynamic and realtime.

Of course, there are exceptions, variations, and thin lines to walk for those, and other, things depending on the system and requirements. But, being able to sort out those issues is the core of what makes someone “technical.”

Editors and Writers

To make an analogy: an editor isn’t a “writer” but they’re certainly in the business of helping put together articles, books, and stories. There’s a shit-load of shared knowledge between editors and writers. If you took some dude off the street and had them be an editor, chances are the best you’d get when they read the book would be “this books is long,” or, “I like this book.”

Non-technical people often give similar responses when confronted with demos of software: “could we move that header over a little to the left?”

An Example

I’ve had the pleasure to meet several “technical” people who aren’t programmers. For the issue at hand, Brandon stands out as a good example. He’s a product manager, though he did used to write code…in C++ I think of, all horrors. No wonder he stopped programming ;>.

Despite being a “mouse person” (as opposed to the “keyboard people” who type code), he knows his shit when it comes to software. For example, if you tell him you’re starting an application, he’ll throw a barrage of technical questions at you like:

• Are you bundling a database? Oracle? MySQL? Hypersonic? Can I switch out the database? Can I move the database?
• Is it a web application? Java? Ruby? Does it use JBoss? Just Tomcat? Rails?
• OK, do you have group permissions? Fine grained permissions? Permissions at all? LDAP? Active Directory?
• How about an XML over HTTP based API? On that note, do you implement the <insert your domain here> blah-blah data/process standard(s)?
• You doing water-fall or Agile? How long’s the iteration?
• Of course you’ll want to upgrade to the new Java. But do we really need to? Does it at least run faster?
• Users don’t want 3,000 nodes, events, or 3,000 of anything. Let’s give them 5.
• There is no right click on a web page. Shove that JavaScript up your ass.

(OK, maybe that last, ass part is what I’d say. Brandon has — what do they call it? — couth?)

The above is a good mix of “speeds and feeds and feature tick-lists” and to understanding how technologies are used and can be used, in both old and new ways.

Point being: he can actually add a shit-load of value to the process of writing kick-ass software. And that, of course, is the idea of a “technical” person. They don’t need to write code, but their work should directly inform and feed into the development and (if you’re into making money) monetization of code. Otherwise, there’s probably a degree of waste going on that could be cut out.

Popularity: 1% [?]