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

151–160 of 203 posts

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

#151

Post by pm90 »

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…

> developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.

Thank you for saying this. I haven’t heard it being said anywhere else, but knowing people that you can DM and ask about things first is “socially” a better strategy than an ask tons of questions in a public thread. What’s also worked for me is to have a private channel meant only for developers (no manager, PM etc. Just devs, free to ask any question without judgement).

People instinctively assume the junior person asking questions is less competent.

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

#152

Post by pm90 »

underwater wrote: post #131
cbushko wrote: post #102

Earlier quoted context omitted.

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.

Wow. I’ve understood this viscerally but it’s great to be able to describe it explicitly this way.

Having been both on the sending and receiving end of this, I’m somewhat reflexively hesitant to ask others to do things for me “on a top priority” unless there’s a really good reason (most often a production outage).

I take a somewhat gentler view in that requesters may often not be aware of the effort required by you. If you’re able to communicate that, very often that’s enough for them to reconsider their ask or it’s priority.

Of course there will be a handful of jerks who always want their requests to be prioritized.

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

#153

Post by wruza »

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…

I agree. Whatever level a developer is, there is a mountain of tedious work to be done. Asking is more like getting directions, not taking a free ride. Good developers grow in a method negotiation skill, not in a complete autonomy, because exact methods and their details may and will be very important for future integrations. In a complete isolation, no plural number of seniors will create a good system. It’s strange to expect that from noobs.

Of course there is always a level of knowledge too low to participate constructively, but that’s another scope (fire your HR along with yet another zero-skills guy, etc).

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

#154

Post by qwertywert_ »

Yea maybe if managers didn't pressure so hard on new features when they know 100% that there are so many bugs needing fixing + tests need writing, and general stability issues.

Shit will hit the fan but that's how they are directing the course of the ship, early in my career I just have to go with it right now It is not worth it for me to try doing the "easy" things when they aren't valued..

Working like this is too stressful though even if you look like a hero.

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

#155

Post by krab »

quickthrower2 wrote: post #141
Fiahil wrote: post #68

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 f…

I imagine this works as long as you can say no, requiring good financial management and marketing skills. Easy to say no when you are turning away work.

It works both ways as a positive feedback loop.

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

#156

Post by Shugarl »

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.

I've gotta ask : How do you read these quickly ? It'd take me so much time to read even half of the articles from threads I'm somewhat interested in, I can't help but feel that trying to get the gist of it by reading the comments is the most efficient way for me. Well, it would've been, if the people commenting actually read the article.

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

#157

Post by simonbarker87 »

AQuantized wrote: post #22
civilized wrote: post #12

Earlier quoted context omitted.

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

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

I read the article, doesn’t mean I can’t leave an anecdote and reiterate the same point.

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

#158

Post by brundolf »

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…

It varies widely by company culture. At a previous job we had a Slack channel called #dumb-questions, specifically for exactly this type of thing; a no-judgement zone where everyone could share the job of filling in each other's mental gaps (one problem with finding just a single friend to ask questions of is that you start to worry about bothering them too much; this way no one person was a choke point)

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

#159

Post by fridif »

klyrs wrote: post #61
version_five wrote: post #19

Earlier quoted context omitted.

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

In my fantasy world, the developers are the ones who make promises to the users and thats it

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

#160

Post by ngc248 »

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.

true, the problem is when the same person is both the arsonist and the fire fighter. It becomes a habit for some people to show "heroic" effort. No effort is done to see who caused the issue, the spotlight is usually on who fixed it. These "arsonists" also have higher velocity in delivering features since they don't care about quality, so they get into the good books of upper management.
Post reply on HN