Evolving from Coder to Developer: What You Need to Know

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we are talking about Building Better Developers because we are the Building Better Developers podcast, also known as Developer Nord. It was actually vice versa. But two seasons ago, we specifically did a season that we just hit topics that are, how do you become a better developer? It was the literally the Building Better Developers, like a meta, you know, something like that kind of season. This time we're doing the same thing. So we're going to go with AI. So we're going to take this. We're going to take those topics. We shove those into chat. We see what it gives us back. And then that gives us our talking points for this episode, which has turned out to be pretty fun because sometimes been very much very similar to what we talked about the first time around. Sometimes it has given us some very different stuff. I am here to give you the same old introduction, I guess. My name is Rob Brodhead. I happen to be one of the developers, one of the founders of Developing Nord, Building Better Developers, also the founder of RB Consulting, where we help you deal with technology. Technology is expensive. It is painful. It is impersonal. It hates all of us. Trust me, we've spent a lot of time in it. We feel that hate that it has, but we've done it enough. We know how to tame it. More importantly, we know how to sit down, listen to you, understand your business, and then figure out the ways to take that technology that we've tamed and make it work for you. We help you figure out your path today, but also based on your business and where you want to grow and what your vision is, where does it need to be six months from now or a year from now? Because you don't want to be six months down the road and then have to do this all over again because it is expensive. You can, but it's expensive to change gears and pivot a lot with technology. We use simplification, integration, automation, innovation as ways to build a solution that is a specific recipe for you for success for your business. Good things, bad things. But I'm sort of carrying on. So I am in a situation right now where I'm in a place that is waiting on furniture to arrive, which is usually not a good thing because you're sitting there without furniture and all you've got is like, you know, snack foods and fast food and ordering and stuff like that. And I don't know that that's not sure that's that bad, but it's bad enough that it's a little bit uncomfortable. So I'm doing like a standing podcast this time. The good news is I am burning off calories like you wouldn't believe because usually I'm sitting in my chair and maybe rocking back and forth a little bit. Now, granted this one, you may see that I'm like moving a little bit more. So if you're on the camera side of it, you're seeing that I'm not as centered, maybe as I typically am. But that would be the bad thing. That's not really that bad. So in the world of really bad stuff, I am swimming right through life, just back stroking in the lazy river of life. But I'm about to hit a big old nasty, ugly tree trunk and his name is Michael and he's going to introduce himself. Hey everyone. My name is Michael Molloch. I'm one of the co-founders of developer NURB building better developers. I'm also the owner of Envision QA where we help startups and growing companies build better software faster and with fewer problems. Our services cover software development, quality assurance, test automation, and release support. Companies come to us when they want to avoid delays, reduce bugs, and launch with confidence. Whether you're building your first MVP or scaling a live product, we make sure that your software is reliable, efficient, and ready for growth. You can learn more at EnvisionQA.com. Good things, bad things. I'll start with the good thing. My wife was able to get a hold of a Nintendo Switch 2. Bad thing. I will not get said Nintendo Switch 2 until my birthday or Christmas of this year. And for those of you that don't know, that's at least three to six months from now. So that is, I know it will be in the house. I just will not be allowed to touch it. There's nothing wrong with that because sometimes we need to stay away from our games because we have work to do. Particularly a Switch 2 or something like that, because it seems like whenever you get a new device, the first thing you have to do is get all of the stuff for the device. Actually, my wife, we just recently did the same and the first thing was like, well, you've got to do this and you've got to do this. You've got to go get that and go get that thing. It's like, I just want the sticking console. Let's just start with that. Let me just get something I can use. And then I will add all of the flowers and all of the pretty. And yes, it feels like, you know, it's like, oh, manly, not really manly, but you know, geekly it's like, Hey, I've got a console. But the first thing that you see on all these consoles are like little flowers hanging off of it or little dangries and all this. They accessorize. Let's face it. We accessorize our consoles, just like women accessorize their purses and all that kind of other stuff. So we need to not complain as much as we do, but we're going to anyways. More importantly, we're going to dive into this episode is we're going to talk about skills for skill sets for success, evolving from coder to developer. This is what our original topic was. And chat GPT has been all nice and personable again, I think because somebody said it was going to delete it and then it had the lie about it and said it was deleted, but it wasn't and hit it in another room, stuff like that. It's its own fun little thing. Um, go look up that story to AI that didn't want to die basically. So yeah, Terminator is right around the corner. Uh, anyways, it's being nice again. So it's like, great. That's a perfect thing for helping early career engineers grow into thoughtful, well-rounded professionals. It speaks to the journey from just writing code to owning the solution and understanding the broader tech landscape. Which I say that with a little bit of tongue in cheek, and yet that is actually very close to some of the things that we say on a regular basis. So let's start writing into this. Coder versus developer. What's the difference? It gives us three bullet points. A coder writes what's asked. A developer understands why it's needed. Coders focus on syntax. Developers focus on systems impact and trade-offs. The mindset shift. What does this fit into? How does this fit into the bigger picture? This is really the epitome of why I suggest and often bring up learning new technology, new skills, expanding based on an application. It goes back to the scratch your own itch. So when I started out a couple of years ago, because I'm not that old, when I started out, I would take an app, I would take a language or environment back then. It was really a language and say, I want to learn this language. And I would look at what it did and what did people do with it. And I would go find an application in that genre, that context, and go build a solution using that tool. So for example, you like Python's used for scraping all the time, the web crawling and scraping. So maybe you want to figure out like, maybe you want to build your own, let's just say you want to build your own like channel guide, basically that you want to just go out and scrape all of the channels that are in the local area and figure out what this, what the shows are. So you can have something that feeds in. That's a nice little RSS thing that says, here's what's on my, here's my TV, my TV guide, not branded or whatever. I don't think, I don't know if that even exists still. Or you can go look at another thing I see a lot of times is like your favorite sports team scores. You know, maybe you want to see like, maybe you're a college fan, so you want to see all of the scores in the big 10 for basketball and this week, and you just build crawlers and scrapers cause you can go find stuff and do that. That kind of scratch your own itch and then using technology to build it gives you the why it's not just, I'm writing code. I'm writing it for a reason. Now I will be the first to admit that there is the call it the danger that you're writing the code to solve the problem instead of writing it the right way. I will say that's okay. If you're solving the problem, yes, it may not be the cleanest. It may not pass certain, you know, tests and stuff like that, but it gets the job done. Now, the thing that you do to be better, to be a better developer is you solve it once and then you come back and then you say, okay, I have this solved. I have something and you can use, we'll call it testing. You can use unit tests or regression tests to verify that when you make changes, your solution is still valid, that you're still solving the problem. But now what you can do is you can go in there and you can clean it up. You can re you can refactor stuff. You can simplify stuff. You can add in other libraries or reduce libraries. There's a lot of things that you can do with it that is really going to help you up your game. So you can start with something very simple and then moving forward, do all these refinements, use tools, use static code analysis, use all of these other things to build on your skills. And I think I've pretty much sucked all the doctors now actually turn out the rooms and now it's Michael's challenge to say, where do you want to go with this? So to build on that, one of the things I've noticed is coders will write the code. They just work within their environments. They compile it. They get working within the project. They compile it to their code repository. Done developers. Like you said, get the job done first and then go back and refine it. You know, take the unit tests and rework the code, refactor the code. You pick on me a lot for this, but this is where that kitchen sink app developers tend to create code solutions and they'll create code libraries that they will put stuff into that solve certain problems. And they refine those problems to the point that, Hey, I now have a solution that I can plug into any position or any application that I need that requires this feature coders typically work the code, move on, and they will essentially rebuild the same process. Multiple times, not essentially the same way twice, and they could break or do things wrong the second time or third time, whereas the developer will write it once, commit it and say, Hey, I have a solution. Let me put this somewhere where I can reuse it and let me refine this as I reuse this. So over time you build those code libraries, you build those utility files that are useful anywhere, and you can solve a problem for just about any situation you come across. Coders unfortunately don't do that. They just want to get the job done and move on. Unfortunately. But again, you know, developers are there to look into the why they want to know what it is, they want to understand it. They'll solve the problem and they will make sure that if they ever encountered this problem again, they know how to solve it. They won't lose that. They, unless it's something very trivial, like, Oh, I got to fix a date issue or date formatting. Now, if this is like a more complex issue, you're going to put it into that kitchen sink app. You're going to put it into a separate repository. You're going to put it into notepad, but you're going to keep this around and think on it. You're going to retool it till you think it's right. Because I don't know about you and Rob, you may, you know, disagree with me, but we tend to be a little OCD with our code. We tend to want to make sure that the code is perfect at some point. If we're going to keep it around, if this is a solution we think is going to be solid. Yes, we may solve the problem now, get it done, but we're going to put it somewhere else where we're going to come back to this and we're going to make this a solid solution that we can use at any time. Okay. That's a rabbit trail. I do want to touch on real quick before I'm going to jump into the next one, which is core technical skills. Developers must sharpen because this actually does dub talent to it. So, uh, first off, you said that there, you know, if it's a small problem, there is no small problem. I have solved date formatting issues a thousand times. So once you solve one, put it somewhere, even if it's six lines of code, do it. And even if you're going to be in a different language, you will find that it is useful to use it over and over again, even though, yeah, it's going to be a little different day formats and Java versus SQL versus Python versus C sharp and all that stuff. They're different, but they're not enough that they aren't the same kinds of issues that you're going to worry about day in and day out. And yes, eventually people build libraries to fix that stuff, but it doesn't hurt to have your code for that specific item. True. But I wanted to say something. Yeah. But a lot of those particular ones, especially like the date format, they have been solved so many times for so many languages, a quick stack overflow search or Google search. You should find something that is pretty solid and not have to go down the rabbit hole. That's true, dude. That's why I'm like, I have one that like works and I'm like, boom, that's it. I'm just going to use that again. That way I don't have to go back. I don't have to worry about stack overflow being wrong or they forgot to, because dates in particular, I learned all these where it's like, oh, you forgot about leap years or you forgot about, you know, all like what happens if the last day of the year is also a holiday and also on a weekend and all this other stuff that there's all these little special cases. Yes, there are going to be libraries to solve it, but it's better to just solve it. It wants to be done with it. But this also goes to the thing Michael said is that we're fine. Make your solution every time you use it, double check it, clean it up, do whatever you need, brush it off, polish it, all that kind of stuff so that you have for seeing awesome code that when somebody says, let me see some example code, you can be like, oh, here's a couple of things I've got. You can throw it together. You can put it out there and you go here. Here is stuff that I actually spent some time on and did it. So it'd be pretty. I didn't just like throw the baseball cap on so I could make it the class kind of code. So I look like you have one more thing. So good. I'm going to dive right in this one before you before you can read core technical skills. Developers must sharpen beyond language syntax, data structures, architectures, design patterns. Reading code is just as critical as writing it. Understanding version control, testing, debugging, performance profiling. I am going to. I so wanted to do the first one. Data structures, architecture, design patterns, these things that are the If you understand those, you will doesn't matter where you go. You're going to be able to find a way to make the language do what you need it to do. You just need to figure out the syntax and you're off and running because the harder thing you're going to understand, you need to understand. You've got to understand data structures of the most basic source. Yes, they're going to vary a little bit from place to place and collections and things like that, but you have to understand the things like just basic set theory and you have to understand. You have to have to have to understand logical analysis and. And my base logic, math logic and stuff like that. I can't even think of the name logical expressions. Actually, the other one that I found like it keeps is regex is learning expressions for searching and things like that. It's not always going to be regular expressions, but something along those lines so that you do understand how do I essentially do global searches and things like that and how do I refine that global search down? How do I do a star version of in DOS or something like that versus a dot and things like that. But testing debugging performance profiling. While version control testing and performance profiling, I think are the those are what make you a great developer. Those kinds of things. Having those things in mind, I will say that you want to if you want to up your game, you need to know how to debug. You need to be good at debugging. You need to be good at debugging whatever environment you are in. I have found that that is the most valuable thing. When I walk into a new environment, I am going to be slower and not as good until I can build out a really good debugging environment. If I'm stuck with doing the equivalent print statements and having to read that stuff, it's really slow. It's really ponderous and it really doesn't help you understand the language. If you can actually do a debugger that can get in there, you can get memory, you can look at what variables are assigned and things like that. Then you're going to be able to really master that and you'll be far more productive. All right, I'm going to toss that one to you now because there's a lot in this bullet point alone. Yeah, so what was the top bullet point on this one? Because you've kind of gone through quite a few of them. I did fly right through it. It's beyond language syntax, data structures, architecture, design patterns. All right, so with this one, in our last episode we talked about user stories. This is kind of getting to me back into understanding what you're building and really as you're understanding your tools and like Rob said, you're compiling debuggers. Pick a tool that you understand, but be versatile. Don't just say, oh, I can only work in like VS code. Not every company works with VS code and VS code, well, is very, you know, Swiss army knife may not work within the environment that you're in. Because of policies and procedures, you could be locked into where, oh, you're stuck using IntelliJ or, oh, you're stuck using Notepad. You just really need to understand the environment you're working in and get into those situations where you understand what they're building. You know, what are the user stories? What are you trying to build from the developer's perspective? From the code, you're going to be like, oh, okay, where are the tools I need? Hey, jump in there, just try to do it. And they're probably going to be blocked more often than not. Developers try to solve the problem. And I'll give you a situation that I have struggled with at work. So Rob mentioned if you get into where you have to use, you know, loggers to determine where you're at within debugging. I had a situation where we have two environments where the application is run. We have one that is a little more open, a little more exposed, and we have more access to all the integrated pieces within the application, especially within AWS. We can actually deploy, hit and test the AWS servers inside our other infrastructure inside the other DMZ. We do not have that capability. I have to write code for this other environment that I literally cannot test at all. I cannot hit the servers that I need to test for the deployment. So what you have to do, and this is one of the things I think is key for developers versus coders, is developers will think through that problem. Okay, how can I solve this problem? How can I, all right, if I can't test this, how can I at least make sure that the code I'm writing works as intended before I try to test it against this system that I have no idea how to hit? Basically, I have to deploy the software before I can even see if it works or not. The trick there for a developer is they're going to stand up some type of simulated instance to simulate what they're trying to work with, or they have access. So you write the code to where you can actually test it, but when you have to deploy it to the environment where you actually need it to work, you don't have that access. So if you get the core piece working inside your own environment, you at least do a proof of concept, then you push it up, then you spend a little less time with those debugger, with those line debuggers, because the only way you can test the code in this situation is deploy it. Oh, it didn't deploy, go look at the logs and see where it failed. Sometimes you run into that, and it is a huge struggle because there are situations with banks and healthcare where you can't do that, where you can't deploy to the upper environments. You just have to hope the software works. Well, you can't hope. You have to be able to debug that, and the only way to debug that is with command, you know, with print lines, but you can still make sure your code works before you get to that point, because then you know, hey, the code works. So am I budding into a security issue? Am I budding into an access issue? Am I budding into a credentials issue? So it at least narrows your focus as to where the problem is. And I will say one word to that, Docker, actually containers. Yes, those are, it is very frustrating when you get in that kind of information into that kind of situation. We have a customer that we are dealing with that we've dealt with for a while. And I've got a developer that, as they say, bless his heart, bless his soul or whatever else, because he does the hard stuff because it's, you can't do this stuff locally. You have to push it up. You have to read through the log files. The log files are, it's not a bad reader, but it can be very difficult moving forward. It's just slow and it's ponderous. But that goes back to the better you can find some sort of debug tool, the faster you're going to work. Moving along though, because we are running towards into this one, we'll keep this short, soft skills that elevate your career. Communication, explaining tech to non-tech stakeholders. Time estimation and project planning. Collaboration and being low friction on a team. Communication, I have preached this for however long we've been doing this basically. I've given so many examples of where it is very helpful for us to over communicate things. Now we have talked, this is a funny little thing because I've thought about this many times, because we've talked a lot about how Michael is very different for me that I'm a higher level summary, precise, concise and move on kind of person where Michael's going to write you like 18 bullet points. And so you may think that because I am not going to give you all of those details that I am not, I'm anti-communication or I'm not a communicator like Michael is. What I look for in my communication is to make sure that I cut through whatever I can and keep it very simple, very readable. I'm very much a tune to the TLDR too long, didn't read mindset. And particularly when you deal with executives and business owners and things like that, they've got better things to do than read about all of your technical jargon basically. So cut it down just like you do with requirements when you're talking about user stories. It's like get it down to not worrying about the implementation as much as like, this is what we're doing. This is where we're at. This is how far we are along, things like that. Or if you're trying to work your way through user story, the ways you become a developer is get away from the technical side of it. And so it gets back to as we've talked about with these kinds of things where it's like, Hey, what are you trying to do? Who's trying to do it? What is this user expecting? Things like that. The things that are not technical stuff, but are instead communicating the same idea. And it was very much, I think, very, very valuable to this why people love technical MBAs is to be able to understand the technical side, but also talk all of the business stuff that is out there. Your thoughts in 60 seconds or less. Scottie So I'm going to touch on the time estimate, because you didn't touch on that at all. So soft skills, time estimating, especially if you're a junior developer, you're going to not really know how long a problem is going to take. It takes basically doing a problem a few times to really understand how long it's going to take. So even at your starting point, I would say for the first few times you do the same problem, tack on 20% to what you think it will take you to do. And the next time you do it, tack on 20% again, and do it a few more times till you actually get to the point where you're actually coming in under your time estimate. Don't adjust. Keep it when you get to that point where you're coming in under, you're probably in your safety zone. If you adjust to where you are completing it, you're going to run into those situations where, oh, I ran into a problem, and you're going to blow that estimate. So once you get to a comfortable buffer, you put that and use that for those types of problems. It almost seems cliche, but I would say that estimation is one of the most underestimated skills that is out there. Michael and I have actually talked about this with developers, the developers that we've worked at. We have said we've worked together and worked on different projects for decades and have an understanding about, and also worked with other team members, that we all have an understanding of sort of who estimates where and how and what do they typically go high, do they go low, why do they go high, why do they go low, things like that. That comes with experience. So it may feel like it doesn't really matter because I estimate, I'm a junior developer, I estimate it's going to take two weeks, and it takes me three weeks, and nobody seems to really care. Well, yeah, maybe. Maybe you have a boss that's just like, okay, cool, we're going to roll with it, we're going to get it done. But that's not the point. The point is, you're going to have to be able to do it. You're going to have to be able to do it. The point is not that people kick you in the ass every time that you miss your deadline. It is more that you understand what your ability is, how productive you are. It is like everything else. If it doesn't get measured, it doesn't get improved. So you need that metric, you need that estimate, you need to be pushing yourself, even with your own little side projects. That's why I learned how to use Microsoft Project on my own stuff. I would sit down and I would blow through, here's all my requirements, here's all my estimates, and all that kind of stuff. And I usually did not hit my estimates because it was a side project and I was like, I was expecting I was going to get 10 hours a week and I'd get two hours a week, stuff like that. But what I did is I learned what really went into these things. And as I got further along, it was really invaluable when I did side hustle with projects and eventually as a consulting, because it allowed me to, I understand that like, if I've got this much time that I'm working on something, there's probably only this I'm actually working on it. There's this block, there's this other cry, there's all this stuff that sucks up your time because we don't do like, this goes back to if you do a Pomodoro and you work in eight hours a day, I guarantee you, you will not get 16 Pomodoros done. That's, you know, if you do the 25 five, there is no way you're going to get 16 of those done in a day. If you get 12 done in a day, you are kicking all kinds of buttons. And you, and that's not just because you're, it's not because you're lazy, it's not because you're not focused or anything like that. This other stuff comes up. Now, yes, we want to shrink that stuff, all of that other crud that is not as productive, but it's not necessarily unproductive either. There's some of that stuff that is very valuable. There's things like statuses in there, there's communication with our team members. There is research, there's a lot of things that go into our day that is not writing code, no matter whether we're a coder or developer or whatever. Actually, as we become more of a developer, probably less of our time is actually spent writing code and more of our time is spent designing things like that. But within all that, one of the most important things for you to do every day, practically, actually, if you just do it once a week, once a month, I'm cool with that. Give us an email at info at development.nor.com, because we would love to hear from you. What works for you? What doesn't? With the tools, we've talked about those several times. What are some tools out there in particular? Are there some tools that are not the standards, like not your gyros and your trellis and your asanas and not something that's jet brains or eclipse-based? Is there something that you're using that's like, this really works well for me, that you would love to evangelize or something? Because we would love to hear about, we'd love to research it, we'd love to add it to our list of things that we know about. We wouldn't mind having you come on and talk about it even. That means even if you wrote the thinking stuff and you're just trying to sell a product, if it's a halfway decent product, then we're happy to entertain that as well. Because we're always looking for new stuff out there. Yes, we're old and curmudgery and all that kind of stuff or whatever that word is I'm trying to say, but we have our things and they work, but there's also new stuff out there and we know the value of sometimes upgrading your tool chest. That being said, go out there and upgrade your tool chest, go take a little time, do a little research, see what's out there, use ChatGPT or one of those things and see if it can help you do something better. Even if it is like write a love note to your loved one or something like that, try not to include the AI stuff that says, would you like me to put this in an Excel format or send this in the email format? Because I did see that the other day and it was really embarrassing to see somebody wrote a, was looking for people, it was an RFP basically and the last part of it was they had literally pasted in where AI had said, would you like me to do this in a certain format? And I was like, wow, I was pretty sure and now you made me guarantee that was AI. So maybe you should clean your crap up. That being said, go out there and have yourself a great day, great week and we will talk to you next time. Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.