What Separates Good Engineers from Great Ones

Software engineering fundamentals, how to become a great software engineer and what to focus on. That's exactly what we discussed today. Joining me today is Sonar Muk, Director of Technology over at Picnic. And he's been involved in setting up a training program specifically for people early in career to teach them how to become great engineers. He touches on many pitfalls they teach, some of which I've actually fallen into myself. So enjoy.

One of the initiatives that give me a lot of energy that we

started a few years ago is a path for people who are super early career, who are maybe even just graduated and bringing them into Picnic and giving them a place to grow very fast through our tech Academy. So what's what What you saw initially in Picnic when I joined is that we hired people who were quite experienced, which is great because you are allowing them to hit the ground running and to become very

productive very fast. But at the same time, as we all know, it's super hard to keep hiring experienced talents, especially if you want skill like we did. So we also understood that this was not sustainable to, to, to the level that we have now. So we needed to find a way to also bring in people with less experience and no experience. And as you're a start up moving into sort of the scale up phase,

things are busy, right? So all teams are crazy busy with lots of new features and then all, all kinds of things that need to happen there already. So just throwing someone in there who doesn't have any experience at all doesn't set either side up for success. So it's not not great for the person joining, it's not great for the team. So we, this was around 2122, we started thinking, OK, what do we need to put in place to be able to make this happen and to set

both sides. So the team receiving, let's say this junior joining, but also the person joining up for success. And that's where the idea for this sort of learning path came where we say, OK, basically what we want is someone still with ACS backgrounds, but maybe no experience or very little experience and give them enough support to to grow very quick quickly, to be able to already

contribute from the start. But at the same time have a lot of support structure around that to also get this growth. And that's, that's sort of a initiative that I'm super excited about. But now we've done five groups of roughly 10 engineers that we hire in sort of batches. And these are also groups that that feel very cohesive and go

through this program together. And where you can see that they actually get an opportunity is pretty rare because as an engineer, you will then join one of our product teams. So from the get go, you will be immersed, let's say, in the whole context of team and, and, and doing actual work already. But at the same time, we also offer a very structured path to this group in terms of learning. So there's a few courses that we developed and, and, and, and teach.

There's a mentor that we also couple to this person who's available for yeah, one-on-one coaching. And we also explicitly make time for this, right? So that we also don't put this as an additional burden on someone, but really allow them to to take time for that and also offer a lot of room for people to actually do a bit of self development, self study, offer content for that.

So that's yeah, these people in the first few months that they joined really also experienced the freedom to to actually work on themselves rather than trying to figure out how to implement their tickets and how to actually get something out of the door because there's they they might experience otherwise so much pressure. So designing this program was was something that was a bit of an experiment, right? So for us, it was completely new.

But it turns out that this is very has been very effective, has been very successful. So as I mentioned, we, we've now since 22 and done five or six of these groups with lots of new and and young fresh talents that are coming into Picnic where we also see that this is something that's also reinvigorate teams in the sense that a new and fresh perspective without the burden, let's say, of a lot of experience can also bring a lot of new energy to a team. Yeah, yeah.

I mean, it's really funny. I've lately talked about this concept and I've heard that Booking does it kind of in a similar fashion, but they do have a full training programme before you actually enter a team. Lots of kind of hackathon concepts there. I talked about it with Director of engineering from IKEA specifically. I don't know the insurance and outs there, but they also start with cohorts with 10's and dozens of engineers and you specifically mentioned they

immediately jump in. In a product team. They still have to have ACS background or a more technical background. What do you look for with people that actually join this program with regards to what they already bring to the table? So what I mostly look for is people who are really eager to learn. And that sounds very trite, but you see a big difference in in people who are just looking for maybe like a stable environment. I just want to do my stuff as I think the world works in the

software engineering, etcetera. For just the people who already have maybe done some side projects during the university who are very well versed in some of the technologies where they also try to explore this themselves. And during interviews, you can see sort of the difference in energy level between those people. And that is, that's really what we're looking for.

