I work for a company that supports several languages: COBOL, VB6, C#, and Java. I use those languages for my primary work, but I often find myself coding some minor programs (e.g. scripts) in Python because I find it to be the best tool for that type of task.

For example: an analyst gives me a complex CSV file to populate some DB tables, so I use Python to parse it and create a DB script.

What's the problem?

The main problem I see is that a few parts of these quick and dirty scripts are slowly gaining importance and:

  1. My company does not support Python
  2. They're not version controlled (I back them up in another way)
  3. My coworkers do not know Python

The analysts have even started to reference them in emails ("launch the script that exports..."), so they are needed more often than I initially thought.

I should add that these scripts are just utilities that are not part of the main project; they simply help to get trivial tasks done in less time. For my own small tasks they help a lot.

In short, if I were a lottery winner to be in a accident, my coworkers would need to keep the project alive without those scripts; they would spend more time fixing CSV errors by hand, for example.

Is this a common scenario? Am I doing something wrong? What should I do?

  • 24
    If your coworkers can't figure out a script just because it's in another language, you have bigger problems
    – CaffGeek
    Sep 7, 2011 at 18:59
  • 1
    I agree with Chad. Python is as close to pseudo-code as it gets.
    – Job
    Sep 7, 2011 at 19:37
  • 2
    @Chad eheh nice one but the problem could be another; Python sdk is not part of the default installation of the development machine. In order to install it I've payed a lot of coffees to the right sysadmin ;). Sep 7, 2011 at 19:44
  • 3
    @systempuntoout, developers should be able to install whatever the hell they want on their computer that is within legal limits. So, PowerShell is preinstalled on Windoze and I tried substituting it for Python, but it aint the same. The edge cases slap me in the face every time I try to do something simple. Python just gets things done and if corporate drones do not get it - too bad!
    – Job
    Sep 7, 2011 at 23:58
  • 1
    Put them in source control. Just a tiny corner somewhere, but put them in.
    – user1249
    Jul 11, 2012 at 9:29

11 Answers 11


You need to get the situation formalised as it shouldn't really have got to this point. However, these things happen so you need to explain to your boss that you created these scripts for personal use, but they've "escaped" into wider circulation. Admit (if necessary) that you were at fault for not bringing this to his attention sooner.

At the very least the scripts should be put under source control "just in case" - then at least if you aren't available (for what ever reason) your co-workers will have access to the scripts.

Then you either need to convince your boss that Python is the way to go for these or accept that you are going to have to re-write them in a supported language. If the cost of documenting the scripts and educating your co-workers in Python is lower than that of the re-write you might even win the argument.

  • 8
    +1, agree. I can see how this sort of thing can very easily happen but it is not necessarily "a bad thing" or "a mistake" on the part of the OP. It probably started when the OP was tasked with a "one-off" mini-project and he chose a good tool, python, to quickly clear his desk of the project-- but then found himself performing the task again and again...
    – Angelo
    Sep 7, 2011 at 15:27
  • I'm living this right now. I hacked up a proof of concept in Python to help me figure out some crappy old C code, and actually got the whole mess working as a replacement for the old C code, but was asked to rewrite back to C after making the new changes work. I did manage keep some Python around, I wrote up small web app using Python + Flask and my manager and I use it constantly to analyze the running C code's operations. So there's still hope that Python will get formally adopted around here. :) Oct 18, 2012 at 19:17
  • @JohnGainesJr. Similar experience here but eventually python was adopted. It's meteoric rise in popularity helped a lot.
    – JimmyJames
    Nov 22, 2022 at 17:44

I can't give you a full answer as to what you should do. I can only give a single suggestion you can use to start with:

Check the scripts into a repository that all (required) developers can access. But make very sure to make note of the fact that you've first written these scripts for your own purpose, i.e. to perform a task you'd been given. Then add that you're only checking in these scripts to allow others the advantage to use them.

After that you'll just need to see how other people respond to that.

  • Comment them as whenever possible. Helps to quickly see what's going on, rather than trying to figure out what the heck you're doing.
    – JD Frias
    Sep 9, 2010 at 16:25

I have run into similar problems where I work. I heard "What is PHP?" several years ago. They don't understand or care to learn anything outside of the MS stack. If python is the right tool for the job I'd just tell my supervisors about it and be ready for alot of comparison and explaining as to why python was the right choice. It will be frustrating, but I think most would agree python is a good choice for text manipulation.


