Career Advice I'd Give Every Software Engineer Right Now

Creating code has become incredibly easy. You ask something to a magical box and the output is code. Engineering has not become easier. Creating code has become easier. So yes, we can engineer more, but engineering is still the same challenge. What you know necessarily is not as valuable as it used to be because you can look up so much more. It is easily accessible knowledge nowadays.

So also how you behave and how you look up is a lot more valuable than it used to be. Do you stay for the financial aspect regardless of the toxicity that you experience or do you remove yourself from that position, therefore giving away the gold but taking off the handcuffs? You have to decide. I have to do the things that give me the most energy, otherwise it is not going to be sustainable if I don't enjoy it anymore. The whole thing like a House of Cards, just it crumbles.

Yes, Q&A time, I have my questions. Let's do this now. How should one navigate a

corporate environment that is resistant to adopting new technologies or insisting on sticking strictly to legacy slash mainstream stacks? Yeah, this is really hard, right? Because you want to innovate as part of a bigger organization. But in essence, innovation might not be what the big organization needs.

They might need stability and they might need reliability, and typically with stuff that they already have in production, which can still be legacy or kind of proven technologies is the safe option for an organization. So if you want to experiment, where do you go?

Typically those big organizations, they have experimentation departments where you can experiment with new technologies and once you have shown results compared to older technologies or what the new technology offers, then you might be able to roll it out throughout the organization. In essence, when something new pops up like CHA, GBT or Claude Code, for example, there are people that are trailblazing. So how can you be one of those people?

Typically they are the people that are more senior, sometimes even staff, and that are in departments that are responsible for that. I don't feel like if you are in a product team and responsible for delivery, you might not get much room for experimentation for new tooling. So if you're not in that department specifically, find them, find the people that are doing that and learn from them or join them. That's one that is with specifically the example of Gen. AI for example.

But when it comes to moving from Java to Kotlin, or from Java to Go or from Kotlin to Go, it can be that in the end you have to agree to disagree where you think something is better but the organization doesn't agree. And then either you stay in the organization or you find yourself a start up where experimentation is just goes a little bit more hand in hand with the culture and you can afford to take more risk because taking risk also comes with big rewards.

And some bigger organizations, they do not have to take the risk, so they don't take it. It really depends on what environment you are in. So it can be really frustrating if you want to work with a specific technology and you're not allowed in the organization, so you have to make a choice. Is the frustration for you big enough to look outwards or can you actually work with those newer technologies in hackathon days that you get or outside of your work in the personal

projects that you can build? It really depends on your context, but you have to make a decision in the end. If the organization does not move and you have tried, you've talked to people, you understand the organization, you understand how this might have benefits, but you cannot get the organization to move, then you have to decide. I will say with AI tooling nowadays, it is much more possible to modernize from certain technologies. So you can also play the cost route.

If you're saying this legacy Oracle infrastructure that we have, yes, we are quite dependent on it. But have you looked at the licensing costs and we can modernize and I've shown in a little small proof of concept that through this tooling we can modernize to an existing language that we already have. Can we actually do this? Because in the end, you have a business case and people when it comes to money, all of a sudden they listen.

So the cost saving aspect for modernizing might be the route to go. If it is literally one language to another and there is no business case, there is no cost savings, then that's a very hard 1. So think of what your use case is before having those conversations. See if there is an angle and if there is not, make a decision. How can I build mental resilience and avoid internalizing negativity when

working in a toxic team environment or with a toxic manager? Toxic relationships at work? I mean in essence, what do you do when you have a toxic friend? You can only go so far in dealing with toxic behaviour. People end friendships if people are toxic. People end friendships for much less than toxicity. So if you find yourself in an organization like that, but the organization has a lot of benefits which means you want to stay regardless of the toxic behaviour, Find something that

works for you. If your work is your whole life, then this can really affect you. If you have many hobbies, you go on holidays, you take time off, you spend time with friends and family, you put your mind out of the work context, then you can probably build up the resilience and it's not going to matter as

much to you. But if you're a person that is very much, they care about their career, they want to grow as fast as possible, and they are encountering a toxic environment, then this is going to be very challenging because it is in the way of what you want to achieve. And I'm very sorry. It is very hard to change toxic

culture, right? I've spoken before on the podcast that me as an individual, if I was in an organization where it was not a meritocracy, people were not promoted based on what they deliver in results, based on their merit, But it is based on how much they preach, how much, how much they promote themselves, how much they basically blow themselves up. I would not be happy because my personal values prevent me from being that person.

And if the only way I can get a promotion is by doing so, I would be unhappy because I would feel like I would show results or I would accomplish certain things and they would not be valued as much as people that show results similar or lesser than and then blow themselves up. So I would need to remove myself from that situation. Or there is also the concept of golden handcuffs.

If you get paid so much that you looking for a job elsewhere where you get paid equal level, it's just not out there, it's non existent, then you have to make a choice, right? But then you cannot be the person that wants to grow as fast as possible within their career. You already earn above and beyond apparently. So then you have golden handcuffs. Do you stay for the financial aspects?

For the benefits? Regardless of the toxicity that you experience, you can definitely put your mind at ease with regards to anything outside of work. Or do you remove yourself from that position, therefore giving away the gold but taking off the handcuffs?

You have to decide, looking back on your journey, what does thinking in systems actually mean in practice and how can I deliberately start applying that in my day-to-day systems thinking? I don't think I do it

