Live data from Hacker News

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

yosefk.com

71–80 of 203 posts

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

#71
> One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.

This speaks to another effective career strategy, which is to focus on making the people you interact with feel good - about you, the situation, the company you work for, and especially about themselves. This is particularly important with first impressions and for people with whom you don't work very often.

"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou

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

#72
post #33

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…

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

I've seen many junior 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.

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

#73
I have different attitudes around things perceived as easy or hard. Things that are considered by many to be easy I pay extra attention to looking for details that may show it's not really easy to do properly.

Hard things I think and rethink to see if there's an easy approach or conceptualization that does less or something different achieving the same end goal.

As others have said, I also gravitate toward the hard stuff because it's more interesting. And if there's a complicated way of automating or otherwise have the machine do the work instead of myself, even if it takes longer and may only do once is still a good learning/hacking opportunity. Sometimes cool stuff comes out, like a partial Swift -> Java, or Java to C++ translator because I don't want to rewrite a suite of tests.

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

#74
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…

There is a bright side to this - you're also rather important to the company. You're in effect the 1 in "bus factor 1" of several key activities that nobody else wants to do and nobody else is really qualified to do. This should allow you to put your foot down more often, refuse overtime, demand recognition for contributing to prototypes and to be given more interesting work. Your managers may not care for you, but they care for the company (unless it's one of those cash burning shops, but that's an entirely different problem). After long enough, they should even come around to the idea of hiring a junior dev under your supervision and training to take care of the more lower-level tasks.

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

#75

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

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

#76
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 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 important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later.

And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help.

Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.

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

#78
post #45
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…

computing is a fraud, a CPU is literally a rock that we tricked into thinking

If a CPU is thinking, then all rocks are constantly thinking their rocky thoughts, contemplating the immeasurable eons of their existence. A CPU is, then, merely a rock which we have made to think some thoughts which are to our benefit.

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

#79

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.

Perhaps you can staff your firefighting crew with the effective maintainers. They've been oiling their valves, so they have time to spare helping fight the fire. This becomes doubly visible.

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

#80

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…

> 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 time. Then they become reliant on you, and stop thinking for themselves.

Post reply on HN