6

As a software developer there is many part of my job that can be tedious and/or time consuming. Whenever it is possible I create scripts or softwares to make it easier on me, or make the process fully automated.

Usually it's softwares that anyone could make in a few hours, so I don't publish them anywhere, as there is no point. But I've recently started to work on a software wich can drastically reduces the amount of work needed when it comes to our database.

Basically my software is a script editor wich automatically implement every process we're supposed to take into account when creating a script. The script is formatted in a company-specific way, every needed verification needed is automatically performed.

So my question would be, in what way could I present this software to my team/company ? I am afraid that his may be seen as a gadget/novelty, and end up not being used / adopted by the company.

If it is helpful, we're situated in France, and we're working with the Agile method. In-house software to help with tedious processes are not uncommon here, but are usually done on command by the company.

Note : To be clear, I am not trying to sell this software to them, but to give them the rights and sources of the soft, so that other people can use it, and develop it further. I tried searching for similar questions, but every questions I found where about selling a software.

Improve this question
1
  • What's the downside for it not getting adopted by your company? Could you still use it for yourself if they don't adopt it? Has it been created fully in your spare time?
    – Kaleb
    Jul 26, 2019 at 17:33

5 Answers 5

Reset to default
7

If it's tools that you developed to make your own job easier, I'd absolutely encourage you to share it with your co-workers. Sometimes just pushing the scripts to a side repo, putting them on a file share, or corporate file sharing account is all that's needed. Then email everyone the link with a description of what it does. Something like the following:

Team:

Like many of you, I continually am going through redundant cycle of building, deploying, debugging, and pulling down logs for analysis, then running the parse tool on the logs to find the output of my relevant sections of code. This overhead easily takes 5 minutes per iteration regardless of how much code I changed.

And I do it 10 times a day. So I wrote a script that makes it easier and does all the work for you. So now this overhead is reduced to 1 minute. You can find the script in your enlistment at tools/scripts/debugstuff. Just edit the headers at the top of the script with your test account password and test machine IP address. See the comments at the top of the file. Let me know if you have any questions or suggestions.

user3399

Stuff like this not only makes your team more efficient, it creates a great culture and motivates others on the team to do the same and/or improve your work, or offer suggestions back. There's really no downside to sharing stuff with co-workers to make their life easier.

Improve this answer
4
  • 1
    This is closest to the answer that I would give. Let me add that some companies will want the scripts to be documented and/or controlled (released into a version control system). I wrote a tool using code at home. When I went to share it, I was told that it needed to be documented and controlled. I said that I wouldn't do that for free. They funded a small project to make my tool official. It never got the widespread use that I expected, but a few people use it all the time and think that it is great. Scripts may have lower requirements for documentation, it depends on the company.
    – Mattman944
    Jul 26, 2019 at 19:45
  • Yes, some companies probably have process and guidelines. Most places will just defer to the teams themselves to manage and maintain their own locally sourced tools.
    – selbie
    Jul 26, 2019 at 22:05
  • @selbie, depending on how many people on the project but if tool is getting used by few people it is still the worth to approach the manager or people who manage source control for the team to put it in source control. Disk space is dirt cheap today, time you would loose if the tool vanishes is not. Basically you can use this argument when you approach a manager. If you pay per repo you can create a repository for all tools and then add a separate folder for each tool. And the easiest way to have documentation is to create Readme.md in the tools root.
    – AlexanderM
    Jul 28, 2019 at 2:52
  • 1
    @AlexanderM - Good stuff there, no doubt. But it was not a goal of my answer to describe how to publish a tool. The answer is strong encouragement to the OP that they should not be fearful of sharing code. But yeah, respect the processes and best practices of your teams, and make it easy to consume. As a manager, I'm always encouraging my team to contribute to making the engineering environment better. And when they do, there might be a quick discussion of which repo, folder, or packaging tool to use, but that's a 5 second conversation.
    – selbie
    Jul 28, 2019 at 7:18
1

Here's a good template for pitching new ideas that's worked incredibly well for me in the past. It has three parts:

Describe the current situation. Basically, what's the current process that's being followed.

List the downsides of that approach. Why would someone want to improve the process, what are the pain-points, etc.

Demonstrate an alternative. Describe - or ideally show - an alternative way of doing the process that solves some of the downsides described in the second step.

This is an easy-to-grok format. It gives the background info needed to make an informed decision on the topic. It demonstrates a business use. And it gives the manager a good position to decide whether your proposal is a good idea.

Improve this answer
1

Firstly, the intellectual property rights for this probably already belong to your employer, even if you wrote this in your spare time. Check out L113-9 of the Intellectual Property Code in French law. It sounds like you created this in your spare time but in the course of your duties.

in what way could I present this software to my team/company ?

Demonstrate your automation; find the right forum and show people how it helps. If your colleagues see it work, some of them will want to try it.

In my experience, software engineers create this kind of automation all the time, and it is very much a part of how we work. Depending on your colleagues there could be some scepticism or resentment, but mainly people like things that make life better/easier and aren't hard to maintain.

To your manager:

"I took initiative and created some software that will help us become more productive."

Don't be shy - you've done something good, and any manager worth their salt will recognise and encourage that. Maybe next time you will be allowed to carve out time from your working day to do this kind of work...

Improve this answer
0

If you wrote it, and it is related to your job, you should assume they have complete ownership rights to it. This is the standard employment agreement for software developers.

Improve this answer
13
  • If I write some code at home and it could be applied to work you are suggesting it will automatically belong to the company?
    – Solar Mike
    Jul 26, 2019 at 18:30
  • 2
    @SolarMike: It depends on the exact legal agreement you signed, but often it works exactly as Julie said.
    – Ben Voigt
    Jul 26, 2019 at 18:36
  • @BenVoigt So they pay for 8 hours a day but take 24...
    – Solar Mike
    Jul 26, 2019 at 18:37
  • 1
    @SolarMike: Knowledge workers are usually paid salary, not hourly. So there is no such thing as "pay for 8 hours a day". I am lucky enough to have an employer that compensates overtime for salaried employees, but it's rare.
    – Ben Voigt
    Jul 26, 2019 at 18:40
  • @BenVoigt - I've never heard of a salaried worker being paid for overtime. The only "compensation" I've heard of is additional time off -- "comp time". How does that work? Is there an "overtime after 40 + X hours"?
    – Julie in Austin
    Jul 27, 2019 at 23:16
0

Is it something that helps a developer in his day-to-day work (e.g. An IDE plugin) ? In that case, simply share your tool through an email or in a learn-and-share moment if your team organizes these. Make sure to clearly explain why it's helpful - if it really is, you will have no difficulties in getting your colleagues to use it.

If it is something that helps the company/user (e.g. Something that makes it easier to avoid bugs and therefore create better software and bring in more revenue), you should probably talk to your manager instead. In that case they will make sure in your place that it's used everywhere.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .