I am a contract data analyst, so I bounce between jobs every 3-6 months, which I find to be a good fit for me, but it leads to some problems when it comes to coding. I mostly do statistics (I've asked a similar question on cross validated, but the answers there are not relevant here), but I have also found out that the business world loves excel and loves copying and pasting the same thing over and over again even more. This led me to learn how to write VBA scripts and then VB.NET programs to automate as many of these reports as I can.

I am certain my programs are not the most elegant, but I put a good bit of effort into making sure they work under as many cases as I can test, I add in exceptions and try to code so the program can handle changes in the files that it processes, but there is a limit, if you remove a huge portion of the data, there is a good chance my program is going to trip up, which I accept will inevitably happen. Usually a pretty minor change in the code fixes the problem and I do try and comment my code and make it readable under the assumption that some other person will have to read it some day.

My problem is that I generally get put on teams of folks with essentially no experience with programming (like VBA would be a huge stretch for anyone I work directly with). I am wondering what I should be doing as the person that wrote the code to do my best to keep it maintained. I have two approaches in mind (outlined next), but would be very happy to get any advice.

Solution 1: Find the more tech savvy coworkers and run them through the programs and what basic changes can be made. Honestly automating excel is about as easy as it can get when it comes to programming, so I feel like I could teach someone the basics of maintaining it pretty quick.

Solution 2: Get in touch with the IT department and show them what is going on and maybe they will be able to help. The problem here is that the IT department is constantly swamped (as I'm sure many of you know) and I feel like kind of a jerk for dumping more things on them.

I do leave my personal email address with places and am willing to answer quick questions via email, but I view the need for more exhaustive maintenance as something of an inevitability and would like to make sure I do my due diligence to make sure it gets done. I imagine some combination of the two approaches outlined there, but is there any kind of heads up I should give IT? I feel like I would be annoyed if I started getting requests to fix a program that I had never seen from some random guy that is no longer there.


What you really want is to be IN the IT dev team first and foremost.

Then it would be much easier for your work to become their responsibility once you leave, after you've done a proper handover.

They may well be swamped, but I'm sure they'd rather have hands on any systems now while you around.

I've seen a number of places work in that way with hacked together excel spreadsheets with thousands of lines of VBA written by some non techy becoming mission critical. Then when it falls over IT get blamed when they haven't ever seen the system.

  • You know I didn't think of it that way, I suppose it is a ticking time bomb as far as IT is concerned if there is shoddy code running the company. That makes me feel less concerned about over burdening them a bit. – asjohnson Mar 15 '12 at 15:21
  • When you say I want to be IN the it dev team, do you mean I want to get positions where I am a developer or just I should get to know them and talk to them about what I am doing? I definitely do my best to do the latter (turns out I get along with IT people in general and its always good to be friends with the folks that maintain your data), but I don't know if I am really good enough at coding to get a job as a developer (nor would I necessarily want one, since I have a much better skill set as a statistician). – asjohnson Mar 15 '12 at 15:25
  • @asjohnson - Ideally solutions involve writing code should be done within an development team. If a business unit hire someone with coding skills or even a "real" developer and work outwith the dev team, then they are opening up themselves to issues further downt the line like I described. If you feel you aren't good enough to be in the dev team, or simply you are hired OUTWITH the dev team, it makes sense to get to know them, get the lay of the land etc. HOWEVER..... when the dev team get wind of some programmer being hired outside of them, they may well not be happy. – ozz Mar 15 '12 at 15:35
  • @asjohnson - Make sure your boss knows and approves if you intend to talk to the devs too. This is really a much wider question about politics in an org. – ozz Mar 15 '12 at 15:36
  • Oh I definitely got permission from the boss. I guess I am a reasonable programmer, so I could work with the dev team, but I just have never been on one. The problem is the dev team does not sit with people on a daily basis that are copying and pasting the same thing, while I do, so I just fix it. Most of the dev teams I have seen are working on larger projects (system upgrades, etc) or helping people that have filed requests. Many of the people I help don't have any idea that what they are doing could be automated. – asjohnson Mar 15 '12 at 15:40

I like your first solution: find some tech-savvy employees there and teach them the basics

I usually find there are always a few tech-smart users at most companies. These people always seem to be quite happy to learn something new and interesting, and usually enjoy the break it gives them from whatever their regular job is. Just be sure they have your email and know to contact you with questions.


Isn't this up to the customer? They hired you for a reason: either they don't have your expertise or they don't have the time.

As long as you make them aware of the situation, it's up to them. They may prefer to just hire you back. Of course they'll try and get some free advice. You don't seem to mind the minor questions, so it's not like you're always gouging them for billable hours.

If a company wants to continue to add features and functionality, they'll eventually need a programmer. Most people could learn how to change a car's oil and save money, but they just don't want to crawl under the car.

Not the answer you're looking for? Browse other questions tagged or ask your own question.