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

101–110 of 203 posts

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

#101

Post by sam0x17 »

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…

> The problem with encouraging developers to speak up when they're stuck

I'm not actually encouraging that. I'm encouraging them to not have imposter syndrome when they actually manage to fix something, regardless of their methods. The ones who ask stupid questions, in my experience, don't end up fixing the issue ever because they don't understand what they're doing enough to ask the right questions, so they wouldn't be at this point.

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

#102

Post by cbushko »

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'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" issues disappear when you ask for these things. I personally think it is only critical because someone wants to dump the problem on you so that they can go home to their families.

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

#103

Post by grawprog »

3pt14159 wrote: post #88
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…

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

My wording was maybe a little strong, I did try and clarify a bit in another comment below but, I was maybe a little bit unclear and think I might not have fully understood the point you were making. I admit, I did take it as juniors should just shut up, which i admit probably wasn't the most good faith way to interpret it.

I agree there's a difference between the kind of question like the one above vs. something like 'Why isn't there a check in there before unpacking a record?'

The first question is basically 'Teach me stuff I should know' the second is more along the lines of 'Why do we do it this way?'

And there does come a limit, if after a month they're still asking the same questions, not really seeming to have learned anything, it's probably not going to change.

I dunno, really I guess it usually comes down to the person and I hate to say it but, how annoying I find the questions and the person's behaviour.

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

#104

Post by BurningFrog »

junon wrote: post #36
BurningFrog wrote: post #34

Earlier quoted context omitted.

> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Or find new management, if this is a consistent problem. Unless you happen to be the management hiring boss, that means finding a different place to work.

This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.

I agree finding good management is a hard problem. It's also a very important one for engineers to solve.

If you don't put effort into finding management that you work well with, you probably won't find it.

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

#106

Post by ipnon »

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…

Painful experience has taught me that the solution to this problem, being surrounded by people who don't take me seriously, is only to break out from them and leave them forever behind. Years can be taken from you by inactivity in this regard.

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

#107

Post by [deleted] »

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…

[deleted]

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

#108

Post by mdausmann »

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 the small stuff. grow up.

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

#109

Post by GuB-42 »

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 actually like one-off requests from management. Not all requests, I try to deflect the easy/"easy" ones, explain why the hard/"easy" are hard, take the easy/"hard" ones because it would be stupid not to and actively seek the hard/"hard" ones.

To explain why "easy" problem is hard, the best way I found is to find a precedent. Like "remember that supposedly easy project that ended up costing so much money to the company, that's what you are asking me right now, I can do it, but don't expect a different result", or "No, I can't finish it by 10pm, last time it took 3 days, it will also take 3 days this time, if you want it to be done by 10pm, find someone better than me or reduce the scope". The goal, if you get the task, is to make it clear it is harder than it looks (bonus point if it isn't).

With one-off tasks, you get to learn a lot in many fields. Being a jack of all trades is interesting too. "Interesting" work can become stale if you are doing it for too long. You may think that spending all day working on a state-of-the-art project that make inspiring YouTube videos is interesting, but it can quickly become routine. But if you are recognized as a wild card, you can get to work for some time on that fancy project, maybe just because there is a library that crashes or because they need you do whip out a quick UI, but you get to see the environment, work a bit, and see if it is as interesting as it looks, and if it is, and if you really saved their ass, you have your chance of getting in the team, especially if it really is your field of expertise.

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

#110

Post by yarky »

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 matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.

That's eye opening, thank you! I've once worked on a "hard" statistical model and all I got from my boss' boss was a "who cares" face. Then he was so happy to see our (to my view) dumb web app, he didn't even realized it was the model behind that app that consumed 80% of my time/energy :/

Post reply on HN