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.
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.