AI Is Changing Software Engineering Forever | Gregor Ojstersek

0:00You need to have a multiplier mindset. That is the mindset where you're not just focusing on your own individual contribution, being the smartest person in the room, but you're actually helping everyone to be better.

0:16Do you just want to give everybody like a quick, high-level, 10 ,000-foot view of who you are and what you've been up to? Yeah, definitely. Thanks a lot for having me, Daniel. Yeah, so my name is Gregor Ojstersek. I come from Slovenia. I have over 13 years of experience both as engineer and also engineering leader. I grew from engineer to senior software engineer, team lead, engineering manager, head of engineering, VP of engineering, and then CTO. But yeah, these days most people know me from writing the engineering leadership newsletter where I try to help as many people as possible to become great engineering leaders.

0:54and also recently as we talked briefly before i published a book called the multiplier mindset uh and uh yeah some people may may know me from from from from the book as well that's awesome yeah it's uh crazy to i saw your post about 200 000 subscribers on sub stack and that is that's crazy it's uh pretty awesome i think it's probably a lesson in like consistency because you're pretty consistent i watch your content and i can't imagine how you did that and the book and everything um can i ask about like rewind a little you like how did you get into tech in the first place did you like be super like into computers when you were young like how did that how did you actually get into tech in the first place yeah definitely it's it's a funny story because uh i mean i was i was always a lot into not not like how do i say not not not like purely computers like trying to build and trying to dabble with different tech all the time.

1:52But I was kind of into it, but not like really, really that I would be thinking about it all the time. I was more into games. I was more kind of like even played like as growing as a teenager. I played a lot of games. And yeah, it's been really fun times. What was your favorite game? Yeah, I played a lot of Call of Duty. That's Call of Duty 1. one and two oh yeah and uh yeah that that's kind of like uh you know what also what also helped me a lot with with writing the newsletter it's interesting kind of like connection because like i i i kind of like i make a connection with trying to get better at a certain game than trying to also get better a certain other skill like writing a newsletter or trying to trying to get better maybe like you know with chess maybe a certain sport as well it's kind of like similar you you need to find out like what is the what is the best way to do things and then just consistently practice and so on so um but yeah just a really uh really sideways with this one uh funny story about me coming coming into becoming an engineer is that if you if you'd probably if you'd ask my my colleagues from high school and elementary school they i mean i don't speak with a lot of them at this time i speak maybe with some of them but um yeah they are surprised that i i became an engineer right but uh you know me becoming an engineer wasn't i don't have a cs degree as well i don't i didn't go to i didn't go to university for for becoming an engineer i i learned uh engineering on my own um and finally in in elementary school and then in high school we were learning programming especially building things with java but i didn't like it i didn't like it back then and the reason was like java anyway yeah exactly exactly and the reason why i didn't really like it was because we were traversing characters so we were we were doing stuff with writing boilerplate and trying to memorize functions on our own and trying to code on paper i didn't find joy joy into that right but what really kind of like inspired me to learn more and more was building things on the screen like html css javascript and doing something and changing something in code and then seeing visually how how things change especially like building animations building building uh visual stuff like showing stuff on the screen building websites and stuff like that that kind of like inspired me to to do more and more it was like hey this is this is really cool cool thing what we can do here so after that i got hooked and i was just learning days and nights and um i never looked back back since uh yeah so yeah that that would be kind of like my uh my entry to engineering yeah i didn't i didn't have a cs degree either i went to school but i didn't get my degree in computer science or anything either and i feel like the same as you i was into games computer games you know warcraft missed and then obviously when the gaming councils got big all that kind of stuff and yeah i never i the same way i just fell in love with it because i knew people like around me that had programmed i love computers and then i think pearl was one of like the first languages that i started messing around with and similar to you i kind of enjoyed the web for a while like the lamp that classic lamp stack that's at least like the time frame i was doing stuff and yeah i just enjoyed that too so were you what circa when did you first start working on websites like what year ish or did you start building just to like put it in perspective for people yeah 13 years ago i started kind of like with my first um first kind of like a role as a software engineer um i started even before before before then i started learning myself so about about a year uh before then uh and yeah um that would be what was the main tech stack what was like the first yeah it was php php javascript uh and sql sql that was that was kind of like the first uh first job but then uh i started with uh with a service-based company that was kind of like sorry the first one was kind of like more student student job related and so on then the first full-time was with the actual uh kind of like a service-based company where we did a lot of different stacks for a lot of different companies for a lot of different projects.

6:23PHP was one of them. Then C Sharp was a big.NET. We used a lot of.NET. That's how I spread all over the place in so many different things. Obviously, we used Knockout.js for building via applications. We then moved from Knockout then to Angular. Then once we did that, I learned Angular and I became kind of like a good at Angular as well. There was, I mentioned, like we used Twig for PHP. I can't remember really what was the framework behind it. We used Laravel, a little bit Laravel, but there was, it wasn't Symfony, but kind of like the additional, that is a little bit more lightweight framework, but similar to Symfony, I can't remember at this time.

