Developer among nondevelopers
Published: 11 Jul 2002 14:42 BST
When I graduated from college several years ago, I imagined that I would be part of a small, dedicated development team that would pull together to tackle a mission-critical project against difficult odds. Reality couldn't have been much different. I ended up being a team of one, working as a developer on a team of nontechnical business-side staff members.
Being a developer among nondevelopers can be difficult. First, you lose the opportunity to share ideas and brainstorm solutions. Second, you have to motivate yourself to write "nice" code. Third, you may get labeled as "the developer" and wind up with more development projects than you can deal with. Let's look at how lone wolf developers can stay sharp and grow professionally.
Be your own code reviewer
I once had the opportunity to look at the code written by a friend who was another lone developer. Reading his code was a chore. The code had no consistent style, poor structure, and no internal documentation. I asked him why he wrote that way, since I knew he was a practiced developer who understood good technique. His answer was that no one else would see the code, so why worry?
If you're the only developer around, this is an easy trap to fall into. But we all know that jobs change, organizations change, and sometimes code that only one person ever worked on suddenly ends up on someone else's desk. With that in mind, let's look at a few tips on how to be your own code reviewer.
Find yourself a coding style
Many development groups have detailed coding guidelines that outline commenting, variable declaration, function declaration, and indenting. Even if you are the only developer within miles in your organization, develop your personal developer guidelines. Who knows, the group you work for may hire another developer someday.
Develop a code library
Creating a code library may sound like a given, but sometimes a developer working alone overlooks effort-saving methods used by larger development groups. A code library is easy to maintain as a lone developer, but don't forget to document it well.
Do your code review
Take the time to review the application you just finished. Look for what you could have done better and make sure that you followed your style guidelines.
Bridging the developer-nondeveloper gap
I found that one of the most annoying aspects of living among nondevelopers was the phrase, "Let's get Bruce to write a program to do..." Team members often assumed that I had the technical expertise to write an application for anything. On the flipside, it bothered me to see them wade through routine tasks that a macro could handle. The solution to this problem was to cross the developer-nondeveloper divide. Here are a few pointers based on what I learned while fixing this communication gap:
- Do a little teaching. Although I was the only programmer, some members of the team did have technical aptitude, so I could teach them how certain macros could handle some of the repetitive tasks. They picked up a little programming, and I made my life a little easier.
- Be honest. Don't automatically agree to do everything and be honest about your time and abilities.
- Don't be arrogant. Yes, you have a unique skill on the team, but don't rub it in everyone's face. By teaching and helping solve problems, you can become a respected and valued team member.
Previous
Did you find this article useful?
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
