Q&A #9: Junior Developer Career Advice and Disruptive Tech with Patrick Akil

Hi everyone, my name is Patrick Aquila and welcome to Q&A #9. We have a record amount of questions in this Q&A, so I'm really excited. It's going to be about junior developer topics, a little bit of philosophical AI related questions, as well as some of my favorite podcast questions. So sit back, relax, and enjoy. Question #1 All right, based on

your experience and insights, what advice would you give to someone that just graduated and is starting out in the IT industry? I feel like I've covered this one kind of subtly in other questions, but never so specifically. If I were to give one advice, it'd be find a place where you can actually grow the most and growth meaning gaining the most knowledge as well as developing

your skills the most. I feel like what makes a good professional is a few things, and I've been very inspired by an audio book I'm listening from Stephen Bartlett actually. He's also a podcaster. In any case, he breaks down what makes a good professional in a few buckets, as he calls it. One of them being knowledge, second one being skills, third being network, 4th being resources, which could also be financially, and then fifth one being reputation.

I think especially starting out, it's knowledge and it's skills. It's the only thing you need to focus on. Your network will follow after, your resources will increase after, as well as your impact and reputation. So finding a place you can kick start your career in, finding a good environment where people will teach you, will guide you, where you can have the room and space to develop your skills in whichever fashion, way or from you want.

If you're starting off in back end because you like that initially, starting out from uni or being self-taught in any way, you can grow towards front end. If that's more your thing, you can grow more towards even other roles outside of software engineering. We've covered a lot of them in episodes, obviously Beyond coding. So the world is your oyster. Basically. Finding a good place to start would be my advice to find the best place for you. I do think it's find the best

place you can start off with. All right then specifically for

internships, what expectations should a junior developer have in their first internship? As well as how do you learn as much as possible during that period? This is an interesting one 'cause I never actually had an internship, it wasn't mandatory. We had a minor period when I was in uni and you could fill that with an internship or a minor. And I did a minor in entrepreneurship back then.

I've since talked to a lot of people in my network that have gone through an internship and kind of reap the benefits from there. So one of the main benefits I see is getting actually first hand work experience in the 1st place. I think that's the main benefit of an internship. But also building up a network at a company that you might see yourself working towards as kind of an end station or for the future for longer term. Those companies are usually more bigger where that benefit is

more apparent. I think you have to be lucky to find an internship at a start up. And that start up then spans, for example, 5 to 10 years. But there are huge organizations like the big ones in tech, Microsoft, Google, Apple, what have you that have great, great either graduate programs or even offer internships. So that's a big benefit because then you already know the people there. So your hurdle in getting a first permanent position is a lot smaller, but that's more

from a benefit position. What you can expect as a person is that honestly what I've seen from a company standpoint, they either want you to only work on a specific thing or they don't really expect too much of interns in the 1st place because this relationship is built on you getting as much experience

as possible. And them kind of, yeah, having not as important work, not as impactful work, work that still needs to be done, that might be a bit more manual that someone just needs to do. That's the type of work you're probably going to get. I think that's reality. Again, I haven't experienced that, but that's what I've heard throughout my network. So expect that you're not going

to have the most impactful role. I think it would be very weird to have an organization have a super crucial piece of work being done by interns. I mean, it happens mostly in start-ups. So if you want that, maybe start up internship is better suited for you. So in any case, don't expect too much of the work in and of its own when it comes to how much you can grow or how you can grow the fastest. I think it's the same for internships as well as then your first job.

It's by asking honestly and trying to gain as much knowledge of the organization, of what it's trying to do, it's trying to achieve. And once you understand that, you can see how you can contribute towards that, right? Once you understand within my team, within my kind of sphere of colleagues, even what my manager's goals are, for example, what is the goal? Why does that team exist? What does it do within this organization?

And that can sometimes take, honestly, to get a good understanding of the team's roles within the organization can take a good year to get a really good understanding of what that actually means. So to do it faster, just ask a lot of questions. Honestly, find the people that want to help you because from a fulfilment standpoint, there's always going to be people that like educating others. Educating others is a great way to make sure your knowledge is

more grounded, more fundamental. Your knowledge is really good if you can simplify it and teach it to others. So people will also take that opportunity to teach it to you. So makes you use of that. Find the people that want to teach you and learn as much as you can from a knowledge standpoint, that's one. And then from a second standpoint, look again at those skills. How can you apply that knowledge in whatever you're doing?

