bgribble

I know anecdotes aren't data, but I would not be surprised if this was hitting close to the truth.

I had a friend who had RA starting in her teens and was on very heavy medication for it, with no real hope of improvement. In her mid-20s she changed her diet significantly -- I think she went gluten free, maybe it was some other restriction. I thought it was silly TBH, why would changing what you eat affect arthritis?

After about 6 months her RA was entirely in remission and she was off all of her medication. As far as I know has not recurred. I can very easily imagine that dramatic diet changes affect the gut biome and could have tipped the scales to make her gut less hospitable for specific causes of RA. I hope so!

That would be old news!

My first job as a programmer, in the early 1990s, was working on a tool that was used in one of the last US underground nuclear tests. It was a finite-element electromagnetic effects simulator, designed to help get off of actual bombs blowing up and on to simulation to help design for radiation and EM effects on military equipment.

My part was a 2.5d viewer that showed the input model and let you rotate it around and zoom in and out and such. We used X386 (the predecessor of XFree86), the Athena widgets, and GNU tools on a commercial SysV Unix for PC hardware. This was the era of the actual 386; maybe Linux existed but it was well pre 1.0 (I know because I started installing Linux in the 0.99 kernel days, and that was 3 or so years later)

Open source has been fueling the future of every single technical endeavor for 30+ (40+? more?) years.

It's just a different kind of fun. I have an audiophile friend (I generally change the subject when it comes up) and there's this huge tell: he says he is "listening to his system", not "listening to music". I vastly prefer to listen to music!

I'm conflicted about this. Definitely am a fan of "leave it better than you found it", refactor as you go, etc.

But when it comes to bug fixes, the "absolute minimum" is often the best approach -- it can be explained to demonstrate that we know precisely the root cause of the problem, it can be reviewed for correctness readily, and we can feel good that we are not adding a lot of new behavior that can have downstream effects. The "defensive programming" approach.

A refactoring that makes the problem go away forever is an awesome tech debt project, but when you have a hot problem and someone puts up a 1k LOC PR to refactor the problem away it often introduces so much uncertainty that the improvements aren't worth the risk. You have to start asking questions like how long has this person been around, do they understand what they are doing here, have they really tested this fix or does it just have good "coverage", do they really understand the root cause of the problem or is this just a "refactor and pray it goes away" fix...

A small-as-possible fix relies much less on the credibility of the code author and much more on the fix being self-evidently correct.

At least in the US, skyrocketing college costs aren't really due to excess demand. They are a side effect of the torrent of student loan money that the schools have captured over the last 20-30 years.

The lenders and the schools worked hand-in-hand to ratchet up the price tags and the size of the loans for college educations. All their incentives were to go up up up! The additional revenue to the schools didn't go to a better education, of course ... it largely went to administrative salaries. The administrative budget at US colleges has grown unbelievably while the instructional budget per-capita has been flat, driven down by the "adjunctification" of teaching staff.

For me, personally, my goal is not just to maximize lifetime income. It's much more important to me to have a workplace with good collaborators and meaningful work where I feel like I am contributing something unique and valuable. I have tried to follow that throughout my career (not that I haven't ended up in some bad workplaces from time to time!) and overall I have no complaints with where I am financially. If you told me you would double my salary to work for Amazon I would say no without hesitation.

That’s true for some people but not everybody. I like little companies and am willing to take less salary for the enjoyment of building the product from the beginning, knowing every single person you work with, and playing different roles in the team.

