Skip to main content

You don't know what you don't know

I've been programming since I was little.  I'm not just someone who wrote some code once when I was 15.  I code all the time because I enjoy it.  This industry is both very deep and very wide.  The ocean of available knowledge is what attracts me to it.  I bore easily, and the idea that I can always be learning something new is extremely appealing.  But, though it may change, at this point in time, I'm the exception, not the rule.

Not every programmer started as a kid.  Not every programmer does in for the sake of programming.  Most do it for the ego trip, or worse, the money.  But having the level of passion that I have for programming is something to be proud of.  That means that many people who do this job for other reasons--well, they fake it.

But it's complicated

Like I said, the industry is a vast ocean of information.  This means that the tiniest amount of knowledge in an obscure enough area (it doesn't even have to be that deep) can give a person the appearance of being more skilled than someone who has spent thousands of hours more time studying other areas of development.  Let's name these people for simplicity.  Phil will be our name for the programmer who happens to know something extremely obscure (let's say he's an awk expert).  And Bill will be our name for the programmer who knows a lot of things, but has never heard of this obscure technology.

The thing is, Phil gets respect over Bill because of this knowledge.  "Even Bill doesn't know it!" say his co-workers.  Sometimes, Bill even compliments him.  "I wish I had your knowledge".  Phil doesn't know what Bill does, but he doesn't have to.  He was hired for this specific purpose.  And this is all great.  Phil gets lots of praise.  His ego inflates and he might even start to get the impression that he's actually a better programmer than Bill.

And then things get complicated

Bill, Phil, and the rest of the team are invited to a meeting by Mark, the new project manager who is trying to plan out the next piece of software that the team has to build.  Bill is excited.  He presents a new piece of technology and explains how it will fit well on the existing technology stack.  Phil gets excited as well, and explains how this new branch of his obscure technology is perfect (maybe) for the problem area.

The team, having spent years complimenting Phil on how much smarter than Bill he was, backs the idea to use this obscure technology on the project.  A decision is made and Bill has to make it work.

Do you see it now?

Bill is now responsible for a project written in a technology he has no knowledge of.  Phil, while extremely confident, will have no actual involvement in the project anyway.  The project will be written in an extremely obscure technology, making it harder for the team to get up to speed and learn what they need to get the job done.

The project will fail

It's worse than just the team learning about the technology.  Phil doesn't have knowledge of the existing production stack, the vital knowledge that Bill has to use when making decisions about what tools to use for the project.  Using this obscure technology will actually be impossible for this company, but even the developers don't know that soon enough for it to be able to help.  The business has no clue.  The company will spend a lot of money on changing infrastructure to fit the needs as the developers discover they need this and that to make it work.  And then, when they're mostly there, they'll realize that it's close enough to impossible that the business is not going to waste money on it anymore.  And it gets worse than that, but let's not focus on the negatives.

What about Phil?

Well, Phil hasn't been working on his project.  He won't get blamed when it fails.  Because he understands most of the technologies involved, he may get consulted on parts of it, and seeing the rudimentary mistakes of the other developers learning his technology he may even think it's failing purely because they're incompetent.  It's not his fault either.  His line of thought is perfectly reasoned based on the information he has.  But then, that's the mistake isn't it.  The information he has is incomplete.

This is a common issue in the pursuit of knowledge, and I wrote this post to explain why it manifests itself so strongly in software development.  But with that explanation, it's also inspiration for a new way of thinking.  As much time as I spend studying obscure, deep, complex bits of software, I don't spend as much time talking about it.  Like Phil, I certainly want to talk about the cool stuff I was studying, but I don't usually get to.

Back to basics

Instead, I spend most of my time talking about simple things.  Even skilled developers often have a weak understanding of testing, readability, and sustainability.  That's what I recommend you talk about also.  If you're ever in Bill's shoes in a meeting trying to deal with an ugly situation, stop.  Don't argue about a topic you don't understand.  Fall back to the basics.  Talk about sustainability.  Talk about testability.  Talk about readability.  But above all, remember.  It's not about today.  It's about the long term.  In 6 months, you're going to have to explain what happened.  Be clear and concise.  And above all, remember, you don't know what you don't know.

Comments

Popular posts from this blog

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…