The first thing you need to do is talk with the team and your boss. Right now, you have a huge truck factor (if you got hit by a truck, no one else would easily be able to maintain your scripts). It looks like having scripts to do these tasks are important, but it's also important that anyone who needs to can edit and maintain these scripts. You need to explain how using Python adds value - how it saves time, effort, resources, money, and so on.

Second, get it into the project's version control. Now. Nothing that you produce for a project should be outside of that project's version control, ever.

Be prepared for backlash - people typically don't like change. Running off on your own, using unsupported and unknown (to the team/organization) technologies was a bad idea, without consulting at least the other developers and determining the best (for the project, not just you) way of automating these tasks for everyone to use.

I think this is probably a good case of

It's easier to ask forgiveness than it is to get permission.

It sounds like you got the job done, but you are going to have to deal with the repercussions now.

  • 4
    """Running off on your own, using unsupported and unknown (to the team/organization) technologies was a bad idea, without consulting at least the other developers and determining the best (for the project, not just you) way of automating these tasks for everyone to use.""" - I disagree. Joel Spolsky would not have been able to create VBA for Excel if he went this route. This is by far not a unique example.
    – Job
    Sep 7, 2011 at 16:47
  • @Job I can't speak to the exact circumstances of the development of VBA for Excel, but that sounds like advanced R&D or prototyping was involved. There's a difference between advanced R&D and production systems. You can never work in the dark, alone, and isolated from your team. I'm not opposed to introducing new technologies, but it's important that everyone knows what these new technologies are, their benefits, their drawbacks, and how they are being deployed in a project. Doing something solo and in the dark is generally a bad idea and puts a project at risk.
    – Thomas Owens
    Sep 7, 2011 at 16:56
  • @Thomas I am the team Sep 7, 2011 at 20:13
  • @systempuntoout That may be true now. But will it be in 6 months? Or a year? Software development, even if you are currently alone, should never be considered a solo task - you need to think of the future developer or maintainer of your work.
    – Thomas Owens
    Sep 7, 2011 at 20:34
  • @Thomas you are right; as said in some comments above, I've ported many scripts in C# (Company supported language) Sep 7, 2011 at 20:36

My rule of the thumb is:

Anything that potentially impacts the work of others should be discussed with your peers and superiors ASAP.

But, if it's for you and you alone, as long as it doesn't do any damage to your firm's infrastructure or security, you are free to do as you wish to get the job done.

  • 1
    How do you know if it's for you or for others? At work, you can get reassigned or you could quit. Anything that you produce at work (in most cases) isn't yours, but it belongs to the company or the customer. If they can't understand or maintain it, the time lost is the time you spent developing it plus the time it takes someone else to understand it (and perhaps develop a new solution). Everything produced at work should be treated as something for someone else.
    – Thomas Owens
    Sep 7, 2011 at 14:22
  • 1
    If during the time you were at that job it increased your own personal productivity, then the company has already gotten value from that script and it was not a waste, regardless of whether it gets reused later by someone else.
    – Nate C-K
    Sep 7, 2011 at 15:44
  • @Thomas Owens - there are often one-time tasks - once they're done, they're done - or your own hacks and tests that you do in the course of development to get through something sticky - again, once they're done, they're done - effectively disposable.
    – Vector
    Sep 7, 2011 at 16:03
  • And if someone else needs to do the same or similar task later (which is very likely, in my experiences)? They have to reinvent the wheel. It's one thing to have a throwaway prototype work for solving a problem or learning a library or framework. It's another to spend time developing a tool to do a task and then just discarding it. The types of tools that the question is referring to are for tasks that potentially have to be done multiple times, and if other people do those tasks, they waste time by not having a tool to assist them (or needing to develop such a tool).
    – Thomas Owens
    Sep 7, 2011 at 16:13
  • @Thomas Owens - granted - that's included in what I said 'potentially impacts the work of others'.
    – Vector
    Sep 7, 2011 at 16:18

You have two options:

  1. Make it a standard
  2. Translate into a standard tool

Depending on the organisation #1 might be challenging (after all limiting the list of standard technologies avoids a combinatorial explosion of training and support skill requirements).

The second option would help your skill set, and you might be able to find third party (and likely open source with commercially friendly licences) to do some of the hard work. E.g. a search for "LINQ to CSV" should get some useful hits.

BTW, VB6's developer tools (IDE, compiler) is unsupported (not even security fixes) so it is likely the standard needs updating anyway. (VB6 runtime is supported as part of—and included in the install—of current Windows versions). This could perhaps be used as a helper to approach #1: the standard tool set needs to up a moving target because of supplier dependencies.


