Skip to content

An entirely unscientific look at why people attend conferences.

Dear Reader,

Those of you who follow me on twitter (@calevans) know that recently I asked for opinions on conference attendance. I’ve collected what I learned in this blog post.

Who I asked


First I asked my friends who were speakers why they attended. I got a lot of good answers but most were variations of “…because someone else picks up the tab.” :) (It should be noted that of the speakers I asked, only one was a professional speaker who collects a fee and even he attends some conferences just because they are fun)

Respect Redux

Dear Reader,

Thanks to my friend Alison for pointing out this article,The unspoken truth about managing geeks. This is a must read for everyone who manages IT professionals. From Manager, to Director, to the VP and C-Level, if you have IT professionals below you on your company’s org chart you owe it to yourself and your developers to read this article.


One of the first points the author makes is that developers want respect.

for IT groups respect is the currency of the realm.

This is one of my favorite quotes in the article because it is so true. It’s also true that many in management don’t understand this and that’s sad. I wrote about respect back in 2006 in the blog post “It’s all about respect” and the fact that management can’t seem to understand this fact led me to write “Leadership in Software Development“, which encourages developers to step up into management so that the next generation of developers can have managers that understand this.

Jeff Ello, the author of “The unspoken truth about managing geeks” touches on several points that strike so close to home that I wonder if he’s not been watching the same things I have lately.

Just because you don’t like what is being said, doesn’t mean the other person is whining

Other than respect, I think the next most important take away from this article is made on the second page in the section about “victim mentality”.

IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event.

I’ve personally seen several scenarios play out recently that can be directly attributed to this behavior. In all cases, the “management” attributed disagreement from a developer as whining and ego when in fact things were going on that were not logical and therefore someone said something. What was said, was said in a “manner of fact” way and taken wrong because the person it was said to failed to realize the point of view of the speaker. (I’m being vague here on purpose)

I love Jeff’s call to action to help resolve some of the communication issues:

“Periodically, bring a few key IT brains to the boardroom to observe the problems of the organization at large, even about things outside of the IT world, if only to make use of their exquisitely refined BS detectors.”

To paraphrase, when your developers are complaining, don’t call them whiners or write it off to ego, look past the surface complaint and find out what the problem is. Chances are, there’s a real problem there and managers ignore it at their own risk. This is closely related to one of the points I bring out in “Open Teams”, transparency. Talking to your developers, listening to them and sharing both the good news and bad news will let you tap the brain trust you have built in your IT department to solve the problems that are facing your company.

I’m encouraged that others are saying these things now but still a bit depressed because even though others are saying these things, the people that need to read them, aren’t.

Until next time,
I <3 |<

A Challenge to IT Companies

Dear Reader,
[Note: This blog post should in no way reflect poorly on my current employer. I love my job and am not talking about any one company in particular but about IT companies in general.]

The Problem

Something has been bugging me for a while now. I’ve been a member of more IT companies than I care to remember. Outside of cube farms, one thing seems to remain constant throughout, a contract that was written in the 1800s. Most (not all) of the employment contracts I have been handed to sign have contained a clause that states something to the effect:

While you are working for us, if you invent something we like, we can claim ownership of it.


Remote Developers

Dear Reader,

This conversation takes place via email at least once a week for me

Headhunter: “I am looking for the best PHP programmer available. Do you know anyone?”
Me: “Yes, I know someone right now who is looking around and is awesome; however, they are not looking to relocate. Are you willing to consider a remote worker?”
Headhunter: “no.”
Me: “Sorry, your loss.”


Leadership In Software Development

Dear Reader,

[Editor’s Note: This is an editorial that was originally published on Freshmeat back in 2000. As I’m cleaning up my content, it stuck me that I had never published this here.]

Me to the everybody: “Hi, my name is Cal… and I’m… I’m a manager.”
Everybody: Hi, Cal!

I am a developer who made the conscious decision to move into management. My training, my experience, and my love has always been developing software. I’ve worked under sales managers, business managers, and (shudder) a CTO who believed that all the good software had already been written so we didn’t need to write anything; we could just buy everything we needed. I made the leap into management for one reason: I had a manager who “got it” and showed me by example that developers can make great bosses for other developers. (Thanks, Paul M.!)

