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

121–130 of 203 posts

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

#121

Post by yarky »

grawprog wrote: post #90
megablast wrote: post #80

Earlier quoted context omitted.

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

I agree both as a junior and as a senior human.

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

#122

Post by toast0 »

ravenstine wrote: post #119
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.

Reminds me of moments I had early in my career where I was the hero for fixing problems I caused. :) That company didn't have code reviews and my bosses weren't very technical, so it was pretty easy to pretend like I wasn't at fault for anything. Sometimes they'd figure out that I caused the problems and even then it didn't seem to really matter. If I had the skills I have now 7 years later, my bosses would probably…

If you don't get enough praise for not breaking things, get a days since a workplace accident sign, and update it every day.

Set it to zero when you break something.

Edit to add: you should be able to get some praise (or at least self-praise) at milestones like 30/60/90/180/365 days without an incident.

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

#123

Post by gilbetron »

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've never worked at a place that treats juniors like that, so my experience is opposite of yours. It's totally fine for the more senior dev to push back and say, "I think you kind figure this one out, maybe look into X", but juniors should be asking questions, it's one of the primary ways to become un-junior.

I've never even heard of a junior fired for "asking too many questions".

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

#124

Post by nyanpasu64 »

sharken wrote: post #98
8ytecoder wrote: post #70

Earlier quoted context omitted.

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.

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

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

#125

Post by z3t4 »

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…

They wont let you work on the interesting projects because they can get much more value out of you doing other work.

Write down everything you've accomplished, including the stuff others have got credit for, and also the things you got blamed for, and word it like "was responsible for" and "learned".

And be a bit "humble" about others stealing the credit, instead of "I did not get the credit I deserve", say "It was Joes idea, I just wrote the prototype, evaluated the market, launched the MVP, talked to customers, iterated on and improved the product, helped it grow to 2 million recurring monthly revenue, and helped it expand into five continents, and I trained the staff that is now working on it. But all credit goes to Joe for coming up with the idea and inspiring me to work hard, and the new staff for doing such a good job"...

Make sure everyone know what you can do. Then find another job. People will talk, and they will say - yeh he did all those things, wow.

The only way to make everyone around you change is to change to another company, with a new picture of what you can accomplish.

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

#126

Post by Subsentient »

mdausmann wrote: post #108

This is bullshit. There are any number of 'easy' things that need to get done. The discipline in being a grown up no bullshit engineer is to do all of these easy things well, without errors and with appropriate test coverage. If you are in my team, I will appreciate and reward your maturity and attention to detail. What I don't want is somebody who always want's to work on the 'interesting' problem at the expense of…

I agree with you, though sadly HN doesn't. Some days you're just beating your skull against a brick wall recompiling 3rd party libraries till 5pm, some days you get to write the big exciting part. That's life. That's the job. Accept it or move on.

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

#127

Post by SilverRed »

reidjs wrote: post #113
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…

Please don't do things like this, it makes it harder for your team. Find the challenge outside your work if you need it. Just do it the straightforward way.

Agreed. I often see this kind of work from some developers and I always have to send it back. People who think the best way to fix a minor bug is to rewrite the whole system or to stick on a second system that duplicates loads of logic.

Sure, if the task is to rip the system to shreds and improve it, go ahead. But often I look in to it and see the problem can be solved by fixing a single line that was wrong.

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

#128

Post by robertwt7 »

> So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.

OMG this is sooo true, my first company does not have any product manager or project manager. My boss who is one of the management always try to "impress" other management by saying yes to some stuff that they challenge him: "can you do it?", then he would say "yes it will be finished in 2-3 days", and then he would come to me and say "we need to impress them", again and again until i'm sick of it because we just went away from our sprint and planned projects.

Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there.

best of luck tot hem

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

#129

Post by stadium »

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…

> 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

It's also important to know if it is a bug or incomplete implementation of a feature. Sometimes the code is over engineered or there are no docs to help understand its intent.

If junior devs get fired for asking questions, or because that makes them look like idiots, I'd take a hard look at whether they have the support needed to set them up for success. Maybe the solution is actually "don't hire Jr devs" because the organization isn't able to support them.

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

#130

Post by Ancapistani »

danuker wrote: post #45
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…

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

You’re oversimplifying.

We didn’t just trick a rock into thinking - we beat on it until it was really thin, shoved a little bit of lightning inside of it, then tricked it into thinking.

Post reply on HN