The work might be trivial, but the skills can carry on from work to work, from internship to junior positioner and beyond. So use those skills and see what skills you can bring with you to the next job. Usually it's more what I think you can leverage. In any case, whether you're software engineer or not are more life skills, so they're

more soft skills related. How can you, for example, step it up in giving a presentation or networking in general, Reaching out to someone and being like, hey, I'm new here, can we grab a coffee? Honestly, if it's your internship, who cares? You're kind of a wild card. You're not going to be there full time anyway. And if you are, then you already have those relationships, so why not try and build those skills as well?

They're nothing related to software engineering, they're nothing related to coding, but those you'll take with you from one role to the next. So I'd say focus on your knowledge. Try and understand what your team is doing and how you can actually help them achieve that. Because if you offer help in that way or your insights, that's also what you're there for. Fresh pair of eyes, people will genuinely appreciate it.

I think be eager, be hunger for hungry for knowledge and see where you can leverage your skills, learn new skills and take them with you. I think you'll grow if you do that. Yeah. Thank you. Yeah, I definitely need it. What a good. What a always good liquid of knowledge, good water. All right then on the flip side,

what expectations does a recruiter have of candidates applying for internships or their first job graduating from university? I'm going to take this from an example of a first job, I think because internships I'm not that much aware of what a recruiter is actually thinking. I just have a bunch of assumptions when it comes to a first job, more so junior developer.

I think what I'm what I'm looking for from a hiring standpoint, so I don't even know or can say something about a recruiter because I am not is something that has that eagerness that I just spoke about that is really enthusiastic of working in this environment. Honestly, that I can see myself having a great conversation with being a great colleague as a person. And I'm not going to necessarily look as much into the skills

side of things. I'm going to test some of the knowledge they have either being self-taught or learning through university. At the end of the day, more of a traditional education. But in any case, the skills side, I'm going to park because I think a lot of the hunger for knowledge, a lot of the eagerness will translate into them developing skills just faster, right? If you're starting off, if you're a blank canvas, you can

just paint faster. So also from a person's perspective, if they haven't really gone through any other job experience in this tech field, I expect them to pick up skills faster than any other, faster than a person that's been there for 50 years because they already have a baggage they carry with them in skills. So I don't have to test for that specifically. I just have to test for the right mindset. I think a recruiter will also look for that specifically. So just show that.

And that's the hard part. How do you show that you're eager or hung Hung have a hunger for learning? It's by honestly having that conversation with them. It's really hard to fake it, to be honest. You have to be authentic. So if that's not really you, then it might not be the type of person I want to work with specifically. There are companies where they're just looking for people that execute.

But in any case, I'm looking for a person that I can also learn from, no matter their experience, right? Because they just bring another perspective to the table. So have that dialogue, see what you can offer, see what you can learn. Ask as many questions as they allow you to. You could even ask if you run through an interview and you're like OK, we're at the end, can I still ask any questions? And they'll definitely say yes. You can ask OK, until when do you have time?

And then ask and fire off all the questions you can have. Prepare them in advance. I feel like that has helped me a lot as well. Think of questions with regards to the organization, their goals. Same to your team. You can make it more personal. I asked my manager what he was the most proud of in this work history that he had been working at this company, and he honestly smiled and he just told the story.

And I think that really helped with the bonding throughout that interviewing process, which is going to benefit you along the way. So yeah, that's what I think they're looking for from a recruitment standpoint. So make use of that. All right?

How can a front end fresher stand out in terms of their text stack beyond the fundamentals like HTMLCSS and JavaScript? Knowledge of React, Node and Express is often expected as well. This is a hard one because the text stack and especially on the front end changes rapidly in any case. So what I would look for from a technical standpoint is if they use more of the technology that everyone else uses to be honest. And how you figure that out is honestly to be part of communities.

So for example, last week I did my first talk at a meet up and it was specifically an advanced JavaScript meet up, the one in Amsterdam 16th edition. It was amazing, lots of great speakers, but I didn't really talk about software engineering. I talked about stuff beyond coding, which is obviously one of my favourite talks. But in any case, I learned from the people that were there, both the speakers as well as the

participants. And we talked about how does front end engineering look like nowadays in the modern times, or how did it used to look like and how has it evolved? What technologies are people using? What do they start their project off with? What options are there in different types of flavours, Learning from there and then just honestly, building a bunch of projects out. If you think you have an interesting concept, build it out in a few technologies.

And that's already incredibly valuable from a knowledge perspective because throughout building that, you're going to get a better understanding of what different types of technologies are out there to achieve whatever you want to do. And then just do that. You can show that to a recruiter. That can always be on your resume. You can take that with you, and you can also evolve that. It doesn't have to be static.