deliberately. I think it is a way to solve problems instead of looking at individual components, thinking of the bigger whole, the system and not just looking at the parts of it, but trying to digest the whole thing is something that when you are problem solving, if you did, definitely if you go to root causes and you don't just battle symptoms, I feel like maybe that's the biggest start in the problems that you solve. Are they system?

Are they systematic, which is also quite vague, but are they repeating for example, because then you might be battling symptoms. I can give you an example. The first job I ever had, it was in operations and my team was showing me a routine, something they were doing on a daily basis, and it had to do with order management. Some orders automatically did not get processed. This came from the e-commerce team. We didn't really speak to the e-commerce team.

The order just had issues and the protocol was you go to the order, you manually open the order which was a file, you change some things that allows the order to then be automatically processed again. And me being very young and very naive and very stubborn to be honest, I had the mindset of there is no way in hell that I'm doing this on a day-to-day basis because I feel like this is useless and I'm not learning anything, I'm just doing something and it doesn't make

any sense. Why aren't these orders automatically being processed? So I didn't say that to my colleagues, but I genuinely wanted to understand why these orders were just not automatically processed for me. It seems like seemed like nonsense, so I asked my team members how often does this happen? Well, it happens a few times a week. We just check the the error directory and if it's nothing

there, there's nothing there. So I could have been happy and I could have just solved the issues, which is the orders ending up in an error directory. I would manipulate them manually and I would put them through and then the next day I would do that again. And the next day there might not be an order, but the next day, if there's an order again, I would have to do the same thing. Those are symptoms of an

underlying problem. And my colleagues apparently, and I was a little bit disappointed because this was my first job. They had no problem doing that. And I did. So I learned what the issues were. They were only issues in specific customer data spaces here and there. And with the knowledge that I have, I was like, we should definitely be able to prevent this from a data entry perspective. So I went to the e-commerce team. I was also new, so I introduced

myself. And I did not think of all of this by myself. By the way, I had a mentor. And I was like, I don't think I can do this. Like this is literally week #2 and I already think this is not something I can see myself doing sustainably. And he was like, I absolutely agree. So let's go to the e-commerce team. Beautiful. I introduced myself. I was like, OK, this is the issue that we have from operations. Who can I speak to that knows a little bit more about this and this and data entry.

And it turns out that the data entry did have the validation I was looking for. So there is no way that new data entry can have the issues that were causing the error orders not actually automatically being processed. But we had old customer information, customer information that was already there in a database before the validation was in place. So it took us a while to figure

that out. And with a while, I mean literally half an hour, and then I asked the person that managed the database can we do a clean up? Because as a result of that we will never have orders ending up in that same error directory or there will be new issues and we will still be able to fix them if we look at root cause problems. So I learned that in the second week of my first job, not fighting symptoms but genuinely figuring out what the problem was.

We fixed it by making a connection with a different team, explaining the issue to the world that I could to the best that I could at the time, by not being afraid of doing something that my colleagues hadn't done before and therefore actually figuring out what the problem was. I also learned a little bit more about the system because we have data entry, then it goes to a database and we also have older account information which can also be used to fill in an

order. Makes sense now that I'm communicating it like this and likely this is something you already knew, but me starting out in E com, I had no clue how e-commerce operated. And then OK, once an order actually gets submitted, it goes to our order management system and before being able to be processed, it's going to go through validation. And if the validation doesn't work, if the validation fails, it ends up in this error directory where my other colleagues were always looking.

Yeah, this is the smallest possible example, and it was the first one that I had in my career. It is the most concrete one because I feel like it was that early. And I'm so happy that I actually did something with it. I will forever remember that. Now, a lot of other examples have probably happened throughout my career. Thinking of what is not just the solution here, but what is the underlying problem and can we solve that? And that for me is systems

thinking. So I don't know what your context is. I don't know what problems you're facing, but try and think big picture. That's my advice. At what point there's a strong engineer or developer become a solutions architect? Is it competency or more of a mindset shift? I feel like it is both. Solution Architects in essence,

I did an episode with Gregor Hope and on the day of recording it's coming out next week. But when you're listening to this, the episode is already out. So definitely check that one out because it is one of the best conversations I have had about software architecture. In essence, you can have a different background while still being or responsible for architecture. You can be a product minded architect, software minded architect, security minded architect, doesn't really

matter. In essence, you do have to know your heart skills. So on enterprise, what does it mean for us to adopt A new system or suite of applications throughout our landscape? And if we have a scala of already existing applications, do we consolidate or do we consciously choose to adopt new systems within this landscape that we have? Those are things that you will be responsible for as an enterprise architect or one of the things I think you can be responsible for.

Let me paraphrase it like that. Now you can think along from a software engineering perspective. Depending on the type of organization you are in, some architects are within teams and some are within an architecture team. So depending on the size of the organization and their appetite for risk, architecture might be

applied differently. In essence, you need both hard skills, so everything with regards to good architecture fundamentals, both in software, but also if you're talking enterprise on an application level and on a, let's say longevity and sustainability level. And beyond that, the soft skills to actually persuade teams and take people along with you, not just technical people, but

especially non-technical people. Those, I feel like that's going to be a recipe for success and how you do that and how you can distinguish bad architecture versus good architecture or the people that are responsible for that. I would highly recommend checking out that episode. As an engineer, how can I improve at communicating architectural slash technical decisions to non-technical

audiences without oversimplifying? The only way to get good at that is to know your audience. Who am I communicating to? non-technical audience is not good enough. So are you talking to the CFO? Because the CFO might want to know about the cost specifically, that is what they're responsible for or how this is going to impact revenue or operations. If you're talking to the CMO, they might want to know, OK, how can we make this marketable or what are opportunities here if

