A rant on programmers who can’t program

I came across this post today and wasn’t sure what to make of it.  In my current job and my previous one, interviewing potential hires for programming was part of my job.  I can’t say I ever used “FizzBuzz” types of questions on candidates, and I’m not sure that would tell me the sort of things I need to know about someone.  I find myself asking a lot more design questions and process questions with perhaps one or two programming questions thrown in.  But before even getting to that stage, I have to feel good about their resume.  I think the majority of people give you enough information in their resume that you can figure out whether a phone screen is worthwhile in a relatively short period of time.

What Makes a Good Software Developer?

TSS.NET posed this question in one of their newsgroups on March 1.  Here are the comments I added to the thread:

They only write what they need to. They tend to choose open source libraries and components for needed functionality instead of writing things themselves. They definitely don’t replicate functionality already provided by whatever platform they’re coding against (whether it’s .NET or Java).
A companion characteristic is that they’re good integrators. Because they use third-party components to develop solutions, they’re skilled at making them play well with each other.
They’re good at refactoring. The first version of any application is always the worst one. A good software developer refines and otherwise improves their code as they go along.
The companion characteristic to refactoring is unit testing. No developer can consider themselves good unless this practice is part of their everyday work. A robust set of unit tests is the first line of defense when it comes to high-quality code.

This was what I came up with off the top of my head.  I’d be curious to hear opinions from others (yes, all three of my loyal readers) on what makes a good software developer.

The Honest Boss

Some friends of mine on a mailing list I belong to are having an interesting dialogue on ways to deal with co-workers when they make mistakes.  One of the list members posted a link to the interview with an honest boss e-card from Hallmark.  Mostly, it’s good for a laugh.  But what the “honest boss” says about promotions is a bit too true to be funny.

10 Years

I was in the middle of writing my self-evaluation for work (review time is coming up) when I realized that the end of 2006 marked my 10th year of working full-time in software development.

Goodbye 2006, Hello 2007

First, to my readers (all three of you), I hope that 2006 treated you well and that 2007 is even better.

2006 treated me pretty well as years go. I actually kept the “get in better shape” resolution I made last year by joining these guys. There’s 25 pounds less of me right now than there was at this time last year. I took up a new hobby (skiing). I bought a new car. I also got to do some traveling (Killington, VT for skiing and San Francisco, CA for vacation). I learned enough of a new programming language (Ruby) to try a startup idea with Sandro. A few months ago, I got a new job (and a nice raise as a result).

I haven’t made any resolutions for 2007 (outside of “get in better shape”). I’ve been seeing more of these “101 things in 1001 days” lists (like this one and this one) lately. While I don’t think I’m nearly as ambitious as my friends, there are some things I’ve been thinking about doing that would be good to attempt this year:

  • Learn a new programming language. One of the consultants that works for me has had a lot of good things to say about Eiffel. So far, I’ve installed the development environment, read a bit of documentation, and written a bit of sample code. There’s a small product idea I’d like to try, and I plan to use Eiffel to do it.
  • Incorporate. My friend Richard has been encouraging me to do this for years now, instead of being a regular employee for some company. He’s been working for himself as long as I’ve known him (at least 12 years now) and has done very well. So far, I’ve bought a couple of domain names and done enough budgeting to determine what my hourly rate should be if I were to go into IT consulting.
  • Re-learn the piano. I was good enough at it when I was younger that my last piano teacher wanted me to go to school at the Peabody Institute. Spending the past couple of years as a sound engineer for one of the services at my church just made me miss being able to play even more. Since I can still read music, I need to do something more with it.
  • Study the Bible more regularly. Some years ago, I took a Disciple Bible Study class at my church. We covered 75-80% of the Bible over the course of a year. It was a very spirtually-rewarding experience. I want to get (and keep) my life in enough balance that I can make some Bible study a part of each day.
  • Take a two-week vacation. 2005 was the first year I’d taken more than a week off in a row since my undergraduate days (back in the mid 90s). I took a bus tour through western Europe for nearly two weeks with my dad (and about 50 other people) and had an excellent time. It really helped me disconnect from work concerns, and I’m positive I’ll need to do that again this year.

SQL Injection

It’s one thing to know that SQL injection is bad, and quite another to have some stats to back it up.  I came across a Michael Sutton blog post on the topic via Joel Spolsky‘s latest blog post.

Out of 708 sites checked, 80 had potential vulnerabilities to SQL injection attacks.  Beyond the importance of the topic as a security hole, the most interesting thing about Sutton’s article was the tool he built to come up with these stats.  He used a C# app with the Google API to get his results.  I only wish I had time to build a tool that clever and useful.

Leaving Lockheed Martin

I’ve left to join APS Healthcare as a manager of software development. My last day at Lockheed Martin was September 20.

In nearly two years at Lockheed Martin (and Aspen Systems prior to its buyout) as a combination project manager, systems analyst, and lead developer, I learned many different lessons about myself–some painful, some not.

The necessity of diplomacy

When I first arrived at Aspen Systems, I was blunt in discussing areas I felt needed improvement (code quality, process, etc). Because I wasn’t always diplomatic in the way I talked about what I saw, some people responsible for the work took offense. It was irrelevant that I was describing standard industry best practices. Co-workers who were offended became far more difficult to work with. Being more diplomatic would have made life easier.

The importance of corporate culture

My experience at Aspen Systems led me to conclude that corporate culture is as important as profitability. It affects the quality of work, the caliber of employees, how co-workers treat each other, how management treats staff, and employee retention. I had a lot of disagreements with how things worked in all of these areas (which is probably why I only lasted two years in a company that had an average tenure of seven years). Two other people who joined Aspen after I did ended up leaving before I did. Corporate culture played a role in their departures too.

Project management is really personality management

I didn’t manage difficult personalities very well on my projects. To succeed at project management, it’s vital to have that ability. Being able to put together realistic work breakdown structures, project plans, and budgets is important–and I did all those things well–but being more able to persuade others to do certain tasks would have made my job much easier. When the people assigned to your project(s) don’t actually report to you, persuasion is the only tool you have. Being more diplomatic would have helped me. Beyond that however, the role of project manager needed far more support from the organization than it received.

While the skills are useful, project management is not something I’ll take on as a full-time role in the future. I’m better at other things.