If you are given a task, and eithe the only way you can accomplish it on time, you don't really have a choice. I do think it is wise to let those in charge know what you are doing. You should not go outside the required source control (unless it just absolutely doesn't work at all?) testing and documentation.

Sometimes a company may have to let a single developer start looking into a new area of development. Unfortunately, the code may make its way into production faster than anyone else can get up to speed.

  • Believe it or not, after posting this question and receiving a lot of insightful suggestions, I have ported several scripts in C#. Mar 9, 2011 at 16:03

Well, I got to admit that working with 20 different languages stinks, A LOT.

You have a Bash script that calls Python script that calls Perl script that calls Java binary that calls C dll...

Then something hits the fan in the whole pipeline, and you go through - WTH IS DAT KODEZ? Especially in Perl... And debugging simple, say, encoding problem, turns into a nightmarish mess. You can't debug 5 out of 7 languages effectively, and it turns into a real pain.

Or you have to add a simple change, but you create 10 errors because Perl has gotchas, Java has gotchas, etc.

And that 7+ language chain starts one step at a time.

Tread carefully, here be dragons...

  • Working with the right tool does not stink, it is the Unix way of building things. The Windows way is to launch Excel. Old story of hammers and nails...
    – mouviciel
    Sep 7, 2011 at 20:15

If those are tools you use for yourself, you are free to do anything that makes you more productive.

Actually, you should be encouraged to make and use such tools, which will ultimately became an extension of your arms.

Eventually, they will recognize the importance of having such tools, no matter what language they are written in, and will start to implement in their working environment.

  • At work, I don't think you should treat anything as "for yourself". They are tools to support a project, and there is a team working on that project. You can quit, get fired, get reassigned, or drop dead tomorrow and now your responsibilities fall to someone else. If they can't use and maintain your tools, the effort that went into making them was wasted (costing the company money).
    – Thomas Owens
    Sep 7, 2011 at 14:54
  • 3
    @Thomas: I treat scripts I make for myself and my personal use as mine. They are an extension of my arms and my mind. It's like saying "You cannot think like this, you can only think like that". I think it's not important what you think, as long as you are able to do what you are asked to do.
    – Jose Faeti
    Sep 7, 2011 at 15:06
  • That, to me, is extremely unprofessional and unethical. One of the ethical responsibilities of a software engineer is to act in the best interests of the client and employer, as long as it does not risk the public. Another ethical responsibilty is to be fair and supportive of colleagues. Keeping your tools to yourself when they are for a project violates both of these principles.
    – Thomas Owens
    Sep 7, 2011 at 15:12
  • 3
    @Thomas: I wasn't talking about writing a specific programming language for the project. I'm talking about something like "rename 10000 files with a single command", something that dumb programmers do by hand one by one, while I'm able to do it with a self-made script. I'm not interacting with anything specifically involved in the project. They are NOT project-specific tools.
    – Jose Faeti
    Sep 7, 2011 at 15:15
  • 3
    @Thomas: The point is not knowing if such a utility exists, but knowing how to automate your work by making such utilities. You will always need some new script to aid you in your everyday tasks. Forcing a programmer to use existing tools or tools made by others is like cutting wings to a bird. I cannot imagine working in such a place. Anyway I understand your points. My answer raised because the OP already was in that situation, I think the best would be to share the thought about making/using a particular tool with all the team as soon as it is needed, then decide.
    – Jose Faeti
    Sep 7, 2011 at 15:32

When you are told to write code doing sth., the language is usually specified or implied (the rule in corporations).

But when you have to do some one-shot task, such as import data into DB, you are free to choose the tool that in your opinion fits the best, because you have to do something correct and fast, and the result is important, not the tools.

So, I would use that rule:

1) If you are told to do some task, such as data import, I would use the tools/language/etc. that would be the most convenient for me and would be the fastest for the task.

2) If you are told to write tool doing some task, such as import some data, I would discuss what language/tool to use with the manager (with exception when I use language that is implied standard, for example when company uses [almost] only Java).

3) If the task seemed to be one-shot, but it became repeatable, you should talk with the manager to change it from 1) to 2) and re-write from your preferred to company-supported language.


I suppose that you're not in a position to decide (or else you would not ask the question). What does your boss think about this issue? You should talk to him and try to convince him that Python is the way to go...

Of course, the issue is about what will happen when you leave. Not being able to maintain the code is probably a reason that's good enough to stop using Python. Or you can start educating your colleagues to this language...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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