sdiupIGPWEfh

Brings back memories of reading "Fine Structure" while it was still a work in progress on Everything2. "Ed stories" was great too. Looks like there's a lot to catch up on.

And then there's https://qntm.org/hatetris

> tie their bonus to hitting some kind of OKR even though that goal may be put on the back burner halfway into the quarter

Been burned by this a couple times. Especially infuriating after all the effort that goes into crafting "acceptable" OKRs every three months. Mandatory training sessions, the stress of identifying metrics that are both measurable & meaningful, multiple one-on-ones with management to review them, acknowledging and signing copies, and then toss it all in the trash because we're changing priorities. But it's the core of your performance review and tied to compensation. The hell.

How common is this nonsense?

I've seen that these estimates are inevitably used to judge the performance of teams and individual contributors. If you ask why developers put up with this, my answer is that it's not done openly or transparently. Yet I see it happen, and it is at times acknowledged in hushed tones among insiders. No one's explicitly being promoted or awarded bonuses based on their ability to meet ticket estimates or anything like that. However, a team's failure to achieve predictable burn-downs will be used to justify intervention, and an employee's failure to sustain a certain velocity will be used as part of firing decisions. It's a pulse for management to watch and leverage when needed.

The likes of SAFe argue otherwise, having you plan out and commit to _three month's_ worth of stories in advance. It's supposedly still "agile" because the plans you've "committed to" are expected to change as you go. Oh, and it's set up such that other teams are expecting to be able to depend on your team delivering stories by the sprints you said they'd be done, of course. No problem, as those dependencies probably existed anyway and now they're made explicit and public. As long as you've delivered the increment of work you'd promised when the three months are up, nobody gets fired. Totally agile.

How do you approach estimating effort for this sort of thing? I find it awkward enough in Scrum to guess up front how many days of effort research will take and commit to delivering a plan or design by the end. If you have clients and aren't strictly bound by someone else's framework, they still want some rough idea how long research will take. Especially if the client is footing the bill. If the research is un-billed time, then the estimate is critical to you. What do you do?

What percentage of that insurance doesn't involve arcane rules about what's covered? My parents recently learned, following my dad's heart attack, that our town's ambulance was considered "out of network" and told they should have shopped around first. I had the pleasure of overhearing this conversation. Combined with the fact that many rural and suburban folk can't afford a $20 copay for a regular checkup let alone thousands of dollars for their deductibles, I put little confidence in that 90% coverage.

> Engineers typically are more interested in: frameworks, languages, algorithms, performance, technology of the day, etc.

As a software engineer myself, I think I'd go mad if I had to work with fellow engineers who were that stereotypically one-dimensional. Frankly, even the nerdiest of kids whom I went to college with that chose to present themselves as such had broader interests than that. I got into this field myself because I liked solving problems and was half-decent at doing so with math and computers, which hardly excludes caring about customer experience, messaging, ease of use, and business value.

If I'm choosing to work at companies with products aligned to my interests and values, and if my day-to-day work actually matters to the success of the product, why would I not care about customer experience, etc.? The success of the product or project will ultimately reflect on me, so frankly, I'm going to have strong opinions about what work the PMs are trying to push on the team (maybe not literally push, but at least pressure) and how that work is then communicated back to the customers and stakeholders. The engineers who don't learn to give a crap about all that are setting themselves up as sheep.

Take back your data and kiss latency goodbye. When you deploy Boots™ on The Ground, you're in command.

Explains all the poorly packaged (and thus damages) items I've received from Amazon lately. I'm curious at what point the extra carbon emissions from shipping returns and replacements outweighs the environmental impact of cardboard savings. Anyone up to doing some back of the envelope calculations on that?

Yes, hooray for freedom. Have the same opportunity, personal fininces, acceptable level of risk, and luck is another matter.

Only if you're suggesting that the employees chose to work there because they thought they had the right terms and were expecting a multi-billion dollar sale from which to benefit. If you have evidence for that, I expect you've freely chosen to work for such a company yourself and that you're entirely confident in your situation. (Or else the money just doesn't matter that much to you. That's ok too!)