we actually built this? Depends on what you're pitching and it depends on the context. But knowing your audience is, for me, step #1 secondly, get feedback before actually doing the conversation. If you have room for that. You don't have to ask feedback for ACFO or of ACFO or of ACMO, but people that you know in marketing are people that you

know in finance. They can give you feedback because they are also the audience, maybe not at the highest level, but in essence, asking for feedback cannot harm you. And lastly, experience builds. Experience compounds. So the more often you do this, the better you will get at it, especially in how much you drill down the technical concepts and how much in the end you simplify. It is a skill. The really good engineers, they know how to simplify and how

much to simplify. And they don't just use buzzwords and fluff words in simplifying, but they still make it concrete. They still make it land. They know how to communicate it, One, because they've done it enough. But also secondly, I feel like after you've done it, ask for feedback. Did you understand what I said? And that's kind of confrontational and direct. But in essence, did the person understand what you were going for? Or is their opinion that it's too simple and it is still one

opinion. So ask for feedback from a few people and then see what you can change, what you want to change, and what you don't want to compromise on. In the end, you're responsible. So doing your homework, doing it many times, both homework and the picture of the presentation, the simplification, and then asking for feedback, learning and adapting and doing it again continuously.

As someone who would like to take on a more leadership role and wants to progress in their career, what are some of the responsibilities I should take? Interesting if you want to grow in leadership. Leadership is not just a title. So you can show leadership in whatever position you have. Doesn't matter if you are early in career, mid or senior.

In essence, leaders can come from everywhere and I believe that they are the people that somehow magically get people on board. They build relationships and when they are there, things just are smoother. In essence, they are also people that they do not butt heads with people, but they managed to get everything just up and running smoothly. It's also kind of a characteristics of good architects. But in essence, let's say you start within a team, product,

team, right? If I'm responsible for product, one of the things I love telling my team is I want to know what your ambitions are, what do you want to grow? What do you want to achieve within this team? Because me responsible for product, I am better equipped to put you in a position to thrive and to put you in a position to

achieve those things. I do that because I genuinely enjoy it. I'm curious and I think people will be more motivated in how they deliver and what outcomes we are working more towards together. So it's both strategic but also definitely personal because I like helping people. Now, not every product person does that. However, you as person within that team, you can take the initiative.

You can have a conversation with your product person and say this is really what I'm looking for within this project that we're building. I want to grow more towards front and back and any type of hard skill that you have or I want to grow more towards more leadership roles. So if you are starting early in conversations with stakeholders, can I be there observing or can I tag along or can I have a certain level of responsibility within a project that we have,

right? You can do that to your product person. And secondly, you can also do that to your manager, have the same type of conversation with him or her. But in essence, you're in control of your career. So you need to know what you want to do, what you want to grow into. It can't just be I want to be a leader. It has to be somewhere within the organization that you can point at and say this is what I want to do, how do I get there?

Right, I want to be engineering manager, how do I get there? Or in the end, if it's not within the organization, I want to be an enterprise architect, how do I get there? It also is a signal that if you want that and it's not in the organization, your engineering manager damn well if they want to keep you, make sure that they have a conversation with you on what you can do within the organization that has similar

responsibilities. As the title you're aiming for, but all of this is a conversation starter. Then you have to put up your effort. Basically, you have to do it. You have to walk the walk of

leadership. Now, it's not a one thing that you can do, but within your sphere of influence, you probably have people that you think are leaders or are showing some of the leadership qualities and based on that, what you admire, you can see and even have a conversation with them with regards to a learning path for yourself. I had someone in my team, his name is Robert, Dutch guy, Robert Dion. He's not going to listen to this, but I learned so much from this person and I never expected

that. He was not my mentor, but somehow I always went to him with specific questions because I just loved the way he interacted with people. It wasn't even what he knew on a hard scale level, even though that was solid. It was just his charisma and he was super social, very extroverted. He would just talk to people and make people feel at ease. And when you work with Robert, you would just be like, man, things are going to be OK because he's here.

And in essence, he did not do all the work himself. He definitely also delegated and make sure that other people knew what they had to do. But I really just liked his approach. So I stuck to him. I basically asked as many questions to him and he was completely open to that and I learned a lot from his approach, right? One of his mantras was act nice to everyone. OK, show kindness.

It doesn't matter if it's your colleagues or a person that's there to actually clean the toilets, It does not matter. You are kind to everyone. That is one of his fundamentals, one of his base principles, and he builds on top of that. And I could see that, right? The guy is genuinely kind to everyone, and I always admired that. And I feel like I'm not at that level, but I want to be there. So I try and do that daily, basically showing the same type

of kindness. And hopefully people think, OK, Patrick's here, it's going to be all right. I will never know. I can ask for feedback, and I have to believe that. But yeah, imposter syndrome. But in essence, those are some of the leadership qualities I really liked and I wanted to learn from. So that was my approach. Speaking of imposter syndrome, I sometimes experience imposter syndrome.

How can I overcome it and build confidence over time? I also still feel imposter syndrome. I shared this previously. The biggest feeling I had of the imposter syndrome was when I landed a job that I felt like was not for me. Like for some reason they hired me. I don't have no clue how I got here and everyone around me is way better at executing than I am, and I'm just lucky to be here. That was genuinely the feeling I had. And thinking back, I still feel like that genuinely was valid to

be honest. Because one of the things I noticed was I was learning how to swim and people around me were already swimming, serving, diving, doing whatever in the water they could. And I was like, man, like I really have to learn the basics here. But in essence, The funny thing is everyone around me knew that that was the case and that was fine. And they were more than willing to help me learn how to swim, how to do whatever I needed in the water. And this analogy has gotten quite far.

So that really helped because I had the conversations with them. I also said I have, I feel like I have imposter syndrome, especially when these things happen and especially when I work with you, one of the people basically because of XY and Z. And then we deepened that out and then they gave me perspective and it really helped because they showed me that it is OK for me to not know things and it is OK for me to learn. And in the end, we are responsible as a team.

A lot of that has to do with the environment I was in and the way that the people around me approached it. So I feel like I just got lucky in the end. But if you have the feeling of imposter syndrome, reflect. You can be your best person if you reflect on your own behaviour and what made you feel that in a certain way and how can you accommodate for that. But also give yourself some grace like it is OK to not know things. It should not be a culture of you need to know everything

otherwise you're an idiot. That's just not reality. Especially in tech when things evolve so quickly, it is OK to say I don't know and slowly if you say I don't know. More often you will also have the responsibility to figure things out. The more you figure things out, the more you will build up the confidence of, I don't know, but I have the confidence we'll get there. Even if it's not just me, but especially as a team, I have the

confidence that we can do this. That really is valuable. And even though you can still feel imposter syndrome here and there, it never goes away in the essence. But you might be able to manage it differently than right now. It's funny because this reminded me of a conversation I had about consultancy. This is a minor minor segue, but within my friend group some people disagreed with how I view consultancy and they are also consultants themselves.

They said consultants cannot necessarily afford not to know. And I disagree with that because I do believe that saying I don't know really builds and shows character. I would appreciate it if someone says I don't know versus I know because if I found out that's bullshit then it just harms the relationship and the trust I have in a person. Don't lie to my face basically. So if you don't know, tell me. But I also want to see the confidence that you'll be able

to figure it out. So that's what I show in conversations where I genuinely don't know. And if in the end then it's not a good fit, then it's just not a good fit. But that's how I view consultancy. I don't want to seem like the expert of knowing everything. I feel like what you know necessarily is not as valuable as it used to be because you can look up so much more. It is easily accessible

knowledge nowadays. So also how you behave and how you look up is a lot more valuable than it used to be.

In tech, there's so much to learn that I often worry about forgetting things. What are the best ways to learn effectively and retain knowledge long term? I've mentioned this before. I'm practicing this Tetra custom method and I haven't done it for long. But the idea of this is you make notes and you make them in a specific way and in a specific system in which your knowledge will compound. And the idea of this note taking system is that you also build relationships between your notes

and in outcomes. You can have a graph where certain topics that you've taken notes on can interconnect. And because they are your notes and you distill contents and put them in your own words in a note taking system, therefore you might be able to retain knowledge over time. I'm very early in my note taking career. In my note taking system, I was taking notes and they were just

scattered. And then I had a note taking system which was not really a note taking system, but it was just chaos and I wanted some structure in there. And I still have the same feeling of wanting some structure in there and I'm doing my best.

So that with regards to note taking, I feel like the better of a system you have in place the system that works for you, Just try it. It's a lot of trial and error, but if you have something that works for you, retaining knowledge is going to be easier and easier. There is still crucial information that is just better if you retain it. But again, I am of the opinion that knowledge and looking up knowledge is incredibly valuable

as well. Finding gaps though in your knowledge, in what you already know and where there are blind spots can be just as valuable, especially when you're having a conversation. There are very apparent blind spots if you're talking about a very specific topic with someone that is well educated and knows that topic like the back of

their hand. So yeah, definitely also spar with people, reflect afterwards, figure out where you want to bridge the gap in the knowledge that you have and a system might help with that. There is no definitive finite answer of how much should you know versus how much can you learn on the fly or when there is a task at hand. Experience builds and I am just not a person that loves studying for the sake of studying. I like studying when there are outcomes. That's also why I feel like I

struggled at school. Like I finished my bachelor and I genuinely had the mindset of I just need to finish this because I need the piece of paper to get a job. And that might not be nowadays, especially in tech, the most effective career path. It might be the most safe career path when we're talking about risks. But in the end, what you show in results is incredibly valuable. What you show in skills or how you applied those skills is

incredibly valuable. So yeah, knowledge is an accelerator for outcomes I feel like. What mindset or habit has helped you the most in your personal and professional journey? Habits and mindset. I feel like I have the mindset. I'm a pretty chill person.

I don't know how much it comes across In this podcast, people say they like listening to my voice because it's relaxing. I am genuinely quite a chill person. I've had a lot of learnings throughout my childhood, throughout my upbringing with regards to friends and families and things that have happened and people that have passed away and my mom being I'll having cancer twice and going through all of that. It has shaped me and turned me

into the person I am now. And throughout that also probably how specifically my mom raised me. I have this feeling of no matter what happens, it's going to be OK. So when work gets really tough and there are deadlines and I'm feeling pressure, in my head, no matter what happens, I'm going to be OK.

So worst case scenario, I fuck up, what happens, they're going to fire me. It's very hard to fire someone in the Netherlands. So even worst case, if they will fire me, I will have severance and I will have several months to figure out what I want to do with my life and what the next job is going to be. And if I never get another job ever again, there is unemployment benefits that the

Netherlands offers. So no matter what happens, it's going to be OK. I might not like it might not be the best case scenario because yeah, we were talking about worst case, but if it is even a little bit better than the worst case scenario, it is still OK. I feel like with that mindset, I'm never a person that likes to doom think.

