News for hackers. Stuff that matters.
Re:Evil programmer's tip: avoid “easy” things (2016) by version_five on Wednesday July 28, 2021 @04:40PM (#27989432)
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.
Re:Evil programmer's tip: avoid “easy” things (2016) by klyrs on Wednesday July 28, 2021 @05:47PM (#27990164)
God, this hurts. I pride myself in avoiding deadlines by looking to the future and getting things done before they're needed, so when the time comes, I can focus on polish and integration. But then some dick in management notices that I did this thing in a day, doesn't count the prep-work, and hands me an impossible deadline that's already promised to a customer...
Re:Evil programmer's tip: avoid “easy” things (2016) by fridif on Thursday July 29, 2021 @02:41AM (#27993546)
In my fantasy world, the developers are the ones who make promises to the users and thats it
Re:Evil programmer's tip: avoid “easy” things (2016) by jjk166 on Thursday July 29, 2021 @10:16AM (#27996826)
Hell, I'd settle for managers simply being held responsible when the impossible deadline they set wasn't met.
Re:Evil programmer's tip: avoid “easy” things (2016) by ravenstine on Wednesday July 28, 2021 @08:50PM (#27991535)
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 think they're overpaying me because it wouldn't seem to them like I'm doing anything more of the time.
Re:Evil programmer's tip: avoid “easy” things (2016) by toast0 on Wednesday July 28, 2021 @09:01PM (#27991609)
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) by dreadlordbone on Thursday July 29, 2021 @12:04AM (#27992669)
Recently one of my clients noticed something we had broken on their website. When they noticed it, we fixed it in a matter of minutes. They were so pumped on the response time they then left us a very glowing public review.
Re:Evil programmer's tip: avoid “easy” things (2016) by Lio on Thursday July 29, 2021 @04:57AM (#27994337)
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) by passivate on Wednesday July 28, 2021 @05:27PM (#27989965)
Indeed, thank your (figurative and literal) janitors and maintenance staff! :)
Re:Evil programmer's tip: avoid “easy” things (2016) by ineedasername on Wednesday July 28, 2021 @07:14PM (#27990953)
it's better to be a firefighter than a maintainer

Oh this is very true. I've achieved a pretty good reputation in my org getting called in when things have gone wrong somewhere. Not so much for typical day-to-day work.

Re:Evil programmer's tip: avoid “easy” things (2016) by ip26 on Wednesday July 28, 2021 @06:29PM (#27990580)
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) by chestervonwinch on Wednesday July 28, 2021 @07:15PM (#27990968)
Probably has to do with our brains preferring instant gratification over long term payoffs.
Re:Evil programmer's tip: avoid “easy” things (2016) by beebeepka on Wednesday July 28, 2021 @05:37PM (#27990064)
Indeed. Sometimes the saviour is the one responsible for the disaster but companies also need their heroes or at least that's how I interpret certain management decisions. Been on both sides of the fence.
Re:Evil programmer's tip: avoid “easy” things (2016) by ngc248 on Thursday July 29, 2021 @03:00AM (#27993658)
true, the problem is when the same person is both the arsonist and the fire fighter. It becomes a habit for some people to show "heroic" effort. No effort is done to see who caused the issue, the spotlight is usually on who fixed it. These "arsonists" also have higher velocity in delivering features since they don't care about quality, so they get into the good books of upper management.
Re:Evil programmer's tip: avoid “easy” things (2016) by booleandilemma on Friday July 30, 2021 @09:50AM (#28007941)
When trouble is solved before it forms, who calls that clever? When there is victory without battle, who talks about bravery?

- Sun Tzu

Re:Evil programmer's tip: avoid “easy” things (2016) by hutzlibu on Thursday July 29, 2021 @06:23AM (#27994794)
"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.

Re:Evil programmer's tip: avoid “easy” things (2016) by Dudeman112 on Thursday July 29, 2021 @07:40AM (#27995299)
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) by hutzlibu on Thursday July 29, 2021 @08:26AM (#27995611)
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) by jbn on Friday July 30, 2021 @09:42AM (#28007844)
the fire metaphor still works: we have arsonists (that build up tech debt or just bad practices) that turn firefighters (by fixing in emergency mode).

Of course not all tech debt is bad, the trick is know when to use it to good effect, not building it up everywhere only to pay it back at the costliest moment. It's all a balancing act.

Re:Evil programmer's tip: avoid “easy” things (2016) by casey_lang on Wednesday July 28, 2021 @11:29PM (#27992492)
Thanks for connecting these dots! You've put words to a situation I've experienced before but never fully grokked