I have worked for mega-companies via acqui-hire and I feel like my preference is based in solid experience. I’ve never hired into a company with more than 30 employees in my 30+ years as a developer and probably never will. My current gig is now grown well into the size range where I frequently am reminded why I don’t like bigger companies :(

> “I got this wrong and I take responsibility for that,”

This has always bugged me. Yes I get it you don’t want to put it in some passive-voiced “mistakes were made” kind of thing. But what does it mean to “take responsibility” if there are no consequences?

It would be meaningful if the “take responsibility” statement was followed up with “and I’m submitting my resignation effective immediately.” But “I take full responsibility… and y’all are fired” is just a way to get the good feels of “owning it” without actually owning it.

Seraghina is great, the sourdough crust is sooo good. I like Speedy Romeo a lot too but I think it’s on the wrong side of Classon to officially be Bed-Stuy.

I was the big customer, I was just powerless as a cog in the machine to make my employer pay on time.

As the scrappy vendor, landing those big accounts is so important that you will take the risk even if it kills your business :(

This was a painful learning for me when I worked for a megacorp: the bigger the customer, the less likely to pay on time.

For me as an engineering manager at the “big customer” it was a constant embarrassment. We worked with small scrappy vendors who I was on a first-name basis with. Megacorp would just never cut the checks. They would negotiate super aggressive terms to start with and then still intentionally not meet the agreed terms. I had close collaborators telling me they really needed the $$ to meet their own bills and all I could say was “I’ll send another email to purchasing and hope for the best!” Hated that so much.

I try hard to avoid red meat for reasons but I do like a burger. I tried the Beyond when it was new and I was really impressed. I thought it tasted great and held together as a patty in a way that a lot of "traditional" bean and veg patties fail to do.

Unfortunately after I had cooked a bunch of them I realized what the smell of uncooked Beyond reminded me of: wet cat food. Now I can't get that association out of my head and the smell of the uncooked patties is so revolting I can't really enjoy them any more :(

On urban US supermarket shelves virtually every bottle of olive oil advertises itself as "virgin" or the "even better" varieties ("extra virgin", "first cold pressed" etc). I have read that many of these labels are hogwash, and that the contents of your typical supermarket "extra virgin olive oil" bottle pretty often include adulterants like palm, canola, or sunflower oil.

I can definitely taste the diff between supermarket stuff and super-premium olive oil where I know who the importer is (in New York City, my go-to is the house brand of a restaurant called Frankie's 457 Spuntino who imports their own oil). But I'm not sure whether that reflects the quality of olives/processing, or is an indicator of "real" vs "fake" olive oil...

You're right, for a basic single user license that's a reasonable price.

The thing that is making my team consider alternatives is this: https://www.docker.com/pricing/october-2022-pricing-change-f...

We were on the "Docker Teams" plan, paying $7/user/month. With this pricing change, since we are over 100 users, we bump to "Docker Business" paying $24/user/month, more than a 3x price increase!

At that price point, it's definitely worth looking at what other choices there are.

My team is being hit with really extreme pricing changes for Docker Desktop. I have never been clear on why we even wanted DD (I guess right now it’s the easiest path to getting x86 containers running on M1 Macs?). Alternatives like Podman or even a more extreme solution like this one are becoming more and more attractive.

As a very nearsighted programmer suffering from increasing age-related farsightedness, I often fantasize about a VR headset that would allow me to comfortably focus (say 6 feet away while wearing contacts) on a huge virtual tmux session for coding.

I don't know if this is even remotely a possibility but it sure would beat dealing with constant CSS (can't see s*t)

There was a period of time (00's) when it was hard to get out of an episode of medical treatment for any kind of injury or pain complaint without a script for Vicodin in your hand. You had to actively refuse them at every turn.

This was bad medicine, implemented by oblivious (or complicit) docs, pushed by bad practices by drug companies. Don't blame the patient.

"You screwed up" is a tricky one. Yes, individuals do screw up. But that's actually not very interesting; a true individual screwup (with no one else contributing) has a very small blast radius.

The bigger the screwup, the more people had a hand in it, and the less truthful it is to point to one person and say "you did it."

Let's say I merge a syntactically incorrect piece of code that brings down the entire system on the next release. Nobody notices for a few hours and the company loses a bunch of money. Did I screw up? Yes I did, but that's the tiniest piece of it.

* How did my change get merged? Who reviewed it? Did nobody test it or notice that it had no test coverage that would exercise my stupid change? Do we have any standards or accountability for review quality?

* How did it get released? Do we not have any automated tooling to stand up a candidate release in staging and do smoke tests?

* How did the downtime last so long? Do we have any operational monitoring? Was someone on call? Who is accountable for system uptime overall?

A bad boss would just throw the person closest to the cause of the failure -- me -- under the bus. But who among us has never committed bad code? That's why we build systems for code review, for automated test, for release QA, for operational monitoring. And if all those systems fail or are inadequate, it's not really the fault of any single developer who was essentially walking a tightrope without a net.

There's a lot of focus on the corpspeak vocabulary, which is definitely ridiculous... My current employer incessantly refers to the recent layoff as "ETP" for, I guess, Employee Termination Program, and the laid off workers as "people affected by ETP".

But the thing that drives me insane is the tone of voice and cadence affected by people who are full-time corpspeakers. I can't quite describe it the way it deserves, but there's this singsong sort of rising and falling, yet monotone, sound to it that is so, so artificial and inhuman sounding.

Almost every sentence sounds like a question, in that there's an upward inflection at the end, except for the last sentence of each slide/paragraph which ends on a downward note. It's like they are intentionally sounding like they are reading a text that they don't fully understand -- except it's their own words!

Same story. At about 40 I shaved my epic beard, took graduation dates off my resume and limited it to about the last 10 years of work. Fresh shave and haircut for any f2f interview. So far so good.

Now I'm 51 and lucky enough to be able to seriously consider not taking another job after the current one runs its course (which may be a long time, I don't know). But if I do go out after another job I may invest in a few months of facials and spa treatments to get that maximally youthful look :)

I've read the Tiffany Aching books aloud to both my daughter and my son and they both loved them.

Partly (mostly?) for the spectacle of me trying to read a Nac Mac Feegle accent :)

FWIW I only recently learned that "crivens" is maybe a real expression, a much-shortened form of "Christ defend us". In the same way as "God blind me" reduces to "blimey"...

Not bug-free, but I have used the Jabra Elite earbuds for a while now (75t and 85t) and they manage multiple-device connections pretty well. Up to 3 (I think) devices can be connected to the buds at the same time.

I've been a full-time developer since about 1993. I switched to 100% standing at work in 2014 sort of on a whim. Before that, I had a significant episode of back pain (enough to leave me unable to function normally) about once a year. Since then, never once.

I'm sure it's complicated and I know correlation is not causality. But my personal belief is that standing is a huge benefit for my back's health as a programmer.

As a schoolkid in 1970's Lubbock, TX we got to visit Reese AFB where they did jet training on the T37 and T38. The simulator room had a set of enormous landscape dioramas, my recollection is that they were something like 20 feet by 20 feet. The simulator would "fly" a camera over the diorama. There was a cockpit on hydraulic actuators. I don't remember what the display looked like (or even if I got to see it), but I do remember those huge dioramas and thinking how funny it would be if you "crashed" into a spiderweb on the simulator :)

