Enhancing Developer Productivity: Proven Skills, Tools, and Mindsets for Success

Well, hello, this is Rob, one of the founders of the Dwellafonure. Michael's going to have his little piece to say in a second, but I just want to say thank you, thank you, thank you so much, as this is episode 900. That's 900. There are dozens and hundreds and probably thousands, even millions of podcasts that don't even get close to this. Thank you so much for your time, for your patience, for putting up with us, for seeing us evolve from episode one to episode 900, season essentially zero to now we're in season 25 and we're not done yet. But I do want to just celebrate for a second this achievement and say thank you because you guys have been hanging out and made it possible. Hey, everyone. This is Michael. Hey, again, like Rob said, this is episode 900. We are so grateful for all of you that have been following us all these years and listening to us rant and rave about all things Dwellafonure, developers, you know, how to help you become a better developer, better entrepreneur. We can't express how grateful we are. And again, please continue to follow us. We're not going anywhere. And enjoy this episode. Welcome to building better developers, the Dwellafonure podcast, where we work on getting better step by step professionally and personally. Let's get started. Hola and welcome back to building better developers, developing a podcast. We are here continuing our season where we are doing it with AI. Got a couple seasons back. We had a whole lot of information around developers and how you become a better developer, some of the things you're going to run into. And now we're taking the same topics and we're putting it into AI. And then whatever it kicks back out, we're talking about its suggestions. And so far, there's been a lot of really good ones that's allowed us to have some really good conversations. Before we get to that, let me introduce myself. My name is Rob Broadhead. I am one of the founders of Dwellafonure, also the founder of RB Consulting, where we are what is known as a boutique consulting company. Also sometimes known as a fractional CTO or CIO. What we do is we sit down with you, talk about your business, help you understand your processes, define those processes, improve those processes through simplification, integration, automation, innovation. Basically, we find ways to help you leverage technology to do your business better. We help you, whether it's just guiding you and saying, hey, here's a roadmap, go execute it or on the other end, if it's something where you're just like, I don't even know how to get started, we'll walk you through the roadmap, we'll help you find the right people, the right tools, or help you build the things that you need to to get it done. Our goal is just to help you find better ways to make the most out of that most impressive and large investment that you have, which is always going to be in technology. Like a lot of times it feels like it's right behind your investment in people. Good thing, bad thing. Let's see, this is a tough one, because as I was saying right beforehand, I'm only trying to think of what's going on. It's been a very busy time. So that isn't in itself a good thing and a bad thing. This is interesting. So I'm going to take the bad side of it. The bad side is that the working in my business has petered down a little bit. So instead of having to spend insane amount of hours, get all these projects done and doing all this work, the actual overall need has lowered. As part of that, now that is like, this is the time that I get a strike while the iron's hot, this is where I have to work on my business. So it feels like when I'm working on my business, I even work more hours when I'm working in my business. Because when you're working on your business, there's like a budget and some things like that. When you're working on your business, you go until you collapse. So the good thing is I'm able to do that. It's something that's been wearing on me for a long time. We talk about doing that. Too much of that, I can't get it done in 15 minutes a day. So now I'm paying the price for that a little bit and trying to catch up. But I'm feeling good that it is getting caught up. You can check out our updated RB website, RB-SNS.com. Check that out. I've got updates and things like that. I'm playing around with that, making that a little more appealing and bringing it into this century. It's really this decade because it started to age a little bit. And that's like we mentioned all the time. Check your stuff out, do some periodic updates. And we just happen to go through. Something else you should check out and do a periodic update on is my co-host who's going to go ahead and introduce himself. Hey, everyone. My name is Michael Mulasch. I'm one of the co-founders of Building Better Developers, also known as DeveloperNR. I'm also the owner and founder of a company called Envision QA, where we help startups and growing businesses build software that works the way it's supposed to work and from day one. You probably heard stories about software projects going over budget, launching late or breaking once users get their hand on it. That's where we come in. At Envision QA, we make sure your products are tested, stable and ready for your customers. We handle all the behind the scenes quality assurance checks and support development so that you can launch faster, avoid costly mistakes and protect your reputation. In short, we help you build software that doesn't break your business. You can learn more at EnvisionQA.com. Check out the website. Contact us page where you can schedule a free 30 minute consultation. So check it out. Don't have anything to lose, but you know, faster, better and more improved software. Good thing, bad thing. I'll start with the bad thing. I don't know what I did, but the last day or two, I am limping now. My right knee is absolutely killing me. I thought I had tweaked it, but now I'm thinking I've walked into something somewhere and don't remember getting old. And now it's like just the remnants of, hey, you hit a tendon in your knee. It's going to be a pain to walk for a few days. Good thing, maybe. We're hopefully at the end of this heat wave and we're supposed to get some normal temperatures again and possibly some rain tonight. So we've had some blistering temperatures, heat index over 105 and it's just been miserable. We have also had that and I am looking forward to the fall and some of the rain to bring our temperatures down here a little bit. That is just, it's a little too hot for my taste. So this episode we are doing the building a strong developer toolkit, enhancing skills and productivity idle originally. And it kicks back and it says, hey, it doesn't even like just dives right into it. Episode hook slash intro. Start with a story. Imagine a carpenter showing up without their hammer. Developers often make the same mistake when they ignore the importance of their toolkit. Define what a developer toolkit really means. It's not just IDs and frameworks, but also habits, mindset and learning strategies, which is interesting because I think we did cover a lot of that in our original one. Course segments. So the first one, the essentials of a developer toolkit. Virgin control, GitHub, GitLab, why it's non-negotiable. IDs and text editors discuss Visual Studio Code, in general, J, BIM and how to choose. Change managers, NPM, PIP, Composer, yada, yada, yada. Debugging tools and liners, Postman, browser dev tools, ESLint, PyLint. So starting with that, I hope this one is, I don't know why it triggered me. I hope that you are on Git of some sort, whether it's source, what was it? Source tree, which was Bitbucket, GitHub, something like that. If you're still working on like SVN or RCS or SourceSafe or some of those things in the old school, just move it. Get your stuff off of that and get into a modern version control tool. I've definitely dealt with more than a couple of customers in recent years that are still on these very old version control tools. Yes, they work, but there are ways to migrate those and even with the history in a lot of cases into Git, something that is much more friendly to all of the modern tools out there. Even if you're using some ancient technology, unless their ID hasn't been touched in 15 years, you're probably going to get better integrations with a Git tool, particularly. I hate it. It feels like a commercial for it, but GitHub is just too easy. It's just really the way it's been set up. It's way too easy to use. It's got all the things you need. Yes, you got to watch out. You can start costing your money depending on how you can figure your GitHub stuff, but definitely worth a look into. IDEs and text editors, find the one that works for you. We've talked about this more than a few times. Just find something. The tools that work for you are the ones that are going to work the best. The ones that you use are the ones that are going to work the best. So sometimes, yes, you're going to be in a corporation company where you're basically dictated what you need to do, but for your own projects, play around. Check this different stuff out. You can avoid VI, VIM, Emacs. You can avoid those things, but the modern IDs, definitely there's a lot of good and bad in all of them, and find the ones you can do. I will always say, I think because it talks about debugging tools and liners, the first thing you need to be able to do in your ID is play around with your debugger, whatever it is that it provides. If it doesn't provide one, move on to something else, because if you can't walk through your code and do some good debugging, then you're going to find yourself behind the eight ball, basically, as far as productivity is concerned. I push this for everybody on my team. I talk about this in all of the projects that we always do. And whenever I bring anything new, if we're bringing up a new project or bringing in a new project, the first thing is we want to be able to compile it, build it, deploy it and put a debugger on it. Those are the things that find are like very key tools. If you ain't got that, then you're in trouble. Where do you want to go on this one? So there's a couple of other things that we didn't really touch on with this list so far, but things like Center Queue, where you can have tools that will actually check out your code and check the quality of your code. Linters are super important because especially if you're using like version control and you have multiple people on a team compiling and writing code and pushing it up to GitHub, the linters will help you all stay on the same page so you don't have one person committing code one way, next person formats and in their environment another way. And then you insert one line of code change looks like they've changed the whole file. It is one of the biggest pet peeves I have when people commit code if they don't follow, you know, your coding standards within your organization, because the linter, it can be a very simple, hey, I made one word change to hey, I made a whole file change. What, why did you make a file change? So be respectful of your peers and use linter tools that they are there for a reason. And most of them are free. I did mention Center Queue. Center Queue is great for code quality. Basically, it's a sanity check. There are other ones out there, but Center is kind of like the, I guess, the most well known. It's very good at scanning your code once you commit it to tell you that, hey, you got defects. You know, maybe there's some security warnings and things you need to be cautious about within the language you're working on. Some other things, like speaking of security. So like if you're dealing with HIPAA or Sorbet, exactly. There are other tools and things out there that you can't like, OWASP. Basically, they are security checks of your software. Again, some of them are paid, some of them are free. Run them against your software, have them analyze your code. And a lot of times they'll check your packages and your dependencies and say, hey, this has a vulnerability check. You might want to see if there's a newer version or, hey, here's some ways on how to fix that. Those are just some of the additional things I'd like to throw into this category here. Yeah, I think static linters in our static code analysis in general is huge. It's going to help you quite a bit and it will help you learn the language better, particularly if you've got, which is most modern languages, whether you're doing like React apps or Python or Java or C Sharp. There's so many things that are going on in these languages that having those static code analysis tools that will help you stay abreast of whatever is the recommended approach with your language version is going to help you quite a bit. It's actually, it's really good also if you're bouncing in languages, if you're going from like a modern version, but you got to now also do another project, there's a couple versions back, it will help catch like where you're doing something that's now been deprecated or where you're doing, you know, you did something in the old way, but there's a new or better way. A lot of times static code analysis will pick those up beyond code skills that boost productivity, problem solving frameworks, breaking down requirements, communication and documentation skills, writing better commit messages and docs, time management and focus techniques, Commodore, task batching, flow state. This is where I, this is one of the things where I see a difference between a coder versus a developer. I think that once we start moving away from it's all about the code basically, and it's actually more about problem solving, it's about problem solving in a fast, efficient and high quality way, then that's where you're starting to become really getting into that, we'll call it that developer mindset. And that's a lot of what we talked about here. We definitely have mentioned Pomodoro many, many times is like finding ways to be able to focus, finding ways to get that time where you're not trying to multitask, but you're able to single focus, get that laser like focus, get the problem solved and move forward instead of getting distracted, which is also goes into things like comments and documentation and things like that. Because as we talk about, sometimes your distraction is that you put that project down and you don't come back for three months and you look at it and you go, what the heck is this? Where is this coming from? I don't remember what I was doing. And if you're documenting and putting code commits, particularly if you're good messages that are solid in your code commits, that should help you rebuild the thought process or another developer when they pick that up. So I think those are some core skills that are beyond just writing code to get you started. What are some that you'd like to throw out there? Yeah, since we kind of talked about GitHub in the first one with this one here as you're, I totally agree about the problem solving frameworks and as you become a better problem solver, you know, you kind of leave that coder mindset behind. You move into that developer mindset. Interestingly enough, as you build these skills, as you get better at writing your software, you want to document use cases, user scenarios, test-driven development, writing unit tests are also very good ways for you to build up that documentation. If you can figure out how to write user stories, that is great for communication because you can communicate that back to the business. This is how the software is going to work from the use case, from the user's perspective. Documentation isn't just about comments. You can even write markdown languages or readme files within your code set so that you can tell yourself or even developers later, hey, this is how the code works. This is how you compile it. This is how you run it. You know, things that you take for granted now are going to be critical six months a year from now or 15 years from now when you have to touch the code again. The other thing too is there are tools that are out there that can actually take that markdown language or those comments that are in your code and generate nice wikis around that. API docs is a good one that comes to mind. You can write in markdown and it generates a nice kind of webpage format for your documentation. You know, a lot of languages have their own variations of like Java docs or some type of docs that will generate their documentation. Allow them are proprietary. Look for something that's generic that you can use for anything. Again, markdown is pretty standard across this plate and time management techniques. I love that. Pomodoro, task batching flows of the state. Don't forget your trusty little note cards. You know, make your lists, make sure you follow them and stay on task. So then the next one it goes into is expanding the toolkit with soft skills. So three bullet points here, emotional intelligence when working on a team, negotiating requirements and saying no politely, mentorship and knowledge sharing as a productivity booster. So all three of these are again, these are like your next step up and definitely what you grow you into being a developer more than just a coder. We've talked a lot about the team dynamics and a lot of it does go back to like we were all creatives in a way. I don't think a lot of us think of that, but if you're a developer, you're creative. And then that means that as all recreatives do, they have a tie to the things they created. It's like, you know, you're to your baby and you don't like it. You know, you don't like people throwing shade on your baby. You also, you know, like to protect it and all that kind of stuff. But that's not really what it needs to be is that you want to grow into this being a team effort and everybody being a part of it. So, you know, brainstorming and some of those things that typically are part of organizations and things like that, and all the stress that has evolved, the more you can avoid that, reduce it, defuse it, the better the team's going to work. People don't need to be stressed out. They don't maybe ticked off or anything like that. Are you going to be? Yes. Is it suck when you're in the middle of a death march or something like that? Yes. But whatever you can do to ease that stress and such things will help your team out. I say no politely, I think is goes back to a couple of episodes back where we talked about scope creep. I think it is very, it's, it's more than polite. It's just saying no in general, because I think way too often we get into something we want to impress our boss or we're scared that if we say no to the customer, they're just going to like pull the plug on the project or things like that. It's not just saying it politely. It's just having a reason for saying no. It's like if there's, and it's sort of is sometimes going to be counter to it. They need to have a reason for saying yes. If they say, Hey, we want this feature, then they should have a reason for it. And it doesn't mean that you like, you know, beat them up and try to place devil's advocate everywhere, but you just want her to have a good reason to say, okay, that sounds like a good enough reason. We can go forward. If they don't, then that's where you also need to be able to say, you know what? I don't know that we need this. And here's the reason why is, you know, it's like, we're over budget already, or that's going to take a lot of time, or it's going to take costs, or it's going to disrupt all the test flow or whatever the reason is that needs to be part of. So it's not just being polite in your nose and even your guesses, but it's like being measured in doing so, so that your customer can, you know, builds their trust in you. That's like, hey, they're not just shooting from the hip. If you're going to shoot from the hip, say, hey, that shot needs to be, hey, I'm not really clear on that. I'll come, I'll get back to you later. And I tell you, that is probably one of the best things that I learned early on in consulting was that you can just, there are times where, yes, it's nice to be able to give an answer, but it's also much more effective sometimes to say, you know what, I'm going to take a look at that. We're going to research it. We're going to get back to you. It just makes them feel that much better. Um, the last one I'm going to throw out just real quick is mentorship and knowledge sharing. You will learn stuff so much more if you're teaching somebody else than if you just learn it for yourself. That's just one of the things I've found. So it is definitely a gift that keeps on giving as it were, uh, your thoughts on those bullet points. Yeah. So I'm going to talk a little bit about, you know, the emotional intelligence and, you know, negotiating requirements and saying, no, all three of these bullet points kind of work well together. Um, emotional intelligence when working on a team, it's always good to try and take a pulse check of not just yourself, but of your team. Um, how are meetings going? How is the project going? You know, are you on a deadline? Is everyone crunch? Is someone having a bad day or things going on outside of the office? Sometimes, especially, uh, for those more senior or even managers, you need to understand what's going on with your team. How are they interacting? How are the players moving? Because if one person is down unintentionally, they could bring everyone else down because either they're not able to complete their work on time and that works fine to other people to get done. Uh, but sometimes it's not a fault of their own. It's just circumstances or what they are and they get stuck. You know, we all hit walls or we hit blockers and sometimes we have to walk away or do something else before we can come back to it. Negotiating requirements and saying no politely. Uh, I think it was like Tim Ferrars, uh, for our work week years ago was basically like, just say no to everything. If you are not good at saying no schedule a day or two and just say no to everything, like no to meetings, no to calls, just do it politely, but get, do a day or two of that and just say no to everything and see how people react, figure out how to curtail it. Uh, the more you can politely say no or kind of handle, uh, negative situations and say, Hey, we need to stop time out. You know, let's take a break. That's a very good negotiating skills, especially when dealing with requirements. And lastly, the mentorship and knowledge sharing, think like geek drinks, um, coffee breaks, even in a virtual world, uh, you can have coffee breaks, mentorship, knowledge sharing through video chats. You can take 15 minutes a day and say, Hey, throw the team on there. Hey, anyone have a good idea? You know, anyone learn anything new today? If you have larger topics schedule like geek drinks, like an hour, uh, later in the day, maybe have a coffee again, or, Hey, maybe have a beverage of your choice. Or if it is a more formal training, like, Hey, let's go into a demo. Let's go through and like, look at how to use this product or something new that would benefit the whole team schedule, like a one or two hour lunch, lunch and learn and have everyone in. If you're remote, Hey, managers, you know, get like a, um, what's it? Um, grab hub card or something. So now it's your team, you know, like what we used to have pizza Fridays and whatnot, you know, everyone gets their food. You sit down, you can have good times and everyone kind of shares in the knowledge and learn something new. Uh, we'll go quick to this last one, just on for time considerations, uh, continuous learning. And this is why I want to make sure we get this in there. The ultimate tool, uh, curating a learning pipeline, blogs, podcasts, newsletters, courses using AI tools, like chat, GPT, co-pilot effectively without becoming dependent, uh, building personal projects or contributing to open source as a practice. Um, I'm going to dive in because I've, I've been, I have been in different sides of the AI discussion for quite a while early on. Uh, and I do definitely see it in many cases where it is a crutch. And I think that's your biggest danger is that you get into some of these AI tools, co-pilot and such that basically just let it write your code and you just sort of figure it out, you know, from there, as opposed to being very intentional on where you pick it up. So a lot of times I find the best things to do the best use of those kinds of things. Uh, the AI tools is where you know what the solution is. You could do it. It's just, it's going to take you time. And so when you do that, you can do the, uh, direction of AI to a level that's going to help you out. That's going to be able to give you a solution. That's pretty solid. Um, yeah, sometimes you're going to have to do a little, you know, a little reining it in and things like that. But I think that I found that is definitely the best way. If I don't know what, uh, you know, if I really am not sure where I'm going with this thing and I try to have AI help me, it's probably not going to help me very much. It's actually probably going to cost me more time than it's not. Um, but if I've got something very focused where I'm like, okay, this is what I know I'm going to do. Here's the steps and I can lay it out much like anything else. If you can really tighten down your requirements and tell somebody, here's what I need. They're more likely to give you a, you know, a good response and AI is just like that. And if you don't understand what you're doing, if you don't understand the problem you're solving, you're going to end up solving a completely different problem. You're going to have a great solution that is absolutely useless because it's not doing what it should have done. Uh, your thoughts on this one. Yeah. So I'm going to take this one, you know, learning pipelines, hate development, but also look for things like mentorships, look for people that can teach you. If you have a friend or someone at work that knows a particular skill or technology that you want to learn and they're open to sharing it with you, Hey, schedule some time with them, take them out to eat. You know, it's really good to pair up with someone and even maybe get a mentor to help you learn something new. And with that, you know, I beat this horse dead all the time. Um, building a personal project kitchen sink apps are the number one way that developers can build a Swiss army knife in any language that they want to learn because you can build, basically you write your code for all the little things you want, you build your utilities and then you can apply them to all the projects that are out there. You basically have a tried and true solution on how this works. Like if you're using like Kafka, some message queue, Redis, you write one little app that actually does the work and then you can integrate that in. You just take your code. Hey, I've done this. Oh, okay. I need this in this project. You take it from here, put it in there. You already have your code. Hopefully you commented it and then you just plug it in and plug and play and go. Um, it's kind of like AI, but you took the time to learn it yourself. So you already have something you can go to, to kind of pull out and apply elsewhere. Yeah. Your own personal code repository. We didn't really talk about that site. We've talked about it in other cases, uh, that is something that's very valuable to have. And it is, it's much like AI. It just happens to be your AI, your eye, as opposed to somebody, you know, some artificial version of it. Uh, and it can be much faster than even doing the searches and other stuff because it's your code. Uh, so you know, it better, you know, hopefully better than anybody else. And you can plug that right in wherever you need to do. So, uh, one of the things you can also do is you can shoot us an email info at developer.com and let us know where there are some of the things that you, the tools that you use, how do you get better? Uh, what are some of the other places like the awarding pipelines that you have and things like that, because we're always looking for ways to, uh, to improve that. Um, we've got, obviously we've got tons of that stuff out on development or.com. We've got over a thousand articles out there. When you look at all the stuff out there, uh, YouTube, we've got, I don't know, we're probably approaching 500 different things out there on the, in the YouTube channel across all the different areas. I was just looking the other day, cause I was trying to build out a couple of little links and we've got some really cool stuff there. Um, we've got some long series. I'd forgotten how much content had gone into a couple of the series, the training series that we've got, particularly in the world of, uh, SQL and Python and Django. Uh, we've got a whole bunch of stuff there that we've done. All of that is free right now until we decide that we want to somehow put that behind a paywall. So grab it while you can basically leave us comments at any of those places. We'd love to hear if you have any questions, we would love to help you out with it as well, because our goal is to help you become better developers. I love the title of this. That being said, it's time for us to wrap this up. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers, the developer nor 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.