Hacker News new | past | comments | ask | show | jobs | submit login

I worked a job productionizing models. It was a startup and the company wanted the work done quicker every time. I didn't really know how to say no, so I automated the task of converting from one programming language to another. It had a side effect of reducing the amount of bugs I'd put into code.

My boss once confessed I was the fastest dev he had ever had bumped into. I hadn't really thought about it as "automation". It was a work from home gig, where the quicker the work was done the happier my boss was, yet at the same time I only had one task, so it was socially acceptable to not have work for weeks at a time and still get paid.




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.


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.


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.


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.


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.


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.


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?


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.


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.


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.


If they’re an employee and not a contractor then the automation code belongs to their employer




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: