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 Sander Mok, 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 it. One of the initiatives that gives 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 we 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 to skill like we did. So we also understood that this was not sustainable 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 startup moving into sort of the scale up phase things are busy right. So all teams are crazy busy with lots of new features and 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 great for the person joining. It's not great for the team. So we just was around 21-22 we started thinking okay 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 okay basically what we want is someone still with a CS background but maybe no experience or very little experience and give them enough support to grow very 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 an 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 feel very cohesive and go through this program together. And where you can see that actually getting 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 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 teach. There's a mentor that we also couple to this person who's available for 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 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 yeah these people in the first few months that they join really also experience 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 might experience otherwise so much pressure. So designing this program was something that was a bit of an experiment. So for us it was completely new but it turns out that this has been very effective, has been very successful. So as I mentioned we've now since 22 and done five or six of these groups with lots of new and then young fresh talents that are coming into picnic. Where we also see that this is something that's also reinvigorated 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 program before you actually enter a team. Lots of kind of hackathon concepts there. I talked about it with director of engineering for my kia specifically. I don't know the ins and outs there but they also start with cohorts with tens and dozens of engineers and you specifically mentioned they immediately jump in in a product team they still have to have a CS 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 tried but you see a big difference 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 etc versus the people who already have maybe done some side projects during university who are very well versed in some of the technologies where they also try to explore this themselves and already 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 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 entrepreneurial spirit. So if you're in the product team regardless of whatever you're at we want to have people who look around and say hey why are we doing it this way? What can we improve and not just wait let's say for the business to come up with new features, new things because that is how ultimately as a 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 looking around 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 career it was 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 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 first 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. They don't have to have a job to do what they like. Exactly. And it also shows in the way they can do some self-during interviews. So do they ask questions to you? Are they interested in your company, your team and what's happening there and that already shows that a lot of people during an interview feel that they are being interviewed? Well, that's of course true. That makes sense. That makes sense but at the same time it's also the reverse. 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 what's going on and interested in what your role in that will be that already also shows to me that you're someone who can grow very quickly and then pick up new things. For the people that join, what explicitly do they get taught during that process? So in the first couple of months of this program it runs roughly five months. They will join three let's say very hard-skilled courses around Java development. So the first one is really about what we view at Picnic as a good way of doing Java developments, key coding, how we use certain patterns etc. So really beyond let's say the basics but really how do we do this in a product context, in a picnic context specifically. And then they do a deep dive into a spring framework and there also it's not really about learning which annotations to use or what the API looks like because some of them have already seen that and otherwise they will pick those up relatively easily 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 we're using such a framework? What does it bring to the table? And we also very much encourage people 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 up to a point of course 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 architects are future systems that really deeply know what the technology is about, that really understand why something is there rather than just using it. And that is in this 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 and very much about 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 a whole reactive part of that which in and of itself is quite a challenging topic even for more experienced engineers to pick up. So we also very much focus on that topic and then for the first two courses that I mentioned, we also organize 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 content, it's still very theoretic. So we ask every participant to also bring this back to their team and think about, "Hey, how are we applying this in the current team context? Do I see any improvements? What have I learned and how does it translate into practice?" And then they bring this back to the group and present that which also helps them in their presentation skills and learn how to craft a story, how to actually show people what you've been analyzing, 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 product. 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 context, 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 gain the understanding of technology, but can also immediately apply and learn it in your day-to-day. And yeah, that's sort of the mix that we offer. And that 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, okay, 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. 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 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 do the work and be useful and make sure that your value is 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 learn and to grow. And that is something that is a tricky balance, of course, for people to make. But we do expect them to actually invest the time. And that's also where this mentorship plays a big role, of course, because a more experienced engineer will actually also hold up the mirror and say, okay, but do you actually understand what you do? And then also dive maybe deeper in aspects that they don't understand that they're maybe not covered by the by the tech company 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 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 context, 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 the JVM does? Do you know how to understand garbage collection and the effect it has? 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 at a very core level, understand how things like performance, security, and all of the non-functionals, excuse me, all of the non-functionals are affected by what you do as an engineer. 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 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? Can 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 and more, I feel like, user-facing. And then I have this decision. And 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, versus being a very curiosity-driven kind of 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 is something I recognize. It might also be related to your stage of your career, as you pointed out, right? So, especially when you get started, it is easy to fall into a trap of wanting to be too productive and just copying behavior around you without really understanding. 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 depth that you would otherwise have to invest. So, as you grow, you probably will focus more, let's say, on the usage of your tech and not so much on the under-the-hood stuff. Yeah, it makes sense. 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 the picnic context, again, what really strikes me is that 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 over what you have, make very clear also why that is the case, and not just jump on any bandwagon. And that's something that I feel that very good engineers are good at, right? So, there's this site, I'm not sure if you know it, the boringtechnology.club. I don't know it. That sounds really funny. Yeah. We should have advocates for use what works, use what is proven, use and then use it in a very effective way, as you mentioned. That is, I think, what good engineers do. And discerning between okay, but what new technology is then interesting to jump on to, et cetera. And that is super hard, of course. And also maybe a bit more of an art than science sometimes. But precisely, that's kind of gut feeling, I would say, that knowledge, that wisdom that you have as a craftsman, as an engineer, that sets you apart from people who don't have that taste or who don't have that knowledge to make a good decision. And then, sometimes you end up in situations where there's companies that are much smaller 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 operate anymore, really knows how to how to bring this together. And yeah, that is, I think, one of the hallmarks to come back to your question of a good engineer is to actually also limit this and stick to proven things and what works. Yeah. Do you feel like that problem of newer technologies or also engineers just from a marketing sense getting bombarded with tooling is a problem that's more recent? Because I feel like now everything's about Gen AI. It's like the number one buzz on the internet. Obviously, yeah. Is obviously it's Gen AI. But also, not just from a, okay, 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 so many new things to try out, right? So cursor, windsor, windsurf, all these kind of tools. And there, sure, it's good to experiment, right? But at same time, we also need to be mindful that, yeah, we should do what works and not so much. We should not only focus on what seems shiny and new and interesting in that sense. Yeah. Yeah. One of the things I love, and this is also what gives me a lot of feeling or fulfillment, 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 few things that we do there. On the one hand, as I mentioned, we have a developer platform team. So in a sense, when this can be a new tool or new library, or when something comes up where we feel that this is going to help all of our product teams, we can in a very centralized 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 the effect is on their tooling, etc. 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 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 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 analyzing 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 deliver 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 support from coaching, support on the metrics side, so giving them insights in what is happening in the team. And also 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 we do with coaching, but also with process and tooling supports from this developer experience initiative. For me, it's funny that you mentioned specifically developer experience because when we're talking about hard skills and what makes you 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 experience person, a coach, a mentor, a facilitator, also a 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 regards to process for me is never good. People and 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 regards to process and facilitation, I feel like needs to be done very well. Have you experimented with regards to what works well for your context? Is it very data driven or is it more quality focused? It's a combination of both. People probably know about the door matrix, right? So that is something that a lot of companies use to actually look at, hey, what is happening in the 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. 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 optimizing your team processes, there's certainly quite a few metrics that you 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 as it should be, right? So not everything is data driven. At the same time, we do want to enable there also people to think about, hey, what is for example one of the capabilities there is documentation quality. What do I do in my team? Is that something that is effective or not? You don't find that out 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 confluence or in your developer portal? Or is it very much still in the hands of people and hard for them to get out? That is something that you can find out by talking to the team and helping out to set that up as a second step. 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 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 finding and removing these bottlenecks. So nobody likes the team where there's very clearly a bottleneck in some part of the process or some part of the tooling. So we also run the developer survey, for example, a few times a year to uncover in a more wide manner these kind of things. Our developer experience coaches who work with teams also bring this back to our developer platform. We noticed that, for example, people have a hard time finding out where API documentation for certain services, well, that is a signal that we can pick up and that we can fix on the tooling side and then bring back again to the teams. So this very much is about identifying bottlenecks and taking them away step by step and also taking feedback seriously. Yeah, I was going to ask for me, what I've seen is that gathering feedback. Some people have a hard time doing that, but I think in essence, it's quite simple. 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 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's going to happen with the results, where it will end up. So part of the responsibility of my domain is to bring clarity to that. So I'm not just gathering the data, but also showing, hey, these are some of the things that are across the tech team, a big topic, major theme, and that is also what we're going to focus on them in the next quarter, for example. So to really communicate that is 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 for this Tech Academy program to focus on after they've had these more, let's say, technological fundamentals on the belts is to really understand the context that you're in and to be able to be an effective product engineer. 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 design around this that is validated. So the whole process of bringing an idea into a code base, that is also very important. 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 they maybe write design documents, et cetera. But making this step from coding to actually thinking like an actual problem solver to really end to end be able to look at something and realize it. I think that is another major step that you need to make in your development as a software engineer. 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 and to end with regards to problem solving, also from a business sense? Exactly. And I would also add to that, see the long term impacts of the things that you're coming up with. It's easy to hack something, but it's very hard to design a feature in a way that's future proof, but that's also operable. So it doesn't cause instability, all these kind of things that are not obvious when you look at the user story, let's say. That's also for me what a product engineer entails. 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 interesting. I like that you focus on first principles and fundamentals and also you specifically look towards people that have already done something with regards to side projects or actually have a degree, a CS degree that come on board. I think that also allows you to focus on very, very early in career, zero 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 are very important as an engineer. The more you grow as an engineer, the more you're also exposed to other stakeholders, talking to people who may not have the same background as you. So that's also part of what we offer. At the same time, I also don't want to make it too hard of a distinction between soft skills and hard skills. In the end, even if you're in a course learning about Java, you're still interacting with each other there and understanding each other and trying to say, "Hey, why are we doing this?" And then we do encourage these kind of conversations, not just in a soft skills training, but also on the hard skills side. And also encourage people to ask questions, hard questions, right? So we're doing this. What does this mean 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 a bit hesitant in making this super hard separation. And again, also the whole mentoring aspect, for example, is this connection between people taking time together to talk about not just technology, but also what does it mean to have a career as a software developer? What are some of the future directions that you can grow into? All these kind of conversations are also very important to open up and to also have a meaningful connection in the workplace. I'm very curious to hear your perspective on self-study because I've seen in the comments 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 be, or kind of from a roadmap 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 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 chatGPD 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 made a good step, but 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 make sure that you build stuff. That is the most important part, I would say. Obviously, there is need for people to also engage with content. I myself also am an author at Plural Science, for example, so I'm quite close to this. I get a lot of messages from people who are on such a platform 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 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, 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 out, I think. My take is, yes, you can use it to set up a lot of things for you. I would more use it as a tool for validation rather than something for you to generate things. If you are not able to actually explain what comes out of this model, 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. Of course, then you can say, okay, well, then I have some AI agents who do that for me. But ultimately, there will be a gap of understanding where the model trips up and you are not able to catch it. 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? That's great. But don't focus on getting a polished product out of it and then getting the products there. In the end, it's really a tool that you can use, especially if you're like a taxi driver who's going to learn coding. It's a tool that you can use to build your knowledge. You can also use very much to cheat, of course, and to just sidestep all of this hard work of trying to understand it. But I don't think that will in the long run help you. Yeah. In the end, it's a lot about discipline. 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 it'll say, you have to do this part. And 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 sounds like indeed exactly something that you would want to do at the point. So then fill in the blank, let's say, or take the next step yourself. Absolutely. Thank you so much for coming on. I've had a real blast. Thank you. Cool. We're rounded off here. Thank you so much for listening. We'll see you on the next one.