Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

On being a developer amongst non-developers

by wil (Priest)
on Jul 17, 2002 at 09:09 UTC ( #182361=perlmeditation: print w/ replies, xml ) 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!

- wil

Comment on On being a developer amongst non-developers
Re: On being a developer amongst non-developers
by kodo (Hermit) on Jul 17, 2002 at 09:26 UTC
    hi wil!

    I've had pretty same experiences as you had last year, so I think I know what you feel like. It's always hard to speak about coding to people that don't have a clue what amount of time the "program" they wish will take. I also found out that it's VERY important to discuss out if the things people want really are important or just nice-to-have. I even had experiences where people wanted stuff kinda because they were bored or something but then didn't really use it.

    Currently I work in a room which is full of people who know what coding is about, even if I'm the only person here who codes perl, the others do PL/SQL mostly. But the point is that they know what it is all about and that saves you a lot of time. Also my boss has quite a few years of coding-experience so there usually aren't long discussions needed to find out how long it will take to do the job etc.
    If you have only people arround you who do word-processing mostly and that's it, it often takes more time to find out what they really want than the time you need for coding itself. You start to discuss, then their mind changes after you told them what is necessary etc and so on...
    I think it's always good to request a clear concept of what people want, what they want it for and how important it is. There are everywhere lots of things that could be made easier by coding a script and automating stuff that has beed done by hand until now...so you will get lots of requests pretty soon, once people know "that guy can do that!", so you have to set clear priorities.
    But as I said my boss knows about coding so I didn't have to argue in any way, because if there is a problem I tell my boss and don't have to argue with people usually :)

    What I don't like is when someone "important" in a high position wants something and then it has to be done, doesn't matter what kind of time it takes and if there are other important things but I guess that's pretty usual....

    greetings,
    giant
      Righ, as a consultant, I had to deal with similar requests for 'enhancements' and other 'gotta-haves'. I had also spent some time working for a small .com firm back when it was all hipe and glory. Luckily, my boss too was quite aware of what it takes for a program to work properly as he had a PhD in Comp. Science. This helped me alot as I didn't have to explain a lot of dirty details of my trade.

      Nontheless, I feel that it is equally challenging to communicate with those who have no ground knowledge in 'programming' and those who by far and wide exceed your own skills in the field. In the case of my previous boss, at times he seemed to percieve a task to be overly simplistic whereas it turned out to be quite a task in the end, for me at least ;). However, whenever I had to talk to my boss, I was always careful to reassure him that a project will go smoothly as even at the time of a major setback, as a developer I know the word 'learn'. Throughout my short career as a developer, I have learnt that it doesn't hurt to learn new things to complete your job faster and right. Be it Perl, C/C++, or even Pascal, all are good to use for various purposes.

      With this in mind, I hardly ever deny a request for a certain feature or piece of code despite of the fact I may require to learn something new to complete the job. I guess I'm at odds with wil on that point. I feel that when I'm hired to work for a company as a developer, it may be somewhat damaging to basically go about trying to explain other co-workers that you are in certain ways 'inadequate' for a job/project. You should never as a developer limit yourself to the use of only one tool, be it 'Perl' or something else. For one, this 'revalation' may be ground to your replacement with a new developer that would have knowledge of the tool you are familiar with and more.

      _____________________
      # Under Construction
Re: On being a developer amongst non-developers
by andye (Curate) on Jul 17, 2002 at 11:08 UTC
    Too true! Good post, wil.

    In my experience, you also get lumbered with every form of tech support - I guess it's not easy for suits to see the difference between one sort of sitting-at-a-keyboard-looking-at-a-screen and another (someone thought I was programming when I was actually watching flashcards of the Japanese alphabet - and yes, they could see my screen).

    We had outsourced tech support, but it was (understandably) easier for my colleagues to ask me to fix it.

    Classic dialogue one day:
    Colleague: My screen's not working! Can you come and see what's wrong?
    (I interrupt my work and walk to their desk)
    My finger: *click* (switched the monitor on)
    Colleague: Oh.

    andy.

Re: On being a developer amongst non-developers
by rinceWind (Monsignor) on Jul 17, 2002 at 15:23 UTC
    Excellent post, wil.

    I can relate well to your experiences, as I have been there, and continue to do so periodically as I move around (occupational hazard of being a consultant).

    However, there are a few traps for the unwary, and I will use this thread as an opportunity to share my experience.

    Hardware adept

    If you get a reputation for being a dab hand with a screwdriver (or even a soldering iron), this may be best to keep to yourself. You are likely to find that the company will refuse to spend money on new hardware or maintenance, as they have an expert on site. This also equally applies to MS office applications etc.

    Being too helpful

    Although having a helpful and respectful attitude to users is an asset, make sure that they are being reasonable, and are not wasting your time. If they have a repeat of a problem which was solved, you can rightly say that you have already given them a solution. However, there may be an underlying issue with why the problem has reoccurred, but if this is the case, discuss with your management and earn ++ points for spotting it.

    Not passing on information

    Although it seems on the surface a good career move to set out to try and make yourself indispensable. In practice, the reverse is usually true. If you have set yourself up as the standard repository of all knowledge and wisdom about XYZ, you might find that you have a rival who is more forthcoming with information, who has ousted your position on the team.

    Closing your ears and eyes to what is happening

    At all times, try to be aware of the politics and dynamics of your department. It is easy as a good programmer to get a reputation as a quiet person who gets on with the job. The danger here is that you are excluded from important design decisions, juicy new projects, and news about the future of the company (and hence your future). The answer to this one is to ask questions (why do we do that?) and be proactive.

    General points

    Go check out Dilbert, but don't take it too seriously. Although Scott Adams has a somewhat jaundiced and cynical view of corporate culture, the humour content is second to none. Also there are many useful techniques for recognising and dealing with pointy haired bosses.
Re: On being a developer amongst non-developers
by dragonchild (Archbishop) on Jul 17, 2002 at 15:44 UTC
    The point about non-developer managers is especially telling for me. While I've been blessed to always be a coder among coders (or coder-like people), I've rarely had managers (let alone directors!) who had a developer background.

    For example, my previous position had developer-type managers, but the directors were non-developers. So, they had no compunctions in moving up our due dates without conferring with us. Then, they got mad when we didn't deliver on their schedules after they wouldn't authorize overtime. Big surprise, huh?

    Education is important. I'd even say it's the most important thing, except that willingness to change is more important in a manager.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Re: On being a developer amongst non-developers
by dws (Chancellor) on Jul 17, 2002 at 17:13 UTC
    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.

    This is a good strategy to follow even if you're a coder among coders. Bosses get really busy sometimes, and may not notice the significance of small achievements. Having a note show up in email, where it can be read later, is a good way to make sure that the benefits of your labors don't go unnoticed. And having a paper trail is good at review time, when bossses go through the exercise of collecting data for their side of the review. If your boss is well-organized, they'll keep separate email folders to collect review material, such as notes from co-workers.

Re: On being a developer amongst non-developers
by bilfurd (Hermit) on Jul 17, 2002 at 23:18 UTC
    Good job pointing out the importance of training and keeping you skill set up to date.

    Developing a new skill set helped leave a moderately miserable job for a great one.

    Maintaining a skill set helped a lot of COBOL programmers land some fat contracts when people figured out that the century was going to end a few years ago.

    The hardest part of maintaining and building your skills is finding a reason or an excuse to use them. If you make a point of it and keep it in mind, an excuse will come to you eventually.

Re: On being a developer amongst non-developers
by tmiklas (Hermit) on Jul 18, 2002 at 11:00 UTC
    Well said, wil

    My situation is very similiar, but my current boss is also a programmer... He never did anything similiar to my tasks, but he knows what is it (programming) all about, so our contacts are often very technical... We both learn from each other ;-)
    Although my co-workers (non-programmers) are 'different' in all meanings of this word... Sometimes they call me and ask the same questions every 2-3 days, becouse they try to get to the same point through a different way and of course blow their data away :-) but none of them has read the manual. When i come back to my desk with a stupid smile on my fece, by boss simply says "Yup! I love them... PEBKAC"... If can't find even a few minutes to DO THEIR JOB FOR THEM they are very dissappointed, but I'm curious, if they would the leave their tasks to do something for me?! I don't think so...

    My oppinion: the best solution is to have a programmer as a boss, then it's much easier to survive in non-programmers nevironment :-) Of course what you've pointed out in your node is very helpful... especially the feedback.

    Greetz, Tom.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://182361]
Approved by neophyte
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (18)
As of 2014-07-31 12:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (248 votes), past polls