Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#252 - 3 Coding Principles That Will Save Your Codebase (that most bootcamp grads don’t know)
These principles don't just create pretty code—they reduce bugs, simplify updates, and prevent real-world problems like the $10,000 mistake I made early in my career.
Yeah, that was not a fun one.
Check out https://www.dofactory.com/javascript/design-patterns/adapter if you want to learn more patterns.
PS - I write unfiltered advice for early career developers here: 👉 Real Talk JS
Shameless Plugs
🧑💻 Join Parsity - For career changers who want to pivot into software.
✉️ Got a question you want answered on the pod? Drop it here
Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host. I want to share with you three software principles slash patterns that are going to save your sanity and your code base and make you a better developer. Most new developers, especially self-taught ones, just want to make things work. They're not thinking about scalability or how painful the code may be to maintain in a few months. They're just thinking I want to get this thing to work. And that's a fine way to begin, but you can't just end there. The reason why patterns exist is so we don't have to rack our brain and reinvent the wheel every time we wanna write some code. Patterns exist so we can use what other smarter people have done in the past and then leverage them to focus on the problem at hand. So that way, when you look at a React code base or you're looking at a Python backend and you're wondering where do I start, what should I do, you should reach for a pattern. In my opinion, there's plenty of patterns to do the things that you're trying to do. In fact, if you're a junior developer, there's 100% a pattern to do the thing that you're trying to do. So, instead of reinventing the wheel a lot of times, we just need to be exposed to these patterns. I'm gonna tell you one which I'm sure you've heard of, and two that I'm probably sure you haven't heard of, especially if you're self-taught. The first one, dry. Don't repeat yourself. This is the first pattern that almost every developer hears. Very few internalize it. Me myself, I'm guilty of this thing. The dry principle is very simple. It's that duplication is debt. Imagine this you write the same logic in five places and the business decides to change its mind about where they're going with the product. Spoiler alert, it will. This always happens. Now, instead of making a fix in one place, you have to make it in five places.
Speaker 1:I ran into this very early in my career, during my very first major project. It was an app for Grocery Outlet, a store you may be familiar with. It's the Grocery Outlet Bargain Market. I can't sing, or else I'd try to sing the little jingle. Anyway, grocery Outlet was the first place where I wrote code for a living, for a paycheck, and I also was in charge randomly. I don't know why they put me in charge of this, of this app to do refunds for the store owners. It was called the Pinks app.
Speaker 1:I'll never forget this notorious app that I built, and I had this logic app in like seven different places or something crazy. It was in more than two places for sure where I wanted to check on the validity of a refund, and so when this check would take place, it would look at all these FL statements like is the person on the East Coast? Is it Friday or Saturday, is it a weekend, what day is it, what time is it, and have to understand all these things in order to get the correct refund amount. Instead of having this in one function, I was literally copying and pasting variations of this into different places. I'm embarrassed to say this. It makes zero sense why I did this. When the rules changed, which they did kind of often actually, as I found out, I'd have to go make the fix in multiple places. I didn't know that this was a stupid thing to do, so I was doing this not realizing how bad this was.
Speaker 1:This bit me when I missed a spot and we were approving refunds that should have been denied and you're thinking, oh, you must've got fired. Let me tell you this. The company lost 10,000 or so dollars. I was not fired. They said well, we've already spent $10,000 training you, we might as well keep you now.
Speaker 1:And from that moment on, I was a lot more diligent with the way I was writing code. And I have a more senior person look it over with me and said hey, let's clean this mess up, right? So this is not just about writing cleaner code, it's about having fewer bugs. It's about making easier updates. It's not just about what looks the prettiest or you're just following a rule. To blindly follow a rule, this has real life consequences that can often result in you sending out money to people that don't deserve it, as was the case in my case.
Speaker 1:Let's move on to the next one, the single responsibility principle. You can think of SRP or single responsibility principle is like dry with a little top hat, a little sophisticated version of the dry principle right, dry with a top hat. It simply states that every function, class or component should do one thing. Early in my career, this was a concept I also ignored at my own peril. Guess what happened? At the same place grocery outlet, bargain market.
Speaker 1:I was making that refunds app and it had this monster function. You hit submit and it would determine if the refund was valid that logic that I had duplicated many places. It would send a success or an error message, it would update multiple records, it would send an email and it would navigate to the next screen. It looked at edge cases like is the store on the East Coast and are they selling ham on a Saturday? Or something weird like that. These are real weird edge cases we had for this. I'll never forget some of the strange edge cases.
Speaker 1:All this took place in one big function. No separation, no real composition, just a big wall of if-else statements, deeply nested logic, just terrible. Right, it was doing too many things. At the very least it could have checked the validity and had the email fire off in separate functions. But no, I put it all in the same thing. It's just chaos, just total chaos. And because the function did so much that testing it or replacing a small piece became really risky, it wasn't like I could just change the email without having to run the entire function all together. It's really hard to test small pieces of code when they're all within one function. So if you have a function that does a bunch of stuff.
Speaker 1:The easiest best thing you can do to make your life a little better and make the coding gods hate you a little bit less is to take all those functions and put them in separate functions. This is called composition. Now you can compose all those functions within the function. So maybe you have a function and it sends off an email and checks if a user's logged in and you know checks on a refund status or something like that. Those should all be separate functions. Now those functions can be called within a single function, but they should all be separate. Why? Because now you can test them individually.
Speaker 1:If something changes, you can change that one function. You can now use that function in many places. For an email, for example, how often is it that you only want to send one email? It's likely that you'll send many emails, so why not have a generic send email function rather than having one that sends a specific email? That makes zero sense, right? So SRP isn't exactly academic. It's just how you survive changed.
Speaker 1:You have small focus functions, easier to reuse, easier to test, easier to figure out what's happening when something goes wrong, especially when you're building things that will change. Remember this the code will change. You'd never write code that just lives in like that's it, we're done. Why do you think Google or Apple has updates every other week? Every other day, you know version one, two, three, four, a thousand, a thousand, point one. Every other day there's versions and patches and bug fixes being made because code tends to rot and you have to fix it, update it. Businesses change, things change, businesses have to keep up with the times and then your code will change as a result. You want your code to be able to be flexible. This is so important.
Speaker 1:Now here's the last pattern. This one is probably the most important one and also probably the least known, because I've been exposed to a lot of code bases, mentoring people with Parsity or other people through different programs I've done over the years and I've seen a lot of good code and a lot of really bad code. Hey, I hope you're enjoying this episode. Now you know that I own an anti bootcamp with my buddy Zubin, an ex Google software engineer. If you're interested in not just learning how to code and you know it's going to take more than three months and you're serious about making a transition into a career in software and you want to work with people that have done it before and are currently working in senior plus levels. Join me and zoom in at parsityio slash inner dash circle. You can learn all about our philosophy, how we approach learning how to code and switching careers in a much different way, and how we have so much gosh dang success. If you're interested in being one of the few people that works with us this year, go and apply at parsityio slash inner dash circle. And now back to the episode. Now this particular pattern will really save you if you're in a larger project. It's called the adapter pattern. I think this could also be called the facade pattern. What it really means is you wrap your libraries in your own functions, and let me tell you why this is so important and kind of how you can do this in a practical way.
Speaker 1:So I was following this tech leader on LinkedIn and he shared this horror story. He was working at a company that was using an outdated JavaScript library for dates. I think it was Momentjs or something like that. Now, the problem was this library was used in thousands of places in a million-plus line code base. Imagine that, and that's not trivial, that's not exceptional. That's fairly normal in many ways to have thousands of instances of a library being used and millions of lines of code. That is not that exceptional. Pretty normal in many cases, right in a large company.
Speaker 1:So now they said, hey, we're getting rid of this library, it's a security risk, we can't use it anymore. Great, rip it out. Do you think it's as simple as doing like a find all and delete all? Absolutely not, because Momentjs has these interesting functions. You could say moment plus one day or moment minus three days, whatever. You can do all sorts of date math with the Moment library. The problem was, though, that now, using a different library, it doesn't have the same interface, it doesn't have the same functions. You can't just take Moment out and put something else in and say, hey, new library plus three days. It doesn't work like that.
Speaker 1:So what could they have done? You never want to call a library directly in a file If you're importing it directly. That means that if things change and remember this the only thing guaranteed is change. You're going to have to rip that all out and test each thing individually to make sure it still works, which is exactly what happened at this guy's work. They spent months replacing this, something that could have taken a single day if they use this adapter pattern or this facade pattern.
Speaker 1:So instead of importing that library directly, they wrap it in a function. So this function might be called you know dates or whatever Think of a better name and inside this function they would expose a few methods maybe add, maybe subtract, maybe get now, maybe get later, or whatever. They would expose common methods that they want to use in the library and then in those methods they would call that library Momentjs, for example, and they would say, okay, cool, momentjs. When I say add day, I'll call Momentjs and do this. Great. Now. When the company says, hey, that's a security risk, we can't use it anymore, cool. Now all you have to do is change that one file where you were wrapping that library.
Speaker 1:You can look this up. By the way, this may be hard to follow along with on a podcast type show. So what I would go is to DoFactory JavaScript, and I will have a link in there DoFactory plus JavaScript. Look it up online. There's tons of great examples of patterns in JavaScript that you can use. They also have one for C, sharp and I think for other languages as well, but it can really give you some concrete examples of like oh, here's how you actually use this thing. So imagine, instead of doing a million line code base change or making changes in a thousand places and retesting all these files, you make it exactly one place. You test that one file and you're done. That's it. You move on with your day. It's one hour versus hundreds of hours.
Speaker 1:Doing this actually is one of the first things I like to do when I get to a new company. It's one of the low-hanging fruit. It can make you look really good. It can make you look like, oh wow, this person knows a pattern that we can use and this is really going to help us out in the future perhaps. And it's also a good way to construct your code base. When you're beginning to save yourself some stress and keep some hair on your head if you have any left this is a good way to future-proof your code.
Speaker 1:Now, why does this all matter in the age of AI, you might think, oh, I can use GitHub or Copilot or ChatGPT. They can just scaffold all this stuff for me. You're not wrong, it can do most of this for you. But if you don't know the patterns and instead you're writing some junk and you're saying, hey, ai, extend this junk. And now it's basically writing junk at scale on your behalf. That's not what you want. If you know patterns, you can tell your AI assistant use this pattern. I was using V0 today to construct an entire app. I've used Cursor to construct an entire app. I've used ChatGBT to construct an entire app.
Speaker 1:These are pretty good overall, but what I notice is really lacking a lot of times is any kind of pattern for doing things. It'll get you there, it'll start you off, but if you don't know patterns to implement and how to reduce code duplication or just write code, that's going to be more extensible and extendable. It'll just basically do the work of a really good junior developer. So you have to know some patterns and if nothing else, it'll help you also navigate code that you don't own. So if you're looking at open source, you want to get involved in open source or you're just going to onboard to a big company and you're like well, how do I even know where to look? If you understand some basic patterns, you're going to know a lot about the code base and see these patterns and say, oh, this is a pattern I recognize. Like, oh, this kind of looks like this other pattern that I've seen. So learning patterns is actually one of the most important things, and I think it's actually more important now in the age of AI and again.
Speaker 1:You can go to websites like DoFactory. You can look up books like Clean Code. I really like Clean Code in JavaScript. These are books and websites that are going to make you a much better developer, more knowledgeable and able to actually contribute in a smart way to a code base that you may not be familiar with, and at least understand what's going on just beneath the hood.
Speaker 1:Patterns aren't gatekeeping. This isn't some super academic jargon and stuff like that. These are just ways for you to stand on the shoulders of giants and take what they've already figured out for us so you can build faster and smarter. I hope that's helpful. Learn some patterns. Don't sleep on it, don't be a dummy. Come on, you're better than that. Anyway, I'll see you around next week and if you have suggestions for a show about something you'd like me to talk about or somebody you'd like me to try to get on here I'm always interested to know your suggestions Please let me know and I will see you around. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsityio and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