So to give you an example, one of the participants said when I want to learn a new technology, I build a messaging app because it's very interesting to stream data from 1 user and then have it visible for the other user. You can see from latency and then have the other user apply and see how it gets back. So he does that only on the front end with a little bit of back end as well. So it obviously communicates to

the other users. But in any case, he does it in Solid JS, he does it in React, he does it in View, he does it in Angular to kind of get a better feeling of what these frameworks actually offer and how easy it is to do the same concept in different frameworks. And then all of a sudden you're doing the same thing in different flavours and you learn what flavour you like. And usually that's very

subjective. But in any case, if I'm then taking it again from a recruitment standpoint, I can see that someone actually really put in the effort to learn, to

educate themselves. And I think the skills and the learnings you'll learn along the way, you'll also be able to communicate that better, what your subjective opinion is and why you think XY and Z will translate because of that skills and experience, because of those skills and experience you've built up. So it's kind of a lot, honestly, I would say find a problem you think is interesting solving, solve that in a certain technology, doesn't matter which

one. Just pick one and then go on to the next one if you think that's interesting and the best thing is engaging communities, ask for feedback and grow from there.

All right, where am I? This one is done. This one is done. I recommend any training programs. OK, Would you recommend any training programs or coding practices that developers seeking their first position can undertake to ease the onboarding process? This is an interesting one because I feel like there's always product phases in a project as well as in an organization.

So if you're looking to go to a start up, they might be very early on with regards to whatever product they're building, which means they might not even have gone live, which means every feature that matters to them or that matters to customers, they're going to have kind of a microscope above it to see if it actually provides value. That's one type, but that also requires a specific developer.

So going from scratch, basically not falling into analysis paralysis with regards to what technologies you need to use, you need to leverage, and then using that, leveraging that and speed is really going to matter and make the difference. That's one type of role. And I wouldn't necessarily advise a junior engineer to go into that. They're usually looking more towards seniors that have already done that and that don't fall into any of the more common

pitfalls that go into that. So then from a junior perspective, I'm expecting you to go into an organization where things are already a bit more stable because those companies are usually also looking to hire more junior engineers because they have the bandwidth. They hire you for that extra fresh pair of eyes. Also because you're cheaper. From just a resource perspective, and I hate the word resource because we're dealing with people, but that is the

reality. At the end of the day, your salary is lower than more of the seniors and they expect you to grow faster so to get a better return on investment. I mean, it sounds harsh, but that I think is the reality. But in any case, looking at a project standpoint, which means things are more stable, they can afford to have you on and to educate you and they can reap the rewards for the long term. That means the thing you are going to do on the project is a bit more stable in and of its own.

You're going to build on something that is already live, maybe not the whole thing, maybe a smaller chunk of it that a specific team is dedicated towards, and you're going to increase value and add features on top of that. That's really hard to actually practice. There's a few things you can practice. You can go from zero to one in a pet peeve project.

So if we talk about that messaging app, you can start it from scratch continuously, but to build on top of that in something that is already quite complex, there's only one way. I think you can do that confidently as well as get the feedback and reap the rewards with regards to those skills in practice. It's by contributing to open source code, right? That is the only way where you already have a big weight of code. There's substantial open source projects that you can look into.

OK, how do these things actually work and interoperate and then contribute towards that there? It's very comparable to what you can do in an organization because you're part of a bigger Organism that is this code base, and you're only contributing to a probably smaller part of it. So try that out, see if you actually like it. See how that process goes for you. It's the same review process.

Maybe open source is even stricter than organization, but then you at least already go through the motions. And that is incredibly valuable in, again, landing your first position because that's what recruiters will value, right? If you've already contributed to open source and you can show that once you have your foot in the door and they see what you actually do, or you just get known through those open projects in the community you're part of, then that's incredibly

valuable. And that will, I think, give you a kick start in actually delivering value once you're part of a team in your first job. So try it out, all right now I'm experiencing significant

imposter syndrome as I contemplate securing my first role. Do you still have moments of imposter syndrome today? Yes, I do. I think a lot of people do. They might not acknowledge it or they do acknowledge it. I think it's always going to be there. And I think I always think it's

me as a person. I'm very insecure for a lot of things and I don't really show it when there's a new group of people and I have to introduce myself and, you know, it goes through the rounds and you can see it at some point landing on your plate and you have to introduce yourself. I hate those, honestly. My heart starts racing. I check my pulse to try and relax myself.