7:13Then obviously a lot of WordPress. I did a lot of custom teams with WordPress for many different clients. So, yeah, I was used for a bunch of different stuff, being like a project manager, talking with clients, being a customer success person, being a full stack developer, building WordPress sites, building PHP applications, C Sharp,.NET applications. So that's kind of, yeah, yeah. It was an interesting time, Mike, because I learned, I worked through college doing PHP and stuff, and it wasn't like an interesting time when I look back, especially if I look at what's happening today and just what people have to do today.

7:51Just the different roles, cloud engineers, backend engineers, frontend engineers, although it seems to be changing a lot with AI. But I feel like looking back on that time, I'm so glad that I didn't have an LLM at that time. I'm so glad I grew up in that area because I feel like, I don't know if you felt like this, but you had to, you just had to learn stuff that people necessarily don't get the chance to today. Like you have to be really good on the terminal. You learn what a server is. You learn what networking is. You know, you learn all these, you learn what a web server is like very closely.

8:25and I just feel like some of that and maybe this is like the old program in me this like bemoaning what's happening today but it's like you really had to struggle you had to learn a lot of different pieces like you know you're front end if you're yeah I'm sure there's you know you're using my sequel or who knows what you're using on the back end and like you just had to learn a lot of different things I guess I would call it do you kind of feel that way too yeah definitely I mean I remember a lot of days where I was stuck on something and I couldn't move forward. And then I was bashing my head, what was the problem?

8:59And then I went to sleep. I was dreaming about the problem and then wake up the other morning and I had a solution right in front of me. But these days, a lot of times you can just feed the context to an LLM and it will help you get unstuck with whatever you're doing. So there's a lot less of those kind of situations. But the problem is that you learn so much when you get into those kind of situations, especially if you're debugging something and you don't find the issue. And then you dig through this and then you find that thing. Then you learn about that thing. And then you just keep going through down the tree.

9:33And then eventually you find out where the issue is. That's how you learned so much more. And these days, like a lot of times, that's being skipped. And, you know, that's also one of the problems that I see, especially with new people coming in, is that the fundamentals are just not there, right? We had that experience of going through the pain points of trying to debug and trying to bash our heads of going, going, building stuff on the hard mode. But today, like, it's a lot more on the easy mode to build things. So you skip on a lot of that important knowledge that is really, really highly worth it this time.

10:10yeah it's uh i feel like the llm's definitely i mean for someone like us who've been through it it's almost like an unfair disadvantage because it can really when people talk about 10xing an engineer it's like well it depends right if you've been doing it for over a decade then yeah it probably will 10x you um just find that like you said maybe you're a java developer and you're tired of writing all the boilerplate or whatever but definitely for the younger engineers i see it But I feel like it makes people more of who they are. If you liked writing sloppy code and you wanted to put in 1 ,000-line PR for something, it could have been 150 lines.

10:47It's just going to like, hello, I'm definitely going to pat you on the head and be like, yeah, that's fine. Going back to your early career, can you tell us about that transition? Did you enjoy project management? Because obviously your career trajectory kind of went, I guess you could call it up, the stack of engineering um did you kind of go to like senior level and then you're kind of like doing sort of project management and dealing with people and it's kind of like you natch because a lot of engineers i mean classic right people want to be programmed because they don't want to talk to anybody they want to sit in their basement so a lot of that soft skills are difficult for people you found apparently you found that sort of so some of those soft skills came naturally to you may be that kind of legend yeah yeah yeah definitely it's it's a really great great question and yeah you know start starting in my uh and then growing and progressing in my career i had a bit of like a imposter syndrome to especially with engineers who had cs degrees and i was like i i could never be on their level because they went through the cs school but then the the thing was that the more i started to work with with them with other people who have CS degrees, the more I saw that my learning and the way I approach things and the way I take ownership and the way I have like my motivation and drive for learning, the way I'm driven to make things better, to deliver projects successfully.

