Summary
This episode discusses the journey from being a coder to a developer, focusing on problem-solving and leveraging technology. The hosts, Rob and Michael, share their personal experiences and insights on how to transition from coding to developing.
Detailed Notes
The hosts, Rob and Michael, share their personal experiences and insights on how to transition from coding to developing. They discuss the importance of shifting from writing code to solving problems, the value of automation and scripting in simplifying processes, and the need to expand one's tool set and explore new technologies. They also highlight the distinction between being a coder and a developer, and the role of technology in solving problems, even if it's not code-related. The discussion is engaging and informative, but could benefit from a more structured approach.
Highlights
- The importance of shifting from writing code to solving problems
- The value of automation and scripting in simplifying processes
- The need to expand one's tool set and explore new technologies
- The distinction between being a coder and a developer
- The role of technology in solving problems, even if it's not code-related
Key Takeaways
- Shifting from writing code to solving problems is crucial for becoming a developer
- Automation and scripting can simplify processes and improve efficiency
- Expanding one's tool set and exploring new technologies is essential for growth
- The distinction between being a coder and a developer is not just about code
- Technology can be leveraged to solve problems, even if it's not code-related
Practical Lessons
- Start by identifying areas where technology can be used to simplify processes
- Explore automation and scripting tools to streamline workflows
- Expand your tool set by learning new technologies and frameworks
- Focus on solving problems rather than just writing code
- Consider alternative solutions that don't require coding
Strong Lines
- The best solution is not always the one that requires the most code
- Technology can be leveraged to solve problems, even if it's not code-related
- The distinction between being a coder and a developer is not just about code
- Shifting from writing code to solving problems is crucial for becoming a developer
- Automation and scripting can simplify processes and improve efficiency
Blog Post Angles
- The importance of shifting from writing code to solving problems
- The value of automation and scripting in simplifying processes
- The need to expand one's tool set and explore new technologies
- The distinction between being a coder and a developer
- The role of technology in solving problems, even if it's not code-related
Keywords
- problem-solving
- technology
- development
- automation
- scripting
Transcript Text
Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back to episode two of season 22. And we are two people talking about developing. We're talking about building better developers. We are developing or we're talking about how to build better developers. This is the podcast. This is the place to be. This season, we are talking about the developer journey. This episode, we're going to get into a little bit. It's more of like, I guess, a retrospective for ourselves, but it's how do you know what was that point where you go from being a coder to becoming a developer? What are the things maybe that pointed you to being a developer, which is really, I know we've talked about it here and there, but the gist of it this episode is going to be about turning from that person that likes to just sit there and write code to that person that's actually looking at how to solve problems and how to write better code. I would love to become a better host, but I'm not. I'm going to continue with the same thing where I talk too much before I introduce myself. My name is Rob Brodhead. I am one of the founders of Develop Nord, also founder of RB Consulting, where we do we solve problems. That's what we do, but really focused on simplification, automation and integration of systems because technology sprawls all over the place. And we like to come in with our little broom and stuff and clean it back up and make it nice and neat and put it in a nice little box and little ribbon on the top and maybe a little chocolate. I'm going too far because now I'm going to go over to Mike. Go ahead and introduce yourself. Hey everyone. My name is Michael Milos. I'm one of the co-founders of Develop Nord, also the founder of Envision QA, where we help small businesses, mid-sized businesses and clinicians write custom software to help automate their business needs. So I'm going to tell a little story about way back. One of the things that was, I think was a turning point for me from being a coder to a developer. This is in high school and I had taken some courses. I knew a little bit of programming, stuff like that. And we actually were doing a programming competition and we had gone the year before and the programming competition, I don't remember the language. I think it was, I want to say it was basic. It may have been Turbo Pascal or it may have been whatever you wanted it to be. It may have been that they had a couple of different things. But the whole point is they would give you a list of all these little problems, these little like mini code things. They're usually basically like, write a function to do this. It was like basically write a little application that does this, takes two numbers and adds them together or takes a number then generates a matrix of that size or whatever it is. It's always just like little random little things. So they're all little sort of self-contained programming problems. We had a team of four people. First year I went, it was my junior year of high school. We go, we ended up in second place. We split it up. There's four of us. We've got one computer for the team because that's what you had. And so each team had one computer. And so what we did is we would sit there and like crank out our code, like write it out on notebook paper. So solve it there, pseudo code it. And then we would take turns sitting in front of the computer and typing our stuff in, save it off. However, it was that we sent it to them. I think we printed it out and then they re-entered it. Really efficient system. I digress. We ended up in second place. The next year we said, all right, it's not about programming. This was like, how do we win? What went wrong? What stopped us last year that we can correct so we can win this year? And one of the things was that one computer was it was like we would sit there and we write and we had to like transfer it out and all that kind of stuff. Now, yeah, if we could have brought a second computer, that would have been cheating. It would have been awesome. We would have kicked their butt. Instead, we're like, well, what can we do? What we can do is we can find somebody that can type faster than we can. And so we went from a team of four coders to three coders and somebody that understood general basic programming stuff, so understood programming a little bit, but typed faster than any of us. We were like maybe 40, 50 words a minute. This is this lady that was a girl because we're in high school. This girl that would like crank out 80 to 90 words a minute. And even with code, she could just really crank through it. So if we, it would take us 10 minutes, take her literally like five or six minutes to enter the same stuff. The shortest part of that is we won. We like smoked everybody else. And it was like, I will never forget, we're sitting there and we're like, they didn't announce but third place, second and then first. And so it's third place and it's like, oh, and then second place like, oh, and the team that beat us a year before, they hadn't announced them yet. And so we're like, crap, I bet that just didn't work. And they announced us. So we're like, yeah, in your face, all of you people. We never told anybody what we did until years later, I think. We finally let the secret out. So yeah, we just switched up our team and decided to type faster. Now that to me was a turning point because it wasn't about writing code. Now, technically you would say, of course a programming contest is about writing code, but really it never is. And especially now there's a lot of these contests out there, these hackathons and stuff like that. It is not about writing code. It is about solving a problem. It doesn't matter how you get there. It's this is a problem. How do you solve it? And usually you are graded or scored on the best solution for that problem. Now that I think when you shift your mindset from, I need to write a bunch of code to solve this problem to sort of almost like reverse, I need to solve this problem. What is the best way to solve this problem? And how do I make the code solve that problem is very much like, if you think about like test driven development, some of these things that become more modern. But to me, that is a quintessential point in your journey is that point where you shift from I'm writing code, I'm really cool. I can do some code stuff to I'm solving problems. I am finding a way to use technology to solve my problems. And now I will pass this on to you and allow you to solve this problem for a little bit. What are your thoughts? And maybe do you have another like linchpin in the history of yourself? Or you're like, this is where I went from coder to developer. I actually had a different kind of start. So I went through high school doing all pre-med courses because actually I wanted to become a surgeon when I was in high school. I still took all the math classes. I like programming, but I liked it more of a hobby. So I learned all the basic, the Pascal. But I had a math teacher that basically enforced documentation to the nth degree to the point that we weren't really learning how to code or weren't really learning how to write logically. We were learning how to write documentation and that applied nothing. It bored me to tears. So I'm like, yep, I'm going to be a surgeon. Forget this. I'm just going to dab on this and play with this. I went to college and while I'm taking all my pre-med courses, I worked in the central supply office in the infirmary on campus. And in my daily job, I had to keep track of our inventory within our central supply. We were basically providing all the medical supplies to the infirmary. And this is back in the early, probably about mid 90s. Databases aren't really a big thing on windows yet at this time. But what we had was we had Excel, we had access, and we were keeping track of the entire inventory system in Excel. Every time something came in, we had to update one field, update another in app by department. And through my first semester, I learned how the software worked. I learned data entry. I learned how to keep track of inventory. But by the second semester, I'm like, why are we doing this? This is antiquated. There's a lot of double entries. Things weren't making sense. So I started learning VBA or macros within office, which is another form of programming. But what you're thinking is you're now taking a process and you're breaking it down into its components and you're starting to write a little automation step for macros to simplify the process. By the end of my second semester, by the start of my third semester, I had actually taken the entire Excel spreadsheet system we had and had actually dumped it into Access and had rebuilt the whole thing as a database and automated the whole system. Now mind you, I'm doing all this while I'm studying to become a surgeon. I'm taking biology, chemistry, anatomy. I'm taking no coding classes. I learned all this and this was actually even pre-internet. We didn't really have internet at the time. We had BBSs. So I had to pick up books in the library, learn how to do these things. And it actually piqued my interest. I'm like, there's got to be a better way to do this. So you start down that journey, not necessarily as a coder, but as a problem solver. And you're like, there's got to be better ways to do this. So you start thinking of automation. You start thinking of scripting and then you get into coding and you're like, wow, this is kind of cool. I, you take the next logical leap. Now, long story short, my journey to become a surgeon kind of fell flat. Once I got into the classes where I had to deal with needles, cause I have a phobia so bad that I passed out and I couldn't make it through the class long enough to stay awake or conscious without passing out in class. So I had to pivot and I decided, well, you know, I'm good at this. You know, I really like software. I like coding. And I decided to give it a whirl and heck, here we are 20 plus years later. Yeah. I'm loving it. I think that is a, you touched on something that I have found with a lot of people, particularly customers that I've worked with is that sort of that aha moment where they're working in. Usually it is, it's like Excel or access or something like that. Some tool that helps you get some of the, some of these things done. But then when you jump to the next level, where you realize that now where you're working at something, you're not in this constrained environment. And you're especially with like a general programming language, because honestly, there are very few things from a programming point of view, there are very few, few things somebody's going to ask for that you can't, that you're not going to be able to say that is possible. Now it may be very costly. It may be very expensive. It may be very fragile. For example, like scraping is a big thing these days. People go out there, get data from all these different sites. And I see all these places like, Oh, I'd love to have a customer Rolodex basically. So I'm going to go look at every website in the United States and be able to grab a phone number and a name and an email address and a mailing address. Yeah. That'd be awesome. But those things don't exist on all these sites. And then sometimes they're protected and they're in different formats. And there's all these different things that you have to deal with. So it could be done, but it's going to take a long time because you have to go through and find all of the cases basically, and find a way to address all of them. You're going to be able to get some 80-20 rule. You'll get a lot of stuff the first time around, but the closer you get to a hundred percent, the more time consuming and expensive it becomes. And so I've had numerous customers, but are in that first leap, particularly where they're in this thing that they've got a solution that sort of works. They're in a spreadsheet and it works. I mean, it's like they can move data around. It can add numbers. It can do some things they need it to do. They've got some formulas in there. And when you take that spreadsheet, I don't know how it's just, but we take that spreadsheet and we just put it into a web application. Now they lose the, the spread sheetness. I don't know how often they come back. I'm like, well, we like the Excel-ness of this where I can like just click on cells and enter some data. And a lot of times we ended up building that back in form. We have some way to build something like that form, but somewhere along the way they realized that that was actually maybe inefficient for what they're doing. Now it may be something where I'm swatting it flies. If you're watching the video, it's like, there's a little gnat that keeps going around. So it's, it's not me trying to do hand signals or, you know, like sign language. It's me trying to find this little gnat. So apologies. For those of you that aren't seeing this, just imagine me occasionally swatting a hand out there just to just, I don't know, liven it up a little bit. Back to the whole Excel thing. A lot of times this goes back to my initial thing is that sometimes we have a hammer. And so that's what we're using and that we learn how to solve the problem with the hammer. And so we have a spreadsheet and we learn how to solve, we define the problem in a way that it works for the spreadsheet. Now, sometimes we, a lot of times we give stuff up because we're, we do that with anything when you define it down, when you constrain it by definition, you're removing options, you're constraining it. But when you start to open it back up and sometimes we don't know how we've constrained it, we don't understand where we have shut off avenues until we open it back up. And so sometimes it's, it's really fun. This is like part of the joy of solving problems is when we, we could take somebody from a spreadsheet that works, that does their stuff, but they've got all these issues with it where they have to copy it and they have to save it and they have to back it up. And if something happens and it can like blow up the whole spreadsheet. And sometimes a lot of times they've got little custom VBA code and all these little things that they're doing. And they would love to be able to integrate, but right now they copy and paste stuff all the time. And then they copy and paste and they have to correct the pasted data, all that stuff. You've probably felt that pain at some point, regardless of where you're at. When that gets turned around to like, you know, maybe like just a form based thing where it's like all the data entry is form based and we can put all these kinds of validations in it and we can avoid breaking their data when they're adding new data. And then we can add sweeping scripting type things. It's like, Hey, if you click this button, it replicates that boom. You've suddenly got a new spreadsheet and it can reset some of your data or we can integrate with other systems. So you're not having to copy and paste now. Now you click a button or behind the scenes at night, all of that data gets pulled in, shoved into a report. Now you get to see your report. You can slice it, dice it, throw it into a business intelligence kind of thing. Whatever. Those are the steps that when we start looking to those, to me, that is really where you're becoming the developer. And it's where it's almost, I think, confusing to some people that writing code may not be your strength. Like, you know, like Michael said, it's like, there's a lot of people that come into this as a developer and they didn't come out of it as a coder. So they maybe don't have the same. And this may be some of you, you don't have a broad range of computer languages and skills that you have, but what you are is a problem solver. So you look at it and you look at what is it that you have, you know, what are the tool set that you've got there and figure out a way again, it is a little bit square peg round hole, but you find a way to think, make those things work. And how do you become a better developer is that you expand that tool set. You expand it so that when you realize, and I think that's part of that, that journey that we'll talk about is when you realize that the, the solutions that you're building, the tools that you're using are not ideal, that you're having to do something. It's like, this doesn't make sense. Thank you. Yeah. You, as you said, it's like, why should it be this way? Why can't we do it this other way? And when you start doing that, you explore where those tools and sometimes that's how you create tools as well. So I can go give you like toss this back to you. Give me some sort of like closing thoughts on that whole journey of coder to the developer. Yeah. And in addition to kind of, I kind of want to add a little thing onto what you're talking about there with the spreadsheets and that it doesn't necessarily mean for you to be a coder to have to necessarily work with these spreadsheets or these, uh, you know, screen scrapes, things like that. Your journey could even begin by looking at your business. You could be a paper driven business or in a warehouse and you see a process that why are we doing this so many times? We could put this into a computer. We could write a little bit of code. We can automate this. A lot of the things to me for the journey from a coder to a developer is you start connecting those dots. You start looking instead of me writing this one particular application for this one thing, you start looking at how can I take these systems or these processes that we do on a day to day basis? How can I streamline that? How can I write code that basically makes my life better? And at that point, you're taking that step on becoming a developer, not just a coder. Yeah. And I think that's, that's probably the best thing. There's a parting thought that I think is important is that being a better developer is not about code. It really is about solving problems. Now you, as a developer, you're, you're leveraging technology. So you're writing code, but there are sometimes I've, I talked to my customers about this, I say sometimes the best solution is pencil and paper sometimes. And especially starting out, because if you automate stuff and code it and do all of that. And so now you replicate that solution a lot of times, if it's a crappy solution, then you are building crap faster. Yeah. It's like, it's, it's one of those things that there are stories about businesses that every time they sold a product, they didn't figure out the cost structure, right? So they were actually losing money every time they sold a product. And eventually they went out of business because they sold too many products. It costs them too much to advance to, you know, to get the additional customers. And sometimes we have that same thing that instead of writing a bunch of code and leveraging technology in a code sense, it may be better to leverage, leverage technology in a tracking data sense or something like that, which, you know, could go from maybe you're just pencil and paper and that's a pain to handle hand a folder all over the place. And instead now you, you know, maybe it's just as simple as instead of writing on paper and sending it to, you know, carrying it to the guy down the street, you use an email system and you just, and it's, you know, you didn't have to write any code, all you had to do was install something. But sometimes that's the first step in your journey to the developer side of solving problems and leveraging technology, particularly using what we have instead of having to reinvent the wheel, because that is another area that we get into way too often. And we may talk about that in a future episode, probably will, because we have 31 up or more other episodes ahead of us in this season. As always, thank you so much for joining us for your journey to become a better developer, because we want to get there. We want you to get there because when all of us get there, it saves us a lot of headaches and a lot of pain and it helps our customers helps literally can make the world a better place sometimes in very big ways, because it could be things like you're saving lives, you're doing better, you know, it's maybe in hospitals or something like that, where it is literally saving lives. Sometimes it's making it better because you rate games that people have a fun time playing, you know, it could be in all points in between. So as always, shoot us an email at info at developer night info at developer newer.com. If you have any questions, comments, suggestions, because we are open to those. We love to get feedback, love to take that, utilize that, and either work it into this season, the next episode, or sometime in the future. We may also have blog articles about it. We may have another little like side YouTube post about it. If you're not watching this on our YouTube channel, you can go out to youtube.com. I think it's slash developer newer. You will get the, uh, the developer newer channel. If not look up D E V E L P R E N E U R on youtube developer new also.com. You can see our site. We've got links out there to all of our stuff, including the school.development newer.com. We've got blog articles. We have got hundreds of old podcast episodes, including hundreds of interviews with people ranging from as rodeo clowns that are now working for Google to, uh, that actually would spend some time in blue man group to, uh, creating our own song at one point. And also like, you know, CEOs down to developers from marketing to you name it. We've interviewed them and they are really across the board. It's amazing how many interviews we have that were awesome that I walked out of there. I was taking notes. There was maybe like, I think that I could count on one hand, the ones that weren't that good, that were sort of like, okay, I'm running out of time. I need to get off of this interview. You are probably saying that to me right now. So I am going to let you go. 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 to develop a newer 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.