I also am very much a person that was raised in a way where if I said I could not do things, yeah, my environment around me would get angry and would say you can do whatever you put your mind to, OK, Don't say you can't do things. You can definitely do things and that require effort. So if you want to do it, put in the effort. Otherwise you can still do it, but you choose not to. It's your decision. You are in control. That's kind of also with that directness and with that vigor

and passion. Yeah, it's kind of how I was raised. That's how it feels like. So I take that with me and it might not be a habit. It's definitely part of core values and a perspective and maybe a mindset, but I feel like that has helped me a lot. In essence, I've covered on this podcast salary negotiations. In essence, no matter what happens, it's going to be OK. You're going to learn. I feel like also, whatever happens, there are learnings to take away from.

You might not understand your learnings now, but maybe as you grow, as time passes by, you will reflect and you will then appreciate maybe the learnings that you did not realise existed earlier, which is also fine. I'm a person that reflects a lot. Not much by myself to be honest, but because I talk to a lot of people, I'm also very open and honest. Maybe sometimes too honest and too open, but that helps a lot with reflection to be honest.

So yeah, maybe not as concrete of an answer as I would have liked to give, but maybe a little bit of insight in how I operate. I also don't like to blame other people or other things, tools, environments, people blaming. I don't like that I take ownership even though if I think the fault is not mine, I take ownership because otherwise it's out of my hand, it's out of my control.

If I take ownership, it means I do feel like I could have changed some things or I could have acted differently. And even if I don't believe that, still, by taking ownership I'm convincing myself that next time there are always options and my behaviour influences all those parts, my environment, my team, the people I interact with. So ownership is a big thing for me as well. I take ownership. I don't like blaming other people. I don't like blaming tools.

I should have done something differently. It's not a tool that goes randomly and does something. I am the operator. I take ownership. I would be curious to know how you would train a software developer starting today who had no technical experience, but lots of product, PM and design experience. There's two parts to this. Because if I were to train a software engineer that has no experience, that is slightly different from the PM slash design experience.

Because with PM responsible for product, you are very much thinking of business outcomes and priorities and why should we work on these things and not on these things. And specifically in the order that is laid out right now, that is really helpful from an engineering perspective. You leverage that experience when you are responsible for delivering as an engineer. Same for design. You are thinking way differently about your end users and what

they think is important. You might have interviews with them. You have definitely researched everything from accessibility to best practices with regards to visual design or whatever. Design design is kind of abstract and has a lot of responsibilities. But somewhere in there you have experience that you can leverage when you are responsible as an engineer for building. If you come from a blank canvas and you don't have anything, then there is still experience that you can leverage.

Your upbringing, your values, how you were raised, the education that you had or the the practice that you've done on personal projects, that's all the experience you bring to the table, they are not worth nothing. You always have something to bring to the table, even though you might not realize it now. Learning good software engineering fundamentals. Funny thing is, it is evolving. With the tools we have now, coding has become much much easier. So that is not where I would

start. Maybe I want you to understand coding, and I definitely want you to be able to read coding. But writing code is not going to be as much of A topic in the education that I foresee. So I want you to be able to read code, digest code. I want you to be able to understand code patterns and certain behaviors, and AI tooling can help with all of that by the way, because it will

be the tutor for you. I feel like hallucinations have gotten to a point where it's negligible and the information that you gain is dense enough and it's going to accelerate you enough in combination with human interaction that you basically have a software engineer on your computer that you can ask questions to. What does this mean or why is it written in this way or I actually have read this. Is this comparable to this or is this something else?

Those are all questions that you don't have to wait when someone is available. You don't have to book a calendar slot, you can ask them as they pop up quite quickly. I wish I had this when I was learning. I asked so many questions to the people around me because first of all because I felt comfortable enough to do so. Second of all, they also wanted me to learn as fast as possible.

That was the environment. But in essence I could have also done that and asked it to whatever AI tooling I'm using. I like my experience but I feel like if I were to grow up now and had to learn software engineering, I would leverage the hell out of that. Ask whatever and if things don't make sense, don't stop thinking. I feel like that's my biggest

take away. You still have to do your own critical thinking and you will be good at pattern recognition and you will be better at strategic thinking the more you do it. But I feel like specifically problem solving skills, pattern recognition will be very helpful in your learning process and you will be able to ask whatever question you have, which is incredibly valuable. Now the coding part, why I don't want that to be as much of A focal point is because right now creating code has become

incredibly easy. You ask something to a magical box and the output is code. And if you look at the total lines of code that are executed in a piece of software right now, a lot of people are creating software that only gets executed once because it's way easier to build something that is custom for your own use case. And sure, there might be products out there, SAS products out in the market, but typically because it is so custom, either they are paywalling you or it's

just not out there. So people are way more often building something custom, executing it once and then throwing it away because they just needed it once. And it's now more easier than ever. Now architecting good software systems is very different, even though we are also moving from vibe coding to vibe engineering. Creating good systems or what does that look like? Those are the fundamentals. I want new people to have everything with regards to system design.

Also starting out small, how to expand, when does it make sense? Those would be, I think the focus points. So no matter if you start with a blank canvas or you have product and design experience, figuring out what good software systems are, how do they operate, looking at your competitors or already environments that you can read on online, read incident reports because those typically give a lot of information. They are very, very dense with learnings can give you a perspective.

