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

171–180 of 203 posts

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

#171

Post by mjohn »

Rastonbury wrote: post #168

Effort estimation in agile development is supposed to solve this right? Does it not in practise? I'm not a developer, I've just heard of agile so I don't really know how its actually done in a big software org

No, because it's often very hard to estimate until you're actually working on something. It's common to get a consensus estimate that something is "easy" only for some poor developer to be left with something that is "hard" and takes much longer than estimated.

Also, something might genuinely be easy for someone who has worked on that part of the codebase before. But it could take someone new a long time to get up to speed, again making that developer look bad (this is not to advocate that only devs familiar with the code should work on it - you want to spread the knowledge around).

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

#172

Post by tralarpa »

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…

> If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail

Why? (asking as somebody who wrote a lot of asm)

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

#173

Post by hedberg10 »

cbushko wrote: post #102
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" i…

Not even dumping the problem. Many managers procrastinate by delegating. "I did some work on this" - No, you didn't, you just handed the hot potato to somebody dumb enough to take it.

Notice that the problem usually doesn't get solved by this. On the contrary: These managers "work" on something and the problems multiply, not get less.

Ask everybody who wants you to do work for a spec sheet. The above mentioned people can not do this.

Again what they are really doing is to appear to be working. That is the real goal. If you force them to actually do work (spec sheet), they'll disappear or deliver a hilariously bad one.

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

#174

Post by Dudeman112 »

hutzlibu wrote: post #170
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.

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

What metaphor would you use though?

Clearly there are companies praising heroic fixes, while not praising too much regular maintenance.

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

#175

Post by agumonkey »

Swizec wrote: post #27
agumonkey wrote: post #9

Earlier quoted context omitted.

I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework

“How to make this work within constraints” and “When to suggest alternatives with better constraints that require smol tweaks in requirements” is the whole point of engineering. “Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.

The thing is, at least in my experience, until you work for someone (and especially alone) you have no feel for what constraints are. Especially in programming today.. we have almost infinite compute power and storage (unless you develop something very very demanding) so it's so easy to go wild.

My only lone "pro" gig (and from scratch) I gained a knowledge about what is critical to make your project coast smoothly and how nothing else matters at all. You want clear / small / predictable changes toward a goal that can make you feel finished and solid rapidly. Unlike the neverending projects reboot with grandiose attempts at pure abstractions, that I used to do.

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

#176

Post by hutzlibu »

Dudeman112 wrote: post #174
hutzlibu wrote: post #170

Earlier quoted context omitted.

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

What metaphor would you use though? Clearly there are companies praising heroic fixes, while not praising too much regular maintenance.

I guess firefighting is the right metaphor, to fixing big errors in live production environments: it takes a different skill and mindset, to do things under pressure, nothing wrong to praise that.

But I think it is wrong, to talk down the job of actual firefighters, because:

"Clearly there are companies praising heroic fixes, while not praising too much regular maintenance"

that is a seperate issue.

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

#177

Post by jb3689 »

Working on hard problems isn’t always a rewarding path. I’ve seen plenty of very senior engineers get sucked into difficult problems with no additional resourcing only to be all but forgotten by the rest of the team.

I agree that working on easy problems is not worth your time though

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

#178

Post by [deleted] »

nyanpasu64 wrote: post #124
sharken wrote: post #98

Earlier quoted context omitted.

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?

[deleted]

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

#180

Post by BeFlatXIII »

mateo411 wrote: post #30
le-mark wrote: post #17

A lot of wisdom here. The hard things are almost always more fun than the easy things anyway. > To get away with postponing, you need an excuse: other supposedly urgent work; This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.

Yes, there are a lot of dysfunctional organizations out there. That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.

I’m here to make a buck for myself, not help the organization raise shareholder value.
Post reply on HN