BrandGhost

The Truth About Our Code's Responsibility - Interview With Thimo Koolen

I was thrilled to have Thimo Koolen join me on the Dev Leader Podcast. We dug into the responsibility that comes with being a software engineer when the systems we build touch industries like healthcare and transportation. Thimo shared great advice for new developers: get hands-on, build real things, and apply what you learn instead of just consuming tutorials. We also explored the role of AI in software engineering, why fundamentals still matter, and how juniors can navigate today’s market without falling into Tutorial Hell. What stood out most to me was the reminder that our code isn’t just code -- it impacts people’s lives. Whether you’re just starting out or growing into senior roles, there’s a lot to take away from this conversation. I’m grateful Thimo made the time to share his journey and insights!
View Transcript
That's when you almost get in an information overload because you keep learning and learning and learning. If you're not applying your new knowledge, then you will forget it. Today's guest on the Dev Leader podcast is Teemo Coolen, and we got chatting about the responsibility that software engineers have as we're creating software that's used across different industries. We're also chatting through advice for new software engineers in terms of getting started, getting building things, and getting your feet wet, and just how important that is with respect to learning. And finally, no podcast would be complete without talking about AI. So, we were diving into what it looks like in terms of AI progression as well as why it's so important to understand the fundamentals so that you can use AI effectively. For me, there were a lot of really awesome takeaways from this conversation, so I think that you're really going to enjoy it. So sit back, enjoy, and I'll see you next time. Teammo, do you want to kick us off with some of your career journey? You can start as early as you'd like, as late as you'd like, but give us a little bit of background for how you got to where you are. >> Yeah, of course. Well, first of all, thanks again, Nick, for inviting me on podcast. >> Of course. >> And my instructions are either too short or too long, and there's no in between. So, I'm hoping for you that it's going to be like more on the shorter sides, but we'll see. >> Perfect. So I am a software engineering consultant working mostly with .NET but my interest in computer software engineering programming and all those kind of things started in a very very young age. >> Okay. I can't actually remember like when it started, but uh I've always been like loving experimenting with computers and like websites and programming. And around the age of 12 was when a certain game got really popular and I think it's still popular to this day. It's called Minecraft. >> Okay. And there's like you couldn't host a multiplayer server and that server had like a SDK of sorts where you can make plugins and I loved experimenting with it. I was clueless. So for some reason it worked and the code definitely was not good but uh it was a lot of fun to like play around with and mess around. And then like in the last two years of high school around 16 17 years old I think was when we had an option to join a Java class. >> Okay. >> Uh which was really small like only I think we were with 10 people or something. And this was where I actually learned programming like object-oriented with Java of course and I loved it so much and all those silly experiments started making sense like ah it's because of this and it works like that and it was just a lot of fun and I learned a lot knew a lot and at one point I wasn't allowed to answer any questions from the teacher anymore. because otherwise the others couldn't answer them because I was answering way too many of them. Uh but this really sparked my interest in programming and I joined a computer science course uh for uni and have my degree in computer science. It's a four-year course focusing on like the whole software development life cycle. So mainly programming but also like gathering requirements, testing and all those kind of inform. It's interesting actually. And this is just a quick reminder that if you're enjoying this conversation to like the video and subscribe to the channel for more future episodes. I I found that a lot of people that have gone through like college or university a lot of the time like from my own experience and when I'm talking to other people I end up hearing a similar story which is like we focused on a lot of uh sort of like history of of how we you know got to like first principles of different programming concepts a lot of like computer science fundamentals um for if for folks that went through like an engineering part there's like the chemistry the physics um but And I almost rarely ever hear anyone talk about like there was testing and there was software development life cycle. It's like those things like how we actually apply all of those things uh like the programming concepts just get dropped and you get tossed into the real world. >> Yeah, of course we got like the concepts behind certain things as well. Uh and it's of course different per school. Uh for us it was also we had a brand new curriculum because like we all know tech changes a lot and what was new and shiny 5 years ago is like garbage right now. Uh so we were also like a test person test class however you want to name it which had it ups and downs but was very interesting. And uh in those uh four years I had two internships both uh six months so about a year of internships in total. First one with first one was with Java and Cotlin in mobile development which was fun and my second one was my graduation internship which was withnet and Microsoft Orleans and I was working on adding a new feature to a chatbot uh project they have to basically implement long-term memory which I now jokingly say is like a first prior alpha version of the chat GPT memory and search. >> Yeah, >> of course. I I didn't graduate at OpenAI or something, but it's like it's like a very basic implementation of what we have right now with uh JPT. Uh and I really grown to love .NET. So, I started working with .NET after graduating, which is my current role as a software engineering consultant. I work for a Dutch company that does both consultancy and manage services. and cocy is uh a few areas such as development that I'm in uh data AI workplace infrastructure all on the Microsoft tech and I've done a few internal and a few external clients over the four and a half years that I've been there right now. Uh but uh the external clients are of course the most interesting and the best for your experience. So, the first one was for a major truck uh manufacturer in the Netherlands that's very active in Europe. And the team I was in worked on an application that allowed deal dealers uh across Europe to make quotes for maintenance packages. And it's pretty complex application actually. It sounds very simple, but you can basically compare it to like being in a car dealership and them having a whole uh car configurator tool with a lot of options and restrictions and uh option A and option B cannot go together. It's basically that but then for truck maintenance packages. >> That sounds pretty cool. >> It was really cool. It was really interesting and a lot more complex than it initially sounded. And then the second external client is uh where I'm at currently for about a year now and it's a healthcare institute for radiology where they treat patients that are diagnosed with cancer. And we are working on a new version of a very outdated uh electronic patient record. Uh so basically so they can treat the patients there. Uh and I really love the project. It's interesting and it's a great impact because you really help the institute to help uh people get better and get treated. Yeah, that makes a huge difference when uh you're able to find work where like don't get me wrong, I think as software developers like we all love solving complex problems, building systems, like that's part of why we do what we do. But when you can connect that to something for the end user where you're like, hey, like I actually feel like the impact I'm having is connected to that, I think that makes a world of difference. >> Absolutely. when you can do something that you either love doing like in a hobby or something or something that has a great impact that is so satisfying to work on. >> Yeah. Um it's uh no that's really awesome experience. I think that uh it's always interesting to hear uh I I find like a a lot of people and I don't know if there's there's got to be some correlation here. A lot of people seem to get started in programming because of games for some reason. Um, not everyone of course, but it seems like there's a lot of people. So, for you Minecraft, I can't remember for me what it was. Um, >> I I think before I could program it was like it wasn't really programming. It was like, hey, if I find these files and there's configurations there, I can like change some of the settings and like make the game easier. Like, I'm just looking for ways to cheat, basically. Um, and then I think once I figured out how to program and I had my first like classes in high school, I was like, I want to I need to make games like whatever I'm do like I need to go figure out how to make something. Uh, no game was ever good, but it was that was just like the big motivator for me. So, >> a lot of people seem to light up that way. And your observation is right because I've heard it before that uh a lot of people want to be like a game programmer which well can sound really attractive but I've also heard the industry can be really tough to be in there. >> Yes. >> Uh one of my colleagues actually wanted to be a game developer at first uh and joined us to get like more experience with uh developing net and he's still a net developer. He's loving it and he's learned a ton and well, I don't know if he still wants to be like a game developer. He might be, but right now he's enjoying what he's doing and that's important, I think. >> Yeah, it's uh I've I've heard the same thing about um like sort of the the game industry. I I actually do not know a single person who has gone to work in the game industry. So I I'm whatever I'm about to say is sort of like multiple levels removed, but what I have heard or what I've read is that uh there's a lot of sort of like um you know like there's a grind to get the release dates met, you know, more scope always being added, people working crazy hours and stuff like that. Um that's all that I've heard. And so it's like I think a lot of us on the surface are like, "Oh, making games would be so fun." And then everything else I see is like the reality is that it's terrible. But if anyone's watching or listening this and you, you know, have worked in the game industry and it's been different than that, it'd be super cool to hear. Uh cuz I've only ever heard it's terrible and that's kind of demotivating. But yeah, >> I've heard it's it's terrible like the conditions, the hours, like you said. Uh of course the pay is relatively low for tech. uh there's a lot of competition to get in there and to stay in the industry. So it's it's very competitive to get in and I think if you are dreaming of being a game programmer then it's best to start as like a quote quote normal programmer and learn the basics learn the foundations uh and get the experience under your belt because that really helps you uh get into the industry if you want to. Yeah, I've joked with uh with even my team my current team members uh that you know if I if I ever won the lottery like there would be sign like I wouldn't tell anyone but there would be signs and those signs would be that you would find me on a beach writing video games and like that's what I would just be doing. >> Yeah, absolutely. >> Yeah. And then I I thought it was interesting too that um and I don't know why this is always the case. I'm assuming because of regulations and things like that, but patient tracking any type of system like that always always seems like it's the most outof-date system that's ever existed like I don't know is it because of regulations and and data privacy and stuff like that. >> I think that's exactly exactly that. So there's a lot of regulations uh like who can access data, >> what rules, what needs to be locked. It's it's a ton and that makes it very difficult and of course things can be very specialized and if you want to use a system then you need a system that can work with all those specialties especially in like a larger hospital. And there there's like there's like a few uh products on the market that are very broad um can be used in like hospital but it's very hard to join the market as like a new product because you need a lot of investment to get started. You need uh if you want to be a hospital you need to basically support all departments. You need to be able to handle all the data, all the privacy, all the requirements, all the regulations. You need to be able to communicate with like GPS like with uh a lot of departments also externally. So there's a lot to it and it's like a multi-billion investment to even like get onto market. So it's really hard. Uh that's why there's like only a few major players there right now, >> right? >> Uh the the product we are working on is like internally for the healthcare institute. Uh because it's a really specialized uh environment with specific treatments, specific procedures. Uh so they really wanted something that worked for them. >> Uh and they already had an application but it was very outdated. Yeah, it's also written inn net but then like a very old version so not comparable and it was in uh I believe it was windforms or WPF I2 I always ground yeah >> I always like uh mix the two up but one of them uh now we're working with net 8 um LTS um with blazer >> so the fun stuff. >> That's cool. Um, but yeah, that's a it's an interesting point, right? So, with with that kind of software, you have um like you can't just I shouldn't say can't, but like it seems like it would be very unlikely that you uh to have like an we're going to whip up an MVP and pitch it to a hospital. It's like the MVP would have to have so many things in it that like it can't just be service level. You're talking about all these different integrations. So, you'd have to find something very specialized. >> Yeah. um you layer on all sorts of different uh like like data privacy things like so I'm imagining like if you wanted to be able to support patients and you have a hospital like depending what country you're operating in uh I don't I have no idea but across Europe I'm sure there's a lot of different sorts of challenges across the countries and stuff but >> absolutely and it's also uh not just like regulations and privacy and such. It's also uh healthcare is very complex and you don't want to be like the source of uh like someone dying basically. >> Yeah. >> Because uh well you need to not to register a lot. You need to sometimes have like processes in an application and there has been cases uh of an application that's used across hospitals here uh where some important data was not visible on a screen. I see. >> But like like on the subcreen and that's basically meant that sometimes data got missed and that has resulted to like people dying unfortunately which really sucks and that's horrible but that's like one of the dangers of such an application because you have such high responsibility and you don't want to be the cause of uh such a result. Yeah, it's uh it's uh pretty incredible, right? That like with software, there's so many different domains that we could be working in, right? The one of the last people I was talking to on this podcast was >> uh describing like, you know, working in agriculture, right? So he was saying that, you know, we're sending up all this data from tractors and stuff like that and like that's fascinating, but um not not to minimize that, but if there was a a blip in the error like for the reporting of all those sensors, that would be a blip and probably not result in death or injury or illness. But in something like a hospital environment, if you had a a blip in some execution flow and that's going to cause a screen to not show at a particular time or or to show but be missing data or wrong data, like the blip could be catastrophic for someone. Um >> yeah, >> it's interesting uh not just how many domains we can be in but also how critical our applications can be and of course how important testing is and making sure everything works and everything remains working uh in the future when you create something new or like a bug fix. Uh we have so much responsibility as a software engineer which uh can be very fun. uh especially if you like enjoy solving puzzles and uh making things and making people's lives better and such. But it's a lot of responsibility and some people can very can feel like very daunting by it. >> Yeah, that's that's totally true. And I think a lot of the time we like it's very easy to forget that like when we're into the code, we're thinking about like the systems we're building. Like it's not just code. It's not just how things are structured. It's not just your favorite language. There's a lot of these pieces that when they come together, like ultimately we're building stuff uh usually to, you know, help other people's lives and like we do have a responsibility there. So, um yeah, it's a it's a big weight to carry and maybe a good segue into for people that want to get into the industry. Um, >> I know that this is something that you're passionate about talking about and um I I guess I'm curious like for for your sort of interactions with individuals like is there especially now with AI and like the the current job market and all of these things going on like >> are there are there themes from people that you're that you're talking to or seeing and like kind of what does that look like for you to navigate that? Well, I think the hardest part is to get into the industry because if you're into it and you get the experience that's very helpful and it's easier to stay in inside of the industry. Uh one thing that I can really advise especially if you do like a uh computer science degree or something in programming, I heard that uh especially like on the American side uh internships are sometimes optional. Uh which for me is really strange because like we have two mandatory six month internships. I feel like internships are rare over here which uh is like that makes me uncomfortable. When I went to school in so I'm from Canada I went to school at the University of Wateroo. was a what's called like a co-op program and you are forced I had six internships >> that you're forced and >> yeah and like I when I reflect on that I think at the time like picking it I was like hey this is like this is cool but when I reflect on it now I'm like if I didn't have that I have no idea where I would be. I think they're critical. That's exactly what I was like going to point out because if internships are optional, I would highly suggest to do them like get the experience because I did two internships like I said and in those two six months internship. So in that one year I learned so much more especially like practical knowledge and skills than in the other three years of my degree. Like you learn real code and real projects instead of really fabricated ones. Like I remember one project we had to work on a team uh for like one of the courses and we had to work on a mobile app for like a cinema but it's a fake cinema with like fake data and it was a fun project but nothing really beats a real uh project like people will use with stakeholders with a team and it's so valuable to get that experience and you also learn team dynamics because everyone is different and some people like very introverted, some are extroverted, some can communicate very well, some are poor communicators and there's a lot to learn with uh a team dynamic. But one thing that's important is it's a team. You work together. You have to deliver a product, a project together. It's not solo work. And of course, you learn practical communication, prioritization. You really learn the skills that are needed to survive in the industry that you don't learn or at least not to its full extent uh during your uh uni course. >> Right. That's I was even amazed when you were and I shouldn't be amazed but when you were saying yeah we got to talk about like the software development life cycle we got to talk about testing in school I was like we like I I don't know why they didn't do that for us that doesn't make sense but um but to your point at least for me when I was going through internships it was like oh this is what you know this is what real life is like um but yeah like you I I just find that relying I I hate to say this but like relying on only what's in school feels like that's um a big miss and I don't know like it's it's been quite a while for me since I've been in school. I really hope that things are more and more modern but >> like when I think back to when I was in school, this would have been over 10 years ago. It's not like we were still talking about stuff that was so far behind that um I'm sure that even fast forwarding 10 years I'm sure it's more modern than when I was there but I am still betting it's behind like what's actually happening in the workplace. Yeah, of course. I like uh when you have assignments at school, you will get like those perfect clear requirements, >> which rarely is the case in real life when you work in a team. You always have to like find out the why >> behi behind the requirements. And I think that's like a good one as well because if you ask why instead of just how you start to understand the business and well this is more geared towards junior standards like entering the entering the industry >> but if you uh really want to like level up so to say it's good to uh understand the business understand the why behind the require ments understand why it's a problem and like what a good solution will be because coding is fun but code is also a liability because it can break uh things change it's work it takes time and if you really understand the why behind an issue then you can work together with the team uh the product manager and whatever roles you have because also That's different per company and per team >> but you and you can work together on like getting a proper solution for the end user for the stakeholders whoever is using the product and that's what really makes you stand out if you can understand how to deliver the value behind beyond just >> right and I find like I I really appreciate the the why part because I I think that Even, you know, for for more junior developers, if you're like, at least in my experience, we're bringing someone on to a team. This happens, by the way, even for more senior developers, just introducing people to a team. But it's like, hey, we're going to give you some stuff that's a little bit more like we understand the scope of it. Like, it's not ambiguous. It's not that complex, but like here you go. Like, this will help you explore the code base. With more junior individuals though, we generally spend a little bit longer on that. And that's not because we think a junior is stupid or they're not capable, but it's to build momentum, right? Here's some bite-sized things. We understand them relatively well. At least other people on the team might be able to kind of dive into that and help. And you build this momentum up so that you you get in the habit of like this is what the software development life cycle is. This is our domain. This is our tooling. And then you introduce more complexity and ambiguity over time. But >> it's it's interesting because now you're like touching on to the on boarding process >> uh when someone starts the company and like things I heard and things I read is that on boarding processes are still like a good onboarding process is still rare like a lot of times you join a company if you're lucky your laptop is ready >> and if you're even more lucky then your account is ready as well and you have all the like the permissions you need to get set up and running. You have all the licenses. It's so rare that that process worked well on like your first day and then like you need to get set up, you need to get your environment set up uh all the login uh all the systems. Uh that's a lot of work. Uh if a company invest in good on boarding process that can really help uh new people get started but especially juniors because well for most of them it will be the first maybe the second uh on boarding process and if the process is good that really helps them like uh get started fast to get learning and to delivering value and it's not just the login and the devices and like the development environment. It's also okay learning the application, learning the team, learn and getting those stakeholders and who's important processes. There's a lot of information and either you're not doing it well and it takes a few weeks to get set up or it works very well and it's like an information overload because that that can definitely happen. Uh it's it's a good it's it's a good balance. Um I think a lot of companies can really uh have a better on boarding experience and they can really benefit from that. >> Yeah, it's I I definitely agree that like that uh the onboarding part is almost feels like it's it's like never never good. And uh I'm sure there are places out there that that do have it nailed. I feel like it's probably pretty rare, but it's a good reminder for for people that are, you know, are junior, they're kind of landing their first job, they're excited to start, and then they start and they're like, "Holy crap, what did I get myself into?" Um, like, you know, hang in there. Um, you will get through it. Um, it's a pretty common thing, unfortunately, that onboarding is rough. Um, you'll learn this, but documentation is important, but documentation is also a tax, right? documentation is like it's obsolete the minute it's written like things move very fast and really like we like many of us will say like oh we need good documentation we value good documentation and then you say great well go update the documentation and it's like h no I got I got better things to do so you have to you have to sort of create this culture where keeping documentation up to date's helpful or sorry that it's uh that people are doing it so that it is helpful yeah you know when they're on boarding. The onboarding documentation is probably out of date, but there's probably some valuable things in there. So, update it as you're going. You'll help the next person. We kind of have to get in this this habit. >> Yeah, I think that's actually a good idea to uh have the documentation and update it uh as you learn the application. But one thing to also like get to know mostly the technical structure of the application is just start the application in debug mode and just go through it with debugger. Step through it, step into it and just learn the flow uh the architecture like clean architecture, vertical slice, whatever it is. uh or most likely a mix of both because architecture is rarely perfect. >> Yeah, but they followed the tutorial, right? So, it's got to be exactly as the the YouTube video said. >> Oh, of course. Yeah, the tutorials and they got stuck into it and we all know tutorial. It's >> That's a nice bridge, by the way. >> Yes. But tutorial is so easy to get sucked into and to stay in there and well most people don't even know about the tutorial. Like they are stuck in something and they don't know what it is. They don't realize they're into it. And that's why I try to uh like in one of my posts I really uh well what do you say I like try to draw attention to uh this is not going well >> like draw attention to tutorial hell and like this realization that like what that even means because like I think you like you said it already though like people get into it and they don't realize it's happening. Yeah. And then then it's hard to get out of it because you're like, "Oh, this tutorial is interesting." And oh, there's another one that follows up to this. And I think this ties nicely into just building, just doing just get your feet wet, try it out. Uh do that one or two tutorials to like understand the basics and then get started. just try something, build something, build something that might be useful for yourself or like a family or friend. Uh, learn something practical and then get stuck and then look up why you're stuck and solve it and then repeat the cycle. >> That's that's process. >> People avoid getting stuck because like I think it's a human nature thing to be like it's friction, it's uncomfortable, like I don't want that. So, let me like we have all of these tools, all of this information. Like, you can like it's it's funny now because it used to be go to Google or Bing, like wherever. Um, you go search the thing, you go look it up on Stack Overflow. Um, you have to go dig up the information to solve your problem. Now, you can you if you type something into YouTube, there is guaranteed to be a list of tutorials. you type it into chat GPT or whatever your favorite LLM is, >> it will answer it all for you. Regardless of how accurate it is, it's giving you an answer. Um it's we've never had information and answers to things so readily available and that the the reality is that this idea around getting stuck is so important for learning that we like we we're almost like sabotaging ourselves because it's like we have all of these things that can avoid the friction, avoid the getting stuck part that we don't get stuck enough. >> Yeah. And and that that's when you almost get in an information overload because you keep learning and learning and learning and then you just start forgetting things. You if you're not if you're not applying your new knowledge then you will forget it. If it's in five minutes, in an hour, a day, a week, whatever, you will forget it if you don't apply it. And that's one of the key learnings I think I figured out over the years. Don't get stuck learning things uh one after the other. Just apply it. Make something because well honestly making something is fun. I enjoy it. Um, so just just get your feet wet and start programming. >> Yeah. You will thank yourself for it. >> Absolutely. Yeah. This this idea of getting stuck and applying things is it's not like unique to programming, right? It's >> this is what we do when we're learning things. I I go back to this example. So I'm from Canada. Uh Canada is bilingual. So most of Canada will speak English. And yes, there are parts that speak French uh significantly more. But um as you know, a kid growing up in Ontario, we had I can't remember what age we started or I think grade three or grade four we start French. I think grade four. So we learned French from grade four, five, six, seven, eight, nine. So I don't know how many years that is. It's enough years that I should know some French. >> I know so little French. Like I can say bonjour or like jamael Nick like my name is Nick. I had very little French, only the things that were said so frequently that they're burned into my brain. But I could not have a conversation in French. I can't read French. Like I to say that I know French would be like a very silly statement. But why is that the case? Despite many years of doing it, it's because it was never applied regularly and it has not been applied regularly since. So it doesn't matter how many years. It was very much just like to me that education process was kind of like tutorial hell. It's like here's the things just repeat them over and over and some of them stick right but like the vast majority of it are like the concepts the concepts do not stick for me for French. I can't conjugate my verbs. I can't I don't know the uh you know masculine and feminine version of words. It's like I have no idea. There's just a couple of phrases that are burned into my brain because it was not applied. >> And that's also like one of the things that I suggest if you are learning something new for programming, don't learn languages, but learn the concepts like object-oriented, it shouldn't matter if you are learning Java or C. Well, just stay away from Java. But >> that's right. >> Curly braces on on the wrong lines. It's not okay. >> Yeah. And the map then the methods uh start with a lower case. >> No, that's not okay. >> And they don't have link. >> Yeah. What's with that? They should. >> Yeah. >> Link link is amazing. But uh just just learn concepts. Just learn object oriented programming and then you can basically with like little extra training uh program in multiple languages. Learn structures, learn if else, learn uh inheritance, learn composition, solid principles, learn those concepts that are important. Learn databases. Learn a database before uh like working with an OM because it's a fundamental and if you understand how it works, then it's easier to remember it and to like debug when you run into issues. >> Yeah. And like the the reality is that going back to like this tutorial hell concept is that all those things that you were talking about learning like yes you could go find a tutorial on like what is composition, what is inheritance and like yes you could go watch a handful of them and kind of walk away from that feeling like I get it. I get it. And you you might but like the reality is start applying it. Start reading through code that's using it. start like you have to kind of be around it more >> like it really starts to click like if you don't what happens is you go oh I remember I remember composition I remember inheritance but >> I got to go look it up and there's going to always be things like that in software development where you have to go look it up that's totally fine but >> you never know >> exactly but some of these fundamental things that you were around like like to give you an example I for I use a lot of SQL and I still have to go look up certain things in SQL but like I understand the general structure of the query like I understand that I can you know I can specify the columns I want to pull or I have a wear clause like the the general structure I got but there's certain operators and things like that I don't remember but >> general yes um and then you you have the same type of thing with like everything in programming where there's the concepts the general you know aspect effects to programming that you you will understand because you apply them so regularly and then all these nuance things where you're like I remember something about this but like I got to go ask chat GPT now. >> Yeah. And just like we said just apply it. Uh create side projects. Uh create something that's helpful for yourself, a friend, a family member, whatever it is. Um, follow creators like people with a YouTube channel, BLS. Um, I heard Nick is a great creator. That's all of >> but that like that's also why I started writing because I like sharing knowledge and writing is such an undervalued skill in tech and it's something you can really learn and I've seen that over the past sevenish months that I've been posting daily on LinkedIn >> is that writing writing gets easier It gets easier to write a post to think about what to write and like just the text that you write it's easier to read your code gets easier to read as well and it's really helpful and >> it's a skill right like you have to practice it and you will get better at it and like like we were just talking about programming right and you have to practice programming to learn the concepts like yes writing is going to be a very similar thing um it's you the I'm sure if you went back to look at your first post on LinkedIn where you were thinking like this is this is going to be like a I I'm I'm trying to help people like this is going to be a good message to deliver if you were to go read it you might be like h probably wouldn't do it that way now >> and that's growth and that's also like one of the things I suggest with programmers is okay you've been in industry for six months now just go look back at your first code look back at those old commits see how you did it back then and compare it to how you're doing now. Feel the cringe because that's what you're going to do, especially in the first few months. But even now if I look back six months ago at a lot of code I've written and so much learning opportunities and so much feedback I've gotten on PRs and so much feedback I've given on PRs and you learn so much and you apply those skills and those that new knowledge and even now after like being in industry for over five years it's you learn so starts new things and well things change anyways. So tech moves ahead and if you look back six months it's a whole different person and you should be proud of learning and growing and getting those new skills. >> Yeah, that shouldn't ever feel like embarrassing, right? Like I I'll give you a great example. I was now that we have all of these AI tools, like I can run an agent or a group of agents on my machine and go build stuff. By the way, for new developers, it might feel like that's a cheat code, but you're probably cheating yourself if you're not asking the LLM like to explain things and you're diving into it. Just getting code produced is not learning. So, be careful with that. But >> for myself, I've been programming for over 20 years. There's some things where I'm like, "Hey, like now that I have I have some projects that I haven't touched in years and years and years and I don't have time for them." But I was thinking if I clone the repo down and I can go set clawed off and go run like some agents and stuff. I'm like that would be really cool that I could go have this thing chip away at this project that like I don't really have time for anymore and I can kind of check in with it and give it some tasks. And I was like that that would be cool. And I went to go look at the the repository and I was like I I never thought when I was working on this that I would say in the future I got to scrap the whole thing and rewrite it from scratch cuz that that last time I was touching it was already like you know the fifth rewrite and I was like this is going to be the final one. And now I'm looking at it and I'm like there's so much here that I don't even want to go ask an LLM to go start restructuring it. I kind of want to be like just do it from scratch so it doesn't suck. And that's only a few years back and that's after at that time like over I don't know like 17 plus years of programming like it's going to keep evolving >> but the reality the reality is AI is here to stay and we don't know where it's going. Uh it's been moving a lot over the past two three four years. >> Yeah. and it's going to move even faster, but it's here to stay and you need to keep up. Especially if you want to join the industry, it's very hard to keep up. But you have to try and at least like understand the basics, understand how it helps you as a software engineer, do your work, do your work better, and learn faster because everything is just moving so much faster right now. and just know okay how to ask questions to an LLM to understand concepts how to use GitHub copilot or any other copilot to help in your code uh how can it like write your tests there's so much to it or maybe update documentation like we mentioned before it can be really helpful >> testament documenting things >> yeah absolutely And uh I think it's such a vital concept uh and a skill that you need and if you don't learn it especially now as a junior or someone wanting to join the industry you're already falling behind and you don't want that. Yeah, I'm uh I've personally been challenging myself more and more because you're right, even I would say even over just the past 12 months alone, how I'm trying to use AI has like dramatically changed. It was it started off like you know I'm asking chat GBT for not like I don't even know probably not even programming related things just information in general. Cool. It's convenient. Then it started to be and this is for my personal projects by the way, not for things at work. I don't actually write code at work. So when I talk about this stuff, it's almost exclusively just my my side projects. But then it started to be let me use chat GBT, let me copy and paste like a method in like hey go do something with this method. >> Yeah, cool. Okay, stepping stone kind of neat. Then it was okay chat GBT like I want you to go write this class like this is what this thing needs to do. And then it's sure it's whipping it up and I'm going this is pretty sweet. And then I see the co-pilot changes cursor and I'm like okay now I can have that in my IDE cuz I mean I was using the autocomplete like with co-pilot stuff for for as long as it was out and I'm like this is pretty fancy. This is helpful but >> it's not to me it wasn't quite doing like this next level like the productivity boost that everyone's talking about. But then agents come around and I'm trying the agents in VS Code, in Visual Studio and Cursor and I'm going, man, like this is not it. Like I have to hold this thing's hand so much that by the time I prompt it perfectly, I might as well have just coded what I need to code. Mhm. >> But this stuff is already evolving so fast over the past few months that if I use GitHub copilot with poll requests, I can write the most simple like ticket and it does a really good job to like go do something pretty good. Is it perfect? No. >> Is it pretty darn good at getting it mostly right despite me giving it barely any information? Yeah. Um, I was coding before we got on this call and I was using Claude locally and I told it to go write some tests. We were just talking about writing tests and um, it wrote some tests and it introduced a whole new mocking package that I don't use. Uh, it like invented totally new testing patterns that I don't use in my codebase. So, I'm sitting here going, "This thing is so dumb. This is so frustrating." And then I'm like kind of stopping and going, "Wait a second." Like if I think back less than 12 months ago, I was only getting chat GPT to try and write a method body. This thing just wrote like, >> you know, like a hundred tests and yeah, it picked the wrong package and yeah, it did some different, you know, testing structure. >> And in one more prompt, I said, "Don't do these things. Go look at these examples." And it rewrote all of it. And it's the right patterns, the right framework. Like it's pretty it's pretty impressive. >> Yeah. With the current speed in like a few months, it's going to be even better. >> So, but this also like shows how it's still important to learn the fundamentals of software engineering, learn how things work because right now AI is a co-pilot. You are still the pilot. You are still in control. uh AI creates a nice draft with like 90% done and like the last 10% you need to polish. That's the state right now. And that requires you to understand at least the basics. Understand what works and what doesn't work. Understand the structure of your application because AI gets better but you still need to work within the same structure of stress test application. Otherwise, you can just throw away the architecture and go free for all and that doesn't that's that just creates like a beautiful legacy application instantly though, right? So, I think that's a really good reminder for folks. I mean, a couple things. One is this reminder that like please the there's a difference between learning things because you're getting stuck versus just generating code. I cannot stress this enough because I I know the temptation is there. I was just describing, you know, being able to blast out tons of tests and stuff, but the only reason that I like know when I'm looking at these tests that like maybe a lot of them are garbage. Um, I know that because I've written thousands and thousands and thousands of tests. >> Like I had to go practice that. Um, so there is a difference between generating code and uh and actually, you know, building up those skills. I can't remember the other thing I wanted to say. um that will come back someday. But um yeah there yeah hopefully but uh the the reality is like the tools are evolving, right? Um it's we cannot just jump to especially for for junior folks, right? We cannot just jump to get it to output code and oh that was a legacy codebased thing that I knew it was going to come back. Um, so if you're if you're just outputting code and you're not having this opportunity to like learn these these concepts and these fundamentals, which take time, by the way, they take time and practice. You will get code that gets output. Great. Most, let's say it mostly works. Let's say it works 75% of the way. You kind of vibe code the rest of it to get it mostly working. The reality is code is never perfect. There's no such thing. So now you go to build the next set of things and instead of it being like something that you have like an architectural path forward or like some some common you know uh frameworks and systems that you're using. What happens is the next iteration of this lowers the bar even more. You have you know all these diverging patterns. You do it again. It diverges even more. And you're basically all of us have or not all of us but many of us who have been in the industry for a while have worked in these legacy code bases where we're like what the heck is this? You're basically doing that within like one working day of just blasting out code and creating the most legacy looking ball of spaghetti anyone's ever seen. avoid. >> And one thing I also hear with the rise of AI is people of course getting scared of the industry especially juniors or those currently chasing a computer science degree or coding boot camp or just selftaught >> wanting to get into the industry. AI is making it harder and yeah we've seen it over the past few years and there was the rise with co with tech hires and now there's like a lot of layoffs uh which is unfortunate but I think it will turn around because we know tech is needed uh and I think our jobs are safe for the next uh few years at least >> there's more people coming like more tech leaders coming out and saying this right like Yeah. >> Unfortunately, in the news, in the media, uh I keep repeating this to people, but like headlines on any news outlet or any social media, anything, headlines are designed to invoke or evoke emotion. They're designed like people click things when they're afraid. It's turn on the news. Any channel, any channel, it's going to be things that are scary. >> Absolutely. It's not like you don't watch news and it's just happy things like that's unfortunately they're tapping into our psychology. This is the same thing with headlines. Um it's designed to get you to click and to watch. So you'll you'll see this overwhelming majority of things that are scary especially with AI. And I'm very glad that there's at least a couple more like tech leaders coming out and saying like no like I think uh uh Sundar Pachai from Google was one of the most recent that I I'm aware of that was like we're still hiring engineers like we absolutely need engineers because it's not AI replacing them. It's like this is AI augmenting them and it's going to enable us to do more things. We need more engineers to go do those more things. It's it's always been a capacity thing like uh companies wanting to deliver more than engineers have capacity and now engineers can be more productive so that means they can finally deliver more. >> Yeah. It's I don't I know this is like unfortunate because when people see what's happening with jobs with layoffs it's very easy to go draw the conclusion especially when there are some companies that actually we're laying people off because they're like oh we'll just use AI >> it don't think I've seen one be successful yet by the way I haven't it's either they go under or they rehire the engineers back but um so I realize that it's easy to jump to that conclusion um you know with the general um you know outlook on this stuff. But the the reality is there is no like it's not a fixed amount of work. It's not like you know there's a hundred features and 100 bugs that need to be done. So if we just introduce AI, we don't need the engineers. It's like there is there is always far too much work to do. >> Absolutely. And what I've just heard like people do get nervous about AI uh especially those wanting to join the industry and that makes sense. Uh it makes sense to get uncomfortable. >> Yeah. >> But being uncomfortable is important in this industry. If you're not if you're not uncomfortable, then that means you get complacent and tech changes fast and that means you get falling behind. I've seen it happen with people that are at a company for five, six, seven, 10 plus years. uh work with the same technology over and over again and don't new don't learn new things and they get comfortable, they enjoy it, they get a nice pay and then well the company changes. They are working on a product with new technology and they are behind because they haven't been learning for at least 5 years and especially now the tech industry changes so quickly that if you don't learn you're falling behind. And that's one thing uncomfortable is good. That that's the imposter syndrome talking and most people say it's a genial thing. At least that's what people think. But I think we can both say it's something all levels of of experience have. I have it myself. Um some days more than others. Um, I had it when I started writing on LinkedIn. Uh, like is my experience good enough? Uh, am I experienced enough to tell those things to people? >> Right. >> Well, I'll let you know on a secret. I might have felt a little imposter syndrome before this interview because it's something new. It's it's uncomfortable. >> But well, so far it's very enjoyable. So, >> not so bad, right? >> No, it's not. Uh being uncomfortable is good. It's not fun, but it's worse when you are feeling uncomfortable, especially for like a longer period of time. You need to keep learning. You need to keep challenging yourself and you need to keep asking questions. And right now, of course, we ask those questions more to AI and LLMs like chat, but uh just ask questions. Ask your team, ask that senior person on your team uh that has been there for 10 years, whatever. Uh ask your question because well, you don't want to get stuck like we mentioned before. Uh and you want to keep learning and that's one of the ways to keep learning. Yeah, it's uh I think that advice is applicable, you could argue applicable for any industry, but I think given the pace that we move at in in software development, um it's I I feel like if you're the kind of person who's like, I just I just want to sit back and relax and kind of coast through, you'll probably find that it's not it's just not going to work very well. It might work for a little bit, but like you know it it's it changes too fast for it to be um a realistic approach. So, uh but I I agree with everything you said. I I do think that that often leads to >> what what is imposter syndrome, right? Like things move very fast. We do have to put ourselves into situations where we're learning new things. This doesn't just have Thank you for sharing those examples too because it doesn't just have to be oh well I'm going to go learn like I know C but now I have to go learn Python and like now I have imposters like it. No, it could be this is the first this is the first project I have to lead at work. Um you know this is I I joined a new team and I'm a manager and now am I actually good enough to be a manager? Like was it just a coincidence that I was able to do it before? you're applying to a new job and you're like, I know I've been a developer for 15 years, but like am I actually good enough to for this role? Like it comes up all of the time. It will keep coming up in our careers. The more people that I talk to about it, the more that I realize like and I hear this advice from others as well. It's like try not to look at imposttor syndrome as something where you want to um avoid it where you're like this is terrible. Like how do I cure the imposttor syndrome? It's more like acknowledge it's there. >> When you feel it, when it's around you, it means you're uncomfortable. It means that you're learning. It means that you're going to grow. >> You will get through it. And then you will get on to the next round of imposter syndrome for the next thing that's helping you grow as an individual. >> You will never cure it. Even if it's temporary, it will come back. It will come back harder likely. Uh and you have to learn to live with it. And that's not easy. It's not a comfortable truth. But like I said, software engineering is uncomfortable and you need to be okay with that and you need to know that it's going to be uncomfortable. >> It's one of the good signs that you are growing and getting better, right? So I think it's a good reminder for everyone and especially if you are a junior when you start experiencing that. Maybe you have already, maybe you haven't yet, but when you start to it's like just a reminder, it's okay. It's good. We all go through it. >> Yeah. When I started my computer science course in uni, one of the things the teacher said at the beginning was when you join tech, you will always have to keep learning. And that's very true. If you don't, you're falling behind and you just need to want to. I mean, if you don't like learning, don't go into tech. You need to enjoy it. You need to enjoy learning and being curious. And like I always say, curiosity is king. If you're not curious and you don't want to learn, just don't go into tech. It's only going to like work move you towards a burnout and that's only going to put you back further. >> Yeah. It's just going to be friction and you're going to feel like you're fighting it the whole time, right? So, I think that's I think that's really great advice and and Teemo, I wanted to say thank you so much for this conversation. Um, for I know that you're very active online. If folks want to find you, where do they find you? Where can they read what you're posting? Where can they reach out to you? What's that look like? >> Well, I I'm active on LinkedIn mostly, but also on X or Twitter, however you want to call it, and Blue Sky. Um I think link's going to be uh in the description maybe on screen as well. If it's on screen it's either here here I don't know >> it's somewhere >> somewhere uh it's also in the description you can find me I can no with me if you want to um I'm active on those platforms but I'm also working on like starting something new. Uh that's that's a surprise for now. >> Okay. Okay. I'll I'll have to find out more about this. And you have a you have a newsletter, right? >> I don't have yet, but that's like one of the things that I want to start. >> Okay. >> Okay. Interesting. Okay. So, yeah, that means for folks that are listening and watching that if uh if you want to to see more from Teemo, then social media. Yes. And then stay tuned on his socials because you'll see what else he's cooking up. So, that's awesome. Um Teemo, thank you so much for making the time to chat with me. I think that um I think there's a lot of helpful words of wisdom. I am glad we got to talk on AI, how that's uh, you know, shaping how people are are, you know, getting into that that learning phase. Uh, you know, I think that's really important. I think that it's it's like you said earlier, it's not going away. There's only going to be more of it. And that good reminder that, you know, if you're getting into this space, then you need to be comfortable like always trying to learn because you're going to have to keep doing it. >> Yeah. of course and like once again thank you for inviting me over here. It's been a lot of fun to talk about my experience and of course my vision as well and I just see that we've been talking for like an hour now which is a long time and it's flown by very quickly. So like I said it's very com it's very comfortable to be here and talking with you. So thank you again. >> Of course. And there we go on the imposttor syndrome part, right? If you had a little bit of imposter syndrome before. >> Yeah. totally got through this and survived, right? >> Absolutely. Now up to the next level of imposter syndrome. [Laughter] >> Awesome. Thanks again. I appreciate it. >> Thank you very much.

Frequently Asked Questions

What advice do you have for new software engineers just starting out?

I recommend that new software engineers focus on getting hands-on experience as soon as possible. Don't just stick to learning from tutorials; instead, start building projects, even if they are small. This practical application of knowledge is crucial for retention and understanding. Get your feet wet, experiment, and learn by doing.

How important is understanding the fundamentals of programming in the age of AI?

Understanding the fundamentals of programming is more important than ever, especially with the rise of AI tools. While AI can assist in generating code, you still need to be the pilot and understand the basics to ensure that the code is structured correctly and meets the project's requirements. This foundational knowledge allows you to effectively leverage AI tools without losing control over your code.

What should I do if I feel overwhelmed by the fast pace of technology and AI in the software industry?

Feeling overwhelmed is a common experience in tech, especially with the rapid advancements in AI. It's important to embrace discomfort as part of the learning process. Stay curious, keep asking questions, and focus on continuous learning. Remember that it's okay to feel out of your depth sometimes; it often means you're growing. Just take it one step at a time and seek support from your peers.

These FAQs were generated by AI from the video transcript.
An error has occurred. This application may no longer respond until reloaded. Reload