Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yosefk.com

Post reply on HN
Print view View original

61–70 of 203 posts

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

#61

Post by klyrs »

version_five wrote: post #19
simonbarker87 wrote: post #7

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…

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.

God, this hurts. I pride myself in avoiding deadlines by looking to the future and getting things done before they're needed, so when the time comes, I can focus on polish and integration. But then some dick in management notices that I did this thing in a day, doesn't count the prep-work, and hands me an impossible deadline that's already promised to a customer...

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

#62

Post by quelsolaar »

amirkdv wrote: post #46
quelsolaar wrote: post #21

I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud o…

I can't tell if this is sarcasm or not. If serious ... This seems like a reckless way of regulating your motivation at work IMO. I don't mean to be snarky. But it really does put a lot of risk and cost on your colleagues, doubly so if you're leading a team, /and/ puts a lot of risk on your own career and reputation. If you need to over-engineer everything to stay motivated, you need a different job. A job where the _…

Who said i don't already have that job?

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

#63

Post by amelius »

titzer wrote: post #28

A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit [1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. Th…

Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?

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

#64

Post by JeremyNT »

tcoff91 wrote: post #26
quelsolaar wrote: post #21

I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud o…

Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.

... but also 3x the job security, perhaps?

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

#65

Post by titzer »

amelius wrote: post #63
titzer wrote: post #28

A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit [1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. Th…

Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?

Sometimes writing asm is just to get access to certain instructions or states not exposed in C. Particularly on embedded platforms. But generally, I agree that you should write most, if not all, in a higher-level language first.

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

#66

Post by lazide »

ppati000 wrote: post #14
simonbarker87 wrote: post #7

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…

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?

If management thinks it’s easy and it has big business value - they’re going to understaff it and expect it done tomorrow. Which is gonna hurt someone, and it usually isn’t the execs.

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

#67

Post by razzimatazz »

SavantIdiot wrote: post #60

What the author is outlining is a management paradox when managing by indicators , combined with some egotrippin'. It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip t…

My favorite is the times when I have dived in to fix performance of the system, found the place where I or a team mate left in a terribly unnecessary loop or increased complexity, quickly fix that and report back the great success in improving performance! Great indicator there for management.

I think the person/team following such a path does deserve accolades but if their ego blocks them from admitting honestly how difficult the work was, others will sense (maybe not management) the dishonesty sooner or later and problems will eventually develop.

I always give my team mates accolades and offer them excuses when they've messed up: "we were really busy that week", "its easy to forget to bump the minor version", "that manual testing work is tough". If they choose to ignore the offered excuse and go silent with their ego I think it stands out sorely over time. If they accept it then we all know what we have to improve on next time.

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

#68

Post by Fiahil »

Since I started working as a “consultant”, I started using the exact same Evildoer tricks ! I’ve said “No” to partners coming with easy & urgent requests, just because I wasn’t feeling like dropping my work and doing these. To the juniors’ disbelief, I _gained_ their respect.

This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked for it..” song. Nope, he’s just being evil. I have other plan, good luck.

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

#69

Post by LordDragonfang »

mateo411 wrote: post #30
le-mark wrote: post #17

A 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.

Yes, there are a lot of dysfunctional organizations out there. That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.

>but it's probably not helping out the organization.

If this strategy is useful, the organization doesn't care about you anyway.

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

#70

Post by 8ytecoder »

sam0x17 wrote: post #33
simonbarker87 wrote: post #7

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…

I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it through to the logical conclusion. Many people have difficulty even conceptualizing the steps that need to be taken in order to solve a problem. If you are smart enough to get help from someone in devops and understand the advice they gave, you're doing the same…

That's pretty much it. There's a certain category of people with a certain attitude towards debugging. You have to be able to break it down into steps - sometimes from "first principles". Then work up and identify where the issue is and how to resolve it. Sometimes it requires looking at logs and simulating production conditions and other times you may have to understand low level network stack.

I still remember the time trying to reproduce and fix a certain issue. We had a 3-node cluster mysql database setup with one main and two replicas. The replicas are read-only. If one replica goes down, reads shouldn't be affected at all. We had an application layer on top of this to coordinate and enforce these requirements. Every which way you look at the code, there's no reason why this shouldn't work. And yet, when one node went down in production under a very particular circumstance with the network, it took down the entire cluster - not that the cluster was not reachable - it wouldn't allow reads and just hang.

Tracing it took me down the hole of understanding the precise network issue (fading memory - I think the machine wasn't responding back and tcp kept retrying) + linux tcp setting (I think tcp_delack_min) + a java networking setting + how thread safety was setup in the application (do not use synchronized at the method level). It took a week to diagnose.

Recently, there was a minor issue with adapting a sample Spark UDF to work with our setup and it took the developers 3 weeks and they kept giving up after every try.

Post reply on HN