From the same author: https://grugbrain.dev/#grug-on-saying-no

Thanks for sharing, I agree with what he says.

I've reached a point in my career where i can essentially call the shots as far as engineering and even product direction is concerned.

But recently had to do some consulting as an IC due to circumstances (worst case scenario deal closing delay), and i can tell you that there are places where non-technical people make tech decisions without consulting anyone. Also in my already quite distant qconsultant past (wow, time flies) while it has always been common for me to sort out requirements, and help with business analysis to align them with engineering, even when you dismiss flying unicorns, the class of core requirement evolutions that can make you regret choosing a tech stack is still very large. I've seen a couple of folks fired literally due to this.

Even now that i call the shots and sell products rather than time, the roadmap uncertainty is still high (largely driven by the need to make products user-friendly enough based on feedback), so i default to .NET + angular as it keeps my game open.

B2B2C at the cross-roads of ecommerce, fintech, blockchains. So you need to deal with vendor integration requirements while making the integration user-friendly from a UX perspective + and keeping your own core UX premium, especially for the B2C segment, and being competitive. Requirements change fast, especially at the beginning, so you don't want your engineering to constrain you or make things more difficult than necessary.

It did, in at least one way: https://docs.spring.io/spring-framework/reference/web/webmvc...

In every monolithic Java Jersey server I worked in there was always at least 1 class using @MatrixParam instead of the query param equivalent. No one could ever answer me why or who because it was always written in a project before it migrated to git.

That ... wasn't the kerfuffle

She wrote the stochastic parrots paper.

Google’s internal review blocked it from publication. Stated reasons were about paper quality. You can speculate whether that was the real reason.

Gebru issued an ultimatum email and said she would resign if some list of conditions weren’t met.

Google said “thanks, we accept your resignation”.

She claims it is retaliation, but it seems more like an own-goal if you ask me. She basically handed Google the solution to their problem.

Practical lesson: don’t tell your employer you might quit before you’re ok with leaving.

It kind of was. I really hate gaslighting, but GP is not inaccurate. Google claimed it did not meet their bar for publication because it ignored recent research on how to reduce the environmental and bias-related risks of LLMs. On the other hand, a large org is unlikely to subsidize high-profile research that makes it look bad. And Gebru was critical of Google’s internal culture and diversity efforts…

"They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." - Carl Sagan

In a shocking twist, the prompter works in VC.

As I learned while burning through all my savings in the 2023-2024 timeframe: You are free to have principles, but principles aren't free.

I am ashamed I worked there.

That’s a choice. This isn’t a story about someone poor who needs to work at McDonalds to make ends meet to feed their family. We are talking about the top earners in the world who made a decision to make more money than working at a competitor (Google/Apple/Microsoft/etc) where they would still be in the top 1% of earners.

It was a choice. I chose it and I wish it was never a choice I considered.

If you worked at Meta and couldn't find a job for a year, its not because of Meta.

I was unemployed before Meta.

Focusing on your first point: Memorization isn't everything. But it's not nothing either.

Sometimes it's nice to be able to just bang out some code without looking everything up. IDEs in an IDE-friendly language make this awareness accessible in the immediate frame, but don't necessarily help with having a mental menu of possibilities to choose from.

That said: I find spaced repetition utterly crushing, so I only use it very sparingly.

> I do not understand how can someone with so much money produce such a low quality products.

It's what management rewards.

Why would they reward non functioning chat interface?

Basically:

1. You smash out rubbish as quickly as you can.

2. You get credit for "shipping" and "moving fast".

3. It is later learned by management that the rubbish is rubbish. But crucially, they do not view bugs as arising from how the work was done. Rather, it is treated as if it is an uncontrollable natural process.

4. Fixing high-profile rubbish is prioritized.

5. The rubbish is smothered with still more rubbish that moves the observable rubbishness to elsewhere in the codebase.

6. You get credit for "better engineering" and "moving fast".

Nobody is properly incentivized to prevent rubbish. Only to produce it and then to produce more of it.

Exciting. Honestly I expect this will do more to advance bitemporal design than decades of jawboning has.

And really, ranges are an amazing substrate for this. I've had to do this by hand in a ... less featuresome ... SQL-speaking DB and it was clunky and performed fairly unimpressively.

AI slots quite neatly into the capability trap model, actually.

Which loop it belongs to in the model is left as an exercise for the reader.

You'll see capability traps everywhere once you learn about them.

Sterman, Repenning and other collaborators wrote several papers after this one. All fascinating and almost entirely depressing.

Especially since MIT's Sloan school, where system dynamics first became a discipline, is just around the bend from Harvard Business school, where system dynamics first became ignored.

One thing I don't get about the concept of capability traps is why is it expected that a company which is good at one thing would be capable at the new thing? What exactly makes a capability trap a trap?

The trap is that you can't get better without first getting worse. You can't get out of the destructive cycle of production pressure and decaying productivity without removing the pressure. Many managers expect, or at least behave as if they expect, improvement to be monotonic and costless.

When you are at capacity and in a degraded state, you have no additional headroom to get out of that state. Why wounds won't heal, or the poor stay poor.

I think because it’s a negative feedback cycle. So once it starts it’s hard to go back, the deeper you are the harder. A trap is something that’s easy to get into and hard to get out of.