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

91–100 of 203 posts

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

#91

Post by a9h74j »

3pt14159 wrote: post #72
sam0x17 wrote: post #33

Earlier quoted context omitted.

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…

I'm a senior dev I say this only because I have to. The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for…

My intuitive response as I started to read this was a sort of "gentle-art" thought: Would it be helpful for someone to start their question: "I don't know if I should know this [already]..." ?

If the answer is [in context] indeed "yes", then that could help tune their threshold for when learn-by-self vs learn-by-others will be appropriate [again, in that context].

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

#92

Post by cbushko »

3pt14159 wrote: post #72
sam0x17 wrote: post #33

Earlier quoted context omitted.

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…

I'm a senior dev I say this only because I have to. The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for…

I think speaking up is fine. It is when ANY engineer is lazy and doesn't bother to:

  a) do any research before asking the question, 
  b) trying to understand the answer given or 
  c) doesn't follow the answer given.
I will help anyone that asks but if they are just using me for quick answers and never learning anything then eventually they will use up their credits with me. I cannot do their job and mine at the same time...

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

#93

Post by ineedasername »

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…

but if management/product view something as easy or hard

Yep. My job involves a fair amount of coding but it's geared toward data analysis. I might create something in a day with dozens of data points and look like a hero, while another project might take a week and the output is a single number.

Actually, yesterday it was two numbers, X & Y. (Upper & lower bounds on something). Deceptively simple in appearance to anyone consuming the information, but behind the scenes it took an order of magnitude more time to make it a dynamic model based on latest available data instead of a static hand-crafted analysis.

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

#94

Post by ineedasername »

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.

it's better to be a firefighter than a maintainer

Oh this is very true. I've achieved a pretty good reputation in my org getting called in when things have gone wrong somewhere. Not so much for typical day-to-day work.

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

#95

Post by chestervonwinch »

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.

Probably has to do with our brains preferring instant gratification over long term payoffs.

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

#96

Post by a9h74j »

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…

Years ago I realized I was the only person doing software (and original electronic hardware) in a group of 10 people; in addition the larger organization I saw was mostly mechanical engineers.

I imagined the term "programmer in a corner syndrome", to describe, among other things, the realization that one had worked for years and not one person had looked at one line of your code in all that time.

(In fairness, I primarily imagined the term, not so much felt it. I was hired in the first place because they first spent O(1million) on hardware and realized no one there could make it work.)

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

#97

Post by maerF0x0 »

at a job once we had a programmer do a gratuitously bad implementation that wasted over $400k of cloud spend. They got promoted for fixing it the following half.

My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists.

Law 6 Court attention at all costs - https://alexanderemmanual.medium.com/law-6-court-attention-a...

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

#98

Post by sharken »

8ytecoder wrote: post #70
sam0x17 wrote: post #33

Earlier quoted context omitted.

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…

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.

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

#99

Post by SavantIdiot »

razzimatazz wrote: post #67
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…

> I always give my team mates accolades and offer them excuses when they've messed up: "

I like that a lot!

Engineers almost always know when they've screwed up. No need to thunk people over the head: I've been thunked (and screamed at, and threatened, and humiliated) so many times that I made sure that bullshit ended with my management style.* Unless they do it repeatedly, or are totally unaware... those are some of the worst types of situations for me personally as a manager.

* to the best of my knowledge: blindspots abound, esp. across cultures.

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

#100

Post by cbushko »

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 feel your pain and I have been/am in your shoes.

Unfortunately, you will not get the kudos for things you build unless you spend time selling those projects. I personally hate this as I want to spend my energy on building things that make a difference.

Post reply on HN