|Perl: the Markov chain saw|
On being a developer amongst non-developersby wil (Priest)
|on Jul 17, 2002 at 09:09 UTC||Need Help??|
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.
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!