There's one element of programming that I wish I had learned early on. One of the things that programming books (especially beginner programming books) do is try to make it seem like programming is fun. They create cute experiments for you to tinker with in the hopes that you'll become fascinated like they were and keep plugging away with programming. That's all fine and good when you're starting out, but when you start hitting harder problems the calm "you can do it" attitude seems to melt away into the "why haven't you memorized this" or "why do you need to head to the manual for this?" The expectations ramp up, and it feels like weakness to try something and fail.

I think one of the reasons I glommed onto programmer post-mortems like "Programmers at Work" and "Coders at Work" was to figure out the emotions that these folks must have felt while they were working on their amazing tasks. Unfortunately most of the time these books are either humble-brags about how great it was that they solved the problem that transformed them from a programming citizen to programming royalty. Rare is the case when a programmer will admit that they didn't have the answer, or how they tried several things that didn't work only to find the one that sort of worked. I think our industry needs more of these breakdowns of how a project came together. The one that I point to as one of the best is the Source Code for Eastern Front 1941 by Chris Crawford. The reason this is so great is not because of the commenting of the code, but more about the why of the code. It's not just a list of "these were the technical decisions that lead to me deciding to use this data structure" but also "this is how my design process came together and what I found didn't work". It highlights that game programming in particular and programming in general is more iterative rather than prescriptive.

I wonder how many programmers have been fouled up thinking that they're somehow defective because they couldn't keep the whole program in their head, or had to keep referring to documentation because they needed to find some syntax that wasn't intuitive to them. How many programmers might have been helped with a mentor saying "no, this is exactly how you should be feeling, and here's how to deal with that fear". How many nights of frustration-leading-to-burnout might be avoided if we acknowledge that we're human beings programming a machine and not vice versa.

Learning to be OK with not knowing and understanding the fear that it causes is one of those skills I wish I had been taught better. I think it would have helped me get further along with my journey.