It's not about the programming language you know; it's about your ability to code and adapt.
Hey guys, how are you doing? Somebody sent me a message that a Google engineer put on LinkedIn, so it's public, and I'm going to share it here. Let's jump into it.
As a software engineer, you don't need to know everything. Before I read the rest of this, I want to emphasize that everything we're going to see here is what I've been talking about for years. For years, I did not know any Linux commands when I started my first job as a programmer. When I joined Amazon, I did not fully understand Git. At Amazon, my first project was in Python, but I had never written a single line of Python code. When I joined Google, I could not program in C++, but most of my work was in C++. Later, when I changed teams, I built a feature in Dart but had never used Dart before. As a software engineer, you don't need to know everything; you just need to know where to find it and when you need it.
There you go, something I've been talking about for years and years. I always say the language is not important. My Ruby joke—if you've ever been watching my videos, I make fun of Ruby all the time. I'm not actually making fun of Ruby; I'm making fun of the notion that the language is important. It's not important. I know a lot of you young learners out there are going, "How could you say a language is not important, Stu?" All these YouTubers with at least six months of experience on YouTube, these 21-year-old influencer experts, are telling me that this is so important—React is so important, or JavaScript is so important. It's not. Everything I've been saying for years and years is borne out with this guy here who worked at Amazon and Google.
It's not about the languages; it's about your ability to be a coder, to be a developer. That is the key. I'll use a boxing analogy because I used to box a little bit. It's not about the gloves you wear, the shorts you wear, or the shoes you wear—these are just tools. It's about whether or not you can box. The same thing applies to driving. It's not about the car you drive; it's about how good of a driver you are. Yes, we'll have our preferences. Some of us will prefer this, and some of us will prefer that. Some of us will prefer JavaScript, Swift, Python, or PHP—whatever, except for Ruby.
Don't get caught up in the languages; get caught up in becoming a pro developer. Learn to write pro code. You could take a great developer with five-plus years of experience and put them on any language, and the quality of that code will be superior to the person who's only done two years of coding on average. The professionalism of your coding has nothing to do with the language. You can write amazingly pro-level code in Perl, and you can write dog crap code in C++. It all depends on your ability to code, not the language.
That's why when people ask me, "Why don't you teach TypeScript? Why don't you teach React? Why don't you teach Node?" I don't need to because in my training courses, I teach three programming languages: JavaScript, Python, and PHP. But more than the languages, I teach pro-level development. I teach people to think like a pro developer. I teach people how to structure code like a pro developer. These lessons are 100% transferable to all software development. Once you understand how to be a pro developer, you can be like this Sahil Gaba guy, a Google and Amazon engineer. You will be able to pivot from language A to B to C with no problem.
Understanding comes through doing—dive in, build, and learn!
In a previous video, I cited a post that somebody made under one of my YouTube videos. He said that he had tried learning React after only having spent a few months on JavaScript and couldn't get his head wrapped around it. So he fell back to basics, started building websites, doing some PHP and JavaScript vanilla stuff, and did this while making money for about nine months. He then decided to revisit React because he had a job opportunity. To his surprise, he learned it in about a day. He wasn't an expert, but he was able to start doing basic things. Why is that the case? Because once you understand how to be a coder, regardless of the language, once you understand and build things, you understand by building. Then all these other technologies—learning new languages, learning new libraries—are not such a big deal.
Remember one of my principles: comprehension comes through application. Write that down. Comprehension comes through application. What does that mean? It means you understand by doing. I learned this actually in martial arts. I started doing martial arts when I was about 10 years old. I started with Judo, then did some Japanese karate, then Taekwondo, then Kenpo, and then a little bit of Muay Thai and all kinds of different things like wrestling and Judo. I did a bunch of styles, including some traditional ones. Even the weirdest and least effective traditional styles provided interesting lessons and understanding.
So, even with some really useless traditional martial arts, I was able to gain some knowledge. I did all these different types of martial arts, and what I found in practice is that one street fight, one actual altercation in the street, was worth months and months of training. Every time I fought, at least for the first several times, my understanding of combat in general deepened quite a bit. This real-world experience formed a lot of opinions about actual combat.
Years later, I became a bouncer in a nightclub, which was my last job working for somebody. I was about 18 through 19 years old. That experience in big group situations, sometimes involving group fights with beer bottles and chairs, continued to form my opinion. It changed the way I trained and what I emphasized. It highlighted what was important and what wasn't. This is something I notice in all fields of study. People often concentrate on things that are not important.
Especially in software development and coding, there is so much information out there. There are so many languages, but it's hard for a beginner to know what is important. One of the myths out there is that math is super important in development. It's silly. 99.99% of programming, math is one of the least important things. I've been writing commercial code for three decades now, doing typical business apps. The most advanced math I've ever done is maybe modulus. If you know how to add and subtract, and occasionally multiply and divide, that's the extent of the math skills you need.
When you hear people say you need to learn math, they don't know what they're talking about. The only exceptions are if you're building a gaming engine, doing some advanced AI research, or big data analysis. For every other type of development, math is the least important thing. If you're math-challenged, don't worry about it. For 99.99% of jobs, you won't need math.
Focus on mastering the fundamentals and writing real code—don't get lost in endless tutorials.
Algorithms fall into the 0.01% category of development; they are not crucial, and there are libraries available for most algorithms if you ever come across them. In terms of efficiency and application, another big myth in software development is the notion that apps have to scale. Scaling is not an issue for 99.9% of development. The only time scaling becomes an issue is perhaps if you work at Google and need to process teraflops of data. For the vast majority of business apps, the bottleneck in terms of runtime speed is database access. If you have a properly structured database, typically a relational database, and know how to write efficient queries, you can optimize performance. For example, in an e-commerce store, how you query the database to display products can significantly impact performance. Understanding how to logically write a good query and strategically decide how much data to pull out is crucial.
There is too much emphasis on marginal aspects in the software world, which wastes a lot of time. To get into the development world quickly, you must concentrate on the key fundamentals. Once you have your fundamentals, you can jump into the game and learn new things on the fly, just like a Google engineer. Avoid getting caught up in tutorial hell, where you are pulled in many different directions. Writing real code, not just school projects, will make you a good and competent developer much faster.
If you take anything away from this video, remember: don't learn Ruby, learn your fundamentals, and get out of tutorial hell by writing real code. Nobody knows everything, and it's impossible to do so. I've been doing this for decades, and I forget more than I currently remember. However, I know that if I need to learn a particular language, I can just learn it. In my last few years as a freelance developer, I had no expectations about what language I would use for a particular job. I would look at the requirements and choose a technology accordingly. Sometimes I used something familiar, like Java, and other times I learned a new language specific to the job at hand.
At first, I was resistant to learning new languages because I was a Java zealot, which is a sign of a noob. As you mature, you understand the lay of the land and become more flexible. You might use Python for one job, Dart for another, and maybe PHP for yet another. The only thing I won't do is Ruby.
Hey, I'm Uncle Steph. I mentor people in coding, freelancing, personal finance, and more. I teach you what I've learned over the last three decades as a developer and entrepreneur, passing that knowledge on to you like any good uncle should. There's an old expression: "If only I knew then what I know now." My idea behind this channel and my mentoring program (shameless promo: UncleStephUncle.com) is to transfer my decades of experience to you, making it easier for you. One of my uncles gave me valuable life advice, and I'm just passing it back. I'm here to help, so if you have any questions or disagreements about anything in this video, please post them below. Cheers, and code long and profit.