And in the end you will have to join a team. You will be responsible for a suite of components and systems and applications and you will be tasked with delivery. I from product, don't really care how you do it, but I do care that you are responsible and that you understand what is running and how it's running and how things kind of are interwoven in the system that we have.

So yeah, some stuff you can learn from, some stuff you can read, definitely theoretical and educational, and a lot of stuff you will have to experience. Have you ever worked with Brazilian developers? What is your opinion on hiring

engineers from Brazil or Latham? Yes, yes, I have Brazilian colleagues. I would even call them my friends. Some of the Brazilian colleagues and friends, we've done podcast episodes and I really enjoyed them actually. Brazilian LATAM people coming from Asia, North America, South America, Europe, they're people. They're all people. We need to connect as humans before we can connect as team mates, colleagues, anything else

like that. And I feel like, yeah, I connect quite quickly with my Brazilian colleagues. It might have to do with the culture, might have to do with the friendliness or the openness, or also them really wanting to connect. Because I mean, if you're outside your home country and you come to a new culture, you just also are very curious and you want to learn. So yeah, it's nothing to do with specifically people coming from abroad, which is connected really well.

I don't have a preference for where you are from. I do see that some cultures just get each other more. Some has to do with hierarchy, some has to do with work culture. That can be a benefit or it can be a curse. So yeah, I like open mindedness. I like open perspectives and that can come from any culture to be honest, can come from any person. So I feel like the more open our perspective is, the more we are open to learnings and learning from each other and the better

the outcomes are in the end. So that's what I look for. My plan is to work as a software engineer in the interim, building strong coding skills while preparing for my transition into cybersecurity slash penetration testing. Does this sound like a strategic path to you? Would you recommend any adjustments? This is a hard one. Like I'm not a cybersecurity expert, I'm not a penetration testing expert. I feel like whatever experience you leverage, whatever

experience you have built up, you can leverage in whatever you do. So I know a person that hired a dentist who went to boot camps and re educated himself to be a software engineer. This was a he in this case. And the person hiring said already this person has shown that they can go through lots of educational curriculum to be able to be a dentist in practice and they have done that for a few years. For them to move and re educate themselves to a different career, They really admired

that, right? They are giving up a huge salary to kind of start from scratch in a new career. And they admired that so much that they gave this person a chance, right? It wasn't just a OK, based on the context and the papers and the the theory, here's a job. You know, they actually had a conversation with this person. But still the fact that this person had gone through that showed ambition shows what the person wants.

So I feel like whatever you do, either if you are still early in career or you come from a different career path, there's always experience that you bring. Now, is being a software engineer going to help in cybersecurity and penetration testing? If you were to ask me a black and white answer, my answer would be yes. I do feel like it will help. It doesn't mean that it's the only path.

If there are junior cybersecurity consultancy roles for example, then I think doing that compared to 1st building up a career in software engineering would be better. But in the end, I haven't done it.

So this is very theoretical. If you are already a software engineer or you're already an engineer, then figuring out how you can apply some of the responsibilities that cybersecurity people are responsible for in your day-to-day as a software engineer to building secure systems or thinking about security, privacy and risk, for example, or data protection can already help and can show what

you've done on the job. So I'm assuming you're the software engineer figuring out in your domain what you can do for any of those topics, safety, risk, personal data, etcetera, etcetera. That's going to really help because then you are already applying probably what you will be responsible for to a certain degree and it's something to talk about when you actually apply for a job fully.

What market slash industry slash area do you see the most potential for at the moment specifically for solopreneurs to look into to find problems that can be solved? Right now I feel like everyone is trying to figure out where the gold is for Gen. AI. So The funny thing is there is a lot of educational content that can be created for that. I feel like if you are have a

way of communicating either online and likely this is going to be through video or even through newsletters and you know what the fundamentals are versus what is specific to tooling and you can really teach and educate, educate fundamentals, then you probably are pretty well off if you're able to package that. There are many platforms that offer courses, structured courses for X amount of weeks that will teach you a lot specifically in tech.

And the people facilitating those courses, they are making bank, to be honest. Because me, for example, I get a study budget, I'm responsible for finishing that study budget

within the year. It means that I will be looking for courses or conferences or specific things to spend that money on. So any offerings that do that, and if they're more companies like mine, which likely there are, it just means that there is money available to go to education for people either for upskilling, reskilling or whatever purpose. So I feel like education for AI right now is, yeah, equivalent to people selling shovels in a gold rush. Now that is it.

But for solar entrepreneurs then specifically, it's quite interesting. And it's not something I'm good at. I'm not good at finding problems that in the end will be interesting for a multitude of people. It's just not something I'm good at. I do know that a lot of people are trailblazing. They are trying to figure out where there is good product market fit. And I feel like right now I'm not building enough. I'm definitely not building enough.

Right now. It is easier than ever to build to get a Moat. Not to get a Moat, but to build something and then to find the Moat to find user problems and to actually figure out if what you're building has value because you can build and iterate so quickly. So I don't know what it is in problems that are right now good to solve. I feel like education plays a

big part. I also feel like especially when it comes to kids and people going and teens with regards to education, that is all going to evolve or I feel like it's quite behind. So there is an opportunity for it to evolve. That might be the industries I would look at specifically if I were to build a product. In essence, if I am building a product, I would look at my own interests. But yeah, it's very hard to find a problem that you then want to solve.

My interests, anime, fitness, nutrition, travel, a problem in there. I don't know, to be honest. I'm building up a little company which I might share a lot more about, but it has kind of 0 tech. Yes, we have a website, but a lot, a lot of it has to do with community building. And those are very different problems. So my biggest problem right now, the tech we have down my Co founder and I, it is getting users, finding the right users. All right I have ideas but they

