Hi everyone, we're back. Q&A #12 that's like one for every month of the year, but like smeared out over three years. I can't believe we hit 12. I have so many interesting questions today. Everything from software engineering, that's what we start with, to career and personal development that's going to be in the middle and ending with podcasting and
contact creation, obviously. Obviously my favorites if this episode, if it's a format that you like, if you have more questions throughout the episode, put them in the comments section. I love doing this type of style of episode. The more questions I get, the faster I get them, the more I will be inclined to do another one and I definitely will. That's my promise. So sit back, relax, and enjoy starting with the first one. What is the most underrated skill that makes a great
software engineer? So I feel like especially in recent episodes, we've talked about everything that is non-technical, which I think is very valuable communication, things like curiosity. But I feel like those will do you well in a lot of fields. So not just software engineering. I definitely think they're a must to be a great software engineer, especially a senior.
But when it comes to skills and then looking more at the hard skills, one of the first things that comes to mind is mastering your tool set. So your IDE, everything from how you deliver code into your version control system, GitHub usually, likely everything having to do with that needs to be smooth, optimal, efficient, effective, everything.
When it comes to your IDE and how you manage code and how you manipulate code, I would all put that under like I would say hard skills, but those are very teachable. Those are very learnable. So if you master those, then you can be very effective and efficient with what you do.
Then when it comes to what you do, disregarding communication, disregarding solving the right problems, let's say for me, what I've seen really good software engineers do is balancing out what needs to be done now versus what needs to be learned later. And there's a lot of subjectivity in there. My mindset is keep things simple, keep things more so manageable from the eye of the reader rather than from the eye of the writer specifically, because that's what most code is
going to be there for. It's going to be read by other people, it's going to be scaled, it's going to be built on top of, it's going to be a refactor. It's going to be migrated, might even be transferred to another team with regards to knowledge and ownership, which means that what you write, writing is really easy. Reading and understanding is going to be the hardest. So optimize for that and optimize for now and don't optimize for the future.
Not even too much. Just don't optimize for the future. Honestly, if that's like the the backbone of how you create software and how you incrementally improve, I think you'll be good. Yeah. How do you stay relevant in tech when everything is changing so fast? Even with on a day-to-day level not doing software engineering, I think I'm still relevant in the end. The reason why I say that is not just because I do podcasts. I talk to a lot of people. I read stuff online.
I think those are all good with regards to content and awareness, but I experiment. Not too much of my personal time, but I am in an environment in an organization where I get time from the organization to do that, which is incredibly nice. Like as a secondary benefit is definitely I would put that under the main benefits. If you get time to experiment, if you have stuff like innovation days, hackathons, if you can go to a conference. I went to a conference overseas.
I learned a lot, met a lot of people, did hands on workshops. It's a lot of fun. You get to interact with people, you get to learn from their perspective and you get to experiment and try things out. I downloaded DeepSeek on my laptop. I don't know what it does under the hood but probably safe. I did it with open LLM. I tried to extract information from APDF using that.
Specifically I figured out what the insurance and outs are, what the Gen. AI and what the new stuff is and what actually still is. Software engineering. Because especially with AI, you can draw a lot of comparisons to what you've done in the past if you know how search works and keyword ranking versus categorization, meta chunks and description, if you have a search term. And that then anchors into a certain weight, which means certain product pops up. Yeah, a rag and embeddings kind
of similar. Like it's, it's something that we've seen before, something that we could still include in software. So then the AI part is quite small. It's still software engineering. Keep up to date, experiment and have fun. To be honest. That's how you keep up to date. OK, As a small asterisk on that last one, choosing what to stay relevant on and consciously saying I'm not going to be relevant in this field or I'm not going to keep up to date with this field is completely fine.
All right? I've done front end development for like 2 years. I've mainly done back end for the last few years. I've done product management for the last year and front end things are moving incredibly fast. I cannot keep up to date with front end and back end in cloud and AI specifically, but I keep up to date with what I need to do to create software and put it to production. Basically that's like my core.
And then within that I can focus and go deep when it needs to, when I when it goes into back end and front end technologies. But that's my core. Like I don't keep track of what development has happened in Kubernetes and it's not because I'm not interested, it's just not my core. I can't be up to date with everything. So also learn how to let go and focus on what you want to focus on, where your interest is, and where your curiosity drivers are. What is the biggest mistake
junior developers make? Biggest mistake is I think trying to solve everything in isolation. And for me it makes a lot of sense. If I always had a question as a kid, I would go up to my parents or whomever and they'll be like, OK, this is where you can find it. And then you can figure it out yourself. Because most of the time, especially in your early of age, that's how you learn, right? That's how information anchors, that's what they told me.
I don't know if I believe that, don't quote me on that. Maybe I should check out some studies before I say that. But in any case, I do recognize that when you get an answer versus when you do the research yourself, it might stick with you longer. Now when you're executing, when you're part of a team, you might get a story. You might pick up that story and start executing.
But the way people execute, I think many years ago versus at least what I expect of juniors or anyone within my team nowadays is when you're stuck, when you have an even a question that doesn't make sense where you're like, maybe I shouldn't ask this, just ask it to be honest. Because we are all in one team. Our goal is to execute and deliver. And if some part of that with regards to a story gets hung because you want to try and figure it out yourself, it's not a bad thing.
But time is of the essence most of the time. And I think you can learn faster by asking those questions. And then we guide you along the processes, the learnings, the experiences. I personally learn the fastest from the experience of others. So I almost always ask and hopefully people don't think I'm annoying. I try not to do it in an annoying way. So especially when people ask me, I always have the patience to explain it and I'll explain it a million times until it
clicks. Because if those people are already part of my team, we've already accepted that these are people we're going to be working in working with for a long time. These are people we believe in. Which means it's also my job as as an educator to educate people and put in the time that it takes. So ask when you're stuck, reach out for help and execute together.
I think as a junior engineer, you'll grow the fastest and it'll be the most fun to be honest because you don't feel isolated, you'll have less of an imposter syndrome in the 1st place, and you'll have fun with peers. That's the best. What is the best programming advice you've ever received? Programming advice. I mean, I wouldn't say it's advice. It's more so experience that always stuck with me.
I think I I might have shared this before, but my experience mainly lies in I come into a product or a project or an organization and what I'm building, building software on what I'm developing in features is a product that's already live. I don't have a lot of experience going from zero when there's absolutely nothing to something that needs to go live, but that is a completely different skill.
Having something building on top of it and executing, making things more effective, making things more scalable, more resilient towards the future is different than starting from scratch, delivering as fast as possible something that goes live to then be developed further and further and further.
Now, what always stuck with me is from the surface level, from what I've seen with other people, from what I've heard in the industry, when there's a decision that is going to be the core of your application, think architecture, think cloud, think software language, think database, even those are going to be the core of your software going forward. Those are not things to change easily is what I thought. Now, some things were already decided.
We came into an organization architecture, cloud environment, was there programming language, Go love it, not going to question it. That's what I'm there to execute effectively in. Now when it comes to database micro services versus monolith, those are things we did have a say in. Those are things we decided as a team. Now, my natural instinct was to be pros and cons list, like axe them out together.
And sometimes, especially when it comes to databases, you can have many databases back and forth and next to each other. I spoke to a really good colleague of mine. He said we don't do that. There's only a few options. All right, we're on Google Cloud, we're a small team, managed services. Basically it's going to be Firestore or Spanner. All right, document structure, fine. We don't know what our structure is going to be to already make relational tables basically.
So that's why we choose Firestore specifically that. And then I was like, OK, decision made. It's like that's quick, all right, implementation very quickly done, especially in Go we go. Then we run into some issues specifically with Firestore, specifically with our environment. This was in IoT hitting a lot of records, sometimes on the same entities in Firestore specifically same documents. So we had some issues with regards to Firestore.
Now we can push and we can try and make Firestore work or we're like OK, with the knowledge that we have now. This was already a few weeks further. We know at least have a better idea of our data model.
We can structure these things in a relational model just by virtue of having gone through this, having thought out what the data looks like, actually having built it, to be honest, and put some stuff in Firestore. It's not like we implemented Firestore and then immediately steered away from it. No, we tried to make it work, doesn't work. All right, same colleague goes, it doesn't work. We'll do a proof of concept with Spanner, the other managed service. All right, let's go.
And within a day, the implementation was rewritten. We weren't at a stage where there was a lot of code hitting the database yet, which is great because we could swap it out within a day and it worked very smoothly. And that is still what they use. Like this is a year and a half ago. I know people still on the project, they still use that. They're quite happy with it. They haven't hit any limitations.
It's skills basically. That decision was made in my head reflecting back now, especially because I mean, time is a, is a factor here, but it was like so simple, no pros and cons list. All right, These are the requirements. These are kind of our constraints in the amount of people that we have. We cannot have a lot of cost of ownership going to infrastructure because that means we can't execute on a software level. So then these are the decisions,
these are the factors. And because of XY and Z, we picked this no pros and cons list. I was like, man, I like that. I think I will always take that experience with me and use that in other factors. Does it matter the decision that we're making or should we decide based on the constraints and based on the knowledge and then be flexible when it comes to it's not working anymore? Obviously commit and try or some people disagree, but I want the I need the commitment within a team.
Then we execute and we reflect. If it works, it works great. If it doesn't work, we pivot. We do a proof of concept with something else and then we scale. Basically, if it works, I will always have that knowledge and experience with me and I'll take that to the future and educate
others. I feel like the kind of default mindset that I had with the pros and cons list, Like it makes sense if this decision cannot be irreversible, but the way you structure and the way you go about creating software, just by virtue of having the mindset that decisions can be reversible, I think it's great. Keep your software in a flexible state. Make sure that what you're building is flexible enough to be swapped out. Some stuff is harder to swap out and you don't have to do that
for everything. But when it comes to certain decisions, always be mindful of that. That I think is the best experience that especially recently that I've had. How do you choose the right tech stack for a new project? Me personally, I choose the tech stack that I'm most effective with, that I'm most efficient with. Why? Because usually I'm trying to go towards a certain outcome. For me, I mean, disregarding learning.
But if I want to achieve a certain goal, I want to be efficient and effective with it. So I choose some tech stack that I'm familiar with. It's a means to an end. If it's not a means to an end anymore and I'm trying to experiment, then choose whatever you like, right? Learn from the experience and that can be then the goal. Because if the goal is learning, then do new stuff basically.
But when it comes to executing for me, for at least the use cases that I have in mind, the tool set that I'm familiar with, that I'm comfortable with, it's already good enough. I'll make sure that everything runs on my laptop. I'll use Go as a programming language. I can use React on the front end or not even. I can use Go HTML templates and then do some CSS magic and it
works, is great. Actually, I've ran a product in production like that and it's still using that three years, yeah, three years later, which is ridiculous. And they're making a lot of money. So really good tech stack. Basically, depending on if I want to do stuff with infrastructure, I will use the cloud because I think I can get stuff up and running, get really quickly to customers, test my assumptions the fastest. When I use managed services on the cloud, it's not going to be
the most cost effective. I'm not going to look at costs specifically. I want to validate assumptions because the longer I spent engineering, I feel like that's going to be the sunken cost that I don't want to spend. Basically time is of the essence and I want to deliver quickly and I want to test assumptions. The best in production life with real users. So the fastest path to get there I will choose. And I think that currently still
is the cloud. Now I'll also use AI nowadays because I've done some programming recently with AI. It's getting better and better, especially if you're going in and out of doing hands on work, using it as a tutor, using it as an educator, using it from previous experience and seeing where it's apartment and being effective with that is incredibly valuable. So that for me is all to boost and contribute speed. So then I have go. Maybe React could be. I've heard a lot of good front
end frameworks nowadays. I used to love you to be honest, but I don't even need a front end framework anymore. I can go HTML and CSS like I mentioned, definitely maybe ACSS framework, but then I've done Tailwind, I've done Tachyons which is a long, long time. I've done Boomer which was quite fun as well. I feel more effective in that specifically and then some piece of infrastructure to deploy it on. Likely going to be Google Cloud because I haven't done too much with AWS.
I've done some stuff with Microsoft Azure, but Google Cloud is like bread and butter. So that's my go to now. I've structured these to be career related. What is the one thing you wish you knew earlier in your career? That's a funny one. For me, what I remember now from previous experiences is maybe not what we did, definitely not sometimes what technology like the insurance and outs, some features that I built and like the impact that I had. But it's mainly the people that I work with.
So early on, I would more consciously the choose the people I want to work with. And that is both from a person that applies to a company as well as from a person that gets new people in the company. I want to work with people. Let's start with a manager, all right, I want to work with a manager that I believe in that I think I can learn a lot from and then I just have a good bond with. Doesn't even have to be on a personal level.
I mean, yes, I would like to have real conversations with this person basically because I like being myself at work, which means I don't want to have this professional front in front of my manager. I want to like my manager and I want my manager to like me not from a people pleasing aspect, but from a genuine like, I want to be friends with this person. I think you can be the most effective in that way.
And that's where my fondest memories are now, stepping away from managers, the people that you're going to be working with on a hands on basis on a day-to-day basis, the people you're going to be interacting with, what you have in common with them, how they are different from you with regards to diversity, what you can learn from them, not just professionally, but also personally. The most fun I've had were with a team which was very diverse
from a cultural background. I was looking at the lunch table we were sitting at with like 10 people. And I would say different countries people came from. I, I counted and it was like 6 or 7, which was incredible to me. Those people all brought their perspective. And when we were not talking about work, I learned a lot from their food, from their culture, from their hobbies, from their nuances, how they experience the country that we're in, which is the Netherlands with their
lands, from their own country. And from my perspective growing up here, born and raised, I was like, man, everything here is normal. Everything else is like, oh, that's interesting. Or, oh, that's an observation. People pointed out the fact that in winter it gets dark at like 4:30 or five. I was like, what do you mean that's normal? They're like, absolutely not like, man, apparently I was born and raised in the darkness.
They're like, yeah, absolutely. Like those memories, the people that you work with, I would more consciously choose that the people and then what I'm doing kind of as a next thing and then career, maybe even somewhere in between or somewhere there as well. Growth potential. And then I think that is like a recipe for having fun and being successful and going to your job with like a good, good atmosphere. That's incredibly important.
I think, especially early on. Should every developer aim to become a tech lead? Tech lead is like a colloquial term. Some companies have an official position, some people don't really have it, but they have it informal. So it's like having the role without the title for me, tech lead.
And this is like from training I went to with Patrick Qua and some of the research, the resources I looked at online is a combination of a mix of architecture, a mix of like stakeholder management, people related stuff and then hands on software development. That's like the trifecta of responsibilities. And I would say they're evenly distributed now. Nowadays really good software engineers do that without having the title in the 1st place.
But then I'm talking about do you want to grow with regards to depth in software, You don't have to have as much stakeholder management. You can be really good at architecture and software. I would always keep those close together. People that are architects that don't do the hands on stuff for me, I haven't seen people that
are effective. They will always, really good architects will always do the organizational business development side of things and stakeholder management and people aspects if they don't do hands on stuff anymore. Otherwise really good architects will always also do software, which means from my perspective they're just really good software engineers because I think architecture nowadays should not be a stand alone role anymore.
Now obviously bigger organizations, especially in certain like insurance and government and banks definitely still have that position and sometimes you feel the pain. Now, disregarding that, I don't think every developer should. Aim for those responsibilities necessarily. So disregarding tech lead when it comes to stakeholder management, architect and really good software engineering. You can do whatever you want. You are like the person that's in the driver's seat for your own career.
I would say go where your curiosity like leads you. If you love cloud and figuring out infrastructure for your software to deploy on and run on and scale on, do that. Really good software engineers that also do cloud incredibly good. Really good software engineers that know the nuances of when to use cloud and how to get stuff running on bare metal. Incredibly valuable security.
Huge, huge topic. That is one of the aspects where I would say a specialist and a person that does security from outside of a hands on role. Like for some reason I equate those differently from architects. I feel like security's ever evolving with new ways people figure out software with new, even with AI and AI ethics nowadays, and how to accommodate for that from a security
standpoint. It is a field in in and of it's own in my opinion, but the aspects of security are always relevant when it comes to creating software. If that for you is fascinating, see how you can combine the two. See how you can do that in isolation if you want. See how you can do that in combination with cloud, Because that in and of it's own is a super interesting field as well. See how you can do that outside of cloud? Very very good and still incredibly valuable for
organizations in the end. Doesn't matter, right? From my ersonal career position, I really like the people aspect of things. I think I've become better and better at communicating still with these episodes and with podcasts specifically, I think I still am growing when it comes to how I communicate what I'm saying. Is it too much or too little context? Am I losing people or am I getting the right buy in that I need? Am I using the right words for the right people, for the right cultures?
Even like in and of its own? I constantly can tweak that and I constantly can improve that, and I can even use that as a position for future career path, which might even be outside of software engineering. Not every engineer needs to be a tech lead. There are many opportunities and hopefully you're in an environment where you can grow the direction you want to grow in. So that for me is the most important. How do you handle imposter syndrome as a developer?
I think imposter syndrome is something that will always be there. If you don't have imposter syndrome, it means you're confident in what you do, right? Because for me, imposter syndrome is, especially if I equate it a long, long time ago in my career in this organization. They always told me because I worked with people from this organization before, you need to have five years of working experience as a software
engineer. I got in the organization and I did not have that five years of experience. I had just one and somehow I landed the job and everyone was way smarter than me and everyone was executing on a level and effectiveness that I wanted to be at, but I just was not. And then I was like, what am I doing here? Like I don't belong here. ID I got in sheer luck. Now, somewhere in the back of my head that is still true.
Even when I talked to even the same people that I worked with many, many years ago and they appreciate me being here and in my head somewhere there, it's still there. I definitely think luck is is a factor, but still I got in. I feel like in every environment where you have people around you that are really good that are way better at maybe even all aspects than you from your perspective, you will feel
impostor syndrome. If this is not the environment you're in, that means you are not learning from your peers anymore I feel like. And the way you grow is by learning from whatever you can do yourself. But for me, I've always learned by having really good people around me, basically, which means that naturally equates for me with impulsive syndrome. So if there's no way around it, it's like a a job to accept it, except that it happens, it's fine that it does. What can I learn?
How can I grow? Do I want to grow there? Do I want to grow there? Do I accept that I'm not as good as that, which means I'm going to rely on my colleague for XY and Z, that all is fine. You can't be the best at everything, which means naturally you'll feel insecure with some of the stuff that you do, especially in tech. There is a lot of fun in picking up new technologies, but new
technologies means learning. And the skill of learning is like the biggest thing you can hone as a software engineer. If you're good at learning, you can do anything, to be honest. All right, some stuff might take longer for you to learn, but having the confidence and the ability to learn and then execute, that's like the biggest skill you're going to have, which means that you can overcome imposter syndrome
yourself. And if you feel that, and if you believe that you can do it, so then just do it. It's might sound hard in theory and I definitely still have the feeling of, man, I'm not as good as I, I should be or I'm not. I don't belong here. But then again, I don't let that hold me back. And I just execute and I rely on the feedback from others and then just go, basically just go and then see why you end up. How do you know when it's time to leave a job? This is a funny one.
I think it's funny because it's very subjective. Different stages in life lead you to make different decisions, right? I don't have any kids and I have many responsibilities. I don't own a house, I rent. I want to own a house, but I don't, which means that I don't have many, many responsibilities. I can be without a job for a little while and I'll be fine.
So what I look for in a job is growth opportunities, is career opportunities, opportunities to have fun, to execute with colleagues and learn a whole damn lot and for stuff to contribute towards my career for the long term. That is like the essence of what I look for in a job.
When that goes, when the essence is no longer there, when I don't have that feeling of impostor syndrome anymore because I feel like my colleagues around me are not as good as what I want to be good at specifically, then can I grow like the fastest that I want to like, do I do justice to myself by being there? I don't know. And when those answers go from I, I know I want to be here. I feel good about being here. I can learn so much while being here.
I'm having so much fun to an I don't know how much I can learn here. I don't see any career opportunities. I don't feel fulfilled when I talk to people or when there's an end of year performance review and you get your next salary and you're like, man, it doesn't really do a lot to me. Those things when those pile up, then it's the start of you need to leave to probably you will leave basically if it doesn't turn around in that way.
Now, it's different if you have kids, if you own a house, if you have many other things going on in life. Specifically. I believe that your work should contribute to your life. Your life should not contribute to your work. The goal is not to work. The goal is to live and you work and you make finance, you make money to live, basically to live your life. Do you want to go on a sabbatical? Do you want to travel to Japan? I do, and I try and do that
while working, basically. But if you have to make those choices specifically and you cannot for whatever you have kids or you have other commitments, then it's fine. You don't have to focus on your career. You don't have to focus on growing as fast as possible. The sense of urgency does not need to be with everyone.
If you're happy with where you are, if you are confident in your executing skills, if you maybe cannot learn from your peers, but you have joy in educating others, even though educating others still means you're growing yourself because you can become better at communicating and your fundamentals become a better core. Disregarding all that, which is true, you can still be in the same position. You don't have to leave. Ultimately it's going to be your choice, right?
You might not be able to financially afford leaving. Maybe you're in a really good job. Maybe you grew really really fast and now you have a really good salary and in other companies you just won't earn the same completely. Fine, stay, have fun. I think it is a shame if you lose kind of the passion for your job as you, if you lose the passion for what you're doing on a day-to-day, if you become like a shell and a former version of yourself. I think that's a shame.
It's harsh to say that I've seen that in people, but I would say people are close to at least some people that I've seen are are close to being that and they don't really enjoy their job and they're there only for the money. Even though I think that's completely fine because that's the relationship sometimes you have with an employer. I do think it's a shame. So I hope that when you're fine with your job and you don't want to grow super, super fast, you still have a lot of fun in your job.
And if not and you don't want to leave, hopefully you can find the fun, right? Maybe you can grow towards a different position. Maybe you can kick start something, a new proposition, maybe a new initiative within the field. Maybe one of my colleagues said, hey, everyone loves remote working. We can't all do it or afford it. Let's bundle together the efforts of a group of people. Let's go somewhere abroad. We'll do like surfing in the weekends and then working during
the week. That sounds amazing. That sounds like so much fun. That's what I want. Like even when I'm not growing the fastest, those types of initiatives, if it's not coming to me, I would love to like initiate them and still have fun because I think our job should also have fun. Like you want to have fun in life. You work probably a big chunk of your day, basically your time investment. So for me, that should also be fun. So let's figure out how to make it fun.
What are the best habits for long term success in tech? Best habit that I recommend? It's like for anything long term success is drink water, drink a lot of water, drink a lot, a lot of water and exercise. But that's basically to be a really good version of yourself in your job. I feel like you need to be feel good with what you're doing.
I feel like you need to be healthy with what you eat and how you live your lifestyle and then you'll be successful in your career because it's just easier to be honest. At least that's my my life model. Otherwise, a lot of habits is, and I don't really have a lot of habits, to be honest. I talk to a lot of people. I try and be flexible with regards to my reasoning with the rest of my thinking. What I say now is not going to be set in stone. A year from now, I might change
my mind. I use the conversations as well as my own experience to have perspective. I try and have empathy with other people, which means I'm trying to see it from their perspective when it comes to whatever they're dealing with, right? Incentive structures are a thing. There's a lot of research on that. Why are people behaving the way they are behaving and how can I not necessarily make use of that? But how can I navigate that, right?
Everyone has their own goal. Could be a team goal, could be an organizational goal, could be a personal goal. It's the best if they all align and they're trying to achieve that. And for you to navigate that, being aware of that, for me, that's been incredibly valuable.
Maybe it's because of the role that I'm in now in product where I'm interacting with more people, but being flexible don't Not necessarily thinking in in black and white terms, seeing things from the other perspective, experimenting, learning from failure. Also advocating and educating others, trying to improve your communication skills, trying to learn whatever you need to learn specifically and then also having a healthy lifestyle. I think it builds resilience.
I think it in on the long term. You will build success, build relationships. Don't burn them. Like actually spend the time, even though time sometimes might be very, very tough, spend time to learn and get to know people because these are people that you're going to be working with. It's very hard to work together with only from this professional
aspect, right? I, if I cannot have a real conversation with you, you might think I'm rude, you might think I'm negative because I will be incredibly critical. That's how I am at my job. But people that know me on a personal level, people that have seen me on this podcast don't see me as this negative critical asshole that some people have perceived me because we don't know each other, right? And maybe that is like a version of myself, sure.
But because people see this multifaceted version of myself, they don't think that's the only me, which means we can always collaborate. There's always a conversation to be had. And that, I don't know if I would call it a habit, but you build that, you build those relationships. If you do that continuously, you'll be successful at your job. It'll build bridges for the future.
Because those people that you're going to be working with, if they really want to work with you and they go to different organizations, they still will remember having worked with you. They don't remember what features they built. They don't remember. Maybe they'll remember the ups and downs, but definitely not necessarily the nuances.
If overall they had a really good experience working with you, they see you as a friend and not just a colleague to get stuff done, then that's really good. And that's going to build the the future foundation, the bridges for you and it's going to open doors. So yeah, I don't know if that I would call that habits. It's like a way of working, an approach, a mindset. Lastly, in the career related things, it's going to be AI related of course. How should developers prepare
for an AI driven future? AI driven future, I think I mentioned this briefly, right? With experimenting and at least my experience with AI, trying to put some use cases that I have in my head in an application and in production, I've realized that the AI part right now in software is still very, very
small. We're trying to figure out with software how we can then leverage AI to have better customer experiences, to have more productive people, to have a better journey or execute things in a way we couldn't really do before, or it was harder to do before, or it's just more accurate before, right? Everything is a little add on on with a whole lot of knowledge of software doing a lot more basically.
So the lessons that you've learned from your experience as a software engineer are going to be crucial here. How you keep up to date is the same as always, right? Experiment, learn, figure things out, play around with things, get an understanding, trying to relate with previous experiences or previous kind of bundles of knowledge that you've gained and things will be the same. It will still be software engineering when it comes to the output of AI and and what it
actually does in coding. Sure, it's going to resolve a few issues. It's going to solve more and more issues. Our role might evolve in and of it's own. I don't know how that's how long it's going to take, to be honest. I have no clue. But the nuance there and the most crucial point is that our role will evolve. And if the role has evolved, whatever new people come in, in juniors, will the junior in that evolved role, like it's just a natural migration of the skills that you have.
When it was like the industrial revolution and things were being automated on an industry level, people not doing stuff by hands, but it was machines actually in creating projects or products. It wasn't like the world was gone and no one had a job anymore. Now people migrated, people moved, people all of a sudden became like the maintainer of whatever machine was there, I'm assuming because I wasn't there. But I feel like a role will evolve similarly.
Maybe it's not going to be an abundant kind of landscape of software engineers anymore. Maybe we only need a few software engineers and then more people on security or more people on infrastructure. I have no clue. All right, But this landscape will evolve. It is evolving. It's evolving quite quickly on some aspects, and it's evolving quite slowly on other aspects. Stay up to date, keep experimenting, see where your
curiosity kind of leads you. And there will always be opportunities for people that are looking for opportunities, right? If you're not looking for them, they're not going to present themselves to you unless it's like magic, all right, But I don't believe in magic, which means if you want to be in control of your own destiny, if you want to look for opportunities, they will present themselves to you. So if you want to evolve, you
can. That's what I truly believe in related to podcasting and content creation. How do you come up with a great podcast episode ideas? This is a really funny one because this not just by comments and chats is 1. I get the most probably in real life, and especially since it has been close to four years now that I've been podcasting and people like, man, 200 episodes. Don't you have like aren't you out of ideas and like things are
simple? I think I've explained this in probably like the first or the second Q&A. How I used to do things is I would have one list of all topics and then I would look at the topic and I would find the best person to cover that topic with. Now I don't do that anymore. That is gone and I might need to bring it back because it did have some benefits here and
there. But now I try and find people that are interesting, people that other people recommend because I love having a really good conversation with a person and they're like super excited about another. I'm like, man, that's like a win win basically. So from a relationship side or from just a surface level, what I see, what I hear about people, what I might have seen on a conference, I try and build those bridges and that's where I
get people that are interesting. Now with those people, I have a one-on-one intro call, which is non negotiable and we distill a common passion and it is quite simple because I ask what are you really passionate about? They give me a few things. I'm like, man, I love this, I love that. And usually I love the whole bundle and then I'm like, we have to be selective there. We distill the main topic and that's it. It's quite simple.
My topics are endless as long as there are endless amounts of interesting people. The only hardest part that I have also no longer a compromise on is it has to be in person. I've done remote episodes. It's just not the same, especially when I used to edit those episodes. Any sound issues, any during the mic I hear myself issues, Any issues with regards to synchronizing and the recording, All issues I don't want to have any more.
That's just I tried it. It's done too much effort, too much energy, which is a real shame. But I'm still having amazing conversations with amazing people. So even though I'm limiting myself to the Netherlands, and Netherlands is incredibly tiny, they're still amazing people to have conversations with. And it's really fun to have a conversation with a person year and a half ago, invite them on again to have another conversation and see how it's been.
I talked to a person, Andre, Andre Berganovo, going to record an episode probably somewhere in March. All right, today is early February. I spoke to him three, 3 1/2 years ago. He's joined a different organization. He looks different. I was like looking great. How's it been? And we had an amazing conversation and we're going to record probably an incredibly fun episode again. And I'm really excited about
that. So topics are infinite as long as interesting people are infinite, which I believe they are. What is the hardest part of running a podcast now? Hardest part of running a podcast Starting. Starting is always the hardest, but maybe that's me personally. If I were to not have had help starting, it'd be more I would have never started to be honest. Like reflecting now the amount of help I got with regards to OK podcast. This, these are the things I want. We need a guest, we need
recording. It is so much like even I, I go through this list and even though I know exactly what I need now, back then there were many, many unknowns and those unknowns would paralyze me from starting. I still have that with starting. I think it's because I believe that when I do something, I want to do it incredibly well.
And to get to that level, to do myself justice, I need to start basically, and I need to learn and I can't get to a level where I want to be, which means I actually don't do it. And I feel like a lot of people are stuck there. For me, starting was always the hardest. Now throughout starting and throughout doing this and putting these constraints on myself, English, all right, always a person, kind of a one-on-one conversation, no
editing. Basically, I always want to record, not necessarily record, but air weekly puts a constraint on the frequency, puts a constraint on finding people having a location to do so. Right now I'm incredibly lucky. I've been in this location for like three, 3 1/2 years. Like this is super easy. The location didn't have to be, could have been way worse, could have been a microphone by myself at home, echoing audio, all those issues.
I don't have that. Everything has become so resilient that right now it's easy. The start was the hardest, and then improving and experimenting and still having the conversations was the most fun. That's why I still do it. That's still there. Like the essence, the fun, everything is still there, man. I'm incredibly lucky. I feel incredibly lucky to have had help of starting and getting through the hardest part now. If I can help and offer advice on anything, it's fine people
that will do this with you. It's fine people that will give you advice. I have a blueprint of what it takes to do a podcast. I needed it because I needed people to edit because I couldn't do it personal time wise anymore. I was going insane. All right, No free time, no free time whatsoever. All right, My partner's saying I don't see you, basically, which really sunk and hit me to my core. I needed to make a change. I made this overview. This is what it takes. These are the aspects I need
help with. These are the aspects I'm not going to give away. All right, that's me. That's the core, that's the podcast basically, and that's it. Like this blueprint would have really been helpful. I think if I would have seen a blueprint on how to start a podcast would have been easier to start. I still wouldn't have started. I needed people to help me and and move through this.
I think with this experience, I can do this myself now, but it requires discipline, requires effort, and I'm still not good at it. I will never be good at it. All right? But I can do it now. I feel like the confidence. So yeah, the hardest part is to start. Last, last question. What is the biggest lesson you've learned from doing this
podcast? Biggest lesson I've learned might be something I've kind of hinted at, but for me, the lesson that I've learned is that communication is this life skill that's never going to go away. Any effort that you can put into becoming a better communicator by virtue of doing a podcast, by virtue of standing on stage and telling a story, by virtue of doing many presentations and becoming really good at it, by virtue of writing, because by writing you also become a better
communicator. It's just a different medium. Basically, by virtue of creating videos, you become a better communicator, better storyteller. We'll always pay dividends, no matter in what situation, whether you're in a family situation, whether you're in a professional situation. What do you have an issue with the waiter? All right, The way you communicate, the way you conduct yourself, everything you can improve about your communication is a life skill.
And that will never go away. Sure, all right, It might fade. It might get worse over time. If I stopped doing podcasts, I'm probably not good at podcasting anymore in 20 years. But in any case, the things I learned with regards to communicating will always stick with me and they are incredibly valuable. All right for me. And it's it's definitely also hitting home with many conversations that I've had. Rallying people around A certain idea is a skill in and of its own, all right?
Your idea might be absolute Doo Doo. Absolute dog shit. Basically, if you can rally people around your idea, people believe in it. People figure out a strategy to go there and to get to that vision that you've pointed and painted that picture for them. That is the skill. That is the art, all right? The vision is not the core. It's how you build people around
it and rally people. That is an in essence is storytelling, communicating, figuring out what they want to hear and actually communicating that. That sounds a bit manipulative, but I don't mean it in that aspect necessarily. But yeah, that is all the art of communication. So all effort that you can put into becoming a better communicator will pay dividends in every facet in life. That for me has been the biggest learning and the biggest take away of this podcast.
Biggest blessing also, I must say, because it wasn't a conscious choice to work on communication by doing this podcast. It was a by product and I'm very happy with it. I think that's it. All right, we're going to round it off there. Thank you so much for listening. So, so much for listening. I really enjoyed these episodes. I love the questions, man. It seems very self-centered when I say this, but honestly this is
like one of my most. But honestly, this is like one of my favorite topics, one of my favorite, but honestly this is like, I can't do this. But honestly, this is like one of my favorite formats to engage based on questions, your questions, more questions that I find online, questions from the comments. All right, if you have questions for the next episodes, if this content was thought provoking for you, if you have a subsequent question, put them in
the comments below. All right, give me a question of the episode. I will handle all of them. I will collate them and we'll do another Q&A If you love Q and as give me more questions in the comments because the more questions I have, the faster I will do another Q&A because I love doing these and I want to do many, many more. So thank you again for listening. We'll see you on the next one.