Speaker 1: Object-oriented programming is absolutely the worst thing that's ever happened to the field of software engineering. In today's video, we'll look at some of the most controversial programming opinions coming from highly experienced developers on Stack Overflow, which is known for its kind, friendly, and not toxic at all community. I'll give you my initial reaction based on my 10 years of experience primarily in web development, but in full disclosure, I only have about 5,000 rep on Stack Overflow, so my opinion doesn't really matter very much. If you're new here, like and subscribe, then leave your most controversial opinion, and I'll choose the best one to win a free t-shirt of your choice. And I just released a whole bunch of new merch designs, so check those out to support the channel and keep this content coming. Alright, so let's get back to that initial opinion that basically says object-oriented programming is horrible. Developers have been hating on OOPA a lot in recent years, and even the legendary Edsger Dijkstra is quoted saying, The idea behind OOP has been around since the 1960s, and allows developers to encapsulate data and logic inside of objects. You start with a class, which is like a blueprint, that can then create multiple object instances. These classes can inherit behaviors from each other, forming a hierarchy of abstractions. In addition, there are a bunch of design patterns to go along with it, like singleton, factory, dependency injection, and so on. All these features and design patterns sound sophisticated, and sometimes they trick you into thinking you're making productivity gains when there's likely a much simpler way to get the job done. A common complaint is that object-oriented languages require a lot more boilerplate than something that's more functional in nature, and applications end up having a bunch of mutable state that's difficult to test, refactor, and just reason about. Personally, I do think these criticisms are valid, but a bit overblown. In JavaScript, I rarely implement my own classes, and basically never use inheritance. Instead, I create modules that export functions and plain objects. That makes the code tree-shakeable so that dead code can be eliminated when it's bundled together. You also don't have to worry about things like constructors, getters, and setters, the this keyword, which in many cases just add unnecessary complexity. But that being said, I do come across cases where a class is a really nice way to encapsulate something, and they do work really well in frameworks like Angular or Nest that have put a lot of thought into how to work with classes in a predictable way. And there's also other tools out there that I really like that are fundamentally object-oriented, like Flutter or the Unity framework. When done properly, object-oriented programming can be very nice and intuitive, but it may not always be the best solution, so it's good to keep an open mind about procedural or functional approaches as well. Programmers who don't code in their spare time for fun will never become as good as those that do. The idea here is that if you're not passionate enough about coding to do it in your spare time, you're never going to reach your full potential. Now, I actually disagree with this opinion, even though I'm the type of person that writes code in my free time. I think the reality is that many people treat programming as a job, and there's absolutely nothing wrong with that. There's some super talented programmers out there that can get stuff done with a fraction of the effort that other programmers might need. 10x developers are real, and it's not because they're programming in their free time. They're just built different than the rest of us. Like, Allen Iverson in his prime didn't even have to practice, and he was still better than pretty much everybody else.

Speaker 2: We ain't talking about the game. We talking about practice, man.

Speaker 1: Being a programmer is not just about writing code. It's also about communication, being a good team player, vision, creativity, and a bunch of other soft skills. Which brings me to the next opinion, lazy programmers are the best programmers. Or another way to translate it is work smarter, not harder. I agree with this one 100%, but I think a better word for lazy might be something like clever. Working hard is good and all, but sometimes it can blind you to a better solution. Like, have you ever been stuck debugging something for hours, then you take a 10 minute break and come back and solve it right away? That's a phenomenon experienced by all developers and has happened to me many times. Instead of working hard, be lazy about things, take a break, and come back and look at it with a fresh set of eyes. In addition, when you suspect you're doing something inefficiently, it might be valuable to devote a few hours to learning a new skill. Maybe you need to write a function that checks for an odd number, and currently you have an if-else statement to infinity. You might actually save some time by taking a few minutes to learn how the modulus operator works. But in some cases, learning might even be a waste of time. The next opinion is that googling it is okay. One time my doctor told me that googling stuff online doesn't make me a doctor. That didn't make a whole lot of sense to me, because my most important skill as a developer is being able to google things. A better opinion I found on the same thread goes like this, it's fine if you don't know, but you're fired if you can't even google it. I agree with this opinion, because the daily work of most developers is about problem solving for the business, as opposed to more theoretical algorithm implementations that you face on an interview. Google is not the solution to everything, but knowing how to use it efficiently is definitely a skill that any experienced developer should have. On a related note, another controversial opinion is that a degree in computer science does make you a more well-routed programmer. This is controversial, because many influencers out there today say that you don't need a degree to be successful as a programmer.

