Coding vs. Developing: What AI Reveals About Developer Growth

Welcome to building better developers, the developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello, and welcome back. We are developing newer we are the building better developers podcast. We are starting a new season. We talked about last episode, we talked about what we're going to do. This is going to be basically two seasons back. But now we're going to feed it into AI and we're going to see where that journey takes us. But before we do that, I am one of your guides on this incredible journey, not artificial intelligence in any way, no artificial, no intelligence, none of the above. I am just Rob Rodd and I'm one of the founders of developing or also a founder of RB consulting where actually we are pretty darn intelligent there. And actually, more importantly, we have a background in technology. And our goal is to sit down with you as a business, talk about what your goals are, where you're going. What is your current technology footprint? Is it big sprawling thing? Is it nice and clean? We do a technology assessment, we sit down, work with you figure out where you're at. And then through ideas like simplification, integration, automation, and even innovation, we will help you craft a roadmap a six a recipe for success that is specific to you. And then we will help you execute it or give you whatever you need so that you can go on and execute yourself, execute that plan on your own, and move into a better ROI on that biggest expenditure being technology. Good thing, bad thing. Good thing was followed by the bad thing. So way back several episodes now, we talked about like one of the things is I've got a couple of new toys that I've picked up as we're working towards a more of a remote kind of relationship, and had some really nice screens. It was a nice little thing. So I went from my one screen on my laptop to three screens. And it's portable. And it was pretty darn cool. I think I may even had a link in the show notes somewhere. Well, it turns out that that doesn't work for my wife's laptop because she's got a MacBook Air, like, you know, spoiler alert. If you have the MacBook Air, it does not support more than one extra monitor. So basically, it would give you one monitor either side, the other one is just a screen basically at that point. So I was like, All right, we'll go ahead. And since those don't work, we're gonna get an extra one. Well, I got another one got that today took. That's the bad thing that plus you have to hear through all this. It took quite a while I was I'm used to Amazon and it being like next day. It's now like 1015 days later, finally got it. Now to the good part, I got that today. It is slick. It's like it's light. It's it's really easy to plug in. And even lighter than the other ones. And it's actually a little bit better display resolution. So I'm very happy with that. I can geek out a little bit again. And I didn't really need two screens because it was too easy for me to get distracted by too many other things. So it's sort of nice to get down to like my main screen and then maybe something for doing a little reference on whatever it is I'm chasing through. That being said, we can now move it over to my call. I'm not even going to make any jokes this time because I've taken too long. Go ahead and introduce yourself. Hey, everyone. My name is Mike Malasha. I'm one of the co-founders of developer NERV building better developers. I'm also the founder of Envision QA, where we help businesses by creating tailored software to meet your needs. It can be something is very simple to just help eliminate the processes that are eating up your time to help speed up your business. It could be, hey, we can automate updating backups of your website so that you don't have to waste time or, oh, hey, your site gets hacked and now you're down and have to spend thousands to get your site back up. We essentially partner with our customers to help them with whatever software or technology problems plague their business. Good thing, bad thing. This week's mixed bag. Good thing, you know, the weather's better. Sinuses are finally improving. You know, we're past that. I'm praying all the Canadian fire smoke does not come down this far south because that would be bad. Bad thing, right before this call, wife came upstairs wanting an HDMI cable because apparently our TV downstairs suddenly went out. So if you hear a large crash during this, that's what's going on. I don't know what I'm going to be walking into after this. So good thing is I'm upstairs recording. Bad thing is my wife is having to deal with the technology computer or TV downstairs. All right. Well, good thing for us is we have a friend, AI, that is going to help us out this time. And so looking back, what I did is I took our title, which was Embracing the Problem-Solving Mindset from Coder to Developer. And I fed that into AI and to chat GPT. And I just said, for developers and entrepreneurs as an audience, what are some good points for embracing the problem-solving mindset from Coder to Developer? And of course, it is very positive. It's like, great topic. And it tells me that, hey, it speaks to a crucial evolution in a developer's journey. Okay, good enough. Let's get into what, here's some compelling angles to cover. And I'm going to just sort of like walk through these and maybe we'll have a little discussion about these as we find one that's like a really cool thing to talk further on. Mindset Shift from Task Execution to Outcome Ownership. So for Coder, it focuses on completing assigned tasks or features. For Developer, ask why the feature matters, what problem it solves, and how it affects the end user. Encourage devs to go beyond ticket-driven work and think about business value. This is an excellent first one. I think this is something that we like beat this drum on a regular basis of know your why. That is the best way to move from a Coder to a Developer. Coder is just kind of like complete a ticket and move on. Developers are going to actually solve a problem. They're not just there to write code. They're actually there to solve a problem. And it's not just like check a box that it's been solved, but how do we solve it in the best possible way for our users or cost of resources and things like that. So I think that's like, it's great that that is the first thing it hits is one of these that like we hit this on a regular basis. We definitely beat this drum. Your thoughts on that? Yeah, this is one of, probably one of our better topics that we've talked about because, you know, a lot of times the Coder, you know, those starting out or just someone that all they care about is just getting their work done. They're just going to look at a ticket and say, oh, it needs this, get done, move on, end of story. With developers, you tend to be more problem solvers. You tend to be more forward thinking. You tend to try to solve problems upstream rather than basically put out fires constantly. You're like, how do I stop this from being on fire? So you start thinking through these problems. It is an interesting topic though, because it also kind of delves into what role you're in. Because if you are a consultant and you are on a time based time, you know, to completion, you only have like maybe 20 hours for your budget. Sometimes though, you do have to kind of switch modes and get into that task based approach. You are more a Coder than a developer. If you have time on the projects, you spend a little more time developing and making sure those tasks are solving a problem. But sometimes again, just depending upon where you're at, you know, what your position is, you might get stuck in that Coder mindset. It's like they just want you to be the monkey. They just want you to be, you know, knocking out code as quickly as possible and not wasting time going down those rabbit holes or trying to go beyond the scope of the ticket. That's true. And I think that is one of the things that you, you know, we talk about when we talk about the business side of it, is that you want to avoid getting into that situation. You don't want to be in a situation where you are, you're cash strapped, essentially. You need to have that conversation sooner rather than later with your customers to make sure that you can build that buffer. Number two is really good. Problem framing over code writing. Great developers learn to frame problems clearly before touching code tools, ask questions, write problems, statements, consider constraints. Entrepreneurs appreciate developers who challenge vague requirements to clarify the core problem. That one, I'm going to say that they don't always appreciate that, but I think they do need that. I have been in too many situations where people have gotten frustrated when it's like, okay, let's talk about this in a much more specific way. You know, let's dig into these requirements and it's, you know, take it from just something that's scratched on a napkin and into something that we can actually build with it. What are your thoughts on that? Yeah, this one's kind of a funny one because you and I clash on this quite a bit. Sometimes because I'm more of the, because of my years of testing experience, I tend to like defining the requirements and flushing them out a little bit more on the front end, a little different than the agile approach. This is just more before you touch a ticket, you read what the ticket is, what is the requirements and really flush out what is the end goal. What are the user acceptance testing? Basically, what is, what are you producing? And if you start from there, you can essentially write your tests or write tests to essentially test what you need to do from the get go. And then you literally write the code to fill in your test. So you are essentially defining the problem a little more acutely, and then you can come through and put the tasks in place. Alternatively to that though, with Rob's approach, sometimes it's more the get it done approach, but you do still need to understand the ticket. You need to take a moment to read through, don't just assume everything's there because there could be something in the ticket that says, hey, change this parameter. And we expect X, but what no one may think about is that, oh, well, if I change this parameter here, yes, this one section of code works, but now I just broke the entire application because by flipping that one field, you may have essentially just disabled all the other features in the application. So you have to be careful just taking things at face value. Yeah, I think that's where you get into things like test driven development, things like that, and some of the other ways that are like the old RAD approach and some of those things, which are, and Agile does, I know I'm going a little off, Agile does muddy the water sometimes because it's too easy for people to push requirements down the road and not think about them. However, and this has happened on too many projects I've been on is that you get farther down and there were core requirements that really should have been addressed. It goes back to that idea of some of these entrepreneurs are not a fan of being called out on all of these details because they don't, sometimes they don't know what they don't know and that's okay to some extent, but you've also got to have somebody that's really like driving that process to make sure that we are working towards the things that matter when we're putting these things together. It's really thinking through the problem and what are the key pieces that we need to know so that we can get those requirements built in sooner rather than later. This is a fun one, the next one, pattern recognition and abstraction. Skill developers look for patterns and problems and abstract solutions that can be reused. For entrepreneurs, this mindset leads to more scalable and maintainable products. For example, turning a one-off integration into a plug and play module. This is actually an area where I love it because it is really where we've talked, this goes back to the development of a book that really talks about taking your growth, your roadmap for your career, building some things like applications and things like that, that then end up turning into products and services that you can provide to others, whether it's your own personal repository or code library or an application that you use, scratching your own edge. Maybe it's a development tool of some sort. It could be something that you use for your, like I've got a buddy that is, that actually was an ex-roommate that created Byzanta basically out of his own needs for tracking information around a consulting company and about software consulting and how do you keep track of that. I think these are things where it's really, this is where developer and especially the developer nor side of it really starts to kick in because now you're looking at ways to essentially turn from spending hours to solve a problem to how do I reduce those hours because I can take all of these bits and pieces and solve a new problem using the same things that I've already touched on. Yeah, my analogy of that is going to be more on the testing side. If you have a problem or you're trying to work through things, if you want to test, the quickest way to test is to just basically record a whole bunch of tests within your application. You write hundreds and hundreds of tests, just quickly record them. However, if you're more the entrepreneurial, more the framework building, you take the approach of, okay, what really goes into building these tests? What do I need for this? There is a common, if you take the record functionality and now think more along the lines of process procedures, user interactions, you think instead of going through the whole process of recording every functionality in the system, you have things like, okay, a user needs to log in. So you write a component, a function, a module for just log in testing. And now you can plug that into other tests so you don't have to reuse that logic. With websites, it's great. It's called a page object model. You essentially define your tests at the page level and you do it through actions, through user interactions within the pages. And then you can just plug and play those into other applications or other tests. And that's to me, just another abstract way of thinking through this problem. Because if you can look at a problem and there are multiple ways to do it, but if you can reuse multiple components in other places, build that code library, build that kitchen sync app. And I think even today in the IntelliJ presentation they were doing, they were talking about using database models to build core components that you basically just pull out of the database to build your application for reusability. So you essentially have a code library in a database and you just pull from that for different applications. Yeah, that is one of those areas that is probably my, is very near and dear to my heart is doing the essentially code automation, code generation so that you have applications that can build applications and things like that. That's sort of what no code really has embraced that for sure. But there's a lot of other things like that that we can utilize that will take that idea of, hey, I've solved a problem. And actually funny enough, AI is very much that. It's like that problem has been solved somewhere. So let's go grab it and reuse that solution as opposed to reinventing the wheel. Now, we are, like I said, we can go off the track fast. So I'm going to crank through these real quick so we aren't spending six hours in this specific episode. So one of the things that extra product thinking developers who ask how will users interact with this or what metrics should we monitor are far more valuable. This is a great one because it gets back to the why. It's like, why are we doing this? And is it actually going to be useful? Collaborative problem solving, developers grow by learning to work with designers, marketers, and product managers. Great solutions come from diverse input, not siloed code. Entrepreneurs want devs who can communicate and think cross functionality. That, gosh, we can, I said I was going to blow through it, but that's like one that is full stop. That is where you're going to definitely jump into that developer world, that architect, that solution architect, those kinds of the titles that everybody wants in the development world. You need to be able to understand how to talk to the people in the different departments. You need to understand how marketing and sales and all of those other pieces work because you're going to end up talking to them at some point. You're going to need to have them in your mind somewhere along the way when you're building out an application. Well, and these are things that AI can't necessarily bridge those gaps yet. So even though companies want to go full-fledged AI, like we're kind of testing the waters here, learning these skills, being able to interact with multiple departments, understand different areas of the company and how they interact with their software is still very key to a developer's journey and an entrepreneur's journey because if you don't know how to talk to these players, you're going to be siloing your application or siloing your company and not be able to grow. I have to throw out a recommendation again that I've done before and it is Scott Adams who wrote Dilbert. He's got a book called Loser Think and it's actually a really good, it is, yes, there's Dilbert comics and stuff like that, but it's really actually a pretty deep psychology, psychiatry type of book. And he talks about, that's one of the best things about it, he's got three or four chapters where he talks about the typical mindsets of people that are certain types of careers. So this is an engineering mindset, this is a sales mindset, this is a marketing mindset, this is an executive mindset and as you go through these, they really make sense. And the key to this is it talks about where a lot of times the disconnect comes in some of the communication because you're not in the same mindset as that other person you're talking to. So I think it's a really good one to read. It is not super light, it is actually, it gets into some pretty deep kind of areas, but it's actually a really awesome book for that kind of stuff. Using constraints as creativity fuel. So embrace limitations like time, budget and technology as opportunities to innovate. Developers who thrive under constraints are assets to lean startups and bootstrap founders. This, I'm just going to throw a quick one and then we're going to move on, is that this is where it really helps you to not be tied to a technology. It helps you to be technology agnostic, spend some time learning other stuff. Don't just be the one trick pony that's like, I know C sharp, I know Java or whatever it is, even if it's the latest thing, like right now, if you know Tailwind really good, awesome, but there's a lot of other apps out there and it's going to disappear at some point and it's going to be picked up by something else. There's going to be something that replaced it. So make sure you're always working on expanding your quiver, the arrows that are in there. And not just that, but different software languages offer different features and functionalities that could be better for the particular project you have. Oh, very much so. Debugging is a learning superpower. Debugging teaches systems thinking, attention to detail and persistence. I encourage devs to treat bugs as puzzles, not annoyances for entrepreneurs, devs who embrace debugging, reduce downtime and increase product quality. This is, it's interesting because we've never really talked about it in this point of view from this aspect, but I really think that if you, if you hate debugging, then you're probably not going to become a developer because that's just part of it is it's like, I think I got it and it does, I'm not going to say that you don't get frustrated with it. Trust me, been there, have all of the metals for frustration and dealing with debugging over the years. But it is also, there should be that little like, yeah, when you, you know, when you actually get stuff to work and you get that endorphin rush, plus you learn stuff. It is amazing how much I've learned debugging code, especially other people's code over the years. Continuous feedback loops. Developers should seek feedback from both users and systems where there's logs, metrics, user behavior. The mindset should be released, observe, learn, improve. That is how you should do it. That is a cycle to success growth in particular. Entrepreneurs love devs who iterate fast and use data to guide development. The last two will be business awareness and empathy, and then tools are temporary thinking is forever. Both of those actually go back to the whole idea of don't be a one trick pony and realize that you're solving a problem. You're not playing with a new technology. You may get to play with a new technology, but it really comes down to you're solving a problem. The problem you can solve for me is send me an email at info at developer.com and let me know, what are your thoughts? Where are you going with these kinds of things? As far as like, what are the technologies you're jumping into? Where would you love to hear more about a specific technology? Do you think AI is cool? Do you think it's going to dominate the world? Do you think it's going to remove everybody's job and we're all going to be sitting around and just going to be doing podcasts because AI is going to do all the work? Always interested to hear your feedback. We'd love to hear it, whether it's through the email, whether you hit us up on developer.com and leave us feedback there. Leave us feedback wherever you listen to podcasts. YouTube, you can check out the developer channel. You can check us out on x at developer.com. We have a Facebook page. We've got a lot of crap out there. We've got an insane amount of content out there, so definitely take advantage of it because it is absolutely free of charge. But if you want to send us a donation, we are also cool with that. That being said, there is a challenge this time. We're going to be, this is a challenge free season. So you guys get to like coast a little bit, 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 Develop-a-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.