The Difference Between Knowledge and Belief

Every developer knows that unit tests are a good idea.
Most developers know that using version control is a good idea.
Some developers know that a "one-click" build is a good idea.

As you walk the aisles of the programming section at a bookstore, or browse the online equivalent you’ll see knowledge galore.  How-to, what-to, why-to out the wazoo.  With all this knowledge so readily available, why aren’t there more good or great developers?

The Big Swinging Developer is rarely judged by knowledge alone.  As always, you have to be at least "good", which involves knowing a thing or two, but it’s your beliefs that will set you apart from everyone else.  I happen to believe in isolating changes/problems, repeatable builds, and testing.  Because of these beliefs, I’ve learned a lot of techniques to help me practice them.

I’ve been working on a web app this Memorial Day weekend.  I’m a development team of one.  No one is watching me, checking up on me, or even working with me.  I have a one-click NAnt build that deploys to a Virtual Machine and have been branching my releases in my hosted Subversion repository. 

You practice your beliefs because you can’t imagine doing things any other way and that defines you as a developer more than any single technology or language ever can.  So, what do you believe?

What’s Your Battle Cry?

Clarity!

That’s my battle cry.

I have plenty of mantras: "Isolate changes", "Be repeatable", "Put yourself in the user’s shoes", and several others.  These are things that I believe, practice, and preach.  My battle cry, however, is something I actively pursue and defend.  If someone isn’t isolating their changes or is failing to think about their users, I’ll probably say something.  If someone is being unclear, I’ll definitely say something.

In Braveheart the battle cry was, "Freedom!".
In Viking Quest it was, "Victory!".
For me, it’s "Clarity!".

What’s yours?

Being Smart Isn’t Enough

On page 48 of Career Warfare, author David F. D’Alessandro mentions the statistic that eight million Americans have IQs over 130 and that this makes smart people "as common in organizational life as bad coffee".  Reading his thoughts on the subject reminded me of several ideas that keep recurring with my own co-workers.

Smart Isn’t Enough.  As D’Alessandro points out, smart people are pretty common.  Being smart is the cover charge and if you aren’t, then chances are you won’t get past the velvet rope.  Some clubs have a higher cover than others – Google, for example.  Once you’re inside, though, no one else who paid the cover charge is going to be impressed that you made it in.

Smart != Good.  Being smart gives you potential.  It’s how you use that potential that counts.  If you are absolutely brilliant and create something that kind of sucks, it does not matter how smart you are.  Stuff that sucks that was created by idiots is roughly equivalent to stuff that sucks that was created by geniuses.  As a matter of fact, I might even have a preference for the idiot version since it’ll probably be easier to figure out and fix.

Smart Is a Vector.   Most people focus on the magnitude portion of being smart and ignore the directional component.  What’s worse is that they often apply the magnitude to arbitrary directions.  Even worse than that is applying the magnitude to multiple directions simultaneously and start assuming that someone who is good at one thing will be good at a bunch of others simply by being "smart".  This is dangerous before the fact because it sets people up for failure.  It’s almost worst after the fact because it will be used to explain why something can’t be done, and therefore not even attempted: "Bob tried to create a distributed .NET app and screwed the pooch.  Bob created something similar in Java and it was awesome.  Bob’s very intelligent, therefore .NET sucks and can’t work correctly."  Oy vay.  How about "Bob sucks at .NET and, therefore, Bob should have either gone to a Java shop where he could flourish" OR "Bob should have spent a little more time getting smart in the .NET direction"?

You’re Never Too Smart to Be Wrong.  I think that the most important thing that you can do to reach your potential and put your intelligence to work is to know yourself.  Know what you’re good at and recognize when a task just isn’t for you.  Let it go to someone who is actually smart enough (magnitude) in that way (direction) to do a good job.  If the direction is something that you’re interested in, then pitch in so that you can learn something and take a bigger chunk of the work next time.  Don’t, however, believe that since you’re smart that you’re universally capable.  Don’t let others believe it, either, or you’re bound to wind up like Bob where no one can help/save you because they think (because they were repeatedly told) that you were too smart to be wrong.

Learn to Run a Meeting

"Plan your work, work your plan"

In the last post I talked about attending meetings.  The flip side to that is running a meeting.  Sometimes you’ll go to a meeting and it turns out to be a waste of time.  Minimizing that is an admirable goal, but you can’t always tell if it’s going to be a waste until it’s almost over.  There should be no reason, however, to call a meeting that turns out to be a waste of time.  If you call the meeting, you need to run the meeting.

Running a meeting well starts in advance of the actual meeting.  You need to know what you want to get out of the gathering and then put a plan together that can get you there.  The short version is Goal + Plan = Agenda.  If you don’t have an agenda, you are overlooking one or both of its parts.

Next is the attendee list.  With agenda in hand, this should be a breeze: it’s the list of people who need to approve of or execute your plan.  As you look at each attendee on the list, you should know what it is you want them to do post-meeting.  This should then be conveyed and committed to during the meeting.  If you don’t know what you want someone to do post-meeting, then (once again) you’re lacking clarity in either your goal or your plan . . . or that person doesn’t need to be invited.

Now that the "plan your work" phase is over, the next part is easy: "work your plan".  The actual meeting should be a breeze: work your way through the agenda, record any newly revealed information, ensure that everyone is clear on what’s next, and get commitment on all of the planned tasks.  Keeping things on track is a lot easier when everyone knows where the track is.

If I had to guess, I’d say that anyone reading this has been to the type of meeting I’ve just described.  I’d also guess that it represents a small percentage of the meetings you’ve attended.  Further, you probably didn’t walk out of one of these thinking, "Wow, that was a great meeting!".  Instead, you most likely forgot about it because it seemed to be a logical extension of your work.  Contrast that to the "other" meetings – the ones the represent the majority that you’ve attended.  There’s a good chance that you walked out thinking, "That was a waste of time".

Don’t be the one who wastes other’s time.  Plan your work and work your plan or, as a very real but seldom used option, don’t call a meeting.