Good Grief Charlie Brown

If you are familiar at all with the Peanuts comic strip, you’ve seen this frame in various forms over and over again…

This situation was described aptly in The West Wing episode “The Drop In”:

"You are the Charlie Brown of missile defense. The Pentagon is Lucy." When Leo says he doesn't read the comics, the President explains, "Charlie Brown wanted to kick a football and Lucy would hold it except that she'd pull it away at the last minute and Charlie Brown would fall on his butt. . . . Each time Lucy would find a way to convince Charlie Brown that this time she wouldn't pull the ball away, but she would and once again Charlie Brown would fall on his butt." As the President predicted, Leo's high hopes are dashed, and the President tells him, "By the way, the words you're looking for are, 'Oh, Good Grief.'"

(summary provided by http://westwing.bewarne.com/second/34dropin.html)

So is Charlie Brown right to continue to trust Lucy or is he unable to learn from his mistakes?

A friend recently posted Cynicism & Professionalism which this is a kinda sorta response to.  Here is a partial quote of my comment that I posted there:

But I think it's always useful to keep in mind that most people are mostly trying to do the right thing most of the time.
Whether or not people's intent and their results end up in the same place or not, well that's another story (says the cynic ;) )

While “past performance is not an indicator of future results”, I think that we are unwise to ignore past experiences in formulating our response to the future.  Forgiveness is important.  Giving someone the benefit of the doubt is important.  Trusting that people’s intent is generally good is important.  But the lesson I get from Charlie Brown and Lucy is "Those who cannot remember the past are condemned to repeat it."

Sometimes you need to leave Lucy there holding the ball so that you’re not left saying “Oh, Good Grief.”

Programmers’ Mecca

Other than big sites like Microsoft and Google, this has to be the ultimate programmers’ Mecca…

 

(note: if you’re in a feed reader, you might need to go to the site to see the video)

Wipe the drool… and control the envy…

Failure

Sometimes failure is the path to success…

Do you understand the words that are coming out of my mouth?

Often when discussing a disagreement, the two (or more) parties involved will stop communicating.  The natural reaction of most people is to start to defend their position vigorously while ignoring anything the the others are saying.

This frustrates me to no end.

The common case is that both sides have valid points to be made and that usually, if both parties are really communicating (read: listening) and intelligent, one side will either realize that they are in error or both will adjust their positions to another better common position.  I have had numerous occasions when I have been arguing a point and finally started listening and realized that there was a way to get to “win-win” that wasn’t even on the table originally.

If you understand my position and reject it, I’m happy to “agree to disagree”.  But before we get there, we’re both going to need to get to a point where we understand the words that are coming out of each other’s mouths.

“I don’t have enough time”

Recently the Utah .NET User Group had a roundtable discussion where anybody could ask or answer any relevant question.  At one point the conversation drifted to “why aren’t there more people here” which is a valid point given that there were about 30 of us and there are certainly more .NET developers out there along the Wasatch Front than 30.  One would also think with the economy and job market as it is, that people would jump at the opportunity to get some free trainig either because they had lost their job or were worried about it.  There were various theories proposed but they were mostly based on the group speculating on others motivations which at a certain point became a somewhat futile exercise.

So in the next development meeting at my work, I through out the question, “why do you not go to the once a month user group meeting?” to find out what those .NET developers that weren’t coming thought.  I was a little bit disappointed that the common answer was “I don’t have enough time.”

Why was I disappointed?  Because this answer is a cop out.  Consider these questions:

• Why don’t you exercise? I don’t have enough time.
• Why don’t you read (more) technical books? I don’t have enough time.
• Why don’t you watch more movies?  I don’t have enough time.
• Why don’t you play more video games?  I don’t have enough time.

So why is “I don’t have enough time” a cop out?  Because what it really means is “I refuse to prioritize that high enough to do it” or “I’d rather be doing something else.”  And even that is not good enough, I think.  I think, for you individually you have to use the five whys technique.

Of the above list, those are all things that I’d like to do.  Recently (almost three months ago) I decided to prioritize exercise and have been getting up early to do it.  It’s something that I’ve known that I needed to do for some time but “I didn’t have the time.”  Which really meant that I 1) valued extra sleep over exercise, 2) valued staying up playing games over exercise and 3) valued all the other things I was doing in life over exercise. 

