Detailed Notes
In this episode of Building Better Developers, Rob Broadhead and Michael Meloche revisit the journey of evolving from coder to developer.
Learn what separates coders from developers and explore the essential skills that support long-term growth in your software career.
Topics covered include: • The importance of code reusability and refactoring • How to build strong debugging habits • Why communication and time estimation matter • Real-world strategies for working in restricted or enterprise environments
Episode Challenge: Refactor a past solution. Clean it up, document it, and store it in your developer toolkit.
Share your experience in the comments—what helped you grow from coder to developer?
🔗 More episodes: https://develpreneur.com/ 🔗 Follow the podcast: https://develpreneur.com/evolving-from-coder-to-developer/
*Follow-us on:*
* https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://X.com/develpreneur * https://www.linkedin.com/company/develpreneur/
* Chapter * 00:00 Introduction & Episode Setup 01:25 Podcast Milestones and History 02:15 Episode Overview – Evolving from Coder to Developer 03:00 Defining Coders vs Developers 05:10 Learning Through Real Projects 07:00 Refactoring and Continuous Improvement 08:45 Building Reusable Solutions (Kitchen Sink Approach) 11:20 Core Technical Skills Developers Must Sharpen 13:00 Debugging and Problem-Solving Strategies 16:20 Real-World Constraints & Simulated Testing 18:30 Soft Skills That Elevate Your Career 20:10 Communication and Explaining to Stakeholders 23:00 Time Estimation and Productivity Tips 26:20 Code Ownership and Accountability 29:00 Mentorship, Leadership, and Knowledge Sharing 31:45 Final Thoughts & Episode Wrap-Up
#softwaredevelopment #developerjourney #codertodeveloper #debugging #refactoring #buildbetterdevelopers
Transcript Text
[Music] Boom. We're back. We have hit record. Um, I got to go find the Let me grab the other episode that I had in my little list of stuff. Skill sets for success evolving from coder to developer. Oh, this is good because we were just talking about coder to developer. Uh, let's see. We are this episode we are eight episodes away from 900. So that's not bad. I mean that's a lot of stinking episodes. I remember when it was like wow I made it to 100. Wow I made it to 200. We did an interview I did an interview with a guy I can't think of the name of the it's the podcast for podcasters or something like that is his thing. He said, "Yeah." He's like, "You know, once you've gone beyond like two or 300 podcasts, you should be like, you're just cranking through them and you should be awesome." And I'm like, "Uh, I've done like 650 at this point, and I'm still, you know, playing around with this a little bit." And he was like, "Oh my gosh." He's like, "I only saw three." I was like, "Yeah, because Apple only, you know, by default only has 300. You have to do something special to show all the extras and it doesn't like it doesn't like huge amount of episodes for some reason." But oh well. Okay. So skill sets for sets. Let's see. Did it give me answers? It did. Okay. So I have >> and have it do pick the top three bullets since we don't seem to go through all of them. Maybe we can like ref. I'll just go the top I'll do the top three because it goes in order. I mean it's coder versus developer. I'll give you the I'll give you the bullet names. We'll do a little read bonus of material here. Coder versus developer. What's the difference? core technical skills developers must sharpen. Soft skills that elevate your career. Thinking in terms of product, not just code. Code quality, ownership, and maintenance. Becoming a lifelong learner, mentorship, and leadership. So, the three that we'll probably hit. And if we go in order, be coder versus developer. What's the difference? Core technical skills developers must sharpen and soft skills that elevate your career. I think those are awesome. Although, funny enough, like several of these I think are almost exactly titles in our book as we get further into it because we do talk quite a bit about mentorship and leadership and uh lifelong learner in particular. Parting thoughts before I do the infamous countdown. >> Yeah, I kind of like the ownership one though. So, if we don't get to that one, I'll I'll hit that one up as a bonus at the end. Oh, code quality, ownership, and maintenance. >> Yeah. >> Yeah, we may be able to get to that. So, we'll see how we go. Let's see how fast we can crank through this episode. 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. It was actually vice versa. But two 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 develop. It's like a meta, you know, ulta something like that kind of season. This time we're doing the same thing except 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 GPT. 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 Broad. I happen to be one of the developer one of the founders of developing 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 6 months down the road and then have to do this all over again because it is expensive. You can, but is 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, um, bad I'm sort of carrying on. 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 I'm 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 uh 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. maybe rocking back and forth a little bit. Uh, 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. Uh, but that would be the bad thing. It's not really that bad. So, in the world of really bad stuff, I am swimming right through life just backstroking 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 Malage. I'm one of the co-founders at Developer Nurer, 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 a 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. >> And there's nothing wrong with that because sometimes we need to stay away from our games because we have work to do and particularly a Switch to 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. Uh actually my wife, we just recently did the same and the first thing was like, well, you got to do this and you got to do this, you got to get 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. >> Then yes, it feels like, you know, if 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 know, you see on all these consoles are like little flowers hanging off of it or little dangies 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 is being all nice and personable again, I think, because somebody said it was going to delete it and then it had to lie about it and said it was deleted, but it wasn't and hid in another room. Stuff like that. It's its own fun little thing. Um, go look up that story. The 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 theme 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. that is actually very close to some of the things that we say on a regular basis. So let's start right 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 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 uh like Python's used for scraping all the time 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 um 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. Um, 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 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 because 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 we'll call it the danger that you're writing the code to solve the problem instead of writing it the right way. I would 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 now you say okay I have this solved I have something and you can use we'll call it testing you can use unit test or regression test 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 uh 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 oxygen oxygen out of the room. So 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 sync app developers tend to create code solutions and they'll create code libraries that they will put stuff into that solves 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 a third time. Whereas a 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 look to get the job done and move on. Unfortunately, uh 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 encounter 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 sync 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 Robbie, 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 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 dovetail into 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. Date formats and Jler versus SQL versus Python versus C# 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 a lot, >> you 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 that solve it but it's better to just solve it once and be done with it. But this also goes the other thing Michael said is that refine like 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 pristine awesome code that when somebody says, "Let me see some example code." You can be like, "Oh, here's a couple 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 would be pretty. I didn't just like throw the baseball cap on so I could make it the class kind of code. Oh, it looked like you had one more thing. So, good. I'm going to dive right in this one before you before you can breathe. 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 uh I so wanted to do the first one data structures architecture design patterns these things that are the foundations of solving the problems 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 um and uh math based 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 uh reax 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 you know a star version of in DOSs or something like that versus a dot and things like that. But uh 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 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 in 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 potterous and it really doesn't help you understand the language. If you can actually do a debugger that can get in there, you can look at 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 gonna toss that one to you now because there's there's a lot in this bullet point alone. >> Yeah. So, what was the top bullet point on this one? Because you you've kind of gone through quite a few of them. I'm trying to >> I did fly right through it. So, it's beyond language syntax, data structures, architecture, design patterns. >> Ah, 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 know, 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 Intelligj or oh you're stuck using Notepad. Um 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 perspective? From the coder, you're going to be like, "Oh, okay. Where are the tools I need? Hey, jump in here. Just try to do it." And they're probably going to be blocked more often than not. Developers tried 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 uh 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 uh 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 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 where 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 uh 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 help. 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 into a credentials issue? So, it at least narrows your focus as to where the problem is. >> And I will say I will say one word to that Docker actually containers. Um 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 uh 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 uh moving along though because we are running towards the end of this one we'll keep this s short s uh 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 I have communication I have I have preached this for however long we've been doing this basically I've I've given so many examples of where it is very helpful for us to overcommunicate things now we have talked this is this is a funny little thing because I' I've thought about this many times because we have talked a lot about how Michael is very different from me that I'm a higher level summary you know 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 car very readable. I'm very much a att tuned to the TLDDR 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 you know 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 a user story, the way you become a developer is better 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 it's very very valuable to that's why people love technical MBAs is to be able to understand the technical side but then to also talk all of the business stuff that is out there. Uh your thoughts in 60 seconds or less. >> 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's 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 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, keep with that and use that for those types of problems. I it almost seems cliche but I would say that estimation is one of the most underestimated skills that is out there. Um Michael and I have actually talked about this with developers that developers that we've worked at. We have we 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 what 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 you 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 not that people like, you know, kick you in the ass every time that you, you know, 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 used I learned how to use Microsoft Project on my own stuff. I would sit down and I would blow through like 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, you know, I was expecting I was going to get 10 hours a week and I'll 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 became when I went out and did side hustle and projects and eventually as a consultant 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 fluff. There's this other crud. 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 I guarantee you you will not get 16 pomodoros done that's you know if you do the 255 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 butt 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 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 status that's 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, developer, 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 design and 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. Shoot us an email at info developer.com because we would love to hear from you what works for you, what doesn't, uh, tools, we've talked about those several times. What are some tools out there in particular? Are there some tools that you are like not the standards like, you know, not your Jerusas and, you know, not something that's, you know, Jet Brains or Eclipse base. Is there something that you're using that's like this really works well for me that you would love to you evangelize or something because we would love to hear about we'd love the research that we wrote 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 just like to we're always looking for new stuff out there. We're, yes, we're old and commodery and 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 chat GPT 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 like include the AI stuff that says would you like me to put this in an Excel format or send this in an 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 and go out there and have yourself a great day, great week, and we will talk to you next time. Bonus stuff. So, I'm going to fly back through the bonuses. I think you already had your one, but uh thinking in terms of product, not just code. Understanding the why behind features, developers should think about usability, educates, user pain points, how developers add more valuable when they understand the business codes, uh business goals, code quality, ownership, and maintenance, writing for future developers, including yourself. We use it all the time. Refactoring code reviews, documentation is habits. Taking responsibility, bugs, downtime, and fixes. Uh, becoming a lifelong learner. Tech changes fast. Languages, tools, platforms evolve. Setting learning goals, side projects, reading, podcasts, communities. Yeah, that sounds uh not everything needs to be cutting edge. Focus on fundamentals too. Mentorship and leadership. Helping others is part of leveling up. How mentoring juniors builds leadership and clarifi and clarity. becoming a multiplier, not just solving problems, but enabling others. I'm going to jump into this one again. I'm going to take this first and then pass it to you. I do want to talk about because I don't know we touched on this in a while is a mentorship and leadership. uh presenting the idea of sitting there and simply presenting when you build this application when you solve this problem is going back and sharing this with other developers whether it's through a blog whether it's a podcast whether it's a a lunch and learn whether it's just sitting in a team meeting whether it's just like extending your standup to five minutes and saying hey I solved this problem and I found this thing I have done that with my team for a while now uh initially we did it we would have like once a week we just talk a little bit about stuff. It would be basically like you saw in our mentor stuff where we would have a presentation and we'd have a little bit of like a hey did you learn anything new this this week and we did that for a little bit and then we actually got into a project where it worked out really well to have we paused for a while but then we ended up doing something where we had weekly design meetings where we were focused on this customer but a lot of times we would talk about things like what did we get done hey I solved this this way does this work and it really really helps it helps the senior developers because they have to actually think and walk through stuff and communicate two or three different ways the solution and it's going to get questioned. They're going to have to think on your feet. So, you're going to get better. You're going to learn how you know it's like I've said way back there was we had the interview. If you learn if you learn improv, there is so many things that you can do in life. And it's the same thing with that. If you understand this deeply, then you can improvise. Whatever the question is, you know it solidly enough that you're going to give them the answer. they're going to be able to take it in a weird direction. You're oh no, I'm able to apply that over there. That makes you a better developer. As a junior, just walking back through it makes you a better developer. I have watched so often junior developers really grow because they've done a little bit of a presentation. They've done a little bit of a walkthrough with somebody. Code reviews are great for this. Um, I'm going to stop there because I could I could do a whole season just on that, but what are your thoughts? Where did you want to go? So I'll touch on ownership. So ownership when we are developers we tend to take what we do personally. We take ownership of what we're doing. We want to make sure that what we're solving solves not just solves the problem but is is a solid solution. We want to make sure that we are delivering quality products, quality solutions to our customers. Um and we take ownership of it. So if it breaks, we jump in and we make sure that it gets fixed. Unfortunately, from the coder perspective, if the code breaks, it's someone else's problem. I don't, you know, I did, you know, I worked through the code change, I pushed it up, it went through testing. Not my problem. It worked when I pushed it out. Developers won't take that perspective. Developers take it more personally. It's like, oh, it didn't work. Okay, let me jump in. let me figure out the solution. Let me figure out how to fix this. Developers tend to be more problem solvers. Coders tend to be here, I did my work, move on. I think that is something that is a distinguishing factor. You're going to find the good and the bad is if you're a developer, you probably you're going to take ownership. You own that stuff. You are going to you're going to invest more into your solution. That is the the good, the bad. Um, it is great for your customers because then they're like, "Hey, there's somebody I can trust. This person cares. They're going to, you know, get me where I need to be and they're going to put the extra work in." Uh, the downside is that sometimes means that you're going to work all night, that you're going to work through a weekend, that you're going to like you're going to be exhausted, you're going to be there's going to be things like burnout and things like that. If you never ever experience burnout, you're a coder. If you experience burnout, if it's always, maybe not always, but pretty regularly on your mind, you're probably a developer or a business owner because yes, small business owners in particular, you live that same job. So, don't don't let us act like that's not something you're going through. That was a u a great series of questions. We're not done yet. We are a handful of episodes away from 900, I found out, as Michael was saying. I can't remember if that was recorded or not, but I will bring that back out. We'll return next time around and we're going to continue carrying on here. We've got a few more episodes for this season. And uh this has just been great. We may who knows where we're going to go from here. Uh because this has actually been a nice little uh rabbit hole essentially that we've gone down. It's made it a lot easier for us and it's uh obviously I think you guys have seen it's been some great conversation. If you don't like it, shoot us an email at [email protected]. We would love to hear where you would like us to go else-wise or if you want us to take something else some past because we've got 20 over 20 other seasons. We could pick any one of those and we can, you know, grab one and and start doing it with AI. The interview season will be a little tougher to do with AI, but hey, we could figure it out. I don't know how many of those people we could get back on, but that in itself would be sort of a fun and a very challenging season to do. So, please don't ask that because Michael doesn't want to do that kind of work. All right, we're going to wrap this one up because I got to go eat and stuff like that. We've got to go enjoy our day and not uh burn out so much. So, go out there, have yourself a good one. Thank you so much. We appreciate you. Appreciate your time coming to listen to us and put up with all of our crap. We will be back and try to bring you even more content in the future. Have a great one, everybody. [Music]
Transcript Segments
[Music]
Boom. We're back. We have hit record.
Um, I got to go find the Let me grab the
other episode that I had in my little
list of stuff. Skill sets for success
evolving from coder to developer. Oh,
this is good because we were just
talking about coder to developer.
Uh, let's see. We are this episode we
are eight episodes away from 900.
So that's not bad. I mean that's
a lot of stinking episodes. I remember
when it was like wow I made it to 100.
Wow I made it to 200. We did an
interview I did an interview with a guy
I can't think of the name of the it's
the podcast for podcasters or something
like that is his thing. He said, "Yeah."
He's like, "You know, once you've gone
beyond like two or 300 podcasts, you
should be like, you're just cranking
through them and you should be awesome."
And I'm like, "Uh, I've done like 650 at
this point, and I'm still, you know,
playing around with this a little bit."
And he was like, "Oh my gosh." He's
like, "I only saw three." I was like,
"Yeah, because Apple only, you know, by
default only has 300. You have to do
something special to show all the extras
and it doesn't like it doesn't like huge
amount of episodes for some reason." But
oh well. Okay. So skill sets for sets.
Let's see. Did it give me answers? It
did. Okay.
So I have
>> and have it do pick the top three
bullets since we don't seem to go
through all of them. Maybe we can like
ref. I'll just go the top I'll do the
top three because it goes in order. I
mean it's coder versus developer. I'll
give you the I'll give you the bullet
names. We'll do a little read bonus of
material here. Coder versus developer.
What's the difference? core technical
skills developers must sharpen. Soft
skills that elevate your career.
Thinking in terms of product, not just
code. Code quality, ownership, and
maintenance. Becoming a lifelong
learner, mentorship, and leadership.
So, the three that we'll probably hit.
And if we go in order, be coder versus
developer. What's the difference? Core
technical skills developers must sharpen
and soft skills that elevate your
career. I think those are awesome.
Although, funny enough, like several of
these I think are almost exactly
titles in our book as we get further
into it because we do talk quite a bit
about mentorship and leadership and uh
lifelong learner in particular.
Parting thoughts before I do the
infamous countdown.
>> Yeah, I kind of like the ownership one
though. So, if we don't get to that one,
I'll I'll hit that one up as a bonus at
the end.
Oh, code quality, ownership, and
maintenance.
>> Yeah.
>> Yeah, we may be able to get to that. So,
we'll see how we go. Let's see how fast
we can crank through this episode. 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. It was actually vice versa.
But two 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
develop. It's like a meta, you know,
ulta something like that kind of season.
This time we're doing the same thing
except 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 GPT. 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 Broad. I happen to be one of
the developer one of the founders of
developing 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 6 months down the road
and then have to do this all over again
because it is expensive. You can, but is
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,
um, bad I'm sort of carrying on. 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 I'm 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 uh 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. maybe rocking back
and forth a little bit. Uh, 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. Uh, but that would be the
bad thing. It's not really that bad. So,
in the world of really bad stuff, I am
swimming right through life just
backstroking 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 Malage. I'm
one of the co-founders at Developer
Nurer, 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
a 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.
>> And there's nothing wrong with that
because sometimes we need to stay away
from our games because we have work to
do and particularly a Switch to 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. Uh actually my
wife, we just recently did the same and
the first thing was like, well, you got
to do this and you got to do this, you
got to get 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.
>> Then yes, it feels like, you know, if
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 know, you see on all these
consoles are like little flowers hanging
off of it or little dangies 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 is
being all nice and personable again, I
think, because somebody said it was
going to delete it and then it had to
lie about it and said it was deleted,
but it wasn't and hid in another room.
Stuff like that. It's its own fun little
thing. Um, go look up that story. The 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 theme 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. that is actually very
close to some of the things that we say
on a regular basis. So let's start right
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
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 uh like Python's used
for scraping all the time 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 um
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. Um, 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 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 because
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
we'll call it the danger that you're
writing the code to solve the problem
instead of writing it the right way.
I would 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 now you say okay I
have this solved I have something and
you can use we'll call it testing you
can use unit test or regression test 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 uh 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 oxygen
oxygen out of the room. So 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 sync app
developers tend to create code solutions
and they'll create code libraries that
they will put stuff into that solves
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 a third
time.
Whereas a 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 look to get the job done
and move on. Unfortunately,
uh 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
encounter 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 sync 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
Robbie, 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 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 dovetail into
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. Date formats and
Jler versus SQL versus Python versus C#
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 a lot,
>> you 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 that solve it but it's
better to just solve it once and be done
with it. But this also goes the other
thing Michael said is that refine like
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 pristine awesome code that when
somebody says, "Let me see some example
code." You can be like, "Oh, here's a
couple 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 would be pretty. I didn't just
like throw the baseball cap on so I
could make it the class kind of code.
Oh, it looked like you had one more
thing. So, good. I'm going to dive right
in this one before you before you can
breathe. 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 uh
I so wanted to do the first one data
structures architecture design patterns
these things that are the foundations of
solving the problems 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 um and uh math based 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 uh reax 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 you know a star version of
in DOSs or something like that versus a
dot and things like that. But uh
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 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 in 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 potterous and it really
doesn't help you understand the
language. If you can actually do a
debugger that can get in there, you can
look at 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 gonna
toss that one to you now because there's
there's a lot in this bullet point
alone.
>> Yeah. So, what was the top bullet point
on this one? Because you you've kind of
gone through quite a few of them. I'm
trying to
>> I did fly right through it. So, it's
beyond language syntax, data structures,
architecture, design patterns.
>> Ah, 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 know, 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
Intelligj or oh you're stuck using
Notepad. Um
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 perspective? From the coder,
you're going to be like, "Oh, okay.
Where are the tools I need? Hey, jump in
here. Just try to do it." And they're
probably going to be blocked more often
than not. Developers tried 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 uh 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 uh 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 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 where 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 uh
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 help.
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 into
a credentials issue? So, it at least
narrows your focus as to where the
problem is.
>> And I will say I will say one word to
that Docker actually containers. Um 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
uh 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 uh
moving along though because we are
running towards the end of this one
we'll keep this s short s uh 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
I have communication I have I have
preached this for however long we've
been doing this basically I've I've
given so many examples of where it is
very helpful for us to overcommunicate
things now we have talked this is this
is a funny little thing because I' I've
thought about this many times because we
have talked a lot about how Michael is
very different from me that I'm a higher
level summary you know 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 car very
readable. I'm very much a att tuned to
the TLDDR 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 you know 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 a
user story, the way you become a
developer is better 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 it's very very
valuable to that's why people love
technical MBAs is to be able to
understand the technical side but then
to also talk all of the business stuff
that is out there. Uh your thoughts in
60 seconds or less.
>> 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's 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 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,
keep with that and use that for those
types of problems.
I it almost seems cliche but I would say
that estimation is one of the most
underestimated skills that is out there.
Um Michael and I have actually talked
about this with developers that
developers that we've worked at. We have
we 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 what 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 you 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 not that people like, you
know, kick you in the ass every time
that you, you know, 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 used
I learned how to use Microsoft Project
on my own stuff. I would sit down and I
would blow through like 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,
you know, I was expecting I was going to
get 10 hours a week and I'll 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
became when I went out and did side
hustle and projects and eventually as a
consultant 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 fluff.
There's this other crud.
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 I guarantee you you will not
get 16 pomodoros done that's you know if
you do the 255 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 butt 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
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 status
that's 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,
developer, 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 design and 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. Shoot us an email at info
developer.com because we would love to
hear from you what works for you, what
doesn't,
uh, tools, we've talked about those
several times. What are some tools out
there in particular? Are there some
tools that you are like not the
standards like, you know, not your
Jerusas
and, you know, not something that's, you
know, Jet Brains or Eclipse base. Is
there something that you're using that's
like this really works well for me that
you would love to you evangelize or
something because we would love to hear
about we'd love the research that we
wrote 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 just like to
we're always looking for new stuff out
there. We're, yes, we're old and
commodery and 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 chat GPT 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 like include the AI
stuff that says would you like me to put
this in an Excel format or send this in
an 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 and
go out there and have yourself a great
day, great week, and we will talk to you
next time.
Bonus stuff. So, I'm going to fly back
through the bonuses. I think you already
had your one, but uh thinking in terms
of product, not just code. Understanding
the why behind features, developers
should think about usability, educates,
user pain points, how developers add
more valuable when they understand the
business codes, uh business goals, code
quality, ownership, and maintenance,
writing for future developers, including
yourself. We use it all the time.
Refactoring code reviews, documentation
is habits. Taking responsibility, bugs,
downtime, and fixes. Uh, becoming a
lifelong learner. Tech changes fast.
Languages, tools, platforms evolve.
Setting learning goals, side projects,
reading, podcasts, communities. Yeah,
that sounds uh not everything needs to
be cutting edge. Focus on fundamentals
too. Mentorship and leadership. Helping
others is part of leveling up. How
mentoring juniors builds leadership and
clarifi and clarity. becoming a
multiplier, not just solving problems,
but enabling others. I'm going to jump
into this one again. I'm going to take
this first and then pass it to you. I do
want to talk about because I don't know
we touched on this in a while is a
mentorship and leadership. uh presenting
the idea of sitting there and simply
presenting when you build this
application when you solve this problem
is going back and sharing this with
other developers whether it's through a
blog whether it's a podcast whether it's
a a lunch and learn whether it's just
sitting in a team meeting whether it's
just like extending your standup to five
minutes and saying hey I solved this
problem and I found this thing I have
done that with my team for a while now
uh initially we did it we would have
like once a week we just talk a little
bit about stuff. It would be basically
like you saw in our mentor stuff where
we would have a presentation and we'd
have a little bit of like a hey did you
learn anything new this this week and we
did that for a little bit and then we
actually got into a project where it
worked out really well to have we paused
for a while but then we ended up doing
something where we had weekly design
meetings where we were focused on this
customer but a lot of times we would
talk about things like what did we get
done hey I solved this this way does
this work and it really really helps it
helps the senior developers because they
have to actually think and walk through
stuff and communicate two or three
different ways the solution and it's
going to get questioned. They're going
to have to think on your feet. So,
you're going to get better. You're going
to learn how you know it's like I've
said way back there was we had the
interview. If you learn if you learn
improv, there is so many things that you
can do in life. And it's the same thing
with that. If you understand this
deeply, then you can improvise. Whatever
the question is, you know it solidly
enough that you're going to give them
the answer. they're going to be able to
take it in a weird direction. You're oh
no, I'm able to apply that over there.
That makes you a better developer. As a
junior,
just walking back through it makes you a
better developer. I have watched so
often junior developers really grow
because they've done a little bit of a
presentation. They've done a little bit
of a walkthrough with somebody. Code
reviews are great for this. Um, I'm
going to stop there because I could I
could do a whole season just on that,
but what are your thoughts? Where did
you want to go? So I'll touch on
ownership. So
ownership
when we are developers we tend to take
what we do personally. We take ownership
of what we're doing. We want to make
sure that what we're solving
solves not just solves the problem but
is is a solid solution. We want to make
sure that we are delivering quality
products, quality solutions to our
customers. Um and we take ownership of
it. So if it breaks, we jump in and we
make sure that it gets fixed.
Unfortunately, from the coder
perspective, if the code breaks,
it's someone else's problem. I don't,
you know, I did, you know, I worked
through the code change, I pushed it up,
it went through testing. Not my problem.
It worked when I pushed it out.
Developers won't take that perspective.
Developers take it more personally. It's
like, oh, it didn't work. Okay, let me
jump in. let me figure out the solution.
Let me figure out how to fix this.
Developers tend to be more problem
solvers. Coders tend to be here, I did
my work, move on.
I think that is something that is a
distinguishing factor. You're going to
find the good and the bad is if you're a
developer, you probably you're going to
take ownership. You own that stuff. You
are going to you're going to invest more
into your solution. That is the the
good, the bad. Um, it is great for your
customers because then they're like,
"Hey, there's somebody I can trust. This
person cares. They're going to,
you know, get me where I need to be and
they're going to put the extra work in."
Uh, the downside is that sometimes means
that you're going to work all night,
that you're going to work through a
weekend, that you're going to like
you're going to be exhausted, you're
going to be there's going to be things
like burnout and things like that. If
you never ever experience burnout,
you're a coder. If you experience
burnout, if it's always, maybe not
always, but pretty regularly on your
mind, you're probably a developer or a
business owner because yes, small
business owners in particular, you live
that same job. So, don't don't let us
act like that's not something you're
going through. That was a u a great
series of questions. We're not done yet.
We are a handful of episodes away from
900, I found out, as Michael was saying.
I can't remember if that was recorded or
not, but I will bring that back out.
We'll return next time around and we're
going to continue carrying on here.
We've got a few more episodes for this
season. And uh this has just been great.
We may who knows where we're going to go
from here. Uh because this has actually
been a nice little uh rabbit hole
essentially that we've gone down. It's
made it a lot easier for us and it's uh
obviously I think you guys have seen
it's been some great conversation. If
you don't like it, shoot us an email at
[email protected]. We would love to
hear where you would like us to go
else-wise or if you want us to take
something else some past because we've
got 20 over 20 other seasons. We could
pick any one of those and we can, you
know, grab one and and start doing it
with AI. The interview season will be a
little tougher to do with AI, but hey,
we could figure it out. I don't know how
many of those people we could get back
on, but that in itself would be sort of
a fun and a very challenging season to
do. So, please don't ask that because
Michael doesn't want to do that kind of
work.
All right, we're going to wrap this one
up because I got to go eat and stuff
like that. We've got to go enjoy our day
and not uh burn out so much. So, go out
there, have yourself a good one. Thank
you so much. We appreciate you.
Appreciate your time coming to listen to
us and put up with all of our crap. We
will be back and try to bring you even
more content in the future. Have a great
one, everybody.
[Music]