Live data from Hacker News

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

web.mit.edu

371–380 of 446 posts

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

#371

Earlier quoted context omitted.

Easy - half a$$ your code and when it breaks - swoop in, "fix things" (actually do it right) and play the role of hero! (I've seen so-called "Rock Stars" at places I worked do this over and over)

Would you feel good about being that kind of engineer, if the external validation was great enough?

You mean money? Abso-fucking-lately I would do it.

Moral points don’t pay my mortgage.

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

#372
post #362

Earlier quoted context omitted.

There's a famous green text on 4chan, where a user tells he got a sysadmin job which was so boring he started crashing stuff left and right and blocking an entire office even for entire days. By the end of the day he would plug back something and come out the "servers room" saying he fixed that and get everybody's praise. Even got him two raises in the span of 18 months. That's how crazy it is. I know a variation of…

I do not think you can trust everything you find on 4chan. Yes, dysfunctional companies exists. No, someone writing something on 4chan does not imply it ever happened.

Which is why I stated I've read about that on 4chan and not taken is as a truth.

That being I highly believe that stuff like this has and is happening right now.

I've worked in consultancy enough to know that many job's securities revolve around solving specific issues, and if the issues don't exist job security gets lower.

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

#373
post #362

Earlier quoted context omitted.

I do not think you can trust everything you find on 4chan. Yes, dysfunctional companies exists. No, someone writing something on 4chan does not imply it ever happened.

> No, someone writing something on 4chan does not imply it ever happened. Neither does it imply that it never happened.

You cant use it as an argument, just like you cant use a fiction book as an argument.

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

#374

Earlier quoted context omitted.

> 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. There's nothing wrong with elitism as long as it leads to initiation rather than gatekeeping. > My god how I’ve found that working with reasonable people is so much healthier. Could not agree more. Most people can be trained well to do any job required of them. What cannot be tr…

> What cannot be trained, and certainly at the behest of the employer is interpersonal skills. I think that those can be trained as well. The fact is that just acknowledging the issue requires a level of self-awareness that not everyone has, and training THAT as well requires being aware of it. External input and help from a specialist or a dear friend can get the ball rolling.

If you want a concrete example backing up your stance, consider the letter sent by Hans Reiser, discussed on HN in https://news.ycombinator.com/item?id=39042626.

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

#375

Earlier quoted context omitted.

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

Given the cost of the product, I considered all documented features fair game to use. If a bug was found because of a primitive looping construct, then they were on the hook to fix it (there weren't any, they worked fine). One of those same senior devs also didn't know basic logic rules like De Morgan's Laws and tried to "correct" my conditional logic and broke the program instead.

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

#377

Earlier quoted context omitted.

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…

MUMPS is a hoot isn't it.

Not MUMPS, that one actually has a standard. This is a straight up proprietary, maintained-by-one-company language. The concept isn't bad (that is, the objective of having a way to automate a formerly manual, and lengthy, set of processes), but the implementation is. Market capture, that's the name of the game for that company. They slip this into all their projects so even if they lose a follow-on contract they still get license fees for their proprietary components.

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

#378
On their start date, I would to tell new grads assigned SRE / DevOps roles that their job was thankless and at best if everything worked fine no one would notice them. However, if anything went wrong, they'd not only be on the hook to fix but would do so under tremendous pressure. "Who wants this responsibility?" I'd ask.

Those who decided they were up for it usually did a great job, about half opted out at the end of the conversation and were put in roles more suited to their ability to handle stress.

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

#379

Earlier quoted context omitted.

In high school I actually had a friend teach me this in a humorous way. In football we did sprints (the kind where you physically run) at the end. He said -- half ass the sprints. Then on the last sprint, run as fast as you can, you'll have more energy left, and when they see you running fastest you'll get all the credit. He was doing it as a joke, but lo and behold he out runs everyone on the last sprint by a lot, a…

In the case of football that might actually be a good lesson: save enough energy for the end of the game so that you can play best when the other team is tired. Of course you need to play the whole game, but if you play all but the last 5 minutes working just hard enough to keep a tie game, then you can pull ahead in the end. This only works in time limited sports though. Most real world situations are not time limit…

That really only works if the other team is terrible relative to your own. ‘Playing to tie’ a team that is an even match (or close to an even match) results in a competitive advantage for their side.

This does work ok for long distance competitive running, since the factors at play are time and metabolic rate and is missing the strategy present in team based ball sports like football, soccer, basketball, etc.

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

#380

Earlier quoted context omitted.

In high school I actually had a friend teach me this in a humorous way. In football we did sprints (the kind where you physically run) at the end. He said -- half ass the sprints. Then on the last sprint, run as fast as you can, you'll have more energy left, and when they see you running fastest you'll get all the credit. He was doing it as a joke, but lo and behold he out runs everyone on the last sprint by a lot, a…

In the case of football that might actually be a good lesson: save enough energy for the end of the game so that you can play best when the other team is tired. Of course you need to play the whole game, but if you play all but the last 5 minutes working just hard enough to keep a tie game, then you can pull ahead in the end. This only works in time limited sports though. Most real world situations are not time limit…

On sprint training. Me and a friend figured out that if you moved your arms fast whilst not running a full sprint it gave the appearance that you were trying very hard and coach didn't give you a hard time. Like most slackers instead of using the trick once in a while we over did it and the coach soon figured it out. The result was even more sprints. Needless to say our team too wasn't too good.
Post reply on HN