Based on a recent web article, I’ve started to compile a few thoughts of my own and a few thoughts of others on being a developer amongst non-developers. Typically, this often means anyone working for a small company that is not in the IT industry, but I’m sure a few of you might be able to relate these points to your working environment, whatever that may be, too.
From the beginning of next month, I will have been working for my current employer for two years.
As some of you may be aware, it has been a rather bumpy ride. Today, however, I am happily looking forward to a new challenge that does not involve me directly in programming. Coming from a programming background, this may seem a strange career move. It’s not. It’s more of a natural change that has occurred within me personally over the last two years.
From the beginning of next month, I will have been working for my current employer for two years.
As some of you may be aware, it has been a rather bumpy ride. Today, however, I am happily looking forward to a new challenge that does not involve me directly in programming. Coming from a programming background, this may seem a strange career move. It’s not. It’s more of a natural change that has occurred within me personally over the last two years.
Looking back over my two years, however, I’ve been looking at the reasons behind why I may have become disheartened with being a lone developer and why I have opted for a career change. It may have been in me all along that I wasn’t cut out to be a developer, or it may have been a hundred different reasons – but the key factor I believe to have affected me the most was being a lone developer amongst an office full of non-developers.
Being a lone developer in an office full of non-programmers, suits, marketing-droids and sales staff can be very difficult. If done right, however, it can be a very rewarding experience. Looking back over my experience, here are just a few of my thoughts and suggestions on how to get the most out of being a lone wolf. I hope some of these observations will be of some value for you lone developers out there.
Communicating with non-developers
Working in a small organization presented a number of problems where answers were often available, but the answers were often in the form of expensive proprietary software. This scenario was more often than no evident in our accounting department where data manipulation and mangling was core to every day business.
It became obvious after a short time at the company that the answer to every problem was “We’ll get Wil to write a quick program that does …”. Now, don’t get me wrong. I loved these kinds of little challenges and I thrived on them, but I was a Perl programmer. Other team members often forgot about the Perl bit in front of my ‘title’ and assumed that I had the expertise to develop or program anything in as little time as they took to make a cup of coffee. As far as some were concerned, I could even program our toaster to make the coffee.
Of course, on the positive side, there were problems that I could solve and I did make a difference in reducing the daily workload of some members of my team. This was always a rewarding experience, and one that was usually greeted with some amazement from a few co-workers.
Now to bridge this inconsistent and often miss-understood gap, I found out that my best weapon was to educate them. I sat down with a number of small groups within the office and educated them about my skills as a Perl programmer, what I could do, what I couldn’t do and how much work patching a typical program entailed. Honesty is key here. When I first joined the company I insisted on taking on every job I could find, which later turned out in disappointment to people when I couldn’t solve their problems or I was spending way too much of my time getting the toaster to make coffee that my actual work was slipping way behind schedule.
Some members of my team did have technical aptitude and these I took a slightly different approach by helping them to help themselves. I suggested a few advanced Office courses where they could go and learn how to write Word macros, for example. A few really caught onto this and decided to go on further courses or buy books and educate themselves, and this made my life a lot easier by eliminating small repetitive tasks.
Getting your manager to understand
In a business environment where you are the only developer, it is very unlikely that your manager is a developer or comes from some sort of developer background. You must help your manager understand how to manage a developer to advance your career and your professional development.
The first thing I would stress is training. When working on your own, it’s important to keep your skill base up to speed. When you don’t have the typical developer environment of a small group of people learning and sharing information with each other, it’s difficult to keep on top of new technologies and trends. Training is vital to keep your skills fresh and this will not only benefit you but benefit your employer too.
To help your manager realizes the benefits of training, it’s important that you give him good evaluation and feedback. You should spell out exactly what benefit the training gives to your line of work, and also give him a more rounder evaluation of how the training might have lifted your moral or inspired you to think in new ways.
A number of managers also fail to recognize the difference your latest application has made to someone’s workload or repetitive task. This is where evaluation and feedback comes into it’s own. After you’ve finished your application, write a quick memo to your boss outlining how this application is helping the business. If a few of your co-workers are impressed by your application; encourage them to write to your boss too so that your boss gets both the developer’s perspective coupled with the users experience.
---
Anyway .. That's enough for now. I hope you’ve got something out of this Meditation. I’ll post more thoughts as I have them, but please feel free to reply with your own experiences!
- wil
Being a lone developer in an office full of non-programmers, suits, marketing-droids and sales staff can be very difficult. If done right, however, it can be a very rewarding experience. Looking back over my experience, here are just a few of my thoughts and suggestions on how to get the most out of being a lone wolf. I hope some of these observations will be of some value for you lone developers out there.
Communicating with non-developers
Working in a small organization presented a number of problems where answers were often available, but the answers were often in the form of expensive proprietary software. This scenario was more often than no evident in our accounting department where data manipulation and mangling was core to every day business.
It became obvious after a short time at the company that the answer to every problem was “We’ll get Wil to write a quick program that does …”. Now, don’t get me wrong. I loved these kinds of little challenges and I thrived on them, but I was a Perl programmer. Other team members often forgot about the Perl bit in front of my ‘title’ and assumed that I had the expertise to develop or program anything in as little time as they took to make a cup of coffee. As far as some were concerned, I could even program our toaster to make the coffee.
Of course, on the positive side, there were problems that I could solve and I did make a difference in reducing the daily workload of some members of my team. This was always a rewarding experience, and one that was usually greeted with some amazement from a few co-workers.
Now to bridge this inconsistent and often miss-understood gap, I found out that my best weapon was to educate them. I sat down with a number of small groups within the office and educated them about my skills as a Perl programmer, what I could do, what I couldn’t do and how much work patching a typical program entailed. Honesty is key here. When I first joined the company I insisted on taking on every job I could find, which later turned out in disappointment to people when I couldn’t solve their problems or I was spending way too much of my time getting the toaster to make coffee that my actual work was slipping way behind schedule.
Some members of my team did have technical aptitude and these I took a slightly different approach by helping them to help themselves. I suggested a few advanced Office courses where they could go and learn how to write Word macros, for example. A few really caught onto this and decided to go on further courses or buy books and educate themselves, and this made my life a lot easier by eliminating small repetitive tasks.
Getting your manager to understand
In a business environment where you are the only developer, it is very unlikely that your manager is a developer or comes from some sort of developer background. You must help your manager understand how to manage a developer to advance your career and your professional development.
The first thing I would stress is training. When working on your own, it’s important to keep your skill base up to speed. When you don’t have the typical developer environment of a small group of people learning and sharing information with each other, it’s difficult to keep on top of new technologies and trends. Training is vital to keep your skills fresh and this will not only benefit you but benefit your employer too.
To help your manager realizes the benefits of training, it’s important that you give him good evaluation and feedback. You should spell out exactly what benefit the training gives to your line of work, and also give him a more rounder evaluation of how the training might have lifted your moral or inspired you to think in new ways.
A number of managers also fail to recognize the difference your latest application has made to someone’s workload or repetitive task. This is where evaluation and feedback comes into it’s own. After you’ve finished your application, write a quick memo to your boss outlining how this application is helping the business. If a few of your co-workers are impressed by your application; encourage them to write to your boss too so that your boss gets both the developer’s perspective coupled with the users experience.
---
Anyway .. That's enough for now. I hope you’ve got something out of this Meditation. I’ll post more thoughts as I have them, but please feel free to reply with your own experiences!
- wil
Back to
Meditations