So people who are eager to actually not be content with the status quo and to actually embrace the fact that they still have a lot to learn, even though they had five years of CS studies here behind them. So that's, that's, that's, that's sort of what we're looking for in these groups. And I would say this goes in general for people working at Picnic that we are looking for this also this entrepreneur

neural spirits. So if you're in the product team, regardless of, of what level you're at, we, we want to have people who look around and say, Hey, why are we doing it this way? What can we improve and, and not just wait, let's say, for the business to come up with, with new features, new things, because that is how ultimately

as tech company you grow. It's not just by executing on a backlog, but it's also by being very proactive as a team and, and looking around and, and seeing, hey, how can we improve the world around us for our users. I feel like being eager and like hungry for knowledge.

I have had that and I still have that on certain topics, especially early in Korea was is very big and now it's, I think it's similar, but it's very much focused towards more specific subjects because in the beginning I had no clue what I what I wanted to focus on. But I don't know if that's a skill that's just something that's in you or something that

people have or you don't have. I do want it though, because I've had conversations also in an interview setting and then someone would be like, this is a really good opportunity for me, but they could not show what they've already done and why it's a really good fit for them. They hadn't started yet. They wanted the job 1st and then they would start the work. And I like that you highlight that the people that are really eager, nothing stops them from already starting, right?

They don't have to have a job to do what they like. Exactly. Yeah. And, and it also shows in in the way they, they, they can do themselves during interviews, right. So do they ask questions to you, right, that are interested in your company, in your team, in, in what's happening there? And that that already shows that a lot of people during interview feel that they are being interviewed. Well, that's of course that makes sense, that makes sense.

But at the same time, it's also the reverse, right? So, and that's not just for early career people, but for anyone you're also interviewing company. If you can already at that point make very clear that you're someone who's interested in in what's going on and and interested in what's your role. And that will be that already also shows to me that's that you're you're you're someone who can grow very quickly and then pick up new things.

Yeah. For the people that join, what explicitly do they get taught during that process? So in the first couple of months of of this program, it runs roughly 5 months, they will join 3, let's say, very hard skill courses around Java development. So the first one is really about what we view at Picnic as a good way of doing Java development scheme coding, how we use certain patterns, etcetera.

So really beyond, let's say the basics, but really how, how do we do this in, in a product context, in a picking context specifically. And then they do a deep dive into Spring Framework. And they're also, it's not really about learning which annotations to use or, or what, what do the API looks like, because some of them have already seen that. And otherwise they will pick those up relatively easily in, in a product team. But we also want people to really understand the

technology. So how does it work? Why is it there? What is the reason that's that we're using such a framework? What does it bring to the table? And we also very much encourage people to, to, to do this deep dive and to take that time, because ultimately what we want to prevent is that we have very smart and eager people joining A-Team and then only learn by copying and doing what they see around them. Because that will work to up to

a point, of course. And, and it might feel good in the beginning because you're productive and then you're delivering features and you're delivering code. But it will not create the engineers that, that architects are future systems that really deeply know what the technology is about, that really understands why something is there rather than just using it. And, and, and that is in this in spring course might sound very basic and some of the parts are

basic, right? So some of it is new just to these people, but it's also really much, very much about what is what is under the hood and why is it there and why does it function the way it does. And then we within Picnic also make use of reactive programming. And obviously, if you use Spring Framework, there's also the whole reactive part of that, which in and of itself is quite an challenging topic even for more experienced engineers to pick up. So we also very much focus on

that topic. And then for the, for the first two courses that I mentioned, we also organise what we call reflection sessions. So in a way, if you're in a course, you have an instructor, you do some exercises, you get some learnings and contents. It's still very theoretic. So we asked every participant to also bring this back to your team and, and think about, Hey, how are we applying this in the current team context? Do we see any improvements?

What, what have I learned and how this translates into the practice? And then they bring this back to the group and present that, which also helps them in their presentation skills. And then learn how to craft a story, how to actually show people what you've been analysing, what you've been doing. And these reflection sessions are super helpful to actually again, bridge the divide between theory and practice. So these are very hard skilled Java oriented trainings that