I hate those. But I know it happens, and it's happened so often now that I just accept that it happens because, yeah, that's the type of person I am. Whenever I do something new, whenever I am kind of out of my comfort zone, I know I'm going to experience those feelings. That's not going to be comfortable that I'm like, OK, can I actually do this or can I? Why? Why me, basically. And then you execute and then it just happens and it's really weird.

You just have to go through the motions. You do it and people give you feedback. You might not believe them actually, because they're probably giving you positive feedback or in any way, shape or form. And then you end up doing it after having done that continuously and reflecting on that. Yeah, at the beginning, I feel imposter syndrome. You just go through it, you accept that it happens, and then you grow from there. I feel like right now I have the mindset of I can do a lot of

things. A lot of things I can do it just it's going to take time and no one gets to decide if I can do it or not except me. Basically. I can spend numerous amounts of time and effort in doing something. And I think at the end of the day, you'll achieve that. So then what? This imposter syndrome that kind of trickles down and diminishes for me because I'm just accepting how long it's going to take. And if it takes me a bit longer than someone that has already done it, then that's fine.

I think imposter syndrome is very it was very big early on because I felt like I didn't deserve to be in the position I had. And that's a hard one. I felt like I was lucky to get into an organization and someone just messed up, to be honest. And I had a lot of really good colleagues that I looked up to that I was comparing myself to. And that I think is the biggest kind of contributor to imposter

syndrome. Compare yourself to others, seeing where they are right now and where you want to be. Also right now, even though there's a different history, there's a different education, there's a different mindset, as well as the time and investment that someone has done in their craft. It's just not comparable, right? Everyone's journey is unique. So also don't compare yourself to others. Compare yourself to yourself, to yourself in the past. Reflect back and see what you've

actually learned. Write them down and honestly also celebrate them. Something. I'm horrible at celebrating milestones and achievements. So it's really hard for me because I actually barely do that unless someone triggers me and then even then I have trouble accepting compliments. But in any case, I think it's good. I think it's healthy to see how much you've grown and to be proud of yourself and allow yourself also a bit of grace throughout this journey because

it is not easy. I think being a software engineer, there are easy things about it, but at the end of the day, there's a lot of complexities and you have to manage that. And everyone does it in an in their own way, so it's hard to compare to others. I hope that helps. Imposter syndrome, I think everyone experiences it. There's moments, there's waves, highs and lows. Talk to people about it, see what they experience. And thank you for asking that question. All right.

Last week I had a job interview with the head of technology at an agency. During the interview, I got the impression that he had preconceived notions about self-taught developers, which I am, and consequently did not thoroughly review any of my projects on GitHub or my profile. Is this a common experience? It's hard to talk in kind of common experiences. I'm sad you had that experience and probably it wasn't you. Probably it was the other side. But in any case.

There might have been a mismatch also in the organization or honestly from an organizational side, you might not see it, but it can be a mess sometimes and people can get a last minute invite all of a sudden and then they're there sitting with you while they just read your resume maybe 5 minutes ago just because of priorities and time constraints and deadlines and pressure from all over basically.

So that's why I think I can confidently say it's not you, it's probably the organization as well as the environment. So if that's the vibe they get, they give you, it's definitely not a good first place for you to start out in general. So hopefully that eases the pain a bit and allows you to move on. I don't think it's a common experience, but it's hard for me

to generalize. If in a perfect world, everyone had time and space to also put in the effort to assess candidates, their GitHub profile, whatever they've contributed to, to see if they've gone to any meet ups or what they do online for their network and reputation, then they would do that. But that's not the reality we're in. Organizations are competitive

with each other. There's usually pressure and deadlines and resources that people look at, and you have to actually weigh out the pros and cons. At the end of the day, people might not expect too much of junior developers, so if they treat you like that or they don't actually have the time to review, then it's probably not

the best environment for you. That's why I think you just have to go through and find the organizations where they do spend the time and have that attentive kind of one-on-one conversation with you, for you as a person, because that's the only organization why you'll actually thrive throughout the first steps of your career. And honestly, it's like sometimes it feels like finding a needle in a haystack, but that needle is going to be incredibly valuable to you.

I think it can help if you go to kind of those community events that I talked about, either conferences or meet ups. And meet ups are just more local than probably almost all of the time, free to join and to learn and to engage. And that's where you can already fish out some of the companies that have that time and attention because the people from those companies go to those meet ups and they work at those companies and they're probably proud to work at those

