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

161–170 of 203 posts

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

#161

Post by Fiahil »

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.

That's also another positive feedback loop between being "evil" and a consultant job.

If your work is perceived as "hard" and you let your client do the "easy" part, then you can increase your fees (bigger impact, and more ownership for them). If your fees are higher than normal, then your client doesn't want to bother you with the "easy" stuff. You get hired to do the "hard" things. Doing "hard" things often involve saying no to spurious/out of scope requests. Etc etc...

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

#162

Post by chillfox »

iamcurious wrote: post #81
civilized wrote: post #75

Earlier quoted context omitted.

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

I don't think so.

Just look at YouTube, lots of people comment on videos without actually watching the video despite it being right there.

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

#163

Post by chousuke »

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 am in a senior(ish) position and honestly I prefer talking things out with at least one other person before making larger decisions. Even if they're a "junior" person, explaining my ideas to someone helps me see the spots where I don't really understand the problem before I get to solving it. I especially like it when people disagree with me because it forces me to construct a real argument in support of my approach.

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

#164

Post by Lio »

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.

I remember John Sterman doing some system dynamics modelling on Oil Refinery maintenance vs actual fire fighting[1].

The results are just as you suggest.

Personally speaking I'd like to work at the software equivalent of Toyota. Where the whole organisation is constantly looking for feedback about development processes and how barriers to quality can be removed.

I think the problem is that how to get credit for the not having problems in the first place.

1. http://web.mit.edu/jsterman/www/SDG/maint.pdf

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

#165

Post by tluyben2 »

amelius wrote: post #63
titzer wrote: post #28

A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit [1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. Th…

Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?

For all our embedded work, we first prototype (something we always call a simulator which it kind of is) in typescript (used to be c#), then port to c => if we need 'less' (the c version is too big, too slow etc) we port it to asm. The advantage of this way is that we already know it meets the demands of the business (because we fleshed that out with the typescript version) and we have a low level version (c) that corresponds in functionality as we can test the 2 versions in the same way. Moving to asm is still a pain, but far less painful than other ways we tried in the past (like when I did a lot of straight to asm in the 80s, which was very painful, but there was no real way, except for some algorithms, to do the 'simulator' step here).

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

#166

Post by Lio »

dunkelheit wrote: post #82
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 articl…

I know it's management's job to manage and obviously they have their own agenda but...

In the past I've seen issues that I know will blow up at some point in the near-future.

Fixing thing them would also make 3 other existing low level problems go away too.

I've explained that to management but as they don't grasp an issue yet arisen they instead let me get half way through something else "important" when the issue strikes and I have to move onto fire-fighting and working through the weekend.

From the comments that doesn't seem to be uncommon. This is the sort of stuff that "agile management" is supposed to fix but because most managers (in my experience) still think in some form of waterfall.

Rule of thumb: The more senior a manager the more they think in waterfall because that's how they see their master plan unfolding.

I know there's exceptions but there aren't enough of them.

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

#167

Post by teekert »

I really like this advice and always op for the hard way, the way that solves things preferably for many others, once and for all in an elegant way.

At work, you have time to dive into stuff, for hours on end with little interruption. Very different from at home, with your hobby projects. I see work as a place where I do indeed solve very hard problems because I just have a massive amount of time and focus to spend there.

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

#169

Post by gjvc »

newsyyswen wrote: post #149
dexwiz wrote: post #135

Earlier quoted context omitted.

In the last 5 years I have probably written 100k+ lines of production code. My most celebrated feature was about 100 lines to store a single flag in a per user store.

Way to describe the engineer/business disconnect. You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier. I've seen people take this lesson to heart and go full Wally.

>I've seen people take this lesson to heart and go full Wally.

Who is Wally?

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

#170

Post by hutzlibu »

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.

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

The "hero" part of the firefighter comes from the fact, that they actually go towards real danger as part of their job, they often do unpaid and voluntarily. (A big fire out of control, is a very scary thing)

While the maintainance worker is usually not in danger, if he does his job right.

" It's a cultural issue that is very hard to combat."

So I do not really see a issue here to combat (when using this metaphor). The actual firefighters deserve their praise.

And if some companies are too shortsighted and praise the people heroically fixing their own mess, then I would use a different metaphor there, to adress this.

Post reply on HN