they have. We also offer them some training around, let's say, more peripheral components in our architecture. So there's a course that focuses on our use of MongoDB, of Postgres, and all of the sort of infrastructural components that you will need to succeed as an engineer. So Docker, Kubernetes, anything around operating and running the products. So it's a very broad kind of program.

But again, because they're part of a product team, they can immediately next day see how this works in their contexts, how it supplies, how our release is done, how does our production system look like. And then in that way, you not only gain the knowledge and, and gain your understanding for technology, but can also immediately apply and, and learn it in your, in your day-to-day. And yeah, that's sort of the mix that we offer and that's works for us pretty well.

I can see that. I really like the kind of practical part of joining a product team and seeing and feeling kind of what it is to be in there because you are, it makes a lot of sense. And then more on the theoretical

side, really focusing on hard skills, I and when you mentioned you can copy and kind of do what other people do, that hit the nail on the head because that's exactly how I started. And it feels good. It feels productive. You feel like, OK, I can, I can actually do this. And it really hit hard when I started a project where there was nothing. Because when there are conventions, it's easy to follow the conventions and you have to experiment and you have to innovate a little bit.

But really good conventions are there for a reason. It makes people productive and they know how to follow the conventions. When you're building up conventions and you have to build up a solid foundation for other people to build on top of a future you, but also a future people you don't even know yet and a future team, let alone a scholar of teams, That for me is very challenging. No, I fully agree. And and that's also why you point out this pitfall at the very beginning of this program

to everyone who joins. We tell them very clearly, yes, you will have sort of the urge or the inkling to just dive in and, and and do the work and, and be useful and, and make sure that your values as part of the team. But we're offering this pretty unique opportunity to also take a step back and in the first months, take this time to, to

learn and to grow. And that is something that it's, it's a tricky balance of course, for people to make, but we do expect them to actually invest the time.

And and that's also where this this mentorship plays a big role, of course, because a more experienced engineer will actually also hold up the mirror and say, OK, but but do you actually understand what you do and then also dive maybe deeper in aspects that they don't understand and that they're maybe not covered by the by the technique program itself?

Yeah. Yeah. For me, with regards to depth, I also wonder how deep should I go with regards to getting a solid understanding when we talk about programming or or software engineering fundamentals. What would you say really fit in there?

What have you seen engineers do that are exceptional in your view? So if I look at the picnic contexts, a lot of what we do is Java and JVM based. So what sets apart the really good engineers from let's say mediocre engineers is also some knowledge of what actually happens under the hood, right? So do you know what what the JVM does? Do you know how to understand garbage collection and the effect it has, how how to tune it, how to operate a Java based system?

So beyond coding, I would say apps for this podcast also understanding the ecosystem that you're in and, and at a very core level understands how things like performance, security and all of the non functionals, excuse me, all of the non functionals are affected by by what you do as an engineer. And and that is certainly not something that you learn overnight, right? So you make mistakes, you see other people making mistakes,

you learn from that. And that is invaluable as an engineer to have that that kind of knowledge and experience under your belts. From engineers I talked to, some people have that urge to really want to understand what goes on under the hood and they will themselves, I think self educate and that is a continuous cycle of new technology. How does it actually work? And I set it up from ground up,

from first principles. And then you have other engineers and I think I fall into that category more. It's like I can use these things and I kind of have an understanding of how it works under the hood, but I want to be effective. I want to execute, I want to deliver value to customers. I'm more, I feel like user facing and then I have this decision and it's it's the last few years, but also the coming few years.

If I want to become a better engineer, I do have to find this inkling and go deeper to certain aspects because I feel like that's what's withholding me from actually growing on an engineering side. No, I think there's certainly a tension between you as an engineer being a problem solver,

right? You want to deliver value, you want to be effective for just being a very curiosity driven kind of, you know, person eager to learn what the technology actually is all about and what it does and why it works the way it does. So for sure that that that is something I recognise. It might also be related to your stage of your career, as you, as you pointed out, right.

So especially when you get started, it is easy to fall into a trap of, of wanting to be too productive and, and just copying behaviour around you without really understanding.

And, and I can certainly see that once you have sort of gone through the motions of learning and technology very deeply once or twice, then picking up another technology and using that in a very effective manner comes pretty naturally and doesn't take the same kind of level of, of, of depth that you, that you would otherwise have to invest. So as you grow, you probably will focus more let's say on, on the usage of your of your tech and not so much on the, the

under the hood stuff. Yeah, yeah. Makes sense. Yeah. Any other foundations or fundamentals you want to highlight that distinguishes great engineers from not so great ones? If I look at what is happening in, in, in picnic context again, what what really strikes me is that our our engineering culture is relatively uniform in the sense that we started only 10 years ago. We have a very strong developer platform that was developed from the get go. And there what I see in some

other companies and other contexts is that there's a lot of people trying to adopt new technology just for the sake of it. And that is something that I feel that a good engineer doesn't do right. So if you adopt new technology, if you find out about a new technology, you need to understand whether it's actually an improvement of what you have. Make very clear also why that is the case and not just jump on any, any band work. And, and that's something that I feel that very good engineers

are good at, right? So they there's this sites, I'm not sure if you know it, the boring technology dot COP. I don't know it, but that sounds very funny. Yeah, yeah. Which sort of advocates for use what works, use what is proven use and then use it in a very effective way as you mentioned that that is I think what what good engineers do and the surrounding between OK, but what new technology is that interesting to jump onto

etcetera. And that is super hard, of course, and also maybe a bit more of an art than than a science sometimes. But it's precisely that's kind of gut feeling, I would say that's that that knowledge and that wisdom that you have as a as a, as a Craftsman, as an engineer, that sets you apart from people who, yeah, who don't have that taste or who don't have that knowledge to, to make

a good decision. And then sometimes you end up in situations where there's companies that are much smaller than than the company I work at that have like dozens of different technology stacks because, well, people decided that in some kind of context, it was better to use Rust or to use Go or to. And then you end up with this fantastic collection of technologies that nobody really knows how to manage anymore, really know how to, how to

operate anymore, really knows how to, how to bring this together. And yeah, that's, I think one of the hallmarks to come back to your question of a good engineer is to actually also limit this and, and, and, and stick to, yeah, proven things and what works. Yeah. Do you feel like that problem of newer technologies or also engineers just from marketing sense getting bombarded with tooling is a problem that's more recent? Because I feel like now everything is about Gen. AI.

It's like the number one buzz on the Internet. Obviously. Is obviously is Gen. AI, but also not just from a OK, how do you get Gen. AI features if that's already a good idea into production, but everything with regards to developer tooling. It's a huge market. Lots of companies are trying to solve this problem with regards to productivity and tooling, so I feel like I am getting bombarded. For sure and I mean there's, there's so many new things to

try out, right. So Cursor, Windsor, Windsurf, all the, all these kind of tools and, and they're sure it's good to experiment, right. But at the same time, we also need to be mindful that, yeah, we, we should do what works and not so much we should, we should not only focus on what seems shiny and new and, and interesting in a sense.

Yeah, yeah. One of the things I I love, and this is also what what gives me a lot of feeling our fulfilment rather as an engineer is the feeling of also being productive in the way I am productive. So in everything from creating a pull request to tooling to figuring out my IDE and everything on the terminal, I like to be very efficient and effective in all of that. Everything hands on.

And especially now that there's a lot of change and a lot of experimentation going into tooling, I'm more hesitant to experiment and adopt because I am confident with the tool set that I have. You have something that works for you. Yeah, yeah, yeah. But then when you have a platform of 350 engineers, if there's something that can make them a few percentages more effective or efficient, that's going to pay dividends for sure.

Yeah. How do you choose or how do you experiment with regards to things that help developer productivity? So there's a, there's a few things that we do there. On the one hand, as I mentioned,