companies. Striking up a conversation with them and seeing what opportunities are there might already kind of narrow down the hay and then finding the needle makes it easier. I think. So, yeah, it's a lot of pre work. And at the end of the day, you have to see if they actually put in the time and effort to look at your GitHub profile to think of, OK, what has this person done?

And then I didn't even touch on kind of the pre notion of self-taught developers versus actually traditional education there. I'm quite simple. For me, traditional education is just more of an accolade to prove that you have a specific subset of knowledge. It's harder to prove it if you're self-taught because there's no stamp of approval. That's traditional basically. So that's what you're fighting towards.

What can really help is then to use that knowledge and apply it and show the skills in whatever you've built. And that's where the part that kind of disappoints me is that if they don't see that, then yeah, it makes sense that they you have that experience. Basically. I don't think you're doing anything wrong. I think getting knowledge from a self thought perspective, applying it in skills and showing your projects is a great

way to land your first position. But yeah, then finding the right organization that actually approves of that and appreciates that, that's the next part. Good luck.

All right, here's a fun one. If you could eliminate one programming language, which one and why? Honestly, this is a funny one. And I think similarly to like spoken languages, for example, would I eliminate French? I don't know. It would make a lot of people upset. What would they do? What language would they speak? They try to, in just spoken language, have one language for everyone.

I think it was called Esperanto, and it was super easy to learn, but at the end of the day, it didn't stick. And I think it's very much similar for programming languages. So that's one. I really dislike very old versions of Java specifically. So maybe if I could just wipe the floor with, let's say, very older projects of Java. Because honestly, yeah, this is like, OK, I'm removing a tool. At the end of the day, it's just

a tool. And the people that applied it applied it in a weird way, or maybe a way that doesn't sit well with me, and I'm not going to remove the people. So then, yeah, maybe it's Java. I guess at the end of the day, Java's having this battle with Kotlin and seeing what Kotlin's doing and then applying it to later versions of Java.

I think that's great. I think competitiveness, just like in organizations, at the end of the day has a better outcome for all parties involved if someone doesn't just get swamped. And at the end of the day, whatever's in production will stay in production until it's not. So there's still many types of languages, for example, COBOL. COBOL developers are incredibly valuable because apparently there's no COBOL developers.

So all the applications that are in production with COBOL as a language that still need some type of maintenance or feature development all of a sudden have a hard time finding people. So yeah, that's also the risk that you have as organization. And I can wipe the floor with any language. If I do Java, a lot of honestly, a lot of applications would just would just fall to the floor. Yeah, it's hard picking one

spoken language. I also wouldn't know I there's one spoken language that's like from my roots and heritage. It's called Aramaic. You can't even Google that language anymore. So then why do people still speak it? For me, it's like a community and it's my roots and my family speaks. I don't, which is a really hard time. But in any case, does it mean that language shouldn't exist? I don't know. For me, it's the same with programming languages, to be honest.

But yeah, older versions of Jaw Gone only have five questions

left, actually, maybe 6-7. All right, so this question is actually broken down into two parts, so I'm going to touch on the first one first, and the second one comes after. With my software engineering internship, I'm constantly on the hunt for the next big thing. AI is in the spotlight. Oh yes, it is. But what hidden gems are quietly brewing in this tech world waiting to disrupt the status quo? Honestly, I don't think there's many. It's really hard.

The AI wave is, for me, very interesting. And when you talk about disruptive technology, it's a prime example of something that is very disruptive. But right now we don't really know what impact it's going to have for the future. So with what I know now, I don't know of any other proven disruptive technologies that are kind of brewing. I think this concept of data, data-driven decisions or data-driven automation has always been there. Now it's just more to the

forefront. And again, I think I touched on this in a previous Q&A. Once it gets more accessible, I saw a Big Apple announcement that on the fingertips of my phone and iPhone, I can access whatever I need with regards to LLMS and AI. That'd be very interesting because then all of a sudden applications can easy more easily leverage that, which means it's going to be more accessible to also a bigger part of the community that is just beyond the tech space in and of its own.

I think a big part is going to be in education. So not necessarily from a technology standpoint, but more from an application standpoint. I think the biggest benefit will be in education. So looking at whatever you need to learn from maybe your high school process, your university process, or even elementary school. I think tutoring and specific one-on-one education is going to

change. One to many might not be as common anymore as we have it now with the role of AI and the leverage that they can basically spread knowledge on whatever topic you need. Really scratch that itch of curiosity that kids have and I hope it's going to do a great job at that because I can see the benefits there. That's the one applied technology that I think is really going to revolutionize the education industry.

From a tech standpoint, I think you won't do bad if you invest into your data-driven capabilities on whatever thing you want to do. So from a software standpoint, looking at how you can leverage data to make decisions on XY and Z is already there, is already partly established and it's just going to continue to grow with whatever new technologies pop up. I don't think there's anything right now that I know of that I would say is hidden or under the

radar that I would put my time and investment in. But maybe it's also my risk appetite. I like something that is already a bit more established, a bit more on the early horizon. And I think LLMS as well as generative AI as a domain and concept is now seeing a lot of applied application in a bunch of applications that I use mainly, again, from a knowledge standpoint. But in any case, I don't think there's a lot of other technologies right now to invest in.

I said risk because obviously you can find technologies that are a bit more niche and see how you can invest in those. But if at the end of the day, you invest your time and skills and something crashes and doesn't actually get main, main adoption or isn't actually an established technology at the at the end of the day, then I would say that time and effort is a little bit less valuable. I wouldn't say wasted because you're going to leverage that in whatever you're going to do

next. But in any case, from a efficiency standpoint, from my standpoint, I wouldn't invest in that. Then second part of the question, how can these under the radar advancements become

the tools to unlock ground breaking innovations across industries? Now for me, technologies are always interesting ones that are applied to solve specific problems. Problems are very broad when I say it. So it could be literally a problem I have, or it could just be a use case, a problem that no one needs, they no one knows they need solving, but all of a sudden solves a problem that you never know you had.

One of the funny things is I watch a lot of Shark Tank and there was this one company specifically, it's the Ring doorbell they pitched on there. They didn't get an investment. And all of a sudden I walk around through the streets of Amsterdam and I can see that little thing doorbell with a camera that says a Ring underneath. I'm like, yeah, that guy found apparently a solution towards a

problem I never knew I had. But with a lot of marketing, with a lot of campaigning and obviously a lot of education, people figured out that, yeah, once people walk through the streets or it's someone rings my door and I can answer them remotely, I don't even know exactly what ring does. I'd see everywhere. Apparently it's a problem that

people needed solving. So that's why all of a sudden his thing and his applied technology, because he's still using standardized tech at the end of the day, became a problem that people needed solving, so they bought and purchased his product. That's the only way I can see technologies getting mainstream adoption is finding a way to

apply it to solve problems. At the end of the day, the bigger the scope of your problem, the more people it encompasses, the higher production and output and sales you can have. From a product standpoint, from tech, it's the same. So I had an example of this physical product about digital products, for example, whatever people now use for Scrum, for example, Jira, whatever they offer in their suite of Atlassian products, people all of a sudden just need it. Or Myra is actually a better

example. Going from COVID and having a physical whiteboard and all of a sudden needing it digitally really exponentially increased Myra's value because they were already offering it. The problem scope just all of a sudden got bigger. So they needed to scale, sure, their software to a certain degree, but the problem they had already solved also to a certain degree, and probably new problems they were solving still. So from a software standpoint, it's just easier to scale and

leverage. But the application was the problem they solved. So focus on the problem, not necessarily the solution in the tech. That's my long ramble and conclusion. All right, Technology is rapidly changing.

Even before someone learns a skill completely, it is being replaced with something else. That's a statement. How do you think that we can handle this situation, especially those with more than 10 years of experience? What should they focus on? It's funny because this question actually probably continues my train of thought on the last one. I don't think I agree with that statement. I don't think technology is changing as rapidly as we think it is.

There's new innovations, but still they take time. I mentioned COBOL as a language that's still in production. I don't know how old that language is, but it's probably created before I was born. I have to Fact Check that one, but no one knows when I was born, so maybe it holds true. In any case, that means that the technologies we use can still be from 10s, twenties, 30 years ago basically, and we still use that in our day-to-day to some degree.

I think newer technologies that pop up are going to take a long, long time to actually be applied in production. So it really matters where you want to be on this kind of innovation curve. The earlier of an adopter you'll be, the more kind of new technologies your work with, but then how you apply them in production has not been

established as much. If you want something that's, let's say more risk free, depending on your risk appetite, you can go towards technologies that have already been established and that you foresee don't go anywhere. For example, Java is on version, I don't know, probably in the 20s nowadays, but in any case, it's there. It's going to increase in versions. I don't think any of the production applications are going to remove themselves from Java as a language anytime soon.

Because also from a company standpoint, what will be the main benefit of removing all your Java code and replacing it with Go? If you have, let's say, millions of lines of Java is debatable. It's not going to increase your value. Maybe a small subset that you need to scale specifically in the cloud in a structured way, then yeah, you can make the argument, but then only for that part, which means Java's not going anywhere, which means investing in that scale of a programming language.