During my career as a developer, I learned many different things but the one thing that has stuck with me is this axiom:

“If you have never been a software developer, you have no business managing software developers.”

There, I’ve done it again. At least one third of you are now mad at me. But regardless of your feelings towards me, I stand by my statement because, time and again, whether through personal experience of 24 years or war stories from others, it has survived.

Before you fire up mutt and flame me, let me be quick to point out that I do not believe that this maxim is universally applicable to all situations or walks of life. I am not belittling any person or occupation, but I believe that, in most cases, we as humans, co-workers, and professional colleagues have enough shared experience to be able to relate to each other. I do not believe that this maxim applies to the sexes or to races. However, there are a few areas where it does apply, and the one I know most about is software development. Here are three different thoughts on why I believe this is true, what I believe has caused the current crisis, and what I think we can do about it:

The Balancing Act — Why we are here.

There are very few professions that combine the creativity involved in good software development and the rigorous deadlines, often imposed from the outside. Hurry up and create! The ideas have to keep flowing, they have to be scheduled, and they have to be completed on time. If you have to go figure something out, go. But make sure you are back after lunch and make sure your schedule doesn’t slip. Developers, especially now as we work in Web years, are under increasing pressure to “Get it out the door fast!”.

The rigorous detail work of quality software development, however, has not changed. It still takes time to develop quality software. (You can have it good, fast, or cheap; please pick two.) To those on the outside, it may sometimes seem that what we do is easy. (Heck, we may feel that what we do is easy!) The ease with which developers manipulate the tools of the trade is often misconstrued as ease with which the task can be completed. Only a developer understands the countless hours it takes to master new tools, new languages, and new concepts. In this age of rapid development, new concepts come at us like a fire hose of knowledge. We are supposed to know how to soak it all up and be able to use it in our next project. This is almost a bearable burden if management understands what we are faced with. The problem is that, having never been there, most managers cannot empathize. (And most don’t even bother to sympathize.)

The Boss From Beyond — What has caused the current crisis.

It’s generally accepted folklore in the IT community that managers are managers because they can’t do anything else. What has led us to this state, a climate in which developers don’t respect their managers and managers try to manage a software development team like an accounting department? Volumes have been written on when and why people are promoted into positions they are not qualified to hold. I won’t rehash that here. I have a different take on it.

The question we ask should not be “Why don’t managers understand software development?”; the question should be “Why don’t those of us who do understand the process step up to management?” The obvious answer is that there are very few developers who want to be managers.

In the past, developers would have to turn away from promotions to management (and sometimes raises) so they could remain in development. These days, they find other companies to work for that will pay them more and allow them to continue to develop (but that’s a story for another day). The problem exacerbates itself. The more developers steer clear of management positions, the unhappier software development teams will be with the candidates that become their managers.

We, the IT community, have the bosses we have because we refuse to step up to the plate and take the job. I am not advocating that all developers climb the management ladder; far from it. In most cases, a developer pressed into service as a manager will do no better a job than an accountant forced to code. But until the development community learns to train its own management structure, we are doomed to be managed by PHBs.

Managing In Chaos — What can we do about it?

So now we are all on the same Merry-Go-Round from hell. What can we do to get off? At least part of the answer is obvious. We, as a community, have to train our own managers. For me as a manager, that means that as I interview candidates for development positions, I have to keep my eyes open for potential managers. I have to make sure that I mentor as I was mentored. I have to realize that if I don’t train new development managers, I’m as big a part of the problem as non-development managers.

For me as a developer, and all other developers reading this, we have to make sure that we educate our managers.

We have to teach them concepts like:

  • Deadlines cannot be set from the outside without input from the development team they are being imposed on.
  • Sometimes, it just doesn’t come to you and you can’t force it.
  • You can’t run most modern IDEs on crap hardware!

I’ve found that, in many cases, they can learn. They want to learn. They are PHBs because they’ve never been taught not to be. There are some that won’t learn or, worse yet, think you have a lot to learn about business. If you are under one of these and you work in America, change jobs! Life’s too short and the job market is too tight to deal with goobers like that.

To fix the present situation, we, as developers, have to make one of two choices. We can take a stand at our present jobs and educate upper management so that we don’t work for PHBs, or we can find other jobs. But make no mistake about it; it is ultimately up to us to fix the problem.

Until next time,