Evil programmer's tip: avoid “easy” things (2016)

Sounds like a normal day in office.

In my experience these 'evil' things are rather common practice. People do far more nasty stuff to get ahead, all the time. Programmers are no exception.

At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and worked through a number of issues with the lead dev. When this was delivered everyone loved it, lots of kudos and compliments because it was seen as hard. I felt like a bit of a fraud as I felt I had a lot of help and it really was a team effort, I made efforts to highlight this.

I also worked on my own (with the exception of some nginx issues) on a feature to keep an in browser file browse up to date for all users via web sockets. This was really a view on a git repo accessed through the Gitlab api, it was a nightmare to deal with because of the way Git tracks (or doesn’t really) folders. This feature was seen to be easy and I slaved on it for days and eventually weeks because of edge cases and feature creep to no kudos or compliments. Which is fine, it’s my job.

It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.

I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework