How to thrive as a developer among nondevelopers
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.
Help your boss understand
When you are a developer among nondevelopers, it's likely that your manager does not have a development background. Nor does he or she have many other developers to compare you to (if any). For the sake of your career and your professional development, you'll need to help your manager understand how to manage a developer. I recommend the following strategies.
Talk with your manager about your performance objectives
Your job is, of course, different from that of the other people on your team. When you set performance objectives with your manager, make sure that they reflect your development responsibilities.
Sign up for relevant training
When planning for training, be sure that you get the opportunity to get training related to your development. For me, that meant that most of my teammates went to one type of training class while I went to completely different ones.
Spell out what you accomplished and the impact of the application
Some managers don’t recognize the significance of that one big application you wrote. They may say, “Well, you got one thing done during the review period.” Help them see the benefits of the applications you write, how the applications relate to the team objectives, and how they meet your objectives.
Keep focused on your career growth
With any job, you need to take personal responsibility for your career growth. But when you're the only developer in a nondevelopment group, you need to pay particular attention to your career and your job satisfaction. Keep the following in mind.
Don't get pigeonholed
If you get labeled as “the developer,” you may have a problem getting others to recognize you for more than just your development skills. Keep tabs on nondevelopment opportunities to expand your skills and continue to strengthen your position in the organization.
Do a career assessment
Routinely (once a year or more) perform a career check to see if your current position is taking you where you want to be professionally. If the position isn't meeting your developer career goals, you may want to think about other opportunities. To help assess your career, ask yourself the following:
- Am I getting enough development projects that challenge me and allow me to grow?
- What are the prospects of new projects in the near future?
- Am I being pigeonholed or do I have long-term growth opportunities?
Build your position
Since you're the only developer, you can define how a developer should work on your team. This not only helps you secure your position, but it also helps your organization: If another developer is hired, the position will be well defined.
Develop external professional relationships
External relationships will allow you to develop your skills through associating with other developers. Also, you'll have a network to rely on if you need a change in your career.
Conclusion
Being a developer among nondevelopers is a challenging situation. You have the opportunity to make significant contributions to the organization thanks to your skills. Properly handled, a career as a lone wolf can be highly rewarding.