On Coding, Ego and Attention

You are applying it when you change as a result of reading and specially using what you learn. Change is essential, if you do not change anything you are not using it.

It is easier to just (passively) read something than applying it. The problem with reading(or watching videos) is that it can be used as an excuse for procrastination as it is way easier doing something passive that active.

The most interesting thing is that the problem is not in reading. I worked with a kid whose parents were worried as he used videogames to procastinate. They put the console out of the kid's reach and now the kid will just stare at the wall for hours just daydreamming.

So my advice is for you to start applying what one book about procastination says. Select just one good book and start applying it on your life.

It is very important that you just decide and pick one. I don't know "The Now habit" for example.

Write down in a journal the difficulties you face, your emotions while doing so and work over it consistently.

Humans are pretty good at physics. At the layer of abstraction where carpenters work, our predictive ability is solid.

What fields of science are the primary judges of "good software"?

> Programs must be written for people to read, and only incidentally for machines to execute > -- Harold Abelson

So it is pretty much _all_ psychology and cognitive science.

Humans are not yet that good at cognitive science because brains are complicated. There is real disagreement about how Working Memory operates -- and Working Memory is core to why modularity matters!

I've noticed that some of the people who spend the most time paying attention to their blood sugar are diabetic.

Complexity. Understanding a legacy codebase is pretty much a small-scale research project. You need to gain domain knowledge, become familiar with the team, get acquainted with the codebase and its history, before you'll be able to reliably tell bad code from clever solutions to tough problems. The longer a codebase is developed, the more is there to learn and retain in your head. It very quickly becomes just too much, which means onboarding people takes a lot of time, and day-to-day development also involves being extra careful, or creating obscure bugs - both of which make the project take longer.

> They say the way to get ahead at Google is to build a new successful product. Is that the same thing we're doing? It's easier to get ahead by building a new Z framework than to become a core committer on X framework from 10 years ago?

Yes and no. Not every one of us plays the office politics. Some of us code because we like it. The yardstick then is one of personal growth, the ability to comprehend and build increasingly complex, powerful and beautiful systems, or automate mundane things faster and faster.

But, regardless of the "core drives", one thing is true: building a system from scratch is a much faster way to learn about the problem domain than trying to understand someone else's system and maybe contributing a patch somewhere. We learn by doing. That's why there's so many half-baked libraries for everything out there. Yes, there is ego involved - particularly for people who go out of their way to make their half-baked libraries seem production ready - but a big part of the picture is still that programmers learn by writing code and building systems.

(The difference from most other professions is that people there can build stuff xor share stuff - not both at the same time.)