Probably you're going to reap the benefits of that. But that's my assumption. I don't know what's going to happen in 10 years. I try to answer whatever future question with whatever knowledge I have now. And I don't think a lot of the languages that have been established are going anywhere for me, I'm having a lot of fun with Go as a programming language, even though haven't coded in a while now since I'm a product manager. But in any case, for me it's simple.

I like being effective in a language that I use. I like being able to review other people's code and them not having many types of different ways to do the same same thing and then us having a subjective argument on that. As well as I really like how I can do a lot of stuff done in the cloud, specifically on GCP with Go because everything is just very easily interoperable because Google Cloud is written in Go. Now not a lot of organisations

might use that. But since I have this love for language so much, I might just look into organisations that do use that when I move on. So I don't think it's a waste of investment and then have that skill if I still want to move and pivot to another language. I have comparisons as well as kind of a ground fundamental knowledge in how to do software engineering in general, which translates beyond just

languages. So I can always fall back on that and then pick up a new language as we go, because new languages also just pop up. Not like mushrooms, not like front end frameworks. But in any case, they do pop up. And then all of a sudden it might solve something very specific, very interestingly in a new way like Rust. But then if we talk about Rust, for example, it's already also, I think close to 8 years, maybe 10 years old, which if we think

about it, is actually quite old. Like you can't say trust is a newer technology, yet we still say it's kind of newer because it hasn't been established as much yet. So yeah, bit rambly again. I hope it answers the question. I don't agree with that statement. Also, this one has two components, so I'll probably

touch on the latter part after this. How can we ensure that human skills like critical thinking, creativity, and emotional intelligence remain crucial in the IT world? They are crucial. How do they remain crucial? I mean, they will always be crucial as long as there's a human factor at play. And I think with people trying to solve people problems in an organization, and an organization is just a group of people at the end of the day, there will always be people

problems. So empathy, emotional intelligence, soft skills will always be relevant. They will not be relevant. If a an end to end fulfilment process is just completely automated with machines, then maybe still because someone has to create those machines and then there's still people. So then those skills still matter. Maybe it's a bit of a cop out, but unless we only live in a world with machines, the human factor of creating machines will always be there and at play.

Those biases will also translate into those machines. So then maybe even still with machines, they will be at play and as long as we don't understand a lot of the human brain yet, it's hard to translate that into machines the right way. Our brains are kind of objective, subjective, there's a lot of things we don't really know. So then to translate that and have an equal counterpart in an AI or a machine, I just don't see it. For me it sounds like a bit

sci-fi ish yet. That is a lot of the train of thought that nowadays is there with some of the AI advancements. I think they solve a lot of the knowledge problem part, even some of the skills part because applied knowledge you can see in skills. But then solving the right problems, figuring out what humans actually need from a human perspective will always be different from a machine perspective. So I think the human factor will always be there.

Maybe a bit of a cop out. But in any case, second part of that question, how can we bridge the gap between humans and

machines to create a future where technology complements and empowers human capabilities, The future where machines and power? I think we're already doing that. I don't think people are. This also sounds like more of a sci-fi movie, but I don't think people are creating machines to then at the end of the day, destroy humanity. As bluntly, I guess as I can put it, I think they're always trying to solve part of the human problems that we have,

part of the human limitations. I think this concept of machines integrated into the human mind are quite interesting because from a storage perspective, I just have limited bandwidth as to how much information I can store, and I don't even have the options of storing and removing specific information like a computer can. So I just have memories and they're just there and all of a sudden something can trigger me and I remember something else, which means it's stored and all

of a sudden I have it again. It's very weird how the brain works. Machines are way more black and white, and I think a lot of the problems we're solving now are just more so human limitations. So enhancing human capabilities with AI and with whatever new technology we're creating, I think is the aim. At the end of the day, if it's going to bite us in the ass, I don't see it yet. Maybe ask me again in like 1020 years because my perception will definitely change with what I know now.

I don't see it yet. All right, we're going to round

off with two podcast questions, starting off with the first one. Why did you start the podcast? One of my favourite topics to talk about. I think I do it a bit too often. It's definitely been somewhere in some of the Q&A S and I'm not going to lie, to be completely honest, it was not my idea. We had a new person from the marketing front and they said CBR as an organization, there's a lot with knowledge sharing, a lot on conferences, a lot on blogs.

