206. 6 Myths About Software Development

Do I just write code as a software developer? What is the path to becoming a software developer? What is the right choice for programming language? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

Do I just write code as a software developer? What's the path to becoming a software developer? Is the right choice what is the right choice for a programming language? These are just a few of the questions I get that revolve around what I call the six myths about software development. So let's talk about it in today's episode of DevQuestions. Now, if you have a question, you can go to suggestions.imtimcorey.com and ask your question there. Hopefully, you'll see your question answered in a future episode of DevQuestions. Now, let's talk about the six myths of software development. And there are more, but these are the six I think that are most common, at least that come to my doorstep. Number one, software development is primarily about writing code. That's a thought, that's the myth. But no, that's not what software developers do. In fact, writing code is the result of what software developers do, not what they actually do. A software developer creates logic and they identify how to build out a system, how to create something, how to architect something inside of whatever scope and boundary they have. For instance, you may be the lowest rung on a totem pole of software development. You're coming in as a brand new developer and they stick you into fixing bugs and tiny little bugs. Okay, but even that, when you identify a small bug, okay, maybe you can fix it, but is that all you do? Well, you get to kind of pick your head up a little bit and think through is there other ways to fix this bug? Are there different solutions that might work here? How does it fit in the overall environment? How can I make things better going forward? Should I write a unit test to verify this bug is fixed and always fixed for the future? Are there other places this bug might be lurking? These are questions that you as a software developer get to and need to do. And it's not about the actual code itself. That's the code is the result. But your actual value is in this idea of planning, designing, debugging, the acts around actually writing code, which is why, and we'll talk about this in another week, but this is why AI is not a threat to software developers. AI can kind of write code, which really is just a copy of our code, but AI can create code to an extent, but that's not what a software developer does. So it doesn't matter if AI can create perfect code, it's not going to be a threat to software development as a career. So that's the first myth is that software development is primarily about writing code. Now, if you've worked in a corporate environment, you're probably laughing by now because yeah, I spend very little time writing code, right? Because you spend time in meetings and you spend time talking to people and working through things and debugging issues and you know planning out things. There's so many other things you do besides actually writing code. And sometimes as a developer, you just kind of lament the idea that I never really write code anymore. It's the that's the minority of my job, it seemingly. And depending on the workplace, that's you know, can be a really bad thing. But the reality is, even at the best workplace with the best options to kind of clear your plate of other things, you're still gonna spend a lot of time not writing code. Okay. So the first myth that software development is primarily about writing code, yeah, that's a myth. Number two is that it takes high intelligence to become a software developer. And people often focus on, well, they're really smart. They should be a software developer. That's not what software development's all about. Now, if you are very smart and it software development works for you, then yes, you could be very successful in it. And if you're you have a low IQ, maybe you would struggle. But it's not about intelligence, it's not about IQ, it's not about um, you know, the the overall how big your brain is. It's about how you think. And that's the difference. So what's the difference between being smart and how you think? Well, there can be very smart people who don't really have a good grasp on logic or on putting things together or being empathetic towards other people or being able to identify the hidden problems and so many other things that software developers need to do. Maybe you can write really great algorithms. That's awesome, but it's not going to fit every software development role because some software developers, a lot of software developers, have to work through with quality assurance and with the business analysts and with testers and other people to try and identify what code to write, again, going back to number one, what code to write and how to write it to be the best fit for the organization. So it's about being able to think differently than other people. Some people just don't think in a truly strictly logical manner. Doesn't mean they're illogical, it just means they think differently. So as a developer, you have to remember that the computer that's running your application, it has no kind of stake in the game. It's not thinking, it's just doing whatever you tell it. And so when you write code, you can't skip steps. You can't assume things. You have to be very, very specific. Some people aren't good at that. Other people are. And it's not tied to intelligence. But again, having high intelligence and being good at thinking through step by step is a really valuable thing. But that doesn't mean that you can only be a software developer if you've high intelligence. I have seen developers who you might not call highly intelligent, at least compared to other developers, and yet at the same time they have been very successful. In fact, I don't consider myself the most intelligent software developer out there. In fact, I don't think I'm anywhere near the top. And yet I have done very well in software development because it's how I think, not necessarily the level of my intelligence. Okay, number three. The third uh myth that some people come to me with is there's one clear path to become a developer. And I have people ask me, what is the path? What is the path? And I've really struggled with this because the answer is there's not. And anybody that tells you this is the path, well, they're leaving some things out. They're not lying to you. It is a path. And I have a path, I have a few paths that I've laid out for people, but the reality is there's not one clear path. How you become a software developer, what you learn in what order really depends on your situation. The old it depends answer here. So why is this? Well, because it depends on who you are as a person, what circumstances are in your life, what opportunities come up, and so on. For me, I was trying to become an electrical engineer. And so in high school, I actually interned for an electrical engineer and worked through all my work rather quickly. So my boss gave me additional work to do, including starting to create software. I had never done that professionally before, I'd done it personally. And so this gave me the opportunity to try things out. Well, that led me down a path of learning uh VB script and Visual Basic for applications and learning how to build access databases that had forms and reports and all these other things, and then got me into Visual Basic itself, which then led to VB6 and then.NET and so on. But that path and the way I learned it was based upon need of where I was at the time. Another person might come up an entirely different path and have different needs at that time. They may have come up as, you know, one of the things that often happens, I hang out a lot of um of SQL DBAs, database administrators. And there's a term in the DBA community called an accidental DBA. And what it is, is you work on a team as a software developer, but someone needs to be in charge of the database, and you're kind of the best at it right now. So that's your job. Well, that's you know, kind of accidental. You didn't plan on that being in your career path, and you didn't really train for it. You trained to be a software developer, but you end up starting to work on this database thing and you kind of like it, or you kind of just force into it, and then you train up more. Well, that's that's a different path entirely than I might have recommended, but it's one that fit your circumstances. So when people ask me, what's the path? What is the path? I cringe a little bit because it really depends on what you know, what your circumstances are, where you're trying to get to, and how fast you want to move, how fast you can bring things in, how you can practice, what you have to do, what work opportunities are in your area, and so many other things. So it really does have to be somewhat either generic and just, hey, here's a good starting point. And that's what I try and do is my master courses. They're good starting points. So if you want to be a C Sharp developer, the C Sharp Master Course is a great starting point. It'll give you that foundation you need. Web developer, web development master course. Again, great foundation. Game developer, I have the game development master course as a great foundation to get you started. But from there, you have to figure out what's next for me based upon where I want to go. So be careful on anybody telling you there's only one path. And try not to think about there being only one path to this. There may be different options for you based upon your circumstances. So that's myth number three. There's only one clear path to becoming a developer. Myth number four is that you're gonna work on cutting edge technologies in your career. I'm sorry, that's a myth. Okay. Yes, you will work in organizations or you may work in organizations where you work on cutting-edge technologies. But here's the thing is that any application you start building two years from now is a legacy application. It's no longer cutting edge. And yes, you may spend the time and effort to keep it up to date. And I would encourage you to do that, but that is a lot of time and effort. And often people fall off that curve because businesses don't prioritize that. Instead, they prioritize new features and functionality. So you're not going to work on cutting edge technology your entire life as a software developer. You're going to fall off the curve even if you're at the edge of the curve when you first start off. So even on your own, you will not work on cutting edge technology forever because you'll start to drop off. Or what happens is you build an application, you really like it, and maybe you call it feature complete for now and you move on to a different application and work on that for a while. But now you need to come back and work on the previous application, but that's two versions old. Do you spend the time to upgrade and maybe try that, but some things break and you have to figure out dependencies? And do you spend time doing that, or do you just fix what is broken and add that new feature you need? Probably the latter. But that means you're working on non-cutting edge technology, working on legacy technology, even in your own small applications. So this is something that, yes, if you are fortunate enough to own your own business and control the budget, maybe you keep on the cutting edge for a long time. But in general, you will fall off that cutting edge. Number five, there's one right choice, whether that's the language you choose, the framework you use, the techniques you use, whatever it is, there's one right choice. And again, it depends. That's because there are other things that can work. So I'm a C developer. I love C. I have loved C for years, for over a decade, almost two decades. So I have used C sharp a lot, but I've also developed in 20, 30 languages besides that professionally. And I have seen a lot of different languages. And I find I found that I like other languages as well, depending on the circumstance. And you know what? You can have a great successful application written in Java. Yes, Java is kind of the main competitor to C sharp, but you can still have a great application built in Java. You can have a great application built in C Sharp. You can have a great application built in Flutter or in Objective C or C or C or Visual Basic. Different languages can work and can be okay for your circumstances. So trying to say, well, this one is the best is a bad decision. What you want to do is choose the right choice for your specific situation. There's a big difference. So there's not one overall right choice. And if you find yourself arguing, you know, C sharp is the only way, that's not a good look because you're ignoring the fact that there are better options out there depending on the circumstances, depending on the team, and so on. So on the opposite end, if you find people saying C sharp's a horrible choice and should never be used, also a bad take. Okay? When you get into absolutes, you get into problems. So there are different choices depending on the situation. There is no one right choice for all situations, or even a layer or a set of situations. Number six, older means worse. And this is again kind of comes back to that legacy versus cutting edge thing. Um, I'm going to mention a language. I haven't mentioned it yet, but I really like this language. And it's one that people cringe over now, and yet it still runs most of the web. And that is PHP. PHP is a really powerful language, it's easy to work with, and it powers a significant portion of the internet today. And yet it's an old language. It's been around forever. In fact, C Sharp's an old language, it's been around forever. So these languages, just because they're old, and even if they're they're old and not updated a lot, that does not mean they're worse than the new choices. In fact, the new choices can be a lot worse. They might get better over time. But when you when Angular first came out, Angular is a great framework. I used it for a company I was working for, and it was a great option for us. But at the same time, it was worse than PHP in a lot of areas. And the reason why, yes, we're client-side versus server side. I wanted the client side, that's why I chose Angular versus a PHP. But there's a lot of documentation for PHP. There's a lot of examples for PHP. There's a lot of known best practices around PHP where Angular was new. We had to kind of forge some of that. In fact, when Angular 2 came out, they said, actually, we're going to break everything, and we'll call that Angular JS. That's version one. And we'll do Angular 2 as a whole different way of doing things. We'll break everything. Because the first version, they had they learned some things and said, you know what, we need to change everything, or a lot of things. And that caused a major problem. Well, that doesn't happen with PHP nearly as often because it's established, it's been around, it's been tested, it's been tried. People have used it over and over and over again. So just because something is older doesn't mean it's worse. It might be the right tool for the job. So that's myth number six that older means worse. So those are the six myths about software development. But let me know if you have another myth that you think is worth talking about. Maybe I'll cover it in a future episode. Thanks for the question. And as always, I am Tim Corey.

SPEAKER_01 17:36

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamtimCore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.