Live data from Hacker News

Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

web.mit.edu

271–280 of 446 posts

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#271
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

The educational system i was put through was set up to teach that outcome scales more or less linearly with effort and time. The first lesson after graduation is that this is not so. Increased effort and time most likely primarily yields more effort and time being expected of you with lagging compensation.

Value and opportunity are chaotic processes in effort and time.

All we can do is to try to maintain the levels of workload such that we have clarity of mind to seize opportunities when they reveal themselves. Honest and balanced colleagues help there, but that is ultimately a missions for yourself only.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#272
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

Or worse: People get stuck quite frequently and ask you for help pretty quickly. You get everyone unstuck, but your own work falls behind and when your boss's boss asks for metrics on developers you have few points delivered and few LOC changed. Your boss tries to explain, but your head is the one that rolls next when layoffs happen.

Great workers know when they can help others without falling behind themselves. Or have good communication skills to explain what they were doing.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#273
This is a failure of internal accounting. If maintenance is reduced, the value of capital equipment declines faster. Production reject rate increases. Accounting systems are not good at catching that.

Repetitive manufacturing operations which capture many metrics about what a steady production process is doing may capture such info. Non steady state systems have a real problem.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#274

Earlier quoted context omitted.

> Work with honest, intelligent people This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader. I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.” My god how I’ve found that working wi…

Totally get where you're coming from, but it's also kinda splitting hairs. Being reasonable is part of being intelligent. Surrounding yourself with intelligent people doesn't necessarily mean "surround yourself with the highest IQ individuals you can find." (not saying you're saying that explicitly, just that i think you're just using a definition of intelligence that's narrower than the parent) Working well with oth…

> Being reasonable is part of being intelligent

Not in the slightest, those two are quite separate.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#275
post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

If the headline were actually true...

Agree with your point, solving problems gets you points, avoiding them doesn't. My cynical view of the headline is, that a lot of people do get credit for solving problems that never really existed, simply either fabricating (intentionally or not) easy to solve problems or vastly overblowing problems they just happen to have a "solution" for.

If ypu successfully fight a fire, you are a hero, if you prevent fires it is just normal and nothing special.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#276

Earlier quoted context omitted.

For extra points, keep the sane solution in a secret source file, then implement a compiler which generates the obfuscated spaghetti. :-P

I kind of did that once. For a proprietary language that didn't support functions and had very limited support for loops (mostly labels and gotos, it is sold for way too much per seat for a niche industry and the language and implementation are awful). I needed to implement something that was too tedious to write out by hand (~1500 lines of this nonsense) so I made a Python program that spit out the code I needed. Th…

> "You can't be sure a loop will do what you want it to do."

From my limited experience with "proprietary bullshit languages that only exist to hook customers", there's ways to mess up how loops work in the language. So maybe those senior engineers actually know what they're talking about.

I've seen "languages" that treat variables differently based on whether they have uppercase letters and underscores. Before I saw this in action, I believed the seniors telling me to "never use uppercase letters ever" were insane...

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#277

Earlier quoted context omitted.

I found the idea Scrum being efficient when done right was true at one company I worked at. Everyone was committed to the process, the Scrum team included debt as a priority for 20% of the effort and everyone had a fairly accurate velocity that we could bake in an additional 20% of your work as your own interests, so stakeholder priorities filled that remaining 60%. Then we would pivot in some Sprints if any epic/tea…

I don't think it can't be done right, but it's been cargo-culted pretty hard at Fortune 500 companies. But the best scrums I have ever done have just been literally post-it notes on a whiteboard - I think Jira ads a level of complexity that is unsustainable for most orgs.

In my 17 years in the industry I saw working agile twice. Both were small places, both used post-it notes. Both were consultancies, each team dedicated to an independent project.

Everything else, world-class, public, private, consultants or not... was a joke.

I don't think cross-team collaboration works in agile. Either one plans ahead, or everything becomes an unpredictable mess.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#278
post #86

Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet. This is a management problem, because no-one wants to be accountable for a repeat incident even if it was rational to be working on something else more important.

> Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet. I've heard this called "institutional scarring" in a blog post somewhere. The idea is a small wound can be replaced with tough inflexible tissue. The jist of the blog post was that just because something happened, doesn't mean you have…

I called the dev form of this “tech trauma.”

e.g., You were tasked with working on a ball of mud and it was miserable, so the next system you get the chance to build has to be the most scalable, modular, and cutting-edge thing ever, just to be safe.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#279
It even gets worse sometimes. You detect a problem that poses a risk to your organization, manage to convince management that it's dangerous, you get some time to fix it and you fix it. Then, because it's fixed, nothing will happen. And then management frowns upon it and wonders why all this effort was needed.

A big scale example of this was the Corona vaccination. After the large vaccination campaign in 2020, hospitalisation numbers stabilised to levels that were also seen sometimes in previous years during some flu epidemic. Which led to criticism from some people, who said that this was evidence that the whole Corona epidemic was a hoax, organised by a conspiracy of medicin manufactories and policitians who wanted to scare people to gain more power ..

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#280
post #112

Another variation on the problem is the over-allocation of resources to preventing problems which actually happened once, versus those that are more severe but haven't happened yet. This is a management problem, because no-one wants to be accountable for a repeat incident even if it was rational to be working on something else more important.

This is basically how all bureaucracy comes about. In startups everything is so new that problems haven't had time to happen. In big tech, because they have a tremendous knowledge base of previous incidents and the resulting safeguards, every single step seems mired in bureaucracy.

This is why death is a feature and not a bug.
Post reply on HN