Now is that strictly true?  Did I really value video/computer games over exercise?  If you were to ask me a year ago, I probably would have said “exercise is more important that Civ IV” but my actions betrayed me.

So should I look down at my fellow developers that don’t attend the user group meetings?  No, I don’t think so.  If they have found other ways to develop their skills and forward their careers, that’s great.  There are many activities out there that will give you a lot of value.  If they don’t care and have other things that are more important in their lives, that’s great.  But if they think it’s important (and specifically more important than some of the other things that they’re doing), then they need to get their actions in line with their priorities.

When people lack good information: Quote of the Week

Wow, this one hit my like a ton of bricks.

When people lack good information, they will invent some information themselves. When they don't know how well their project is doing, they will try to guess. When they don't know how other teams are performing, they will make assumptions. When they don't understand what their colleagues contribute to the organization, they will invent their own reasons. And when they don't know about their manager's personal life, they will gossip about it.

To prevent bad information from flowing through the organization you have to give people good information.

Jurgen Appelo
http://www.noop.nl/2009/03/great-managers-have-no-secrets.html

Jurgen’s blog has been a fixture in my RSS reader for quite some time and I’ve shared many of his posts in the past.  He has a knack for speaking coherently to issues that are very relevant to my situation.

As for the point he’s making here, I don’t think that, in most cases, information is “maliciously” withheld.  I do think some managers believe that certain information will just distract their employees and so they withhold it.  This tends to lead towards a vicious cycle where the employees are worried about the lack of information (and then the subsequent assumptions) which therefore makes the managers more concerned about distractions and therefore less willing to share information.

As developers we’re all about quick feedback.  We want quick compile times so that we can immediately know if we’ve broken something.  Unit tests give us additional feedback.  One of the reasons ReSharper is such a valuable tool is that it gives you information on potential problems quickly.  I want more information because it gives me a better sense of the overall context in which to make decisions about my code.

Quoting a quote from the post, “The concept is that the more employees know, and understand, the more they will partner and support the company's mission and goals.”  This is brilliant and yet at the same time very obvious!  The corollary is “only when employees care about financial figures, they will think of ways how to improve them.”  If managers don’t share information that gives employees feedback on their actions (how their actions impact the financial health of the company in the above example), then there will be no way that they will be able to effectively change things to improve without stumbling around in the dark.

No information leads to speculation and gossip which leads to incorrect information which is a poor substitute for correct information.  As Jurgen points out, the only way to clean out the system is to flush it with so much correct information that there is no room for speculation.

How many do you think?: Quote of the Week

I found this via one of my co-worker’s shared items.  It’s a variation on a theme that is oft repeated in the software development world.

I heard once that in Great Britain's MOD if you design software for a plane you go up in the test plane when the software is beta-tested. If all programmers were held with that level of accountability, how many do you think would still be in our field? How many would you want to collaborate with before you went up in the plane together?

Jay Fields
http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html

The problem is that not all software is equally critical (which the author does point out).  When asked what the right amount of process is, one of my college professors was fond of saying, “it depends”.  The right amount of process in situation A does not translate to the right amount of process across the board.  I would argue that the same is true for quality of developers working on a project.  This is not to say that it wouldn’t be great if every person writing software was awesome at what they did, but the reality is that there is more software to be written out there than there are great developers to write it.

So where does that leave us?  I think part of it is taking the good devs and making them great devs.  In Joel Spolsky’s Smart and Gets Things Done, he puts developers in three buckets, 1) Great developer, 2) Needs specific improvements and 3) Hopeless.  If you’re in management, culling out the “hopeless” is very important to team morale although I think that those cases are few and far between.  I think the great majority of developers are in the “specific improvements” bucket.  Getting your co-workers from group 2 to group 1 should be one of your highest priorities if you are any sort of management/leadership role.  Most “great developers” would probably put themselves in bucket 2, but the differentiator, for me, is that they are seeking out and working on those specific improvements themselves.  Inspiring those around you (not pointing the finger at those around you) is the way to improve the state of development no matter your situation.

Of course, if you’re surrounded by the “hopeless” it might be time for a change of scenery.  This advice might not be practical in the current economy, but remember if you can’t change your company, it might be time to change your company.