A podcast would be a great platform to also do that. But he said I'm not a podcast person, I'm looking for a host and I'll facilitate whatever you need. And that sentence, those specific words, music to my ears. Honestly, I was like, yes, pick me, pick me because I have been listening to podcasts probably for the last 10 years. Nowadays way less because I'm commuting less. But whenever I was in the gym, whenever I honestly was just laying in bed, I wouldn't

listen. It would be so enjoyable for me. I would learn so much through that. I think my English got way, way better also through that. And I always had this fondness of the English language whenever I was a kid even. Probably because all the games and all the media was just in English. So yeah, definitely came from there. But in any case, I thought it would be great. I have a really hard time starting something from scratch.

And when someone would offer the world to me because that was, that's what it sounded like, I was like, yes, let's do this. So immediately we started collaborating. We said, OK, I had a vision for the podcast. I wanted to talk about something technical, but not too technical. I think very technical topics are way better for video content or blog from content. I think a podcast is about the people, their stories, their perspectives for others to listen to enjoy, take with them

and do whatever. Honestly, It can be applied immediately or it can just anchor in the storage that we call our brain and all of a sudden it's handy or it's not, but it at least offers a perspective or different view. So that's the type of episodes I wanted to create, the type of podcast I wanted to create. Obviously I had big, big dreams. So we didn't do it in Dutch. I wanted to do it in English. Joe Rogan was like the step on the horizon.

If we if we could become and still, if we can become the Joe Rogan of the tech world, I would love that, to be honest. And I wanted to do it non edited For me, that's a big part of the authenticity. Q&A S are the only ones where there's a little bit of editing. No, I I mean, I never lie about that. That's like full disclaimer only Q&A S So that's what we started and I'm really proud to say that's still where we are. Very early on, we covered a bit

more technical episodes. Nowadays we cover whatever piques my interest and whatever interesting people I can find to offer that perspective and those conversations. So I'm really happy with it and I'll continue forever if people around. And then to round off, how much

time does it take to create an episode that has had ups and downs? I think we've streamlined our process to the T. So this recording with audio comes out in the back. I have audio separate here. We put it, we synchronize it. It's separate because it's better quality. Then we do a start and an end in a traditional episode, not AQ and A because traditional no

editing. I do the intro at the end and we put that in the front so we have a better idea of what we actually talked about because it's still a conversation. It's very free flow, very malleable in the moment. Honestly, none of the quick questions are prepared and people are very surprised when I say that. So don't tell anyone. But in any case, that's in the episode part of it. When it comes to everything before I try and find people and honestly it's not my favorite

part. I I'm a horrible planner and I try and do everything in my power to already see what type of person they are online, what their reputation is. I do a lot through reputation. So what people put out there in content block form, open source, or even speaking on conferences and meet ups. And then I do a lot through network. Every person I have on, I ask them, who do you think will be a great next guest? And then I find those people because that makes it more easy

for me to actually find them. Then we do an intro calls, usually half an hour. I lay out the landscape. We find a topic. We get really passionate about both of us. We're recording. Usually I planned in for an hour and a half. And then we have the more editing side of it, which has been simplified. I don't do it myself anymore. There's now an editing team and then we release it, publish it. There's a bit of outline that needs to happen, creation of

thumbnails and assets. I'm AB testing nowadays, so I don't know if you actually see that, but there might be a few different thumbnails of this Q&A episode. We'll play around with that. But in any case, that whole process might take up to 1012 hours shorter or longer, depending on what it was. Early on in the podcast it was longer. Nowadays it's a bit shorter for me, personal time even less because I don't do the editing

anymore myself. So that's the time investment and it's a lot of fun for me. The favorite part is having the conversation and even doing the Q&A S because I really appreciate those questions and the opportunity to answer them. So that's why I do it. I don't like the planning part. I'm a horrible planner. Again, I wish I had a personal assistant, that would be great. People always ask me why don't you do shorts? It's just from a bandwidth perspective. I don't do the editing.

I can't get enough buy in to do shorts and people just say your content looks great but your short shorts are shit. Let me do it. Yeah, I don't have the money. I don't have the resources to pay people to do it. And maybe even if I do, it's just a bandwidth perspective. I don't want to have any back and forth. So if you've listened to this episode, you will probably not send me an e-mail and everyone that sends me an e-mail, I don't know, they have not listened to this episode.

So yeah, with that being said, thank you so much for asking

your questions. Please do them again in the comments section below. If you have any questions, let me know. I hope I did justice answering your questions. It has really been a blast and I feel really honoured to be able to do this. So thank you. We'll see you on the next one.