Routines of a good developer

A reflection on the routines I believe make me a good developer and look for in developers around me.

Posted in Main Thread on December 17, 2009

I have been on contract for the past 15 months, but it is time to move on. So I search for jobs. Submitting my resume. Going to interviews. Competing. Given the current economy, I wondered if it might be difficult. However, I wasn’t really concerned.

Why not?

First, the technical industry runs its own course, potentially immune to economic trends. That is to say technology, in some fashion, is always in demand. Whether I must become a Java developer, web developer, or iPhone developer, development work exists for me.

Second, from past experience, I’ve been fortunate in finding work. I’ve been told I “interview well” and possess a “solid skill set”. Furthermore, I noticed that regardless of title I don’t see this in developers around me. Now I live and work in Louisville, Kentucky. So admittedly this isn’t a technology mecca. Nonetheless, I do consider myself a good developer. I believe two underlying qualities keep me ahead of the rest.

A good developer learns

This can be summarized in the quote, “If your only tool is a hammer, everything looks like a nail”. Very few things are built purely using a single tool. So although it’s great that you know every Java Class by heart, it doesn’t help for iPhone Development. You need more tools in your toolkit. Although knowledge transference can save the day, a good developer will tinker with other technologies and at least become familiar. In doing so, they can call upon this knowledge when presented with something different.

In practice, I make an effort to visit technical blogs weekly, read one technical book a quarter, and learn one new language a year. If budget and timing align, I also attend a conference. This may sound like a lot or a little. Yet it’s a small investment for the dividends it will pay.

A good developer is passionately engaged

There are a lot of developer stereotypes. One of the largest being anti-social behavior. As much as we may want to code undisturbed, in the dark, with the soft glow of our screens, that won’t do. I worked alongside a very bright developer that could rock out a Perl script without even looking up from the keyboard. I worked with other developers that sat through a requirements meeting, then went off and developed their own. That’s not good. A good developer is engaged. They want to know more about the project. They must know more, because they care to do it right.

In practice, I ask questions in meetings and provide alternate solutions. No assumptions. Sometimes this doesn’t win me any points. But, I have yet to see where this failed to help. In addition, when I hit that “coders-wall”, I get up. I go talk with my co-developers. Most of the time, it gets me past my wall. Even if not, I am socializing. To me, this lends to a healthy, arguably more productive, development environment.

Be a good developer

A developer with these two qualities is a good developer. They possess the fundamental elements to continually forge ahead using any technology while collaborating with those around them. In the proper environments, a good developer could become a rockstar – being that key piece to success.

Find this interesting? Continue the conversation on Twitter or in a comment.

Need more? Let's team up!

Schedule 1-on-1 coaching or hire me for your project.


comments powered by Disqus