Code Competence

The question “Having knowledge” of a technology is vague. In terms of defining understanding, the continuum runs from “I’m aware that it exists“, through “the ability to carry on a cocktail party conversation“, upwards to “hobbyist“, “technical competence” and – eventually – “professional expertise“.

When someone says “I am not interested in programming or coding“, I don’t know whether they are identifying a distinction between the two terms.

I do see a distinction, and believe it would be useful (both within our discipline and in the larger professional environment) for us to clarify our discussions along those lines.

Overlap:

  • Traditional functional coders are programming experts with some design skills
  • Interaction Design folks are design experts with some programming skills

The issue is Appropriateness (and that’s what Usability is all about)

CODE

is an accepted system of rules or symbols for converting a piece of information into another form.

As Usability folks, we do “coding” all the time. At the high end we do it through information architecture, metaphors and patterns (often labeled as ‘SEO”).  At a visual/conceptual level we do it through Visio’s and drawings. On a dirt-under-the-fingernails/implementation level we do it through HTML, CSS, DHTML, etc.

PROGRAMMING

captures and expresses functionality and performance features through a form of logic. (I haven’t found a convenient definition, so I just made this one up).

Programming is what the developer community does.  They use a programming language, which is made up of functional “code” (Java, C++, etc.), to manipulate the informational and presentational “codes” that are defined by us designers.

PROGRAMMING  CODE

Yet the two terms are often used interchangeably, which adds to the confusion.

In The Bad Old Days developers defined the presentation and information codes themselves.  Aaaaand … Well, let’s put it this way:

When somebody says “Gee, that looks like it was designed by a programmer“, it’s generally NOT a compliment.

Presentation Level Platform Tools

  • HTML (page templates, sitemap, layout)
  • CSS / Tags (organization of info, style themes, IA)
  • DHTML / Javascript (behaviors)

… are appropriately “owned” by Interaction Design, Information Architecture, User Experience, and Usability. Because it’s our turf.

CSS & HTML have more to do with info tagging than they do with data manipulation (which I think of as “real” programming).  They are actually a unique coding skillset (even if considered to be “coding lite”) -esp. re UI design usage

Are HTML & CSS “Real” Coding Skills?

Well, it’s possible to “know a little html, css and some javascript” yet still produce butt-ugly interaction screens.

Perhaps this implies that

  • using html, css and javascript gracefully is – like any coding skill – a Genuine For-Real Skill (!)
  • Many mainstream programmers aren’t too good at this necessary technical skill
  • It follows that: Denying that it is a coding skill is – well – sort of embarrassing, isn’t it?

Kinda like the construction worker claiming that the architect lacks technical skills just because he doesn’t work with your particular hammer …

Good Code

Don’t know whether “good” – doesn’t matter if you’re referring to programming or design – describes

  • Best Practices (i.e. It’s well annotated code, efficient coding technique, consistency, easy to maintain, etc.) or
  • Decent Results (i.e. “It works”).

For most of us, conventional programming is hidden “under the hood”: We neither know nor care whether it’s rendered in Java, C, ASP, or whatever. For that matter, we don’t care whether it’s particularly well formed (conforming to “best practices”). We just care that “it works“. Not that those best practices qualities aren’t important, but they are of interest only to the practitioners of coding, their managers and the immediate implementation team.

The same coding Best Practices issues apply very much to the design effort.  They’re far more critical because the UI code gets fiddled with much more often than the underlying data manipulation & back-end code.

Stylistic makeovers, ease-of-use improvements, widgets, branding, portaled integration with other apps, “white label” repackaging, etc. are all what define The Competitive Edge – and the UI is where most of them are implemented.

Maintaining those changes is a big old piece of work – and it’s a major headache for conventional program coding teams that aren’t too skilled at UI. But that’s a whole ‘nother discussion…

BTW: There are also a whole set of UI Design Best Practices that are implicitly agreed-upon within the Usability arena and have been implemented broadly across the interactive environment.

True: There are many differences of opinion about how to implement good design (s.a. color preferences, layout, terminology, icons, etc.).

De gustibus non disputandum est : “There’s no accounting for taste”.

As a UI Guy for about 30 years, I’ve found that I need to provide the client with best practices-conforming solutions (emphasize:  “solutions” is plural) – and be wisely agnostic about which one they pick.

That’s the big reason why the front-end UI tools (CSS, HTML, etc.) belong to the IxD/UxP/Usability folks who are best equipped to handle the ongoing, reiterative process of crafting the UI.

The Punchline

Those 50 thousand lines of under-the-hood engine code may be expertly formed, well-implemented, efficient and bug-free, but if nobody wants to use them, it don’t mean nuffin’.

As a Usability Designer I work in HTML, CSS, taxonomy, and information architecture.

Am I a CODER?  You bet.

Am I PROGRAMMER?  Not so much.  Even though I often dabble in the grey area of Javascript mashups and sometimes define UI functionality for “real” coders to implement.  As I tell clients, “I have programming as a modest skill, but it’s not a job description.

And that’s kind of what we’re exploring here:  The continuum of :

  • What we know OF (awareness)
  • What we actually KNOW (wisdom)
  • What we can USE (skill)
  • What we’re really GOOD AT (talent)

The Continuum of Competence

There’s a continuum of technical competence that spans what I call “coding” (the identification, organization and manipulation of info; s.a. HTML, CSS, tagging, information architecture, taxonomy, etc.)

There’s also what I call “programming” (under-the-hood choreography of the codes; engines for applications like ASP, JSP, PHP, C+ etc.).

There’s even an area of overlap between the two that I call “programming lite“: s.a. front-end Javascript, jQuery libraries, behaviors that can be triggered by the artful use of HTML5 and CSS3.

There is no dispute that this Continuum of Competence exists. The roles must be fulfilled. So we can bicker about who does what.

Is this muddying the issue? The confusion was already a well-established norm. Who here has NOT encountered job descriptions where the the client wants a developer + CSS expert + usability tester + visual artist + interaction designer +, +, + …?

Don’t know about you, but I spend (waste) far too much time trying to get recruiters & clients to clarify their muddied thinking. And a lot of it revolves around the coding/programming terminology confusion.

“A code is a rule for converting a piece of information (for example, a letter, word, phrase, or gesture) into another form or representation (one sign into another sign), not necessarily of the same type.”

— Wikipedia

Sure sounds like taxonomy … tagging, semantics and – yes – “keywords” to me. However you define it, it ain’t a program.


© The Communication Studio LLC