we have a developer platform team. So in a sense, when and, and this can be a new tool or new, new library or when, when something comes up where we feel that this is going to help all of our product teams, we can in a very centralised manner, experiment with this in the developer platform, make sure that it's working in the context of everything that we do and then roll this out in a controlled manner. So let's say we have Java 25 coming up, for example, just released.

Rather than having every product team figure out when to upgrade, how to upgrade, what, what the effect is on their tooling, etcetera, we do this in a single place at a single moment and then help the rest of the teams be very productive with this new technology. So that's one example, but of course it goes beyond tools, right? So tech is not just about tools, it's also about people, about

process. So if you look more holistically, let's say they add at our developer experience, what we want to achieve there is that we actually enable teams to continuously improve themselves and this doesn't start all by itself magically. So I also mentioned in my scope, we also have some developer experience coaches that we that we have and that we use throughout the company. And these coaches really help teams to uncover their biggest

bottlenecks. So this can be through workshops, but it can also be by looking at some metrics and, and analysing that just really clearly helping teams to identify, hey, what is the next step I can do to indeed get a few percent more out of my process, Maybe have more stable operations, Maybe look at the way we, we deliver to, to production, How can we optimize that?

And that's something where we want to encourage teams to ultimately get into the cycle themselves, but help them with, with, with support from coaching support on the metrics side. So given the insights in what is happening in the team and also on the on the process side, help them to understand that by maybe introducing a few more steps into their refinements or doing something more on the retro sides that they can actually increase the effectiveness of their team.

So that is something that's we we do with coaching, but also with with processing tooling supports from this developer experience initiative. Yeah, for me, it's funny that you mentioned specifically developer experience because when we're talking about hard skills and what makes a good software engineer and understanding kind of the foundation and things with regards to under the hood first

principles. I feel like everyone that helps with regards to process, if that's a developer, experienced person, a coach, a mentor, a facilitator, and also scrum master, if they don't understand everything under the hood with regards to that process or the intricacies of working together and collaborating more of the soft skill side, then it stays surface level and surface level with the rest of process from is never good people and specific specifically engineers, they're

skeptical. I think by nature they might be stubborn and if things don't work and are in the spiral of continuously not working, they will get jaded with regards to change and process change and anything there. So especially this with the rest of process and facilitation, I feel like needs to be done very well. Have you experimented with the rest of what works well for your context? Is it is it very data-driven or is it more quality focused? It's a, it's a combination of

both. The people probably know about the Dora metrics, right? So that is something that a lot of companies use to actually look at, hey, what is happening in team. So change failure rates, lead time to change these kind of things. But what most people don't know is that Dora also has a capability framework and these capabilities, some of them do also have metrics and are more quantitative, but some of them

are also very qualitative. And so they divide these Dora capabilities into three major areas. One of them is learning culture. The other is fast flow and fast feedback. And especially if you talk about fast flow, you talk about optimising your team processes. There's certainly quite a few metrics that you can, can look at your PR cycle times and things like that. But if you talk about learning culture, this is very hard to measure and, and as it should be, right?

So not everything is data-driven. At the same time, we do want to enable. There are also people to think about, Hey, what, what is, for example, one of the capabilities there documentation quality. What do I do in my team? Is that something that is effective or not? You don't find that out by by looking at metrics, by talking to people and to really understanding, hey, do we have enough here in place?

For example, onboarding, if you have a new team member, do they have enough to go on by what you have in your in your confluence or in your developer portal? Or is it very much still in the hands of people and, and, and hard for them to get out? That is something that you that you can find out by by talking to the team and, and, and helping out to set that up as a second step. Yeah. Yeah, I like that a lot. I feel like developer happiness as a metric is something that is very hard to do.

But when you're talking about a solid process for onboarding people, having this feeling of understanding, and there's a culture of learning and entrepreneurship and people are all effective in what they do, I can definitely see people being happy within that team and within that organization specifically. How do you accommodate for developer happiness? Is it just by providing all of this and then seeing what blooms or how consciously are you

