I was reading other blog posts on HashNode, specifically a detailed piece on How Long Does it Take to Become a Software Engineer by Denis Khodishchenko. Amongst a lot of good points, one that resonated with me the most was building foundational knowledge. I'm a living proof that it works, and I'll also tell you how to get started.
I started learning to program as a kid. I got my first computer when I was 10ish, and since I liked playing games, one day I wondered, what would it be liked to create one? And that's how my programming journey started at the age of 11.
Initially, I started learning a tool called GameMaker, which was a free product created by Professor Mark Overmars. It was a fabulous piece of software. As I grew up, I learnt that GameMaker was acquired and is now published by YoYo Games. It was quite cool to see a hobby software turn into a great commercial product.
But it was not GameMaker itself as a software that inspired me to program, and continue program. No. The secret's something else. Before I get into it, though, I want to tell you that I struggled to learn programming like anyone else. It's like learning to balance a bicycle. When you try 100 things trying to find the one thing that works, you're gonna fail 99 times. And those kinds of failures are not really failures because you're still moving forward. However, if you give up, you've stopped, and that's real failure. And the most heart-breaking thing is thinking that something is impossible, even though you had more than enough in you to attain it.
One peculiar thing about the internet back then was that it was not as crowded. There were other kids out there my age who were also into programming. And since the internet was not cluttered, you didn't find a lot of "programming is insanely difficult," or "you really can't program" kind of negativity to kill your spirits. People talked about ideas and how to implement them. And the secret to me learning to program well was the GameMaker community/forum.
Unlike StackOverflow today, it was not a pointed question / pointed answer kind of a thing. Discussions were welcome, even about controversial choices. There was a section for people to showcase what hey had built, which inspired me further. But why does all that matter?
Because you get feedback, you feel useful. And that was important to me as a kid. Because even if I accomplished something small, and couldn't myself gauge how valuable it was, there were still a bunch of people who found my silly program useful. Who learnt from it. Or used it. Or liked my advice on how to improve something.
In that era, you'd talk to people through your work. Rather than just talking "at your work" as it happens today. Some feedbacks were good and inspiring, some were blunt or heart-crushing, but at least they were all honest.
We didn't have "titles." We were not even from the same continent. We were not all fluent in the same language. But we spoke the language of code and creation. Everyone created something, and everyone else responded to that creation. And that's all that mattered. That was our litmus test for knowledge: could we build it?
While today the focus is a lot on proxies for ability, like the number of social media followers, job title, years of experience, etc. But then, it was just pure build. Like Bobby Fischer said, "Play the board, not the man." We played the board. In today's media-happy world, we often don't.
In the subsequent years that technology has changed, I've found something profound. I can look at a piece of code, or a piece of software, or even a behemoth like AWS, and look at a screen for the very first time and still "solve" problems that a normal person couldn't. Why? Not because I was experienced with the AWS console. But I understood the principles by which that product had to work, even if I didn't know how the product was designed. It was like having a great superpower. And that power came from foundational thinking. First principles.
When you learn something vaguely you learn how it works. When you truly understand something you learn how it must work. And once you have the principles, you don't have to endlessly chase goals. Or new frameworks. Or new paradigms. They're all tradeoffs between different principles after all.
So what are those principles? In software engineering, it's only one. It's the ability to "put any puzzle together." In the case of writing code, the puzzle pieces are syntax, and the puzzle is creating a program.
In the case of systems design, the puzzle pieces are individual components that you use, and the puzzle is a system that behaves in a manner you want, while to the largest possible effect avoiding side-effects that you don't desire.
But syntax, components, algorithms, all of that change. Imagine what the world's first computer scientist must have known to become a computer scientist. They didn't have a syllabus. Nor a textbook. Nor ages of knowledge to assimilate before calling oneself a computer scientist. And that's the key. That something, that skill, that makes a person discover things. Even today, that's true of a computer scientist or a software engineer. A person who pushed the needle of knowledge forward, regardless of how much of it is already discovered. If a large stack is already discovered, that clouds what we are supposed to do. But we are supposed to move forward nonetheless.
