How to Get Cracked at Programming

How to get cracked at programming? If I could change one thing about the years I spent learning to code, it wouldn't be the language I started with and it wouldn't be which tutorials I picked. It would be six principles. I learned all of them the stupid way, which is to say slowly and mostly in production.

None of them are a framework and all six are things you can start this week. Let's dive into it. Principle number one, learn the layer below the one you work in. For two years, I thought getting better meant learning more frameworks. React, Vue, Svelte, Next, whatever launched that month. I could

start a project in six of them and finish it in none. Here's the principle. Tools expire, but problems don't. Every tool is an answer to a question that existed before it did. Learn the question and the answer transfers everywhere. So, here's the question. How does a database avoid losing your data when the power dies halfway through a

write? The answer is a write-ahead log. Before touching the real data, you append what you're about to do to a log file and flush that to disk. Log first, data second, always. If the machine dies in between, the log survives and on restart, the database replays it and

rebuilds whatever was in flight. Postgres does that. So does MySQL's InnoDB and SQLite once you turn write-ahead log mode on. Then, drop a layer. Your file system runs its own version of the trick, which is what journaling means in EXT4. Same problem,

different layers of the stack, and it'll still be true in 10 years or 100 years, which is more than your framework knowledge will manage. So, 1 hour on the layer beneath the one you work in, not the whole layer. Principle number two, escape tutorial hell. You don't learn from the thing working, you learn from the thing not working, which means every

hour you spend watching someone else's code work is an hour of nothing. Tutorials hand you the illusion of competence. Someone else selected and designed the system architecture, handled the edge cases, and got stuck on a CORS error for 2 hours, which you never saw because they edited it out.

Every clean jump cut in a tutorial is hiding somebody being confused. That confusion was the actual learning process, and you weren't there for it. So, build something nobody has solved for you, an HTTP server on raw sockets, no Express, no Flask, no Gin, a

key-value store with crash recovery, like a primitive form of Redis, a toy interpreter. I did the HTTP server myself, spent an entire Saturday debugging requests that kept showing up truncated, completely convinced my parser was just broken. Here's the mistake. I assumed one read from a

socket returns one complete request. TCP doesn't work that way. It's a stream of bytes with no message boundaries. TCP guarantees the bytes arrive in order, but where one request ends and the next begins is your problem, which is exactly

why HTTP has a content-length header. An entire Saturday for one sentence that was in the docs the whole time, and it was absolutely worth it, but not because I memorized the sentence. It's because now every protocol I touch, I ask the same question before anything else. Where does one message end? WebSockets

had to answer it. gRPC had to answer it. Every message queue you've used had to answer it. I recognize the problem instantly now, and I only recognize it because I spent a Saturday losing to it. Principle number three, become a code archaeologist. Your GitHub repository