> You learn by breaking, not by watching.

I can't stress enough how important that statement is. I learned to code by refactoring and revising my old ideas. When I learned a new tech stack, a new library, a new pattern or a new methodology, I ended up refactoring old projects with the new mindset.

I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_.

Good engineers and architects know how to break down a large problem into small enough portions to be able to guesstimate whether it's possible. Then they build little prototypes for those unknown unknowns to come back with a better estimation. And those small prototypes / portions are something like a knowledge library, where you gain confidence over time when you solved and successfully implemented those already.

Bad engineers on the other hand always chase the new hype, instead of learning from their own mistakes they just rebuild the same crap all over again, assuming it will be better by using fancy new libraries. Unsuccessfully.

> I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_

I am on the tail end of making a game from scratch, and while I am quite proud of the feature/performance set, every 2 weeks I stop pulling from the feature queue and just enter 'editor-in-chief' mode where I find any new ways of doing the same thing and extend it to the rest of the code base. Often its leveraging templating, or other generalizing techniques that reduce code-bloat.

I believe this is true for all learning, we consolidate knowledge by applying it, not by hearing about it.