Speaker 3: You don't need college to learn stuff, okay? Everything is available basically for free. You can learn anything you want for free.

Speaker 1: And many big companies have dropped their degree requirements for developers altogether. Personally, I don't have a computer science degree. Everything I've learned has been self-taught or learned on the job, and I've met many other developers making big salaries without a degree. So you definitely don't need a degree to break into the industry, but that being said, if I could go back in time, I would probably pursue a computer science degree. It can definitely fast-track you by getting you internships at big companies, and I do think that foundation of knowledge would likely make you a better programmer. But on the other hand, is it really worth four years of your time and $100,000 in student debt? College definitely isn't a path for everybody, and one of my favorite things about the tech industry is that you can be successful without a degree, which is a good segue into the next opinion. There's an awful lot of bad teaching out there. Whether you have a degree or not, you'll eventually find yourself on YouTube trying to learn from one of the many different teachers out there. As a teacher myself and a supporter of my fellow YouTubers, I unfortunately agree with this statement. In fact, plenty of people out there absolutely hate my teaching style.

Speaker 4: You suck.

Speaker 1: I get mean comments on almost every video saying the content sucks and that it's too fast and so on. What it really boils down to is that different people have different preferences when it comes to teaching style. Ironically, the biggest turnoff for me is when a teacher has a highly opinionated take on something. There are people out there who preach dogma like there's only one right way to do something. That's almost never the case, and my mind is always being blown with new ways to get things done all the time. The only thing I really know is that I know nothing. Speaking of dogma, people have really strong opinions about unit testing. A controversial one is that unit tests don't need to be written up front, and sometimes not at all. Unit testing can be very valuable, and there's even empirical evidence to support that. But also, in my experience, it can be a completely useless waste of time, especially in projects where the requirements aren't very well defined and likely to change as the project evolves. Because if you try to write your tests up front, then requirements change, you not only need to refactor your code, but also your tests. In addition, most developers don't really like writing tests in the first place, so when you put a requirement out like 95% code coverage, you get a bunch of pointless tests just for the sake of testing and horrible code to go along with it. I think quality is a lot more important than quantity when it comes to testing. Or if you have the resources, use a dedicated quality assurance person or team to validate the code before it goes out. Another opinion that's kind of related to testing is that the customer is not always right. When building a new piece of software, you generally start with some requirements from a customer, project manager, or some other kind of stakeholder. And it's not like a blueprint for constructing a building. These requirements are very likely to change multiple times throughout the project. For non-technical people, software development seems like black magic. And it's very important for you, the developer, to communicate when you recognize something as a bad idea, or something that's going to take a ton of time to refactor. When I first started doing freelance work, I took the approach that the customer was always right and ended up working many hours for free just to make the customer happy. And I really only blame myself because it's my fault for not being a good enough communicator. But in some cases, you may end up with a very difficult client. And for that reason, I generally recommend people do their billing on an hourly rate as opposed to a lump sum for an entire project because it's more transparent and allows for a clean break if things go really south.

Speaker 4: I want a divorce. Divorce? I knew we had something in common. Here, sign these.

Speaker 1: And with that, we've reached the final opinion. Most comments in code are in fact a pernicious form of code duplication, where on a related note, readability is the most important aspect of your code. For the most part, I agree with these opinions. I think writing code that is simple and self-describing is the ultimate goal we should strive for. The reality, though, is that even if you write perfectly readable code, I might be able to tell what it's doing, but not why it's there in the first place. Comments that explain why something exists tend to be the most valuable. Another big question here is should you write code that is optimized for readability or performance? In JavaScript, I can write a for-each loop, which is nice and readable, but it doesn't perform nearly as well as a traditional for loop. When faced with a situation like that, I start by writing the most readable code, and if performance does in fact become a problem, then I may optimize it in the future. But 90% of the time, it's too insignificant to even matter. I'm gonna go ahead and wrap things up there. Don't forget to hit the like button, and make sure to leave your own controversial opinion in the comments below. Thanks for watching, and I will see you in the next one.