perpetual novice – years of experience vs skill

Most job listings ask for a certain number of years of experience.  Either in a particular technology or in the industry.  This presumes that the developer learned each year.

I read a quote about whether the candidate has five years of experience or the same year of experience five times.  I don’t remember where this came from, but I think it clearly expressed an important point – that we can’t just measure years.

Upon re-reading the “Software Craftsmanship“, I came across the concept/phrase “perpetual novice.”  This is exactly the idea.  If one never picks up best practices and software development habits, all that time could be spent repeating inefficient ways of doing things.

I’ve seen this upon interviewing as well.  Some people with “X years experience coding Java” look like they can’t code their way out of a paper bag.  I’m thinking this is related to the “perpetual novice” concept.  These people figure out everything from scratch and repeatedly solve problems the industry has surpassed.

What’s dangerous is that such developers don’t consider themselves novices anymore.  Someone new to the field or right out of college realizes they are a novice.  They ask questions and realize there is much to learn.  “Perpetual novices” think they know quite a bit and are less likely to ask a more experienced person.

And worse is when the real novices learn from perpetual novices – the opportunity to learn better ways is lost and the cycle continues!

Have you encountered any perpetual novices in your career?  What do you think makes them stand out?

process maturity and the schedule

When we started our project nobody bother about <activity A> because we had very tight delivery schedule.”

Every so often, one sees a statement of this form.  I think it points out that “Activity A” is not an essential part of the process.

It could be because ‘Activity A’ isn’t perceived as having enough value yet.  I think it is a sign of process maturity when this statement doesn’t occur.  For example, I remember a time when we threw tests and the automated build out the window for emergency bug fixes.  Over time, we appreciated the value of these tools and especially the safety net they give us.  I don’t think anyone has thrown out these parts of the process in years!

What really hits me with the quote is that, ‘Activity A’ is perceived as having some value since the author of the quote feels compelled to justify why it wasn’t done.  This is like justifying not brushing ones teeth!

As a process matures you get different levels of value:

– not there yet – don’t even feel the need to make excuses

– immaturity – do the activity sometimes but throw it out the window when things get tough

– maturity – do the activity always

This activity could be anything.  Seeing it get done for emergency production fixes really shows me it has been fully embraced as part of the process.

javaranch & coderanch forums

I gave IBM’s data visualization tool Many Eyes a shot.  Very cool.

The tag cloud visualization shows the most common words used in the JavaRanch/CodeRanch forum names and description.

Unsurprisingly, words like Java, certification and discussion feature prominately.  In two word mode, “sun certified” was the clear leader.

I have no doubt that other data sets would be more interesting.  It’s a nice tool to explorer.  Free to use with the only caveat being anyone can see your data/visualization.