don't scale. I can go to meet ups but that's just me physically. So how can I find users? That's the hardest part. This is a meta question. Do you like in the Q&A's? Do you like the Q's or the A's? The funny thing is I like the questions that you ask to be honest. And I then re listen to it and I figure out, do I like the answer that I gave? Am I just meandering? Am I just ranting? Am I saying the same thing over and over again? How's my delivery? All right?

Am I looking into the camera? Am I scratching my nose? How's my posture? Oh, I should probably sit more straight. Stuff like that I pay attention to. And then I learn from how I am perceived and that and doing that continuously has been a lot of growth for me personally and professionally. So I like the cues. They make me think, they make me reflect, and then I like the end result. Maybe not even necessarily my answer, but going through that process. I enjoy both.

So if you like you and A's, put your question in the comments so I can do more of them. What made you start this podcast while working? It was not my idea. I will say that forever. I am quite transparent. I'm quite honest. It was someone else's idea. New person from marketing said a podcast would be a great platform to start sharing knowledge on. And I'm looking for a host and I'll facilitate whatever you

need. And at that time, actually, my grandparents had just passed away and I was focusing a lot on work and this seemed like a really cool opportunity. I love listening to podcasts. I still do. I listen a lot less. But back then I listened to so many podcasts. It was always the thing that while gaming would just be kind of educational content. And even though I didn't listen to educational podcasts, I genuinely listen to podcasts. PKA is one of them.

The old school gamers, they know what I'm talking about. Maybe, but it was just a group of three people, sometimes four people with a guest talking to each other, talking shit, talking about funny experiences was a lot of storytelling, was a

lot about gaming. I learned a lot from that and more than I realize because I learned a lot about engaging and communicating and storytelling and I learned a lot with regards to education, which is like little fun facts that are so random, but they are somewhere anchored in my brain. So the opportunity to do something that was similar, I did not want to let that pass. I jumped on it immediately and

that's what started the podcast. What were your strong opinions about software development or tech in general? Which changed Slash challenged after talking to guests on podcasts. I'm going to take the most recent example. And this is a conversation that is not recorded yet. I hope it's going to get recorded. The person has to get back to me. But this is a person that has worked in big tech and they are responsible as staff engineer

for topics like risk and safety. As an engineer and to be honest, risk and safety, yeah, not really something I look forward to. It's been in the way sometimes when I'm trying to deliver, especially in bigger organization like banks, for example. So I was like, man, I don't know if this is going to be an interesting topic, but their perspective is with software, things are not as black and white. And that also means that you will not necessarily know if you

are achieving an outcome. It is harder to measure right. You're serving a certain user base and if they use it or not, it's kind of up in the air. But if as an engineer, your responsibility, your responsibility is safety and risk, there's not a lot of grey area.

If there's something you cannot do, you need to make sure that the software cannot do it. In essence, if you're then bounded by that and the software that you're creating or the systems you're building, there is less room for error. It is like doing software engineering with much higher stakes, and I feel like it's like sports. It could be software engineering Olympics basically because you

have very different constraints. And if you can still deliver in such a way or still have output throughout many teams due to the system you have orchestrated that is safe and that mitigates risk and people are not bothered by it, then that's actually quite cool. To be honest, that changed my perspective because the best safety and risk in a software delivery life cycle, if I'm an engineer, I don't want to experience anything blocking what I'm trying to deliver,

right? Then it would be in the way. But if the system is set up in such a way that I can deliver and I don't even realize that everything is safe and the risk has been mitigated, then that's actually quite cool. I am fully enabled and I mentioned earlier I like helping people. Enabling people on that level is

quite cool. So if you're responsible as staff engineer, overseeing multiple systems, multiple teams and your mindset is I don't want delivery to go down, I don't want to throttle throughput, right? I want people to excel and I want people to have the fulfilment of delivery. However, these are the constraints and that's what you accommodate for. That's actually quite cool to be honest. What are your 3 to 5 predictions? Strong conviction about how AI will transform development slash

employment. If writing code is outsourced to AI, what should be the new definition of 10X engineering? Three to five? Man, you're asking asking me a

lot. I might give you 1 and this also comes from personal experience. I was responsible for product. Then I went back to hands on for close to half a year, mainly because I was feeling FOMO, fear of missing out. Tooling had evolved. I was responsible for product for a year and a half and I was talking to people that were doing things and I was not doing those same things. I was not responsible building daily anymore because I was

responsible for product. So I wanted to go back to hands on and the software development life cycle with AI tooling for me changed because I was much less bothered by finding information, by actually typing myself. And I found this new way of working, which was me orchestrating. Giving you an example, I would be responsible for a certain ticket. I would go to my CLII, would have my cloud code set up to go to my ticketing system. Doesn't matter if it's JIRA.

In our case, it was linear. I would say we're going to pick up this thing. We need to make a plan. These are my ideas. These are the constraints. Let's create a plan together of what that would look like. I need you to think about these things, and that's what I would start with. Then I would have a plan and context. Specifically with AI tooling, it spoils like milk, the fresher the better, basically. So with that context, I would have a plan.

I would put that in Markdown. Nowadays there's more automated ways of doing so, but this is back in the day when I was doing it, which is still a few months ago, but still plan and markdown. I would open up a new context. I would say senior software engineer characteristics. We're going to execute this plan. I would execute the plan. I would review it myself. The plan would be executed quite quickly.