> You mean the employees who chose to work there understanding the terms of their deal?

As if anyone can just choose to be working for a company with the right terms, in a position to make a multi-billion dollar sale, and also somehow not get screwed out of what they thought their terms guaranteed.

> I have never seen a claim from science that something is safe.

Yet I regrettably see people, even here on HN, claiming otherwise. We're not helping.

I've been saying this for a while. SourceTree used to be fantastic a couple years ago. Yet each update since those glory days has brought not just bugs, but a worse overall user experience.

Doing something you love 40 hours a week can easily rob you of that love, depending on your situation.

A couple secret-recipe idiosyncrasies are legend among those handed down in my family. For example, wherever grandma's recipes say "a spoon of sugar", she was actually using a ladle.

Been waiting for someone to do this. Glad to see there's still plenty of room for contributions.

I can relate to that. Fresh out of college and having to move back home during the recession, my parents insisted I be delivering resumes full-time, preferably by mail and in person, rather than "dicking around" on the computer. (No comprehension of what I had studied, of course.)

Eventually I worked things out, with a dose of luck, but I can't help thinking I'd be far better off today if I'd managed to publish some personal projects during that time and networked those around to like-minded associates.

I've noticed that people in many fields who are capable of fast, near perfect work often have had the opportunity to spend lots of time doing the same activities with the slow, methodical mind of a perfectionist. Some of them continue to do this throughout their careers, in the long stretches between the performance of fast, near perfect work.

I think it's a shame that we don't encourage something closer to that balance with professional software development.

At every company, my own managers have exorcised far more blatant use of flex time than I've ever needed. If I'd ever received any guff (which I haven't) for my own needs, they would have gotten a deserved ear-full.

Common misconception. Fermentation happens throughout the wort, which is one reason you want it well-aerated before pitching the yeast. Yeast, when _done_ fermenting, flocculate at the top or bottom. Very little oxygen should be near the top of the wort during fermentation, due to CO2 accumulation.

Potentially better than nothing! However, as a single repetitive motion, it might carry its own long-term risks.

Maybe one of those giant human mouse-wheel things with variable terrain? Tripping would suck, though.

It's almost as if it's lack of constant (even low-grade) activity that's the problem, rather than whether you're sitting or standing. Perhaps not moving all day is the cause.

> so try to walk around more

Even though we just said it's probably not going to help.

Just realized this is now me. "A pile of individual pieces in a loose spaghetti wad" exactly describes what I've been made responsible for. Each source file shows scars of sprints where some poor fool was given a story and told "just make it work" with no concern for any big picture.

> AMD (just kidding, nobody uses this for new code)

Lulz, our Oracle-owned ERP system chose AMD for its module system less than two years ago. All new code will use AMD here for, I expect, the next decade.

Pretty sure I remember those same studies. More or less, I believe it was that the effects of sitting all day were not offset by physical activity after work or on weekends. The conclusions were not that taking breaks from sitting have no positive effect.

Wait, what is the "average ERP programmer salary" in your area? I ask, because I've seen them billed out by consultancies at like $200 an hour. What slice of that makes it back to the devs?

> You seem actively hostile to the idea of there being bad employees, and I'm not sure why.

Why do you say that? Of course there are (were?) bad employees. If they did indeed fire the worst performers, some of them were quite likely bad employees.

> But corporations are usually very reticent to say negative things about people, so for them to specifically call these people out as bad employees at least makes it plausibly true.

Also plausible that it's misdirection or that they're assholes. =)

Lack of trust should mean the burden of proof is on the untrusted. Waiting to fire (not lay off) bad employees en mass at least smells funny, you have people who weren't fired saying it hurt morale, and possible ulterior motives. But no, no hard evidence, only justified lack of trust.

I never said that statement was a lie (your word not mine); I have no reason to take their claims at face value either.

So by all means, let's continue talking about how much those loser dead weights who got fired must have sucked.