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

131–140 of 203 posts

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

#131

Post by underwater »

cbushko wrote: post #102
jofer wrote: post #29

Ouch. This hits close to home. I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems) It's because I'm seen as a technician, not an engineer or a scientist. That's…

I've been the 'fixer' in so many situations and I have a tactic for this. I ask them for the following things: - a ticket to track the work - that they get approval from my manager to drop all of the work that I am currently doing and affect other peoples timelines - that they document the problem and how they want it fixed - that they get approval for the extra hours required You'd be amazed at how many "critical" i…

I've heard the term "effort asymmetry" used for this phenomenon.

If someone can spend five minutes of their own time to create a days worth of work for you, they will do that without any hesitation. If you require them to spend fifteen minutes instead, then all of a sudden these urgent requests go away.

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

#132

Post by tfigueroa »

nyanpasu64 wrote: post #124
sharken wrote: post #98

Earlier quoted context omitted.

People in the category you describe are few and far apart in my experience. To me solving a problem like the one you describe here is one of the biggest joys of working with IT. Though it seems to come at the expense of being able to design large systems. Not sure if there is a way to be good at both.

How does skill at deep-diving into complex unknown technical problems hurt the ability to design large systems?

I’d guess that taking the time to deep-dive a problem takes away from time to design large systems.

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

#133

Post by granshaw »

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…

> Motivation is the most valuable resource in programming

I've never seen it phrased like this before, but I like it and there's truth to it.

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

#134

Post by [deleted] »

3pt14159 wrote: post #88
grawprog wrote: post #76

Earlier quoted context omitted.

I really don't think I agree with this. The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first. Whatever the work is, the impo…

That is what I believe you believe and I understand where it is coming from. I've managed juniors and I know they make mistakes. That said, if a junior brings up a question like "why does this error for some tests, but not others?" records = some_orm_thing() some_model_ids, other_ids = map(list, zip(*records)) The answer is obvious. Some tests return no records for the ORM thing and that doesn't unpack. If you ask th…

[deleted]

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

#135

Post by dexwiz »

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…

In the last 5 years I have probably written 100k+ lines of production code. My most celebrated feature was about 100 lines to store a single flag in a per user store.

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

#136

Post by jodrellblank »

quelsolaar wrote: post #62
amirkdv wrote: post #46

Earlier quoted context omitted.

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?

You said it.

"My job doesn't stretch me."

"Why don't you get a job which stretches you?"

"Who said I don't have a job which stretches me?"

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

#137

Post by ffitch »

For me, it works the same way even if others are not involved. If I do a tricky thing in a matter of hours because I got lucky I tend to feel happier about it compared to if I’ve done a simple but mundane thing over the weekend. Perceived complexion brings excitement.

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

#138

Post by casey_lang »

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.

Thanks for connecting these dots! You've put words to a situation I've experienced before but never fully grokked

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

#139

Post by quickthrower2 »

dunkelheit wrote: post #82
jofer wrote: post #29

Ouch. This hits close to home. I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems) It's because I'm seen as a technician, not an engineer or a scientist. That's…

> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! The thing is, saying no to requests from management (if it is your management of course) is going to hurt your career prospects too. Instead you should say "sure, but this thing will move the completion date of this hard and extremely important project X days, is it ok with you?" (Not having any hard and important project in the works? Fix that ASAP as the articl…

There needs to be a process where you can feedback too, like 1-1s and have some influence over what happens. If not, you need to switch jobs. Zero influence jobs where you are directed to so X and Y but your opinion doesn’t count really really suck!

You want to be somewhere where they make sane decisions so when management says “fix this fire” it’s genuinely serious and a rare event.

There is a holistic aspect to this - other things happening in the company, the culture, the history, the industry and even the general culture of the country / city will come into play.

Post reply on HN