Detailed Notes
Welcome to a new season of the Building Better Developers podcast—this time with AI insights! In this episode, we revisit a fan-favorite topic: the journey from coder to developer. With the help of AI, Rob Broadhead and Michael Meloche explore what separates task-focused coding from problem-solving development.
✅ Key Topics: • Coding vs. developing mindset • Problem framing and solution thinking • AI’s role in developer growth • Debugging, collaboration, and feedback loops • Becoming a business-aware developer
🎧 Subscribe for more developer insights and strategies: https://develpreneur.com/coding-vs-developing-ai-podcast/
💬 Let us know in the comments—where are you on your developer journey?
00:00 - Pre-show 01:33 - Introduction 06:07 - Podcast: Coding vs. Developing 20:17 - Bonus and Final Thoughts: Business Awareness and Adaptability
#BuildingBetterDevelopers #SoftwareDevelopment #AIinTech
Transcript Text
[Music] I just hit record because if I didn't, boy, this would make us not happy. We have enough other stuff to do. We don't need to do like two of these back to back. Uh uh we're going to do the do a little scooch back and forth here. That looks not too bad. Yeah. And I can sit up straight. Fine. I'll sit up straight. All right. And so, uh this episode, for those of you joining us, I think we talked about it last time. What we're going to do is we're going to go back to season, I think it's 22, correct? 22. And we're going to go through starting at episode two, because this is episode two. We're gonna take the title, we're gonna shove it into AI, and we're gonna see what happens. And uh so far, I've already shoved it into AI. I'll join that when we get into the podcast side of it, the audio side. Uh and it's given me like 10 things for us to talk about. So, we will not get through all 10. That may be the bonus at the end of this is we'll cover like one extra one. Uh but, you know, we don't want to spend all night on it. So, that being said, because we're already late to our start, I have my water. I have a few minutes before my pizza is done, so I can get my intro in and then I can I can mute it and disappear while Michael talks. Hopefully, he may have to vamp for a while. I just got to figure out where I'm going to put my uh food when I get it here. I'll figure it out. So, this is gonna be a real fun time. The normal train wreck that you would expect with a three, a two, a one. Well, hello and welcome back. We are developer. We are the building better developers podcast. We are starting a new season. Uh 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 Roband. one of the founders of developer 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 road map, a s 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 uh execute that plan on your own and move into a better ROI on that biggest expenditure being technology. Good thing bad thing uh good thing was followed by the bad thing. So, uh, way back, uh, several episodes now, we talked about like one of the things is I've got a couple new toys that I've picked up as we're working towards a more of a remote, uh, 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. Uh, 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 cuz 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 do give you one monitor either side. The other one is just a screen basically at that point. Uh, so I was like, "All right, we'll go ahead and since those don't work, we're going to get an extra one." Well, I got another one. Got that today. It took That's the bad thing. Uh, that plus you have to hear through all this. Uh, it took quite a while. I was I'm used to Amazon and it being like next day. It's now like 10 15 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 uh display resolution. So I'm very happy with that. Uh I can geek out a little bit again. Uh 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 Michael. 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 Michael Malashsh. I'm one of the co-founders of Developer, 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 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. Uh, this week's mixed bag. Uh, good thing. Uh, you know, the weather is better. Sinuses are finally improving. You know, we're we're past that. I'm praying all the Canadian fire smoke does not come down this far south cuz that would be bad. Uh, bad thing. Uh, right before this call, wife came upstairs wanting an HDMI cable because apparently our TV downstairs suddenly went out. Uh, so if you hear a large crash during this, that's what's going on. Uh, 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 uh TV downstairs. All right. Well, good thing for us is we have a friend AI um that is going to help us out this time. And so looking back uh what I did is I took our title which was uh 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 think we'll 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 mindset shift from task execution to outcome ownership. So for a coder it focuses on completing assigned tasks or features. For a 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 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. A coder is just going to 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 you know cost of resources and things like that. Um, so I think that's like a it's great that that is the first thing it hits is one of these that like we we hit this on a regular basis. We we definitely beat this drum. Uh, 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, uh, you tend to be more problem solvers who tend to be more forward thinking. uh you tend to try to 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 timebased time uh 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 taskbased 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 talk about when we 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 um you're you're cash strapped essentially. You you need to have that conversation sooner rather than later with your customers. Make sure that you can build that uh that buffer. Number two is a really good one. Problem framing over codewriting. Great developers learn to frame problems clearly before touching code tools uh ask questions, write problem statements, consider constraints. Uh entrepreneurs appreciate developers who challenge vague requirements to clarify the core problem. That one uh I'm going to say that they don't always appreciate that, but I think they do need that. I 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. Um, you know, let's let's dig into these requirements and it's, you know, take it from just something that's scratched on a 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 uh sometimes because I'm more the uh 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 flesh 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 um 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 the that's where you get into things like test driven development, things like that is and some of the other ways that are um like the old 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 waters sometimes because you're going to you sort of 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 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, you know, entrepreneurs are not a fan of being called out on like 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 it's it's really thinking through the problem and what are the key pieces that we need to know so that we can get those those rec requirements built in, you know, sooner rather than later. This is a fun one. The next one, pattern recognition and abstraction. Skilled 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 this is actually an area where I love it because it is really where we've t this goes back to the developer book that is where it really talks about taking your 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 you know code library or an application that you use uh scratching your own itch maybe it's a development tool of some sort. Uh, you know, it could be something that you use for your like I've got a a buddy that is uh that actually was an ex- roommate that uh created Baza 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. So um I think these are things where it's really this is where developer and especially the developure 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. that my analogy of that is going to be more on the testing side. If 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 a function a module for just login testing and now you can plug that into other tests so you don't have to reuse that logic uh with websites it's great it's of page object model. uh you essentially define your tests at the page level and you do it through uh actions through what user interactions within the pages and then you can just plug and play those into other application or other tests and that's to me a kind of 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 sink app and I think Even today in the um Intelligj uh presentation they were doing they were talking about using database models to build uh 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 um that's one of those areas that is probably my is very near and dear to my heart is doing the uh essentially code automation, code generation so that you have you have applications that can build applications and things like that. That's sort of what no code really has, you know, has embraced that for sure. But there's a lot of other things like that that we can utilize that will take that that idea of, hey, I've solved a problem. Actually, funny enough, AI is very much that it's like that's problems 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 like crank through these uh real quick so we aren't like spending six hours in this specific episode. So, uh one of the things that next 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 um it's it gets back to the why. It's like why are we doing this and is it 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 some point. You're going to need to have them in your mind somewhere along the way when you're building out an application. Thoughts on that? 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 your software is still very key to a developer's journey uh 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 I have to I got to throw out a a a recommendation again that I've done before and it is uh Scott Adams who wrote Dilbert. He's got a book called uh Loser Think and it's actually it's a really good it's it's it is yes there's Dilbert comics and stuff like that but is really actually a pretty deep psychology psychiatry type of book and he talks about uh 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 it's this is a you know an engineering mindset, this is a sales mindset, this is a marketing mindset, this is a 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 you're not in the same mindset as that other person you're you're talking to. So, I think it's a really good one to, you know, to read. Like, it's it is not super light. It is actually it gets into some pretty uh deep kind of areas, but it's actually a really awesome book for that kind of stuff. Uh 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 onetrick pony that's like, I know C, I know Java, or whatever, 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 something to replace it. So, make sure you're always working on expanding your your quiver uh 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. Uh debugging is a learning superpower. Debugging tech teaches systems thinking, attention to detail and persistence. Encourage devs to treat bugs as puzzles, not annoyances. For entrepreneurs, devs who embrace debugging. reduce downtime and increase product quality. This is uh 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 I'm not going to say that you don't get frustrated with that. I trust me been there have all of the metals for frustration in 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 you know code especially other people's code over the years uh continuous feedback loops developers should seek feedback from both users and systems whether it's logs metrics user behavior uh the mindset should be released observe, learn, improve. That is a that is how you should do it. That's that is a cycle to success growth in particular. Entrepreneurs love devs who iterate fast and use data to guide development. Uh the last two will be business awareness and empathy. And then tools are temporary. Thinking is forever. Um both of those actually go back to the whole idea of don't be a one-trick pony. Uh and realize that you're solving a problem. You're not playing with a new technology. You may get to play with the new technology, but it's really comes down to you're solving a problem. Problem you can solve for me is send me an email at [email protected] 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? Uh do you think AI is cool? Do you think it's going to dominate the world? Do you think it's going to red 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? Uh always interested to hear your feedback. We'd love to hear whether it's through the email, whether you hit us up on uh developer.com, you can leave us feedback there. Leave us feedback wherever you listen to podcasts. Uh YouTube, you can check out the developer channel. You can check us out on xdevelopure. We have a Facebook page. We got a lot of crap out there. Uh we 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 no 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. Bonus. Um I tossed out the idea in there for bonus. What I said, what else is there for in there for bonus? What's it tell? Oh, nine and 10. So, business awareness and empathy. I'll go ahead and read those. Uh, understand business goals, acquisition, retention, revenue. Code should serve strategy, not the other way around. Developers with this awareness make better product decisions and trade-offs. Number 10 was tools are temporary, thinking is forever. Tech stacks change, problem solving ability endures. Encourage devs to focus on fundamentals, algorithms, architecture, communication. Entrepreneurs benefit from devs who don't chase shiny tools but solve problems effectively. So thoughts on that? So I'll go with the latter because when I went to college I kept wondering why they kept trying to teach us um the science and not actual programming. Like they kept teaching us all the sorting things like database models and it's like why are you teaching us all this? We're coders, right? We we're supposed to build things. We're supposed to code things. And honestly, it took me about two years after I got out of college where uh I was teaching for a while, it dawned on me that, oh, I can look at any system and really understand what's going on regardless of the language or the technology that's there. I it's the fundamentals of understanding how things work, which is really interesting because if you're the type that wants to take things apart to see how they work, and then try to put them back together, that is the perfect example of a developer versus a coder. A coder is a person that sits down, plugs it in, turns it on, great, I did my job, it's working. The developer is more inclined to, how does that work? Let me take it apart. Let me look at, let me get into the guts of it. Let me see how it works. And then, oh, okay. Next thing that comes along that's similar, I can take it apart, put it together again, and you may get to the point where you figure out the next better thing, and you build it because you understand all the pieces that come before it. I I agree. I think that's my college uh season. The best thing I got out of that was how to they taught me how to learn. uh every where I went every class we took was a new language. So you always had to learn you were learning theory whatever it was you know now you're using learning sorting techniques but you're doing it in a language that you've never learned and never used before. So it's every time it was learning a new language and learning some new theory stuff and usually it helped because you were usually learning a language that was very well suited for whatever the the topic was which was awesome from a resume point of view because when I graduated I had you know probably already had 15 languages that I had apps that I'd written. I I had utilized those things by the time I got through there. But the funny thing is almost all of those don't exist now. And you know I very quickly realized that oh I've got to I've got to learn got to learn most of actually all the languages that I use on a regular basis right now. Did not use it all in college. I'm not sure they even existed. I think they did to some extent but like Python way way you know it was version one or whatever it was. Java didn't exist. So, I got one additional bonus question I want to throw out there and it it's along the lines of the debugging problem solving. What is your experience or your advice to our listeners for how to handle a job where they encourage problem solving where they en encourage oh you're running into problems figure them out work through the problems versus a company where oh you can't figure it out and your manager stands over you why doesn't work why it doesn't work they don't really give you time so you have like one company that fosters and encourages is figuring things out, problem solving, and you have one where it's I want results. Well, I think the results is going to I mean, honestly, the short answer is the result. If you want results, you're probably going to end up with a coder. You're not going to have a developer because you just it's like I just need to get something done. Tell me what to do. Uh sometimes you combine both. I've known people like just get it done. I'm not going to give you anything to do it. Go figure it out. That's actually sort of fun, but it's also very difficult. And especially if you're not already a solid developer, you're just going to get ticked off and quit and go work at Walmart or something like that. I think at that point, I am not going to quit and go work at Walmart. Instead, I'm going to wrap this episode up and continue munching on my pizza because I'm starving. And then we will come back around and we're going to just keep on doing this. This is it's pretty cool. Uh I'm already looking ahead at like what the next episode is going to be. We're going to talk about solving problems without solving the problem. We're going to see what AI says about that. This should be really fun. Okay, go out there and have yourself a good one. I appreciate the time you guys have spent. Thank you. Sorry if we went a little long this time, but we'll get back next time. And I'm not going to promise we won't go long next time, too, because this stuff can get us going a little bit off the rails and down some rabbit trails. And that's okay. That is part of being a better developer. Go out there and have yourself a good one. We will talk to you next time around. [Music]
Transcript Segments
[Music]
I just hit record because if I didn't,
boy, this would make us not happy. We
have enough other stuff to do. We don't
need to do like two of these back to
back. Uh uh we're going to do
the do a little scooch back and forth
here. That looks not too
bad. Yeah. And I can sit up straight.
Fine. I'll sit up straight. All
right. And so, uh this episode, for
those of you joining us, I think we
talked about it last time. What we're
going to do is we're going to go back to
season, I think it's 22, correct? 22.
And we're going to go through starting
at episode two, because this is episode
two. We're gonna take the title, we're
gonna shove it into AI, and we're gonna
see what happens. And uh so far, I've
already shoved it into AI. I'll join
that when we get into the podcast side
of it, the audio side. Uh and it's given
me like 10 things for us to talk about.
So, we will not get through all 10. That
may be the bonus at the end of this is
we'll cover like one extra one. Uh but,
you know, we don't want to spend all
night on it. So, that being said,
because we're already late to our start,
I have my water.
I have a few minutes before my pizza is
done, so I can get my intro in and then
I can I can mute it and disappear while
Michael talks. Hopefully, he may have to
vamp for a while. I just got to figure
out where I'm going to put my
uh food when I get it here. I'll figure
it out. So, this is gonna be a real fun
time. The normal train wreck that you
would expect with a three, a two, a one.
Well, hello and welcome back. We are
developer. We are the building better
developers podcast. We are starting a
new season. Uh 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 Roband. one of the
founders of developer 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
road map, a s 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 uh execute that plan on your
own and move into a better ROI on that
biggest expenditure being technology.
Good thing bad thing uh good thing was
followed by the bad thing. So, uh, way
back, uh, several episodes now, we
talked about like one of the things is
I've got a couple new toys that I've
picked up as we're working towards a
more of a remote, uh, 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. Uh, 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 cuz
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
do give you one monitor either side. The
other one is just a screen basically at
that point. Uh, so I was like, "All
right, we'll go ahead and since those
don't work, we're going to get an extra
one." Well, I got another one. Got that
today. It took That's the bad thing. Uh,
that plus you have to hear through all
this. Uh, it took quite a while. I was
I'm used to Amazon and it being like
next day. It's now like 10 15 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 uh display resolution.
So I'm very happy with that. Uh I can
geek out a little bit again. Uh 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 Michael. 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 Michael Malashsh.
I'm one of the co-founders of Developer,
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 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.
Uh, this week's mixed bag. Uh, good
thing.
Uh, you know, the weather is better.
Sinuses are finally improving. You know,
we're we're past that. I'm praying all
the Canadian fire smoke does not come
down this far south cuz that would be
bad. Uh, bad thing. Uh, right before
this call, wife came upstairs wanting an
HDMI cable because apparently our TV
downstairs suddenly went out. Uh, so if
you hear a large crash during this,
that's what's going on. Uh, 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 uh TV
downstairs. All right. Well, good thing
for us is we have a friend AI um that is
going to help us out this time. And so
looking back uh what I did is I took our
title which was uh 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 think we'll 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 mindset shift
from task execution to outcome
ownership. So for a coder it focuses on
completing assigned tasks or features.
For a 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 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. A coder is just
going to 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 you know cost of
resources and things like that. Um, so I
think that's like a it's great that that
is the first thing it hits is one of
these that like we we hit this on a
regular basis. We we definitely beat
this drum. Uh, 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, uh, you
tend to be more problem solvers who tend
to be more forward thinking. uh you tend
to try to 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 timebased
time uh 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 taskbased
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 talk about when
we 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 um you're
you're cash strapped essentially. You
you need to have that conversation
sooner rather than later with your
customers. Make sure that you can build
that uh that buffer. Number two is a
really good one. Problem framing over
codewriting. Great developers learn to
frame problems clearly before touching
code tools uh ask questions, write
problem statements, consider
constraints. Uh entrepreneurs appreciate
developers who challenge vague
requirements to clarify the core
problem. That one uh I'm going to say
that they don't always appreciate that,
but I think they do need that. I 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. Um, you know, let's
let's dig into these requirements and
it's, you know, take it from just
something that's scratched on a 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 uh sometimes because I'm
more the uh 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
flesh 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 um 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 the that's where
you get into things like test driven
development, things like that is and
some of the other ways that are um like
the old 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 waters sometimes because
you're going to you sort of 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
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, you know,
entrepreneurs are not a fan of being
called out on like 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 it's it's really thinking
through the problem and what are the key
pieces that we need to know so that we
can get those those rec requirements
built in, you know, sooner rather than
later. This is a fun one. The next one,
pattern recognition and abstraction.
Skilled 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 this is actually an area where I love
it because it is really where we've t
this goes back to the developer book
that is where it really talks about
taking your 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 you know code library or
an application that you use uh
scratching your own itch maybe it's a
development tool of some sort. Uh, you
know, it could be something that you use
for your like I've got a a buddy that is
uh that actually was an ex- roommate
that uh created Baza 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. So um
I think these are things where it's
really this is where developer and
especially the developure 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.
that my analogy of that is going to be
more on the testing side. If 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 a function a module for just login
testing and now you can plug that into
other tests so you don't have to reuse
that logic uh with websites it's great
it's of page object model. uh you
essentially define your tests at the
page level and you do it through uh
actions through what user interactions
within the pages and then you can just
plug and play those into other
application or other tests and that's to
me a kind of 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 sink app and I think Even
today in the um Intelligj uh
presentation they were doing they were
talking about using database models to
build uh 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 um that's one of those
areas that is probably my is very near
and dear to my heart is doing the uh
essentially code automation, code
generation so that you have you have
applications that can build applications
and things like that. That's sort of
what no code really has, you know, has
embraced that for sure. But there's a
lot of other things like that that we
can utilize that will take that that
idea of, hey, I've solved a problem.
Actually, funny enough, AI is very much
that it's like that's problems 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 like crank through
these uh real quick so we aren't like
spending six hours in this specific
episode. So, uh one of the things that
next 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 um it's it gets back to the why.
It's like why are we doing this and is
it 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
some point. You're going to need to have
them in your mind somewhere along the
way when you're building out an
application.
Thoughts on that? 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 your
software is still very key to a
developer's journey uh 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
I have to I got to throw out a a a
recommendation
again that I've done before and it is uh
Scott Adams who wrote Dilbert. He's got
a book called uh Loser Think and it's
actually it's a really good it's it's it
is yes there's Dilbert comics and stuff
like that but is really actually a
pretty deep psychology psychiatry type
of book and he talks about uh 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
it's this is a you know an engineering
mindset, this is a sales mindset, this
is a marketing mindset, this is a
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 you're not in the same mindset as
that other person you're you're talking
to. So, I think it's a really good one
to, you know, to read. Like, it's it is
not super light. It is actually it gets
into some pretty uh deep kind of areas,
but it's actually a really awesome book
for that kind of stuff. Uh 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
onetrick pony that's like, I know C, I
know Java, or whatever, 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 something to replace
it. So, make sure you're always working
on expanding your your quiver uh 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. Uh
debugging is a learning superpower.
Debugging tech teaches systems thinking,
attention to detail and persistence.
Encourage devs to treat bugs as puzzles,
not annoyances. For entrepreneurs, devs
who embrace debugging. reduce downtime
and increase product quality. This is uh
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
I'm not going to say that you don't get
frustrated with that. I trust me been
there have all of the metals for
frustration in 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 you know code especially other
people's code over the years uh
continuous feedback loops developers
should seek feedback from both users and
systems whether it's logs metrics user
behavior uh the mindset should be
released observe, learn, improve. That
is a that is how you should do it.
That's that is a cycle to success growth
in particular. Entrepreneurs love devs
who iterate fast and use data to guide
development. Uh the last two will be
business awareness and empathy. And then
tools are temporary. Thinking is
forever. Um both of those actually go
back to the whole idea of don't be a
one-trick pony. Uh and realize that
you're solving a problem. You're not
playing with a new technology. You may
get to play with the new technology, but
it's really comes down to you're solving
a
problem. Problem you can solve for me is
send me an email at [email protected]
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? Uh do you think AI
is cool? Do you think it's going to
dominate the world?
Do you think it's going to red 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? Uh always interested to
hear your feedback. We'd love to hear
whether it's through the email, whether
you hit us up on uh developer.com, you
can leave us feedback there. Leave us
feedback wherever you listen to
podcasts. Uh YouTube, you can check out
the developer channel. You can check us
out on
xdevelopure. We have a Facebook page. We
got a lot of crap out there. Uh we 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 no 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. Bonus.
Um I tossed out the idea in there for
bonus. What I said, what else is there
for in there for bonus? What's it tell?
Oh, nine and 10. So, business awareness
and empathy. I'll go ahead and read
those. Uh, understand business goals,
acquisition, retention, revenue. Code
should serve strategy, not the other way
around. Developers with this awareness
make better product decisions and
trade-offs. Number 10 was tools are
temporary, thinking is forever. Tech
stacks change, problem solving ability
endures. Encourage devs to focus on
fundamentals, algorithms, architecture,
communication. Entrepreneurs benefit
from devs who don't chase shiny tools
but solve problems effectively. So
thoughts on that? So I'll go with the
latter
because when I went to college I kept
wondering why they kept trying to teach
us um the science and not actual
programming. Like they kept teaching us
all the sorting things like database
models and it's like why are you
teaching us all this? We're coders,
right? We we're supposed to build
things. We're supposed to code things.
And honestly, it took me about two years
after I got out of college where uh I
was teaching for a while, it dawned on
me that, oh, I can look at any system
and really understand what's going on
regardless of the language or the
technology that's there. I it's the
fundamentals of understanding how things
work, which is really interesting
because if you're the type that wants to
take things apart to see how they work,
and then try to put them back together,
that is the perfect example of a
developer versus a coder. A coder is a
person that sits down, plugs it in,
turns it on, great, I did my job, it's
working. The developer is more inclined
to, how does that work? Let me take it
apart. Let me look at, let me get into
the guts of it. Let me see how it works.
And then, oh, okay. Next thing that
comes along that's similar, I can take
it apart, put it together again, and you
may get to the point where you figure
out the next better thing, and you build
it because you understand all the pieces
that come before it. I I agree. I think
that's my college uh
season. The best thing I got out of that
was how to they taught me how to learn.
uh every where I went every class we
took was a new language. So you always
had to learn you were learning theory
whatever it was you know now you're
using learning sorting techniques but
you're doing it in a language that
you've never learned and never used
before. So it's every time it was
learning a new language and learning
some new theory stuff and usually it
helped because you were usually learning
a language that was very well suited for
whatever the the topic was which was
awesome from a resume point of view
because when I graduated I had you know
probably already had 15 languages that I
had apps that I'd written. I I had
utilized those things by the time I got
through there. But the funny thing is
almost all of those don't exist now. And
you know I very quickly realized that oh
I've got to I've got to learn got to
learn most of actually all the languages
that I use on a regular basis right
now. Did not use it all in college. I'm
not sure they even existed. I think they
did to some extent but like Python way
way you know it was version one or
whatever it was. Java didn't exist. So,
I got one additional bonus question I
want to throw out there and it it's
along the lines of the
debugging problem solving.
What is your experience or your advice
to our listeners for how to handle a job
where they
encourage problem solving where they en
encourage oh you're running into
problems figure them out work through
the problems versus a company where oh
you can't figure it out and your manager
stands over you why doesn't work why it
doesn't work they don't really give you
time so you have like one company that
fosters and encourages is figuring
things out, problem solving, and you
have one where it's I want results.
Well, I think the results is going to I
mean, honestly, the short answer is the
result. If you want results, you're
probably going to end up with a coder.
You're not going to have a developer
because you just it's like I just need
to get something done. Tell me what to
do. Uh sometimes you combine both. I've
known people like just get it done. I'm
not going to give you anything to do it.
Go figure it out. That's actually sort
of fun, but it's also very difficult.
And especially if you're not already a
solid developer, you're just going to
get ticked off and quit and go work at
Walmart or something like that. I think
at that
point, I am not going to quit and go
work at Walmart. Instead, I'm going to
wrap this episode up and continue
munching on my pizza because I'm
starving. And then we will come back
around and we're going to just keep on
doing this. This is it's pretty cool. Uh
I'm already looking ahead at like what
the next episode is going to be. We're
going to talk about solving problems
without solving the problem. We're going
to see what AI says about that. This
should be really
fun. Okay, go out there and have
yourself a good one. I appreciate the
time you guys have spent. Thank you.
Sorry if we went a little long this
time, but we'll get back next time. And
I'm not going to promise we won't go
long next time, too, because this stuff
can get us going a little bit off the
rails and down some rabbit trails. And
that's okay. That is part of being a
better developer. Go out there and have
yourself a good one. We will talk to you
next time around.
[Music]