Actions Speak Louder Than Code
It took me a while, but I finally settled into my routine and got to where I’m reading my RSS feeds most days again. I was going through the posts of the past month or so, since the job change, and ran across this article on the “Making Good Software” blog about things that keep someone from being a good software engineer, outside of (and often in spite of) an ability to engineer software.
I’ll summarize here. It isn’t my intent to plagiarize; if you are remotely interested go read the article. Here are the things:
- Lack of discipline
- Big ego
- Poor communication
- Forgetting the customer
- Lack of proper work prioritization
I have known many of these people during my career. Indeed, I was one of them. I remember coming to Novell from IBM almost ten years ago. I thought I was pretty hot stuff and I made sure my team knew it. In fact, I actually said (this is embarrassing to admit) on more than one occasion, “There are people who know C++ better than I do, but I haven’t met any of them.” My ego surely made me hard to work with. It definitely was a cause of friction between myself and my management chain, and ended up being a (deserved) source of frustration and difficulty for me, until I recognized the problem and started working to address it.
I’m pretty ashamed of having behaved that way back then. I hope I’m better than that today. I guess recognizing the weakness is a good first step. Fortunately for me, back then I was on a really great team with a lot of very capable, patient, and talented engineers that waited for me to learn from my mistakes and to grant them the mutual respect they deserved. I consider myself pretty fortunate to have been able to learn from them what real software engineering is about.
Over my career I’ve had to work with people like this from time to time, software engineers that manifest one or more of these traits. Sometimes these guys are pretty talented technically. I’ve felt sorry for them as I’ve observed, realizing that these weaknesses are going to hold their career back until they recognize them and work to overcome them. No amount of programming prowess will compensate for it. And what’s even worse is, often because these people have the personality issues they have, you don’t get anywhere by trying to bring these weaknesses to their attention; they are often unreceptive to this type of feedback. Like I said, you just have to wait until they recognize it themselves.
I can imagine being in a performance review with someone like this, having them explain to me all the technical awesome they did, and me replying, “Your poor soft skills are shouting so loudly that I cannot hear your technical awesomeness.” Or, as I said in the title, actions speak louder than code.
I really believe this is true. To write software professionally, of course you must have technical ability; however, this is a necessary but not sufficient condition for greatness. The best software engineers I’ve had the fortune to work with in my career, past and present, not only had awesome technical ability but did not exhibit weakness in these areas. And I’ll tell you what: Those teams are wonderful teams to be a part of. Those teams create strong. uplifting work environments and are able to deliver great products that meet customer demand.
Another way to say this is, in order to be a good software engineer, you must first be a good employee.
In fact, I’ll tell you how important I think this is. The ability to mitigate or eliminate these defects from a software engineer’s persona is so important to me that, if I had my own company and were making the hiring decisions, I would not hire a candidate that I knew had these problems, no matter how incredible their technical ability.
A person with these weaknesses is really only suited to be set to the side to work on a special side R&D project where interaction with other employees is limited, and they don’t have to interact with customers at all. Problem is, those kind of projects are either a) strategically important to the long-term future of the company, or b) of little to no real value, or c) a combination, often high potential value but with a lot of inherent risk that causes the real value to be low. If the project is strategically important or of high value, do you really want to reward the biggest jerk in your company by giving him the highest profile assignment, leaving your best engineers to maintain the legacy project? Wouldn’t you want to have someone working on that high profile assignment that knows how to collaborate with others and assemble all the best ideas to solve the problem the best way, even if that solution isn’t his/her own? Contrariwise, if the project is of little real value or has so much risk that it offsets the real value, why even do it at all?
Nope. In my company, if I were ever to have one, I wouldn’t hire or keep an employee who had these weaknesses and was not committed to addressing them. I’ve seen the difference, both in morale and productivity, between teams where they don’t have these problems and teams that do.
