ruslan_sure

"Move fast and break things".

I suggest reading or listening to Dr. Andy Galpin on this topic.

Great words! I would add that the developer block specifically appears when you delve too deeply. You may get stuck in limbo.

Simplify the mental model of the code, product, etc. Discuss it with someone.

Soreness isn't ideal. It won't make you stronger. Actually, it might make your recovery slower.

Physical activity triggers the production of endorphins, specifically beta-endorphins, which are natural painkillers.

Physical activity increases lifespan primarily by lowering the likelihood of falling and breaking your hip. If you break your hip, your life expectancy is dramatically reduced. If that's your goal, just train your legs!

That said, I think the most important part of exercising is the mental boost it provides. It's like a healthy drug. There are no negative side effects, and it's highly praised by society.

Yes. Programming isn't just writing code.

It would be better if these fundamentals were spread out alongside code writing.

Reading comments. It seems like there are a lot of bad managers.

The title is misleading.

It's not about management skills.

It's also impolite to use "nobody" in it.

We should do something similar with AI-coding.

If you don't have a documented mid-term check, vibe-coded PR might not be what you expected.

This can be used in any process where the result is only judged at the end.

The solution here may be to add a midterm check. I think this is what you mean by a "design review."

In my experience, there are some rules that need to be followed for it to work.

- Keep the number of stakeholders involved in all decisions, including PR, as small as possible.

- Everyone involved should take part in this check. That way, no one will be surprised by the results.

- This check should have been documented, like in the ticket.

This can be used in any process where the result is only judged at the end. The solution here may be to add a midterm check. I think this is what you mean by a "design review." In my experience, there are some rules that need to be followed for it to work. We should keep the number of stakeholders involved in all decisions, including PR, as small as possible. Everyone involved should take part in this mid-term check. That way, no one will be surprised by the results. This check should have been documented, like in the ticket.

When and how to do this check and how to handle disagreements depend on the task, culture, and personalities.

After reading this, it's clear that: 1) It's more important to hit the target (what users need) than to throw quickly or with force. 2) We often don't realize how scalable things are.

I agree. It's a constant dance between theory and practice.

Simply put, the author doesn't know what he's talking about.

This nostalgia for the "good old days" should have a name.

This comparison of "medieval learning" and "modern learning" is tougher than "Wilt Chamberlain" versus "Michael Jordan." The amount of knowledge and usage of high abstractions is incomparable. Imagine what we've learned in the last 500 years, and then forget it all and teach children that. They'll finish school in one year.

If your goal is to create a capable laborer for a specific job that won't change in their lifetime, apprenticeships are the way to go. However, if your goal is to teach a person many abstract ideas not specifically related to a particular job, it won't work.

3. It's a popular idea to teach with real-world examples and learn by doing ("general abstractions" vs. "hyperspecific things," "do and watch" vs. "study"). But how many things that you study in school can you touch or do? If you throw away the last 500 years, then yes, what's left you can definitely touch. For example, the author refers to "economic reasoning." Okay, let's create a real-world example and have the student either do it or watch how someone else does it. Hard, right?

4. We can actually use "real-world examples" and "do and watch" for almost anything students are learning. For example, we could go with the class to a nuclear power plant and 'do and watch' there. There are two issues: many things will not be allowed for students, and it would take years to finish just one year of school. We may call not using it "an embarrassment," but there is a reason for it.

5. "Human beings, it appears, are nearly unique in the animal world for being able to learn something by watching somebody else do it." This is simply not true.

6. "It’s often not so important to understand the reasons why you should do something as it is to see it being performed correctly." We do so much of this in real life unintentionally. Imagine a world where we do it intentionally. What would happen if things changes faster and faster? Who would pay all of these "real-world example" learners during their transition?

7. "Most theories are wrong anyway." You may read this and skip the other parts.

8. He got the pyramid model wrong. Putting a base first doesn't mean learning all of math first, then physics, then chemistry, then biology. A biology base may be about the differences and similarities of animals and plants, and the types of animals.

9. "...this must mean we have an ironclad theory of how scientific knowledge is produced. Except we don’t." Yes, we actually have a scientific method. He probably couldn't "do and watch" it, so it fell out of his sight.

What if LLMs get 'a mental model of requirements/code behavior'? LLMs may have experts in it, each with its own specialty. You can even combine several LLMs, each doing its own thing: one creates architecture, another writes documentation, a third critiques, a fourth writes code, a fifth creates and updates the "mental model," etc.

I agree with the PM role, but with such low requirements that anyone can do it.