> Remember, I purposely withheld detail and evidence in my filing, and yet I was offered a quick settlement. I would love to see the math that goes into this strategy.

I've never done arbitration, but I did pursue legal action against a contractor that defrauded me and I think the logic is basically the same.

Lawyers are constantly evaluating the cost (to their client) of further pursuing a claim vs the likelihood of succeeding. They know how much it will cost in time if it goes all the way to litigation/arbitration, and they have a fair idea what the outcome will be, but it's uncertain. They are always going to try to settle long before the end-game unless they are trying to make a point and it's worth wasting a bunch of money on.

In my case, my lawyer was very convinced that they were likely to settle for an amount basically up to about 75% of the amount it would cost to litigate. My claim was solid (he DID defraud me) but there was some possibility that a trial would find otherwise, so it was better for them to settle up to the point that it became worthwhile to roll the dice.

The emails between their lawyer and mine were about details of the dispute, not about the financial calculation I outline above, but that was just window dressing; the real decisions were made based on how much it would cost to litigate vs how much they would pay to settle.

The only place the facts of the fraud even came into it were as part of the calculation of how likely we were to prevail in court, but it was not at all precise; more like "given the facts, we are pretty likely to win but not certain".

It’s definitely not as featureful as Evernote, but Simplenote is working well for me for my day to day note taking.

To me, the point of "blameless" PM is not to hide the identity of the person who was closest to the failure point. You can't understand what happened unless you know who did what, when.

"Blameless" to me means you acknowledge that the ultimate problem isn't that someone made a mistake that caused an outage. The problem is that you had a system in place where someone could make a single mistake and cause an outage.

If someone fat-fingers a SQL query and drops your database, the problem isn't that they need typing lessons! If you put a DBA in a position where they have to be typing SQL directly at a production DB to do their job, THAT is the cause of the outage, the actual DBA's error is almost irrelevant because it would have happened eventually to someone.

That was the only thing about the video that disturbed me. Duct taping the dude to the seat was fine, but putting duct tape over his mouth is super dangerous. He could easily have barfed and been in real trouble.

I read the article as a critique of “root cause of failure”, making the point that failures are always failures of systems, not individual elements.

I agree with this basic premise… if a single fat-fingered SQL command can bring down a service, for a random example, it’s not the operator that is really at fault but the system that has the operator typing SQL directly at the database to do maintenance.

However, unless you identify the specific causal pathway that led to the failure you can’t improve the systems! Root cause attribution strategies like “5 whys” do a pretty good job of teasing out the layers of a system failure to identify both the specific causal pathway and the systematic failures, if you keep it going long enough.

Getting you to come in for service is just an excuse to get you to come in to look at cars. Service is usually a break-even business for dealerships, but it’s a good source of sales leads.