On Benchmarking Skills

A common topic on Stack Overflow (and possibly many other places) is developers looking for some measure of their skills.  Many ask what they should learn next (or learn first), some ask what they should do for a job search or an interview, some simply and directly ask how they can know how good they are at what they do.  (My personal favorite, and I'm currently having no luck finding a link, was when somebody asked if it was possible to completely master a programming language.  Most of the responses were similar to what I am about to write, but one was simply the word "Yes" linked to Jon Skeet's profile.)

It's a natural question, really.  Humans have a psychological need for positive reinforcement.  We want to know how good we are at something, most specifically in relation to how good other people are at that something.  We want to be weighed and measured in the hopes that we can pin a badge on ourselves demonstrating that we're experts at this and that.  Hell, there's an entire industry of certifications and courses built around this.  And I've certainly met a fair amount of people who cling to those certifications as ironclad proof of their superiority in the field.  (After all, if Microsoft says you're good at something, then you must be, right?  Why else would they be willing to sell you the course materials over and over again every time they release a new version of something that they also sell you?)

But it's relative.  We all know the old saying: "The more you know, the more you know you don't know."  It's a popular saying because it's essentially true.  So true, in fact, that the most common answers I see to such questions as above are that as long as you're striving to improve, you're good.  It's only when you believe that you've mastered something and that you have no room for improvement that you should worry.  No matter how good you get at something, you should always be aware of your limitations.  It's not entirely necessary that you have the ambition to overcome those limitations, so much as it's necessary that you be aware of them.

We've met the people who thought they were the top dog.  Hell, I've been that person.  Back when I worked at a state job, I was the man in terms of software development.  I knew my stuff, I was up to date on technologies, I was the hot shot codeslinger.  I had what I now refer to as "big fish in a small pond syndrome."  It was a state government job, it presented no challenges or growth.  There was no evidence that my skills were lacking or reason to improve.  The job I took after that corrected this syndrome.  The pond, the size of which being measured by the overall skill and talent of my fellow developers, grew and grew and grew.  (It eventually tapered off and I found myself needing to expand and take upward flight under my own strength, which led to my seeking a new job again, but that's another story.  Still seeing how that's playing out.)

I've discussed this with Tony a few times as well.  He's mentioned that the team at his current job as a big fish in a small pond.  Some developer who is "the senior developer" for no other reason than he's unopposed.  He's not really skilled, but until Tony got there he had no means to measure his skills against anybody else.  Recognizing this in the professional world, Tony now finds himself wanting to be the smaller fish in the bigger pond.  This is because our skills are relative.  You only know how good you are at something when standing next to someone who's better.  (American Idol auditions notwithstanding.)

So, to really answer the question of "how do I know how good I am at something?" is to find someone who's better at it.  Learn from them.  There is no certification or online test that can measure you quite so well as you can measure yourself when you work with someone more knowledgeable or more experienced.  Keep in mind that the business model of certification courses isn't to make better developers, it's to sell certification courses.  Online tests (the kind I loathe when required by a hiring manager) don't actually test your ability to perform on the job, they test only your ability to take online tests.  Unless you're interviewing to be an online test taker, they're not particularly applicable.  (Though all too often they're a necessary evil to get past the first line of defense in an interview process.  Even though the code seen in such tests is generally the kind of code a qualified candidate would run from screaming rather than choose to support as a career.)

If you believe yourself to know all there is to know on a subject, that's a bad sign.  The more you know, the more you know you don't know.  Or, as I once saw it comically expressed online somewhere:  "When I graduated high school I thought I knew everything.  When I graduated college I realized I didn't know everything.  When I received my Master's Degree I realized I didn't know anything.  And when I received my PhD I realized that it's alright because nobody else does either."

Someone Doesn't Like Me

I must have offended somebody's delicate sensibilities on Stack Overflow:

Some quick research on meta.stackoverflow.com revealed that they have a daily script that checks for this sort of thing and remedies it.  (They have a number of daily scripts that look for a number of things, actually.  It is the internet, after all.)  So we'll see if that does anything.

It's just 10 points, so no big deal either way.  I just hope whoever this is doesn't continue to have nothing better to do.  People are just strange.

Intro to Programming with Python

About a month or two I did a video for SummeryPyGames to teach entry level programmings (or those very new) about programming in Python. I just recently uploaded the video to my vimeo account so I figured I would share it. My first screencast and it came out pretty good I thought.

http://www.vimeo.com/14223348

I have thought about doing more maybe delving into some details about different parts of the language, or slowly building a library to teach someone Python moving onto classes and basic scripting after the video above. I'm sure I would learn a lot in the process.

On Business Priorities

Raise your hand if you've been told "this application is very important and critical to the business and absolutely must work."  Now raise your hand if you've ever called them out on that bunk.  Maybe I'm just a little more cynical or blunt about these things, or maybe I'm a bit of an ass, but I think it's important that business users be made aware of the level of bunk often found in this statement when it comes to their applications.

For all the times I've heard similar statements made, they can all fit neatly into two distinct categories of "highest priority" (notwithstanding the fact that constantly pushing the panic button does not build a constructive sense of urgency):

1. Real business priority
2. "Squeaky wheel" priority

The former is simple.  There are systems that are critical to a business' core functions.  At my company, for example, our core database is of the utmost importance.  Millions of dollars have been spent, teams of people surround and maintain it at all times, there are detailed policies and procedures that have been created by experts and have stood against rigorous testing, etc.  It's a business priority, and the business knows it.

The latter, however, is nonsense.  And it's nonsense that affects the business' bottom line often without the business even knowing it.  It wastes everyone's time and effort (and, ultimately, the business' money) all because someone somewhere is being a "squeaky wheel" and demanding attention.  More often than not, we as support personnel are simply told to just go along with the demands.  That is, after all, part of our job.  (And that's fine, just don't complain to me when the real work suffers as a result.)

But let's talk for a minute on what this "priority" really boils down to.  This business user has an application that was created for a specific business purpose.  For this user (and this user alone) this application is critical.  They need it in order to do their job.  And their job relates to other business functions which are also critical and so on and so on (which this user will gladly explain in an email, since justifying their job is clearly more important than describing the actual problem).

But if this application is so critical to the business, why then was it not given any design or architectural attention?  Well, that's "just how we do things here."  Our development group isn't so much a "team" as it is an assortment of people who work individually on their own projects and support their own projects until they eventually leave and everyone else inherits their mess.  But that's another story for another time.  If the application is important to the business, then why was the business not willing to put any effort into creating it.  It was given to the cheapest "resource" (person) and done as quickly as possible.  That sounds pretty low-priority to me.

But the user thinks otherwise.  The fact that the business as a whole consciously decided that this application was not important enough to merit any effort and that the resulting application was designed to fail doesn't matter.  Evidence and historical data are unimportant if that wheel can get squeaky enough.  Now we're into a political battle, not software support.  Now we get to play a game that managers and children alike play.  Complain loud enough and you will be heard.  (It's amazing what business professionals have in common with my two small children.)

It gets especially interesting when the user begins invoking names and business terms as part of their squeaking.  Toss around the term "HR" or cc: an executive and the squeaking gets louder.  Sorry, but I don't believe in magic.  Stringing together words of power to form an incantation that will rouse and frighten others into doing your bidding is, I'm sorry to say, witchcraft.  Voodoo.  And it has no place in a professional environment.

So what ends up happening?  Amid all my ranting and complaining (sorry about that) it all comes down to one simple truth.  All we're going to do for that user is placate them.  We're going to apply some quick fix to get them up and running again.  Not even get them up and running, but just get them to shut up.  No effort, no thought, no expertise at all.  Just do whatever it takes to stop the wheel from squeaking.  Again, does this sound like a business priority?

So why are we maintaining this charade?  This charade costs money.  It directly affects our bottom line.  We know that user will be back, we know that application will fail again.  It all comes down to a very simple business decision...

Is this application a priority or not?

While this post was a whole lot whinier and rant-ier than my last, the message is essentially the same.  Care about your software.  As a business (either a whole company or just a department or even a single user, whatever entity "owns" a particular application), if a piece of software is critical to your business then put forth the effort required to make sure it meets your needs.

I've said it before and I'll say it again... If the person who actually cares about this application doesn't really care about it, why should we?

Interconnecting The Tubes

I was bored at work today, so I figured I'd add Stack Overflow flair to the side of the blog.  I also started a personal blog (since too much personal stuff would be noise here) and added my Twitter feed to that.  There's also a Twitter list for this blog's contributors and peeps, but it seems that the Blogger widgets don't have a way to add that as a feed as well.  At least, not one that I've found.

Thoughts?