working towards that? That has everything to do with with finding and removing these bottlenecks, right? So nobody likes, likes A-Team where there's very clearly a bottleneck in, in some part of the process or something part of the tooling. So we also run the developer survey, for example, a few times a year to, to uncover in a more wide manner in these kind of things. Our developer experienced coaches who work with teams also bring us back to, to our developer platform.

Hey, we noticed that for example, people have a hard time finding out where APR documentation for certain services that that is a signal that we can pick up and that we can that we can fix on the tooling side and then bring back again to the teams. So this this very much is about identifying bottlenecks and taking them away step by step and and also taking feedback seriously. Yeah, I was going to. I was going to ask for me.

What I've seen is that gathering feedback, some people are have a hard time doing that, but I think in essence, it's quite simple, right? You can talk to people, you can get surveys, you can do a team day and then have a brainstorm. For me, the most important part, the most crucial part is what you do from that feedback, how you take it with you and how you implement it. Especially if this is in a in a

cycled manner. If feedback doesn't get implemented, then people will question why they give feedback at all. Exactly nothing is worse than being asked to fill out another survey where you don't know what what's going to happen with the results where it will end up. So part of of the responsibility of my domain is to bring clarity

to that, right. So not just gathering the data, but also showing, hey, these are some of the things that are are across the tech team, a big topic, major theme and that is also what we're going to focus on them in next quarter, for example. So to really communicate that, it's also super important to get people on board for. Sure. Yeah, I love that.

Back to software engineering fundamentals we covered going under the hood, really understanding things from our first principles way of thinking. Also figuring out what tooling is effective and not just jumping on something that's new from a bandwagon perspective or from a marketing perspective. What else is there with the rest

of building solid fundamentals? The other thing that I very much encourage people who've gone through this tech Academy program to focus on after they've had these, these more, let's say, technological fundamentals on the belt is to really understand the context that you're in and to be able to be an effective product engineer, right?

So in the end, code is a tool. We're here to solve problems. Are you able to independently look at a problem, break it down, make sure that there's a sort of a design around this that is validated. So the whole process of, of bringing an idea into into a code base that is also very important. And, and a lot of this is taken away when you just start out, right? So there's more senior people who look at this and they will create tickets for you and then maybe write design documents,

etcetera. But making this step from from coding to actually thinking like an actual problem solver to really end to end be able to to look at something and and realise it. I think that is that is not a major step that you need to make in your in your development as a yeah, as a software engineer. Yeah, product engineer, I feel like it's a term that's more and more now out on the market, especially with tooling where you have to think a little bit

less about the technical side. You have some magic and it generates stuff. Product engineers is what I've seen grow as a role. Specifically, is that what for you? Is a product engineer someone that can think end to end with regards to problem solving also from business sense? Exactly. And I would also add to that, see the long term impacts of the things that you're coming up with, right.

It's easy to hack something in, but it's very hard to design A feature in a way that's future proof, but that's also operable, right. So it doesn't cause instability. All these kind of things that are not obvious when you look at at the user story, let's say that's, that's also for me what a product engineer entails. Yeah, yeah. Gotcha. Where do soft skills play into

this part? You mentioned the curriculum, it has a soft skills part, but for example, if I draw a comparison to booking, their training was very much tailored towards the more soft skills side, which I thought was was interesting. I like that you focus on 1st principles and fundamentals and also you specifically look towards people that have already done something with the arts side projects or actually have a degree, CS degree that come on board.

I think that is also what allows you to focus on very, very early in career, 0 to one year of experience instead of what we or what I've seen where people look into kind of two to three years. So you can still kind of steer, but where do soft skills play a part in this from your perspective?

So soft skills obviously very important as an engineer and the more you grow as an engineer, the more you are also exposed to other stakeholders, talking to to people who may not have the same background as you, as it is also part of what we what we offer. We at the same time also don't want to make too hard of a distinction between soft skills

and hard skills. In the end, even if you're in, in a course learning about Java, you're still interacting with each other there and understanding each other and trying to see, hey, why are we doing this? And then we, we do encourage these kind of configurations, not just in the soft skills trading, but also on the hard skills side and also encourage people to ask question hard questions, right? So we're doing this. What does this, what does this mean in in my team context?

What does this mean for my future? These are all conversations that are related to the technology, but maybe in themselves not very technological. So yes, we do offer specific training also on the soft skills side, but I'm, I'm a bit hesitant in making this super hard separation. And again, also the the whole mentoring aspect, for example, this disconnection between people taking time together to to talk about not just technology, but also what does it mean to to have a career as a

software developer? What's, what are some of the future directions that you can grow into? All these kind of conversations are also very important to, to open up and to also have, have a meaningful connection in the workplace. Yeah. I'm very curious to hear your perspective on self study because I've seen in the comment section and I know people listening, they might not have a career yet as a software engineer. They might be doing something

else. So they might be in education, but especially people that don't come from a traditional background. I saw a comment lately and that was like I'm a taxi driver now but I'm learning web development. What would your advice for your

kind of from a road map perspective, what would be the start and how does that progress into them actually getting that role? Obviously it really depends on sort of the, the area of tech that you want to get into. But in general, I would say whatever you do, start building stuff from the start. So nowadays, of course with chat, GPD and all kinds of other tools, it becomes even easier.

But the trap that a lot of people fall into is that they watched like 30 hours of YouTube tutorials and think they, they made, made a, made a good step, but haven't opened an, I haven't opened an IDE or didn't write or try anything at all. I think that is in the end, trial and error. Just just make sure that you, you build stuff. That is the most important part. I would say. Obviously there is need for people to also engage with, with

content, right? So I'm, I'm myself also, I'm an author of Pluralside, for example. So I'm, I'm quite close to this and I get a lot of messages from people who, who are on such a platform that, that get a lot of benefits out of this. But you only learn if you also start doing. I love that. What is your perspective on AI tooling in this building frame?

Because if you're looking towards end goals, if my end goal is to build a product or an e-commerce website, I can, I can generate a lot of that stuff, but would I then learn how to actually do that? No, I would achieve my goal in a

different manner. Would people from your perspective that Start learning now? Should they leverage AI tooling or how can they use it to learn effectively? That's a great question. And we're still finding that as I think, yeah, so, so my take is yes, you can use it to to set up a lot of things for you. I would more use it as a tool for validation rather than something for for you to generate things.

Right. So if you are not able to actually explain what comes out of this model and, and if you are not able to understand why the code is there, then you will have a very rough problem also maintaining that and extending that. And of course then you can say, OK, well then I have some agents, AI agents do that for me. But ultimately there, there's, there will be a gap of understanding where the model trips up and, and you are not able to get it, catch it.

So use, use AI models to validate your understanding, try to generate maybe a few things and see, do I actually understand what's happening here and not ask the model right that that's great. But don't focus on on getting a polished product out of it and then getting sort of the, the, the, yeah, the products there. In the end, it's it's really a tool that you can use, especially if you're like taxi driver who's who's going to learn coding.

It's a tool that you can use to, to build your knowledge. You can also use very much to cheat, of course, and to just sidestep all of this hard work of, of trying to understand this. But I don't think that will in the long run help you. Yeah, in the end, it's a lot about discipline. Indeed. Yeah, I feel like I've experimented with Cloud code and it has a learning mode, so I can generate whatever you're trying to do from a prompt perspective and it'll stop.

And I'll say you have to do this part. That was great. And I haven't, I haven't done it a lot, but the fact that it's there and they're experimenting with not just generating but also facilitating learning, I think that's fantastic. I didn't know that, and that that sounds like indeed exactly something that you would want to do at at the point. So then fill in the blank, let's say, or take the next step yourself. Yeah, yeah, absolutely. Thank you so much for coming on.

I've I've had a real blast. Thank you, President. Cool. We'll round it off here. Thank you so much for listening. We'll see you on the next one.