Sometimes there was a little bit of back and forth with regards to OK, we need to think about these things. Do you have a preference? Do you have a decision? We need to come to a decision on this thing. We need to decide. It's like a buddy Claude code and I, it's a lot of fun. To be honest, I found a lot of joy in it. Once something was executed, I

would review it myself. I would actually ask to make the changes if I found some things, or sometimes I would manually change it if I thought that was faster. And then a pull request would go and my colleagues would have feedback. And again, with cloud code, new context, we have built this thing. This is the feedback. Let's go through the feedback 1 by 1 and see what we want to do with it.

That would be my software development life cycle in the smaller sense from picking up a ticket, building testing, reviewing. There would always be unit tests or integration tests in the build process as well. Then to make that a smoother process, I would take the review remarks and I would say these are review remarks on the work

that we have done. Can we build a skill so next time we can accommodate for the review remarks that are typically on pull requests that we've created specifically. So yeah, I don't want to do the same thing over and over again. If there's something that happens twice or three times, there might be a pattern. So I would take that and I would build a skill specific to that. So my next cycle would be if we've built something Claude code and I I would execute the

review skill. So with that skill and with some of the remarks that we have distilled, we would see is the code actually fine? And then I would take the review skill and I would take the code and I would make a code convention skill specifically. And I can use that when I'm creating a planning documentation on what we

actually need to execute. So continuously I was in this life cycle of picking, picking up a ticket, executing, reviewing, figuring out what are conventions or what are review remarks that are distillable and can be conventions and then making skills for those or refining the existing skills that I had. And when that was smooth, I could do that in one terminal, I could do some research, and in another terminal I could do execution.

I could copy the code base that I was working on multiple times locally to have multiple terminals, both doing research and execution in parallel. I know you can do that with get work trees. I didn't really look at it. The fastest way for me to do it, copy the repository. So yeah, probably at some point I need to figure out how get work trees work. But there's not much downside to this, to be honest. And it worked quite well.

That was my life cycle and in essence in explaining all of this I have forgotten the question. My prediction is that this life cycle will hold or this life cycle will more evolve. And I've already seen people

labeling this as vibe coding. I've people go seen go beyond where they figure out to turn figure out a way to turn vibe coding into vibe engineering where the system that creates the software also self reflects with the same conventions and creates a whole system instead of just one feature specifically. Very cool. I feel like that is more of the future engineers will be responsible for engineering. Engineering has not become easier. Creating code has become easier.

So yes, we can engineer more, but engineering is still the same challenge. And you're an engineer, you're not a code monkey. So something else is now coding. You're still engineering a system. That's my prediction. I'll give you 1. I typically don't do many predictions because there's the stubborn part of me not wanting to be wrong, but also I have to kind of feeling that it's going to be very hard for me to

predict the right thing. So yeah, last question, are you satisfied with the growth on all social media platforms? I'm assuming with regards to the podcast Satisfied, I don't think like I have a weird relationship with Satisfied or like maybe content because I have ambition and I feel like I can go above and beyond, which means sometimes I'm never happy with growth and I think always I could have done better or we can do better or yeah, that's just how I am.

I raise the bar or I try to. It doesn't mean I'm not happy with where I am now, it means that I feel like I can do a lot more. Like that's just the drive that I have when it comes to numbers. I was incredibly happy going on YouTube specifically to from zero to 1000 subscribers. And now the podcast has like 50,000 subscribers and each video has like thousands of views. Like the number has just become a number for me.

I'm happy with people commenting saying I genuinely learned something from it or I absolutely disagree because of XY and Z because it gives me perspective, it shows me growth and I'm genuinely having fun talking to people. I feel like I could be way bigger of a podcast if I would have applied the learnings I know now very early at the beginning but that is impossible.

I cannot go back in time. It is what it is right now and I hate when people say it is what it is, but in essence, I know what I know and I'm very thankful for those learnings. And if I ever start something new, I can apply those learnings from the start. And I'm happy that I'm still learning and I'm still experimenting specifically on things like Twitter or LinkedIn on my personal accounts.

I feel like I could have grown to a much larger audience there, but I'm just, it drains me sometimes. Like I, I had the idea of creating weekly LinkedIn posts and I, I followed through on that for a long time, but in the end it was just draining. I was not doing it because I was enjoying it. I was doing it for numbers. And once I realized I was doing that for numbers is also when I stopped doing that. In essence, I don't need to reach numbers on LinkedIn doesn't in it's not enjoyable.

I don't, I see a lot of benefits there, but it because it just doesn't give me energy with the podcast, I don't do a lot to contribute towards growth. In essence, probably because it doesn't give me joy, but also I don't have a team. So I have to make decisions. I have to do the things that give me the most energy, otherwise it is not going to be

sustainable. And because I don't have a team or I don't have a big team, I should say, if I don't enjoy it anymore, the whole thing like a House of Cards, just it crumbles, which is a big risk. But in essence, my podcast, I do have to enjoy it. So I do the things I enjoy. So yeah, am I happy? Yes, I'm very happy. To be honest. I'm very thankful because there will be no podcast without an audience.

And the fact that the podcast now has an audience, a community, people that are watching, people that are listening, people that are sending in questions to gain my perspective, I'm very thankful for that. So yeah, if you're still here, thank you for listening. I love doing Q&A's. If you have more questions, put them in the comments. This has been it. I've done Q&A's now back-to-back because of the amount of questions we had and I'm really thankful for that. So see you next time.