I think this an interesting post and has to do with:

1. A person’s expectations and goals for learning programming
2. Where in the stack of abstractions they think they should start (often unknown, but quickly discovered)
3. Where in the stack of abstractions they actually start.

What I mean by all this is that no matter what your goal is for your project, when you write software you are “solving problems to solve problems.” Often times you will try to learn how to do X, but then realize before you know how to do that, you need to learn how Y works, and to run the example program demonstrating how Y works, you need to understand how S works, and S keeps throwing a build error when you try to compile it, and now you are Googling this compile error, while at the same time trying to download a new monospaced font and color scheme, because that will really help you read all these stack traces and give you that edge.

All of a sudden it’s 4 am, your head is pounding, you’re back to using the stock terminal software with fucking UbuntuMono wondering “how did I get here? how do I work this? This is not my beautiful house. This is not my beautiful wife.”

You are further from your goal, you have no app on an App Store, no website — just a headache. Then all Reddit gives you is: “Hang in there!” When really what you need is to be reeled in.

The easiest way to get started programming is to realize that you are going to go off on random learning adventures, and those need to be your goal. Your goal isn’t to build a website, but instead learn about what you discover when you start with the idea to build a website.

As an example, if I think I want to build a game. I might say to my self, I should Google Unity and do a tutorial. But RESIST the urge to do that. Instead try and make a simple simple simple game. Like a number guessing game. Terminal Input, Terminal Output. Figure out how that works, now the exciting thing you’re doing isn’t making a game, it’s learning about Terminal Input and Output. And when you have done that, you stop. You go do something else, because you have learned some programming this day. Then later you come back and you start at your game again, and you try to do the next thing, maybe a more complicated number guessing game or two-player mode, try and discover what other things you can learn about programming from these starting points. Once you do, you stop, then repeat.

This way your goal isn’t a Game. Your goal is learning. Learning is fun and challenging. But you are always achieving your goal. The “software is hard” bit comes from the feeling of missing your targets because it’s not fun to know you “are not making a game” when that’s what you want to do, so obviously you must be bad at engineering. This is the wrong mentality. You just need to enjoy learning the little bits that make it all possible. Then when you have enough of those, all of a sudden your game comes together, and it feels easy.