3 ms·

I was worried whole time that you will tell your boss about your automation and you and whole team will get fired and replaced by it.

datashow 7y ago
But do you have to give the automation tool to the company? My impression is that the automation tool is not part of the job.
- mcv 7y ago
  But it's related to your job, and if your contract specifies that anything you write that is related to your job belongs to your employer, they own the automation script.
  - Dumblydorr 7y ago
    How automated though? I have an automated script that is really easy for me to run, but I'm not sure others would easily pick up the pieces if I was fired out of the blue...its automated but not simple.
    - mcv 7y ago
      I was in a similar position in my first job. We got an extremely detailed functional description of what the software was supposed to do. It was so detailed, I had a couple of scripts and macros that created most of the code for me. I was always the first to be done with my work. I wouldn't have minded sharing those macros, in fact. Those macros were specific to that particular project, though. I was eventually fired from that job (I suspect my boss didn't like seeing me lean back and watch my scripts and macros run), and this never came up. I think the real value here is the skill and desire to automate these things, not the automation scripts themselves.
  - datashow 7y ago
    Sorry I did not make it clear. What I meant the automation tool is something like Autohotkey. Let's say I made a private software XAuto (like Autohotkey) many many years ago with tons of efforts, and then I wrote a XAuto script (like an Autohotkey script) to automate my work. Do I have to give both of the XAuto script and the XAuto software to my employer?
    - triclops200 7y ago
      That would depend on contract, but, assuming you have a decently sane contract, you'd have to hand over the script, but not the software itself. However, it now sounds like you've landed your first paying customer for a license for your software.
- tcoff91 7y ago
  If they’re an employee and not a contractor then the automation code belongs to their employer
Bombthecat 7y ago
Why bother? Look for a new job, as soon as you have it, tell him and leave. There is enough demand for even the "most basic" developers.
- 0x445442 7y ago
  I agree with this and think it touches on a more fundamental issue with our industry; in general, developers are not viewed as professionals by their employers or eve themselves. I think many of the negative aspects of the profession can be mitigated if developers would just take a different perspective on their work like viewing themselves more as plumbers, electricians, doctors or lawyers and less as clerks.
proverbialbunny 7y ago
I didn't think my comment would blow up as much as it did or I would have given more information: It was an MLE / SE role, so writing code was not some taboo thing. The job was taking models and putting them onto in-house hardware with limited processing power. The code had to be fast, very fast. So I wasn't just transpiling but putting optimizations in to the output code as well. The output format was C++, and it would output a handful of classes, which I would stitch together into the design pattern of my choosing, so the job wasn't fully automated. Nor had I wrote parts that take in the whole range of the input language, but a fraction of it, because the models only used a fraction of the language. This was far from an industry standard program, but more a quick hack in Perl, because I was in a hurry and it's the fastest prototyping language I know of. It wasn't meant to be used by anyone but me, and sometimes I would have to go in and reconfigure it if new models had anything unexpected. To me it was just speeding up my job. I thought of it as meta programming. Something that would have taken 60 hours of crunch time, became 2 hours of writing code and testing, at a leisurely pace.

datashow 7y ago

But do you have to give the automation tool to the company? My impression is that the automation tool is not part of the job.

mcv 7y ago
But it's related to your job, and if your contract specifies that anything you write that is related to your job belongs to your employer, they own the automation script.
- Dumblydorr 7y ago
  How automated though? I have an automated script that is really easy for me to run, but I'm not sure others would easily pick up the pieces if I was fired out of the blue...its automated but not simple.
  - mcv 7y ago
    I was in a similar position in my first job. We got an extremely detailed functional description of what the software was supposed to do. It was so detailed, I had a couple of scripts and macros that created most of the code for me. I was always the first to be done with my work. I wouldn't have minded sharing those macros, in fact. Those macros were specific to that particular project, though. I was eventually fired from that job (I suspect my boss didn't like seeing me lean back and watch my scripts and macros run), and this never came up. I think the real value here is the skill and desire to automate these things, not the automation scripts themselves.
- datashow 7y ago
  Sorry I did not make it clear. What I meant the automation tool is something like Autohotkey. Let's say I made a private software XAuto (like Autohotkey) many many years ago with tons of efforts, and then I wrote a XAuto script (like an Autohotkey script) to automate my work. Do I have to give both of the XAuto script and the XAuto software to my employer?
  - triclops200 7y ago
    That would depend on contract, but, assuming you have a decently sane contract, you'd have to hand over the script, but not the software itself. However, it now sounds like you've landed your first paying customer for a license for your software.
tcoff91 7y ago
If they’re an employee and not a contractor then the automation code belongs to their employer

Bombthecat 7y ago

Why bother? Look for a new job, as soon as you have it, tell him and leave. There is enough demand for even the "most basic" developers.

0x445442 7y ago
I agree with this and think it touches on a more fundamental issue with our industry; in general, developers are not viewed as professionals by their employers or eve themselves. I think many of the negative aspects of the profession can be mitigated if developers would just take a different perspective on their work like viewing themselves more as plumbers, electricians, doctors or lawyers and less as clerks.

proverbialbunny 7y ago

I didn't think my comment would blow up as much as it did or I would have given more information: It was an MLE / SE role, so writing code was not some taboo thing. The job was taking models and putting them onto in-house hardware with limited processing power. The code had to be fast, very fast. So I wasn't just transpiling but putting optimizations in to the output code as well. The output format was C++, and it would output a handful of classes, which I would stitch together into the design pattern of my choosing, so the job wasn't fully automated. Nor had I wrote parts that take in the whole range of the input language, but a fraction of it, because the models only used a fraction of the language. This was far from an industry standard program, but more a quick hack in Perl, because I was in a hurry and it's the fastest prototyping language I know of. It wasn't meant to be used by anyone but me, and sometimes I would have to go in and reconfigure it if new models had anything unexpected. To me it was just speeding up my job. I thought of it as meta programming. Something that would have taken 60 hours of crunch time, became 2 hours of writing code and testing, at a leisurely pace.