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.

This was not decadence: Quote of the Week

Ahh, Joel.  You are a unending fountain of good quotes!

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1.

Joel Spolsky
http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

I think this quote brings out two interesting points that are a little bit at odds with each other.

1) The rest of the company lives to serve the programmer’s needs so that he can put out a good product.

AND

2) The programmer cannot exist in a vacuum and needs the rest of the company to support him or it doesn’t matter what kind of product he puts out.

So how to reconcile these two points?  Well, it comes when both sides recognize each other’s roles.  Each had different and important roles in the success of a software company.  I think the important point though is that in the scenario presented by Joel is that everyone is working together on the software, to improve the software, to give the programmers the tools and information that they need to create a delightful experience for the end user.