Evil programmer's tip: avoid “easy” things (2016) • Hacker News Board

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

#81

Post by iamcurious » Wed, Jul 28, 2021, 10:36 PM UTC

civilized wrote: post #75

AQuantized wrote: post #22

Earlier quoted context omitted.

He explicitly says this in the article. I think the majority of commenters only read the title.

> I think the majority of commenters only read the title. I've lost count of how many times this has happened. In one case, I went through and read several dozen comments on an article. No exaggeration: all commenters (100%) said nothing whatsoever about the article's text. They were all just holding forth on their own opinions and experiences related to the headline.

Maybe if the article was right here instead of a click away, more people would read it.

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

#82

Post by dunkelheit » Wed, Jul 28, 2021, 10:41 PM UTC

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 article suggests). Then ideally you reach some kind of compromise (sometimes these requests are urgent and you are the best person to handle them). If instead they say "no, I want you to do this urgent thing and complete your other projects on time, here is a nice weekend that you can use", then it is time to look for a new job.

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

#83

Post by jonplackett » Wed, Jul 28, 2021, 10:45 PM UTC

The Elon Musk Doctrine

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

#84

Post by irrational » Wed, Jul 28, 2021, 10:49 PM UTC

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…

> if management/product view something as easy or hard.

This applies not just to work done, but work to be done.

Once the business people asked me to do something that turned out to be extraordinarily difficult. Afterwards we were talking about it and they mentioned that they considered asking me to do it a different way that would have achieved the same goal, but they thought the second option would be harder, so they only asked me to do the first option. The second option turned out to be extremely easy and I could have finished it in 5% of the time option 1 took.

This applies outside of programming as well. One time I was building kitchen cabinets for a remodel. I gave my wife 2 options for the doors. She went with the more difficult option. After they were done she admitted that she preferred the other option, but thought it would be harder so she went with the less desirable option to save me work. Facepalm.

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

#85

Post by rlayton2 » Wed, Jul 28, 2021, 10:50 PM UTC

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 feel your pain.

On one small thing. I've started asking people where they want to be on the fast / polished scale.

I've always struggled with this. Have budget for a prototype, call is a prototype through speccingand end up with a client complaining it doesn't do everything perfectly. That's on me for not being clearer which is why I'm trialling the scale above. See how it goes!

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

#86

Post by mlader » Wed, Jul 28, 2021, 10:54 PM UTC

megablast wrote: post #80

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…

> 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. Until you get the person who questions everything, draining all your…

This can usually be solved by coaching, not only for this person, but for the teammates who are spending more time answering questions.

For coaching the questioner, I ask them how they approach finding information, and recommend they time box their exploration, and only ask their question if they've given it a good try. I I also will describe my personal workflow to find answers when answering their questions.

For coaching the rest of the team, I often suggest they ask "what have you tried so far?" or "where have you looked so far?" before just giving an answer. This can help show knowledge gaps, and oftentimes the questioner will take another look and discover the answer themselves.

And yes, if they never get away from this behavior even after getting feedback multiple times, then that turns into a different sort of conversation.

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

#87

Post by ineedasername » Wed, Jul 28, 2021, 10:58 PM UTC

Maybe? Sometimes? But the article seems to imply a very high level of control over the tasks & projects that come your way.

In reality, I (and probably a lot of people) don't have that choice. I end up looking like a hero when I can deliver quickly on a "hard" easy thing, and look like I'm slacking off when an "easy" hard thing comes my way. Fortunately I have had bosses who listen when I explain the difficulties of a project, but they still get frustrated on occasion when an ostensibly simply task snowballs into something massive more complex once you dig into the details.

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

#88

Post by 3pt14159 » Wed, Jul 28, 2021, 10:59 PM UTC

grawprog wrote: post #76

3pt14159 wrote: post #72

Earlier quoted context omitted.

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 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 this type of question it makes you look bad. I'm not saying it's the end of the world or anything, but we should at least be realistic about how juniors are treated. A private, friendly slack message is much less likely to get them fired than a post in a channel or pull request.

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

#89

Post by code_duck » Wed, Jul 28, 2021, 11:01 PM UTC

I’ve had first-hand experience confirming this and another field. Sometime in my 20 years of artistic glassblowing, I believed that people where to find it moderately impressive if I made intermediate level work very solidly with a flourish. I thought this was an alternative to making work that was more overtly at a higher skill level, and a better choice than making less solid work reaching above my skill level. It turns out that as the article states, working on anything cutting edge, especially ambitious publicized projects, would have been much better for gaining notoriety.

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

#90

Post by grawprog » Wed, Jul 28, 2021, 11:06 PM UTC

megablast wrote: post #80

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…

> 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. Until you get the person who questions everything, draining all your…

I guess maybe I could clarify. I do agree there's a difference between a person who asks a lot of questions and one who just asks questions out of laziness. There's a difference. If a person is asking a lot of questions, especially the same ones over and over without any clear signs of gaining understanding, yeah there's definitely a problem, that person is dragging down work then.

But I do think there's a difference. If a person generally asks a lot of questions, but there's clear signs of improvement and they're trying to pull their weight, then I really don't see it as a bad thing.