[deleted]
Evil programmer's tip: avoid “easy” things (2016)
11–20 of 203 posts
Re: Evil programmer's tip: avoid “easy” things (2016)
#12At 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…
> It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.
I think that's why he's putting scare quotes around "easy", because it's referring to what managers or stakeholders think rather than the real level of challenge.
Re: Evil programmer's tip: avoid “easy” things (2016)
#13At 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…
this is what the article talks about, you want to work on things you know are easy, but others think is hard
Re: Evil programmer's tip: avoid “easy” things (2016)
#14At 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…
Those two problems sound like they could differ substantially in perceived business value. Maybe it’s not how hard management think it is, but how valuable?
Re: Evil programmer's tip: avoid “easy” things (2016)
#15Whatever one thinks of the techniques recommended in this article, the perils of working on a "easy" but in actuality hard problem are not to be overstated.
The dreaded 3 point story that takes 3 weeks.
...yeah been there.
Re: Evil programmer's tip: avoid “easy” things (2016)
#16'easy' and 'perceived' as easy are different things.
Things that are perceived as hard, usually are way harder, and you're set up to fail.
Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic.
I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor.
It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on.
The added challenge, is that sometimes 'bad devs' make things necessarily complex out of stupidity, and 'brilliant devs' often do the same out of adding on unnecessary complexity.
It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.
Re: Evil programmer's tip: avoid “easy” things (2016)
#17A lot of wisdom here. The hard things are almost always more fun than the easy things anyway.
> To get away with postponing, you need an excuse: other supposedly urgent work;
This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
Re: Evil programmer's tip: avoid “easy” things (2016)
#18This blog is amazing. I currently find myself in some sort of a conflict with management over the classic "new-features vs make the thing stable" situation. Management openly admits to valuing tech debt repayment, reliability etc. but I can clearly tell that it is not what is actually valued.
And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system.
http://yosefk.com/blog/people-can-read-their-managers-mind.h...
We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :)
(Just to make it clear: I am not working on medical devices or power plants or anything of this sort).
Re: Evil programmer's tip: avoid “easy” things (2016)
#19At 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…
It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
Re: Evil programmer's tip: avoid “easy” things (2016)
#20This works until your boss understands software development