12:13And to also, I've always been decent in communication, talking with business people, talking with stakeholders, talking with, you know, collaborating with other people because I was playing a lot of basketball growing up. I was naturally more inclined to be a team player as well. So a lot of this soft skills came naturally with me but a lot of my peers especially the ones who went to to cs school they were focusing a lot on technologies technical details trying to learn all the stacks possible trying to be the smartest person in the room trying to just be inside the technical details they never wanted to talk even with stakeholders with customers with users they didn't want to collaborate with project managers managers or even other programmers probably they would just like to be okay this is what i need to do for the day i'm gonna be spending eight hours writing code and that's it i i enjoy it and so on those were a lot of people were like that but with me i was different i was focusing a lot on successful on delivering successfully projects making sure we are building the right things making sure that we are communicating correctly with the stakeholders because i find out really quickly that you can build the best you know the best software in the world that you can you can spend like hours and hours on it but if you don't manage expectations accordingly it's not going to be perceived that way and i learned a lot on that about that by doing freelance projects when i built wrong things for for a client and they were like okay what what did you bring me uh what is this actually how is this going to help my business but then i was like okay maybe we need to first find out actually what what do you need and then i'll start building after we found exactly what what you need right so those kind of skills came a lot more naturally to me than a lot of other people so that's why i was more kind of like prone to always be kind of like that tech lead team lead person obviously when i was a senior software engineer i didn't know exactly where i want to grow either go to become a manager become an architect or grow uh in the in the icy path i was very uh i was very kind of like um undecided about that but then fortunately uh there was a new new teams performing and i was offered the team lead position uh which which i accepted and that has shown to be one of the really hard transitions for me but it was really also great because then like a whole new horizon of things open up for me to learn new things that's like before i was kind of like feeling a bit stuck stagnating because i'm not really learning new things but then becoming a teammate like okay i need to learn all of this other important stuff that will make me successful so um yeah but you know i was um if you ask me like back then it's kind of like a natural position for me to be that kind of a person and um i always i always recommend people to do what gives you energy and what you're good at and focus on that.

15:11Not everyone is like that. I'm also a great generalist. I wouldn't be so great if I would be just specializing in one single thing, but I really thrive in environments where I'm given a certain business problem and I have open hands to dabble on different functions and so on. That's also like what I said in the beginning, doing project management, customer success, being a full-stack engineer, learning different frameworks all the time. That's the environment I always thrived in. Yeah, it's funny. When you had said C-sharp, it just took me back to one of my first jobs. It's so apropos because of what you're talking about.

15:49I worked with some of the smartest engineers. I can see them in my mind, like one of the smartest engineers I've ever met, a C-sharp guy. but yet at the same time i just remember at that time like i was having to like sit at the stakeholder and like how unhelpful he was you know like smart could write anything could write anything that you ever would want great software engineer the best but at the same time it was like super difficult to work with just no one he didn't want to talk to anybody no one wanted to talk to I remember just like sitting in excruciating meetings with like the business stakeholder on like the right side and him on the left and just trying to like, you know, deliver something that you know you need to deliver, but you've got to like pet him on the head and at them on the head.

16:39And it's just so, and I've seen that at like, I've worked at a lot of different startups and I've even seen principal engineers, for example, that are just, again, the smartest engineers. But at the end of the day, they're just, you know, not the best team players like you said they want to be the smartest person in their room which is fine it's great you always need good engineers to solve hard problems but at the end of the day i learned quickly that there is a problem and like it gets recognized eventually in the business that like hey this person's hard to work with or you know they don't want to take critical feedback from the business or like you even said they don't even really care that much what the business thinks you know they're really what they care about is like the framework that they're working on the new technology they want to work on.

17:24Yeah, I think it's probably still a problem today. I don't know how much with AI, but it's such a classic problem, right? Yeah. I think it's exposing these days people that are like that a lot more. And it's a big problem that I see a lot talking with different people, especially that identity shift is you can't just be a Java developer, a Python developer, a C Sharp developer these days because AI can write so much code. these days that you need to find leverage in your work in some other places and then that's automatically why people that are more generalists like for me personally like the transition is quite natural like we we are here to solve problems not to just uh do do some computer science experiments right but a lot of engineers unfortunately it's uh it's it's like you know uh what worked like 15 years ago 10 years ago it doesn't work these days and you need to find leverage in your communication, in your problem-solving abilities, in your human skills, in the way that you're collaborating with, with everyone, you being a team player, focusing on solving business problems, being, you know, there's always a return of investment for the business.

18:35And if the business is not getting the expected return of paying your salary, it's just how it is. It's a business, right? At the end of the day, right? So you need to look at your knowledge and what you bring to the table and what company wants and what they look for. and you need to kind of like match those expectations. So that's a really important thing. And that's also what I talk about in the book, especially what's important these days now that AI can write most of our codes. You know, you need to have a multiplier mindset. That is the mindset where you're not just focusing on your own individual contribution, being the smartest person in the room, but you are actually helping everyone to be better.

19:16You're moving the whole team forward. you're moving the whole organization forward you're making sure that projects are being successfully delivered and you're delivering value to the business so if you make 10 20 people around you 20 better that's that's so much more value than just five percent uh better at a certain framework or certain technology yeah for sure are you generally bullish i mean if you think about someone who is a brand new software engineer like they read the news whether they believe it's because of it or not you know it's like layoffs like you go on linkedin and it's like layoffs every day um what's your kind of take do you have one do you think these layoffs are related to ai do you think it's just like a convenient reason for these companies who may be overhired i'm just curious are you generally bullish and but what i mean by that is like five years from now do you think there'll be like as many software engineers as are today where they might be less the same more do you have a yes at all yeah it's a good question i think especially regarding the big tech what big tech is doing with layout especially with microsoft with 60 000 roles being offered uh a compensation for for uh for um for for for going going going to uh for for their resignation the thing is with big tech they're just going to do what they're going to do you can't control that there's always a money factor there's always investors there's always a lot of other people who are going to to make things happen and that is not a knock on any individual who is a part of Microsoft or Amazon or another even if you do the best work in the world you can't influence that you're going to have a job or not But there's going to be a lot of other places, especially startups.

21:06There's always, startups are always hiring these days, especially like Entropic, OpenAI. They are, you know, hiring like crazy. These days we see so much like forward deployed engineers, roles available. Like there's a bunch of them at this time. So that's my prediction as well. The role and, you know, the separation like front and back end that we were used to, that's probably not what's going to be in the future. The roles are going to change, but the people who can develop the skills that are needed in certain positions, especially like a forward-deployed engineer, that you need a good mix of communication skills, problem-solving abilities, engineering fundamentals, understanding the engineering concepts, and then also having a good touch on the product and the business.

21:55Those people will, in my opinion, always have jobs, and jobs are going to change. we can see like a lot more product engineers a lot more generalist engineers are thriving these days there's also a place for specialists like a certain person that is really good in a certain certain niche type technology and understand it really well maybe goes in really really fine details of react python maybe flask framework really understands the nuances of it and so on that person can also be a multiplier and kind of like help others to ensure that we are building a performative code and kind of like give good examples to the LLMs.

22:34That's automatically how like a lot of other engineers are going to automatically have good practices because, you know, the way LLMs work is they need a good example and someone needs to give them a good example, right? So if you can be that person, that's also very, very highly worth. but a lot of these days, good generalists are going to be more and more important. And, you know, I think with the amount of roles, I can't really say if it's going to be more or less, but the roles are going to change. The roles definitely, we see a lot more forward employees, engineers, product engineers. I think, you know, focusing on business, product is really important.

23:13Communication skills, human-led skills are more important than ever. And pure problem solving. Like you see a problem, you're not just waiting for someone to assign you a ticket or a task. you're actively looking to solve that problem for the business. And if you have that mindset, you're also going to always look for what are the companies looking for and you're going to invest in the skills and knowledge that companies are looking for. So those people always have jobs in my opinion. Yeah, I think you're right. And honestly, even if you rewind pre-LLM, it's like those people were always the more, those were the most valuable engineers already, the ones that were, you know, of course, like you said, you always need somebody who you need that expert and maybe a streaming system or a certain framework or you know these guys that can know how databases are built and like know the nuances but again like there's always going to be room for people like that but yeah i think that the um all those soft skills that have been ignored mostly i think yeah it's going to be difficult in these days those those were always the more valuable engineers who could walk in both worlds and yeah i mean it's clearly now that it's like code is not the you know differentiator anymore um and it's funny because when i go online you still i'm surprised and i'm like am i still crazy because i try not to be it's everything's an echo chamber right you can go online and it's like you're gonna you're not gonna have a job in five years this is just people you know they're trying to get clicks and whatever and say stuff and then but it's also funny to see the people on the other side who were like and i know like i have a i know a rust engineer he's probably gonna listen to this and he lives probably like two miles away from me and he he still hasn't touched an llm you know just because it's funny you still have these people that are i don't know they're kind of the protectors of the old ways i guess i don't know what to call it you got yeah it's kind of funny to see that of like and i think it takes time for the world to change right it's cultural for as many for every company that's like adopting ai and saying you must use these many tokens There's probably 10 other companies that are probably maybe it's size.

25:18Who knows? They're very scared. Maybe they have a huge, maybe it's a very large organization and they want to be very careful how they roll out things in there. I think there's like anything, there's a spectrum of companies, you know, I think it'll take a, maybe take longer than we think for, you know, some of these software organizations that maybe are, you know, maybe they have a thousand software engineers in some building and they're very, you know, just, just like anything that an organization of that size adopts if they're not a startup they probably can like it'll be a while right they're like very slowly rolling magenta coding out and stuff so i think it maybe it'll take a while i don't know yeah i wanted to say that i would just like to say that like a bigger companies they're still evaluating if ai is a security risk yeah right So it's going to take some time, but I think eventually those bigger companies are also going to get to where startups are at this time.

26:15So I think it's a matter of time before your Rast engineer friend is going to also get to that spectrum. Yeah, we just need to be flexible. It's a weird time. Things are changing quickly. I know that change makes most people uncomfortable, change of all types. and we just need to be just need to like you said roles are going to change just get ahead of the curve work hard learn be good at what you're doing work on your soft skills i think people be fine if they just as long as you don't stick your head in the sand like you said pretend to say like oh nothing's ever going to change well like clearly things are changing and no one's going to put the genie back in the bottle it's out so you might as well just you know move forward and learn what the future looks like um i want to talk to you about your new book the multiplier mindset how when was the launch that's pretty recent right yeah so the the kindle version was released i think about october 21st something like that 2021st and then the print version in a lot of different places was released on october 31st but then in internationally so in u.s and then in brazil and i think canada as well it's going to be november 17th that's awesome uh so So it took you like how long to write this book?

27:30Was it kind of painful? Yeah, I started writing in December. So almost a year from starting to actually then seeing the book to come in and be published. I still haven't got my first physical book yet, but hopefully next week I'm going to get my first physical books to be delivered to me. so I'm really excited for that but I also started to think about writing a book quite some time now we started talking with Riley about October last year something like that I was thinking about doing self-publishing but it's been a really great decision for me to go with them I think if I would do self-publishing I'll be first, obviously as we talked before I'll be still writing today and also like the the focus of the book would be much different i'll be more focusing on career development because i also were at the same time i was doing a course called senior engineer to lead like helping senior engineers to become to become leaders managers staff engineers tech leads and so on but um talking with o 'reilly they had a really good uh argument about hey let's let's let's let's not do like another career oriented book but let's focus more about the multiplier mindset, like the mindset that is going to be applicable to many, many engineers, engineering leaders across various of industry and what's going to be more and more important as we go forward.

29:06And yeah, it was really a great decision to go that route. And I also wrote a lot about that as well in my previous articles and me personally being that kind of like a person that has been doing that for his whole career. It was kind of like a natural fit for me to write that kind of book. Yeah, that's awesome. Congratulations. It's a lot of work. And I suppose, I don't know, maybe it's the best time to write a book or the worst time. It feels like you're like, is everything going to change tomorrow? Is what I'm writing even going to matter? I don't know. You know, some people even told me like, hey, why would you write a book?

29:47It doesn't make sense these days, but I don't know, like thinking about like how many people have already pre-ordered and bought the book and it's been a number one bestseller on Amazon now for quite some time. Like right after I released the Kindle version, it seems like people are resonating with it and people seem to like it so far. I think you know the funny thing is that attention span is very problematic these days and I think a lot of people are moving back to instead of like scrolling through YouTube, Instagram, TikTok whatever, go and read a book and that's also my advice as well, it's much more healthy to do that you're training your attention span and you're also learning something new especially like books are very good curated knowledge like all together you know what you're gonna you're gonna get something that is valuable because especially like working with Riley we went through so many different layers in order to get to where we are now with the book you know if I would be just you know doing self-publishing the book would come out like completely a lot less professional a lot less kind of like developed and so on it went through a lot of different people, people's eyes, also a lot of tech reviewers, also case studies from a lot of different individuals.

31:11So it wasn't just me. I was just a person who has a name on the book, but there were so much more people involved in creating this book. Yeah, that's awesome. I do enjoy the – I've read quite a lot. I'm sure you've read some of Will Larson's books. Yeah, exactly. A lot of them. I always enjoy the deep dives as well as like the like the studies tech studies like talking to people and you include that sort of it's kind of nice to have that and how long ago did you I'm just curious about your writing when were you writing before you started Substack or did you like just decide one day I'm going to start writing on Substack how long have you been doing Substack was it this was that easy for you and why did you even start doing it.

32:00Yeah, good question. It was exactly four years, one month, and two days. So October 3rd was the first kind of like blog post that I published. I also created a Substack account, but it wasn't like the newsletter as it is today. I was basically, as a lot of engineers, I built a blog myself with React and Gatsby. Of course. And then I used Substack more as email functionality to deliver to the people. So you have like a subscription and then you would subscribe to the Substack newsletter and then you would also get to your inbox. But I was focusing a lot more on that blog and pushing that blog. All the links were there, were put to people to go there and read the articles there.

32:47but the reason why I started was I was hard on a drink at that time and I also became an interim CTO and I was thinking like okay I'm now an interim CTO I'm eventually going to become a CTO one day so what's what's the actual goal for me like where do I want to grow after I become a CTO in my engineering career right because CTO is the last step in your career and I was thinking okay maybe you know i accumulated a lot of knowledge over the years and i also had a lot of growing pains especially growing to become a team lead engineering manager had made a lot of mistakes and i know i could help uh at least some people to avoid some of these mistakes when they when they uh when they they go through uh those hurdles so i it was kind of like i took it as a challenge for me to kind of like share knowledge i started with two linkedin posts per week and one article article per week which was on posted on blog and then also sent through the sub stack um so i did that for about six months i got space i was basically invisible maybe like a couple of likes here and there a couple of subscribers uh here and there on the on the sub stack newsletter but then about like um six months after that that's when the growth started to become a lot a lot higher and yeah i think it was the first year was about uh 15 15 000 subscribers on the newsletter and that that's where i saw like hey maybe something that i'm writing is resonating with people so i just doubled down more more on that and yeah it was really a really good decision to start start writing and um yeah i couldn't be happier with it and really really grateful for for me to start and also grateful to to to consistently send out every newsletter every week and two times two times a week i haven't missed a week for over four years and um yeah i'll keep doing that yeah it's uh there's something about writing that makes you whether it's technical or non-technical it's like you really you can't hide behind anything like you really it drives you to understand the topic because you're kind of putting yourself out there and put it in a paper there's a like sort of it forces you to understand what you do what you do know what you don't know um yeah that's super interesting and the consistency is amazing yeah i would agree that like that's someone who writes a sub stack it's like 80 consistency and then 20 you know marketing and making sure you're writing about things people care about etc but um i wanted to because i know there's a lot of different people from different you know there's probably junior engineers that'll watch this and listen to all the way up to staff engineers do you like pre-LLM and post-LLM do you think it's the same what is the different like say somebody I don't know anymore if there's like on it's kind of weird to think about I don't know if there's a difference between like a just an engineer and a senior engineer anymore I'm not sure maybe it probably is depending on your context but what is that difference if somebody wants to make that and do you think these positions will still be here like to go from like engineer to staff slash principal if we like put those in a bucket because thinking about like your trajectory and like at least the trajectory now right you've got just individual contributors engineers but you still have you know you have the tech leads like you talked about but then that staff principal engineer that's kind of like quasi people lead quasi not and then like that cto what do you think the what are like the biggest hurdles or obstacles or maybe even skills that people need to move from like say engineer to like staff principal and from staff principal to cto or maybe and how would they know whether I should go to staff principal or do I do like engineering manager or team lead does that make sense?

36:32Yeah it's a really good question and if you would look at I think obviously big tech is different than a lot of other bigger companies but other bigger companies outside of big tech not a lot has changed so as we talked about your friend he doesn't really use LLMs a lot in their day to day work that's the reality in a lot of bigger companies and if you enjoyed that kind of work then potentially that that could be a better fit for for those kind of engineers but as as as we talked about i think the the um lms are going to come to those companies as well and i think my recommendation is always to be ahead of the curve instead of like trying to trying to be trying to be after the curve is already there and and so on and you're you're being someone who is who is trying to be in the what worked like five years, 10 years ago and so on.

37:29But yeah, like depending on the company size, it's totally different roles, like especially in small to mid-sized companies, like for example, with companies like OpenAI and Tropic, they expect for every software engineer to be a tech lead. So they don't hire just engineers who can work on tickets, but they expect from engineers to provide ideas for projects and they expect them then to build that project and then also to release that project and also maintain it. And that can sometimes be on their own or that can be a team of three people and that person is expected to lead that project. So that's what I see more and more in startups and let's say mid-sized companies, especially with OpenAentropic and other AI labs.

38:14And that's probably what's going to become a reality in a lot of other roles. Obviously, Europe is a little bit going to come after some time and then bigger companies after some time. But that's what I see. The tech lead kind of abilities are going to be the expectation for every software engineer engineering role. So regarding the difference between junior to senior, the difference is just getting less, is getting more and more blurry. A lot of junior engineers are expected to come in at this time and just, you know, take on and share ideas, take on projects, start contributing right away. They are not given time to work and shadow a senior software engineer for three months, six months, and then learn slowly and so on.

38:58I mean, the biggest benefit that you get from a junior engineer is their ingenuity, their motivation and drive for learning. their problem-solving abilities because they look at things from their own perspective from their own lens and you want them to contribute as well right you don't want them to just try to be in the shadows and just um yeah uh stick stick to learning for for one year and so on so yeah the reality is uh is like that for software engineers senior junior mid-level kind of like closer together do you think that is still the same for principal and do you see those kind of collapsing like the principal staff do you think that it's going to collapse to as well yeah uh good good questions just wanted to get into into that level as well for example i talked with redis and what i do is they have small teams of two three to four engineers per team and every team is owning a certain project and they have a feature lead inside a team that is more kind of like a tech lead senior staff engineer but they also have a service lead who is more kind of like a principal distinguished engineer owning a bigger spectrum of number of different projects and then those feature leads are talking with that with that uh service leads on to about like hey how to do this how to do that and aligning on different projects and so on so i definitely see a place for principal staff engineers distinguished engineers in any company especially like i think with with open ai as well uh on tropic you need you need those those kind of people who are going to have a view on that on that bigger bigger spectrum for example like a big part like owning like a big part of chat gpt or codex or or whatever maybe like another product another tool you need you need those people who have that experience that that expertise not just one person who is very driven motivated to build things but you know you need people that have like those experience expertise to to move those really hard problems forward um so yeah i think those those are going to be more and more important as time goes on.

40:59I mentioned like staff engineer role has grown, but engineering manager role has shown decline. And there's a lot less, like for example, Amazon started that initiative with 50 % of decrease of managers to individual contributors. And a lot of companies did that as well. So I see less engineering manager roles these days than staff engineer roles. Staff engineer roles is much more, but obviously like software engineer, senior software engineer is the most expected role and most look for role these days, but it contains a lot of generalistic skills and so on. So the bar is a lot higher than it was before.

41:34Regarding going and becoming a CTO one day, my recommendation has changed from today to maybe like three years ago or four years ago. Four years ago, if you would ask me, I would recommend going through senior software engineering, going through the management route, team lead, engineering manager, director of engineering, VP of engineering, and then becoming a CTO. But today, the problem is that middle management has become a really, really hard path for a lot of people and a lot of people having a lot of problems with that role because you're getting so many problematic things, especially with high expectations from the leadership team and obviously the stakeholders, investors and so on about, okay, we need to use AI more.

42:20we need to be more productive we need to have a lot better results at the same time you need to manage your team and kind of like shield them from all of that outside noise so it's really middle management has has always been hard but it's it's a lot harder these days and also there's a lot less roles there's like a lot of companies that have like a directors and then a bunch of teammates are reporting to the directors so my recommendation for becoming a cto is more connected today with the ic path like going to from senior software engineer to staff engineer then becoming a principal engineer, potentially distinguished engineer.

42:56And then obviously you're going to need some management experience. You're going to need some executive experience. You want to be closer to the people who are decision makers as much as possible and trying to get that knowledge experienced. Then you could potentially be a director VP after you become a distinguished or maybe a very low amount of people get to distinguish but the staff or principal after you get there then you can go directly to director instead of going to engineering manager because i think with directors it's still you need executive presence and also like vps um but it's it's much it's much easier i think role these days than than being an engineering manager a middle manager and you need you need totally different skills you need a lot more you know managing company politics uh and being good kind of like in building good relationships with people outside of the engineering, with other departments, and so on.

43:53But I think that that is the way to go these days. That's my recommendation. Speaking of roles changing, say you're a staff engineer or something, principal engineer, and you've got a group of a handful of engineers below you who are working in something, and you're, I don't want to say AI slot because code is cheap, right? Right. If that's just the when people say I slob it's all like that just is more the that's the person. Right. It's not really the LLM's fault. That's the person who's on the other end of that. It's not has nothing to do with the LLM. But it seems like it's still in some funny way.

44:30It's like so you're this person, you know, you've got these whatever engineers below you, whether they're junior and now or senior. And you've got all these PRs flying in every day, all this code, tons of code. And it's like at the end, like you're responsible to make sure the product doesn't break, that it's performant, that like generally some, you know, like you said, there's some structure we're following of like, this is what we expect the code base to look like. This is how we solve problems. And it seems like now you're back to that same, which is the same thing before LLMs. It's like now like testing is really important because everybody, you know, so much code is being shipped and, you know, maybe you're using CodeRabbit to review everything.

45:12And it's just, I don't know if you've talked to anybody that's dealing with that or like, if you have any comments of how, and it's like almost back to this fundamental thing where it's like, no, we still got to, maybe we need better skills for our agents. Maybe we need more training. This is how we solve problems. Hey, how do we not over-engineer things so we don't have no problem two years from now? I don't know if it's, but again, the same time, if code is cheap, quote unquote, like if there's a problem, it's fairly easy to fix it now, as long as you have the relative. people that can think that way i'm just curious if you see that as like because you hear people talking about this everywhere of like well we've got this a lot of code coming and and which is fine but like how do we make sure that we're building good products and i feel like now you've got these staff principal engineers who not only have to be people please you know people pleasers on both sides to above them and below them but now they're trying to manage this new world of like well, code is cheap and we're getting in a lot of it?

46:13Yeah, it's a really, really good question. I think there's a bunch of insights we can mention here, especially, you know, the first thing is what I recommend is slow down instead of just trying to rush all the time. Because I think these days we are all expected to make miracles with AI. But the problem is when moving fast, it has never worked out well in any in any of our eras in engineering that that's that that's my understanding is if you're rushed to do things you're always going to to generate slop and bad decisions and so on of course yeah we can fix them along along the way but the problem is um if if you deliver slop you need to have a good trade-off in mind right and there needs to be a good business decision there needs to be like a really critical thing that we are going to just quickly deliver it and then we're going to make it better but if if it's not i mean it's not a excuse because speed of coding is so fast that we can just deliver slob and that's also like whenever i see a pr from an engineer and i see a bunch of ai slob in there and then i see a bunch of ai comments in there that's going to be loss of credibility in my eyes in my eyes for that engineer i'm going to be giving them feedback i'm going to be i'm going to be um acknowledging that I'm not happy with that, and I don't want to see it again.

47:38And if they're going to do it again, there's going to be consequences. And that's how I think everyone should approach. Staff engineers, principals, engineers should enforce good standards, the way we are building things, and it should not be an excuse because LLM has made that mistake. Like now you are the one who is owning and who is controlling what is being actually delivered. And yeah, more ownership is crucial these days. And I see, but the thing is that with tools becoming better and better, there's automatically, people are going to be automatically incentivized to just, okay, I'm finished with this and just calling it a day.

48:20And that's it. But that's, in my eyes, those people are low performers, but you need people that are going to take ownership of their work and make sure that they are delivering good quality because of their teammates, because of the reviewers, because anytime you deliver slop, you're going to put the extra work on your reviewers. And you're just being selfish. That's the reality. And we don't want selfish people in any organization. Regarding speed of code, and there's also narrative around coding has never been a bottleneck. and I tend to agree with this because you know building the right things has always been the bottleneck and it's been a bigger it's it's a bigger bottleneck today than before because of the speed of coding and building the right things is really really more important than ever because we can build faster but are we actually building the right things if we if we are not it doesn't matter how fast we can move right it doesn't we're just going to deliver bad things to our users and we're going to bloat our application and users are going to be confused why are we actually getting this there's no value in it it's actually making our product worse that that's more important and especially like with building things like you know meetings have been a drain for a lot of engineers in the past and today as well focus being able to focus context switching is a big problem of course these days even more than before maybe before we had like maybe a lot of interruptions people coming to us when we were coding and then they wanted something but these days you're spawning like three to five agents at the same time so contact switching is is a big bigger problem these days and also like bad bad management bad leadership decisions i think those have always been bigger bottleneck than just just writing codes and i think those are just being exposed these days and have shown to be that a lot bigger bottleneck than even like maybe five of 10 years ago but uh yeah again like if if you were building the right things you don't need to have like a really complex solution you you can win kind of like a lot of users with just pure building a simple feature that is going to be very very uh solving uh user problems and you don't need to have like a really amazing complex technical solution that you spend like one year or two years building.

50:46That I think has always been a lot more important than just the speed of writing code. Yeah, I would agree with you. I've noticed that slowing down to speed up helps. Just people take 10 minutes, you're starting a project, just thinking to yourself, just thinking by yourself. Even if you want to use the LLM to help you research, I think, or think, instead of just saying like, instead of copying and pasting the Jira ticket in and saying, spend a minute to like what technology stack are we using today like let me think through like the options before me myself let me like read some that and it's okay to ask the llm to help like can you i'm thinking about these two things it's just again like critical thinking skills like can you compare them for me oh i probably should think about cost here let me you know ask the llm or do a little research myself i think that yeah just because of the speed at which things can be done just even taking 10 minutes or even stopping maybe you're 50 through whatever feature you're building to stopping to take the data like just pause and like think like where did i move too fast where didn't i what's you know where's things sit am i missing anything just those like like you said it's like a mindset of slowing down thinking big picture stuff asking critical questions um and lms can help you do that right to research and make that quick but i feel like even just taking those simple steps yeah it makes a huge difference and you know the software that's produced um yeah those are really good points um i know we're running out of time here uh i'll leave links to like your sub stack not that you need me to because you have a million followers but i'll leave links to the sub stack the book um and yeah it's super awesome talking to you today anything you want to any last words of wisdom for people watching yeah and i i mean uh thanks a lot for having you daniel i really enjoyed uh this conversation i think you know it's all about like uh being a continuous learner uh don't get too much into trying to to learn every new shiny ai tool fundamentals are more important than ever uh you know also yeah as we talked about you know slowing down to speed to speed up slow down you know just relax breathe and you know keep on trying to get better both at human-led skills, both communication and working with people and at the same time problem-solving abilities, having your eyes open on business problems and providing value to the organizations, to the users, to the customers.

53:19And good things are going to happen. I think that is the way to go these days. And yeah, that's what I would say. Awesome. Thanks for your time. I appreciate it. I feel like this is a masterclass and it's so worth it. Definitely. Everybody go check out the book, buy it on Amazon. I appreciate your time today. Thank you. Thank you for having me. Thanks.