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