Software engineering fundamentals, how to become a
great software engineer and what to focus on.
That's exactly what we discussed today.
Joining me today is Sonar Muk, Director of Technology over at
Picnic. And he's been involved in
setting up a training program specifically for people early in
career to teach them how to become great engineers.
He touches on many pitfalls they teach, some of which I've
actually fallen into myself. So enjoy.
One of the initiatives that give me a lot of energy that we
started a few years ago is a path for people who are super
early career, who are maybe even just graduated and bringing them
into Picnic and giving them a place to grow very fast through
our tech Academy. So what's what What you saw
initially in Picnic when I joined is that we hired people
who were quite experienced, which is great because you are
allowing them to hit the ground running and to become very
productive very fast. But at the same time, as we all
know, it's super hard to keep hiring experienced talents,
especially if you want skill like we did.
So we also understood that this was not sustainable to, to, to
the level that we have now. So we needed to find a way to
also bring in people with less experience and no experience.
And as you're a start up moving into sort of the scale up phase,
things are busy, right? So all teams are crazy busy with
lots of new features and then all, all kinds of things that
need to happen there already. So just throwing someone in
there who doesn't have any experience at all doesn't set
either side up for success. So it's not not great for the
person joining, it's not great for the team.
So we, this was around 2122, we started thinking, OK, what do we
need to put in place to be able to make this happen and to set
both sides. So the team receiving, let's say
this junior joining, but also the person joining up for
success. And that's where the idea for
this sort of learning path came where we say, OK, basically what
we want is someone still with ACS backgrounds, but maybe no
experience or very little experience and give them enough
support to to grow very quick quickly, to be able to already
contribute from the start. But at the same time have a lot
of support structure around that to also get this growth.
And that's, that's sort of a initiative that I'm super
excited about. But now we've done five groups
of roughly 10 engineers that we hire in sort of batches.
And these are also groups that that feel very cohesive and go
through this program together. And where you can see that they
actually get an opportunity is pretty rare because as an
engineer, you will then join one of our product teams.
So from the get go, you will be immersed, let's say, in the
whole context of team and, and, and doing actual work already.
But at the same time, we also offer a very structured path to
this group in terms of learning. So there's a few courses that we
developed and, and, and, and teach.
There's a mentor that we also couple to this person who's
available for yeah, one-on-one coaching.
And we also explicitly make time for this, right?
So that we also don't put this as an additional burden on
someone, but really allow them to to take time for that and
also offer a lot of room for people to actually do a bit of
self development, self study, offer content for that.
So that's yeah, these people in the first few months that they
joined really also experienced the freedom to to actually work
on themselves rather than trying to figure out how to implement
their tickets and how to actually get something out of
the door because there's they they might experience otherwise
so much pressure. So designing this program was
was something that was a bit of an experiment, right?
So for us, it was completely new.
But it turns out that this is very has been very effective,
has been very successful. So as I mentioned, we, we've now
since 22 and done five or six of these groups with lots of new
and and young fresh talents that are coming into Picnic where we
also see that this is something that's also reinvigorate teams
in the sense that a new and fresh perspective without the
burden, let's say, of a lot of experience can also bring a lot
of new energy to a team. Yeah, yeah.
I mean, it's really funny. I've lately talked about this
concept and I've heard that Booking does it kind of in a
similar fashion, but they do have a full training programme
before you actually enter a team.
Lots of kind of hackathon concepts there.
I talked about it with Director of engineering from IKEA
specifically. I don't know the insurance and
outs there, but they also start with cohorts with 10's and
dozens of engineers and you specifically mentioned they
immediately jump in. In a product team.
They still have to have ACS background or a more technical
background. What do you look for with people
that actually join this program with regards to what they
already bring to the table? So what I mostly look for is
people who are really eager to learn.
And that sounds very trite, but you see a big difference in in
people who are just looking for maybe like a stable environment.
I just want to do my stuff as I think the world works in the
software engineering, etcetera. For just the people who already
have maybe done some side projects during the university
who are very well versed in some of the technologies where they
also try to explore this themselves.
And during interviews, you can see sort of the difference in
energy level between those people.
And that is, that's really what we're looking for.
So people who are eager to actually not be content with the
status quo and to actually embrace the fact that they still
have a lot to learn, even though they had five years of CS
studies here behind them. So that's, that's, that's,
that's sort of what we're looking for in these groups.
And I would say this goes in general for people working at
Picnic that we are looking for this also this entrepreneur
neural spirits. So if you're in the product
team, regardless of, of what level you're at, we, we want to
have people who look around and say, Hey, why are we doing it
this way? What can we improve and, and not
just wait, let's say, for the business to come up with, with
new features, new things, because that is how ultimately
as tech company you grow. It's not just by executing on a
backlog, but it's also by being very proactive as a team and,
and looking around and, and seeing, hey, how can we improve
the world around us for our users.
I feel like being eager and like hungry for knowledge.
I have had that and I still have that on certain topics,
especially early in Korea was is very big and now it's, I think
it's similar, but it's very much focused towards more specific
subjects because in the beginning I had no clue what I
what I wanted to focus on. But I don't know if that's a
skill that's just something that's in you or something that
people have or you don't have. I do want it though, because
I've had conversations also in an interview setting and then
someone would be like, this is a really good opportunity for me,
but they could not show what they've already done and why
it's a really good fit for them. They hadn't started yet.
They wanted the job 1st and then they would start the work.
And I like that you highlight that the people that are really
eager, nothing stops them from already starting, right?
They don't have to have a job to do what they like.
Exactly. Yeah.
And, and it also shows in in the way they, they, they can do
themselves during interviews, right.
So do they ask questions to you, right, that are interested in
your company, in your team, in, in what's happening there?
And that that already shows that a lot of people during interview
feel that they are being interviewed.
Well, that's of course that makes sense, that makes sense.
But at the same time, it's also the reverse, right?
So, and that's not just for early career people, but for
anyone you're also interviewing company.
If you can already at that point make very clear that you're
someone who's interested in in what's going on and and
interested in what's your role. And that will be that already
also shows to me that's that you're you're you're someone who
can grow very quickly and then pick up new things.
Yeah. For the people that join, what
explicitly do they get taught during that process?
So in the first couple of months of of this program, it runs
roughly 5 months, they will join 3, let's say, very hard skill
courses around Java development. So the first one is really about
what we view at Picnic as a good way of doing Java development
scheme coding, how we use certain patterns, etcetera.
So really beyond, let's say the basics, but really how, how do
we do this in, in a product context, in a picking context
specifically. And then they do a deep dive
into Spring Framework. And they're also, it's not
really about learning which annotations to use or, or what,
what do the API looks like, because some of them have
already seen that. And otherwise they will pick
those up relatively easily in, in a product team.
But we also want people to really understand the
technology. So how does it work?
Why is it there? What is the reason that's that
we're using such a framework? What does it bring to the table?
And we also very much encourage people to, to, to do this deep
dive and to take that time, because ultimately what we want
to prevent is that we have very smart and eager people joining
A-Team and then only learn by copying and doing what they see
around them. Because that will work to up to
a point, of course. And, and it might feel good in
the beginning because you're productive and then you're
delivering features and you're delivering code.
But it will not create the engineers that, that architects
are future systems that really deeply know what the technology
is about, that really understands why something is
there rather than just using it. And, and, and that is in this in
spring course might sound very basic and some of the parts are
basic, right? So some of it is new just to
these people, but it's also really much, very much about
what is what is under the hood and why is it there and why does
it function the way it does. And then we within Picnic also
make use of reactive programming.
And obviously, if you use Spring Framework, there's also the
whole reactive part of that, which in and of itself is quite
an challenging topic even for more experienced engineers to
pick up. So we also very much focus on
that topic. And then for the, for the first
two courses that I mentioned, we also organise what we call
reflection sessions. So in a way, if you're in a
course, you have an instructor, you do some exercises, you get
some learnings and contents. It's still very theoretic.
So we asked every participant to also bring this back to your
team and, and think about, Hey, how are we applying this in the
current team context? Do we see any improvements?
What, what have I learned and how this translates into the
practice? And then they bring this back to
the group and present that, which also helps them in their
presentation skills. And then learn how to craft a
story, how to actually show people what you've been
analysing, what you've been doing.
And these reflection sessions are super helpful to actually
again, bridge the divide between theory and practice.
So these are very hard skilled Java oriented trainings that
they have. We also offer them some training
around, let's say, more peripheral components in our
architecture. So there's a course that focuses
on our use of MongoDB, of Postgres, and all of the sort of
infrastructural components that you will need to succeed as an
engineer. So Docker, Kubernetes, anything
around operating and running the products.
So it's a very broad kind of program.
But again, because they're part of a product team, they can
immediately next day see how this works in their contexts,
how it supplies, how our release is done, how does our production
system look like. And then in that way, you not
only gain the knowledge and, and gain your understanding for
technology, but can also immediately apply and, and learn
it in your, in your day-to-day. And yeah, that's sort of the mix
that we offer and that's works for us pretty well.
I can see that. I really like the kind of
practical part of joining a product team and seeing and
feeling kind of what it is to be in there because you are, it
makes a lot of sense. And then more on the theoretical
side, really focusing on hard skills, I and when you mentioned
you can copy and kind of do what other people do, that hit the
nail on the head because that's exactly how I started.
And it feels good. It feels productive.
You feel like, OK, I can, I can actually do this.
And it really hit hard when I started a project where there
was nothing. Because when there are
conventions, it's easy to follow the conventions and you have to
experiment and you have to innovate a little bit.
But really good conventions are there for a reason.
It makes people productive and they know how to follow the
conventions. When you're building up
conventions and you have to build up a solid foundation for
other people to build on top of a future you, but also a future
people you don't even know yet and a future team, let alone a
scholar of teams, That for me is very challenging.
No, I fully agree. And and that's also why you
point out this pitfall at the very beginning of this program
to everyone who joins. We tell them very clearly, yes,
you will have sort of the urge or the inkling to just dive in
and, and and do the work and, and be useful and, and make sure
that your values as part of the team.
But we're offering this pretty unique opportunity to also take
a step back and in the first months, take this time to, to
learn and to grow. And that is something that it's,
it's a tricky balance of course, for people to make, but we do
expect them to actually invest the time.
And and that's also where this this mentorship plays a big
role, of course, because a more experienced engineer will
actually also hold up the mirror and say, OK, but but do you
actually understand what you do and then also dive maybe deeper
in aspects that they don't understand and that they're
maybe not covered by the by the technique program itself?
Yeah. Yeah.
For me, with regards to depth, I also wonder how deep should I go
with regards to getting a solid understanding when we talk about
programming or or software engineering fundamentals.
What would you say really fit in there?
What have you seen engineers do that are exceptional in your
view? So if I look at the picnic
contexts, a lot of what we do is Java and JVM based.
So what sets apart the really good engineers from let's say
mediocre engineers is also some knowledge of what actually
happens under the hood, right? So do you know what what the JVM
does? Do you know how to understand
garbage collection and the effect it has, how how to tune
it, how to operate a Java based system?
So beyond coding, I would say apps for this podcast also
understanding the ecosystem that you're in and, and at a very
core level understands how things like performance,
security and all of the non functionals, excuse me, all of
the non functionals are affected by by what you do as an
engineer. And and that is certainly not
something that you learn overnight, right?
So you make mistakes, you see other people making mistakes,
you learn from that. And that is invaluable as an
engineer to have that that kind of knowledge and experience
under your belts. From engineers I talked to, some
people have that urge to really want to understand what goes on
under the hood and they will themselves, I think self educate
and that is a continuous cycle of new technology.
How does it actually work? And I set it up from ground up,
from first principles. And then you have other
engineers and I think I fall into that category more.
It's like I can use these things and I kind of have an
understanding of how it works under the hood, but I want to be
effective. I want to execute, I want to
deliver value to customers. I'm more, I feel like user
facing and then I have this decision and it's it's the last
few years, but also the coming few years.
If I want to become a better engineer, I do have to find this
inkling and go deeper to certain aspects because I feel like
that's what's withholding me from actually growing on an
engineering side. No, I think there's certainly a
tension between you as an engineer being a problem solver,
right? You want to deliver value, you
want to be effective for just being a very curiosity driven
kind of, you know, person eager to learn what the technology
actually is all about and what it does and why it works the way
it does. So for sure that that that is
something I recognise. It might also be related to your
stage of your career, as you, as you pointed out, right.
So especially when you get started, it is easy to fall into
a trap of, of wanting to be too productive and, and just copying
behaviour around you without really understanding.
And, and I can certainly see that once you have sort of gone
through the motions of learning and technology very deeply once
or twice, then picking up another technology and using
that in a very effective manner comes pretty naturally and
doesn't take the same kind of level of, of, of depth that you,
that you would otherwise have to invest.
So as you grow, you probably will focus more let's say on, on
the usage of your of your tech and not so much on the, the
under the hood stuff. Yeah, yeah.
Makes sense. Yeah.
Any other foundations or fundamentals you want to
highlight that distinguishes great engineers from not so
great ones? If I look at what is happening
in, in, in picnic context again, what what really strikes me is
that our our engineering culture is relatively uniform in the
sense that we started only 10 years ago.
We have a very strong developer platform that was developed from
the get go. And there what I see in some
other companies and other contexts is that there's a lot
of people trying to adopt new technology just for the sake of
it. And that is something that I
feel that a good engineer doesn't do right.
So if you adopt new technology, if you find out about a new
technology, you need to understand whether it's actually
an improvement of what you have. Make very clear also why that is
the case and not just jump on any, any band work.
And, and that's something that I feel that very good engineers
are good at, right? So they there's this sites, I'm
not sure if you know it, the boring technology dot COP.
I don't know it, but that sounds very funny.
Yeah, yeah. Which sort of advocates for use
what works, use what is proven use and then use it in a very
effective way as you mentioned that that is I think what what
good engineers do and the surrounding between OK, but what
new technology is that interesting to jump onto
etcetera. And that is super hard, of
course, and also maybe a bit more of an art than than a
science sometimes. But it's precisely that's kind
of gut feeling, I would say that's that that knowledge and
that wisdom that you have as a as a, as a Craftsman, as an
engineer, that sets you apart from people who, yeah, who don't
have that taste or who don't have that knowledge to, to make
a good decision. And then sometimes you end up in
situations where there's companies that are much smaller
than than the company I work at that have like dozens of
different technology stacks because, well, people decided
that in some kind of context, it was better to use Rust or to use
Go or to. And then you end up with this
fantastic collection of technologies that nobody really
knows how to manage anymore, really know how to, how to
operate anymore, really knows how to, how to bring this
together. And yeah, that's, I think one of
the hallmarks to come back to your question of a good engineer
is to actually also limit this and, and, and, and stick to,
yeah, proven things and what works.
Yeah. Do you feel like that problem of
newer technologies or also engineers just from marketing
sense getting bombarded with tooling is a problem that's more
recent? Because I feel like now
everything is about Gen. AI.
It's like the number one buzz on the Internet.
Obviously. Is obviously is Gen.
AI, but also not just from a OK, how do you get Gen.
AI features if that's already a good idea into production, but
everything with regards to developer tooling.
It's a huge market. Lots of companies are trying to
solve this problem with regards to productivity and tooling, so
I feel like I am getting bombarded.
For sure and I mean there's, there's so many new things to
try out, right. So Cursor, Windsor, Windsurf,
all the, all these kind of tools and, and they're sure it's good
to experiment, right. But at the same time, we also
need to be mindful that, yeah, we, we should do what works and
not so much we should, we should not only focus on what seems
shiny and new and, and interesting in a sense.
Yeah, yeah. One of the things I I love, and
this is also what what gives me a lot of feeling our fulfilment
rather as an engineer is the feeling of also being productive
in the way I am productive. So in everything from creating a
pull request to tooling to figuring out my IDE and
everything on the terminal, I like to be very efficient and
effective in all of that. Everything hands on.
And especially now that there's a lot of change and a lot of
experimentation going into tooling, I'm more hesitant to
experiment and adopt because I am confident with the tool set
that I have. You have something that works
for you. Yeah, yeah, yeah.
But then when you have a platform of 350 engineers, if
there's something that can make them a few percentages more
effective or efficient, that's going to pay dividends for sure.
Yeah. How do you choose or how do you
experiment with regards to things that help developer
productivity? So there's a, there's a few
things that we do there. On the one hand, as I mentioned,
we have a developer platform team.
So in a sense, when and, and this can be a new tool or new,
new library or when, when something comes up where we feel
that this is going to help all of our product teams, we can in
a very centralised manner, experiment with this in the
developer platform, make sure that it's working in the context
of everything that we do and then roll this out in a
controlled manner. So let's say we have Java 25
coming up, for example, just released.
Rather than having every product team figure out when to upgrade,
how to upgrade, what, what the effect is on their tooling,
etcetera, we do this in a single place at a single moment and
then help the rest of the teams be very productive with this new
technology. So that's one example, but of
course it goes beyond tools, right?
So tech is not just about tools, it's also about people, about
process. So if you look more
holistically, let's say they add at our developer experience,
what we want to achieve there is that we actually enable teams to
continuously improve themselves and this doesn't start all by
itself magically. So I also mentioned in my scope,
we also have some developer experience coaches that we that
we have and that we use throughout the company.
And these coaches really help teams to uncover their biggest
bottlenecks. So this can be through
workshops, but it can also be by looking at some metrics and, and
analysing that just really clearly helping teams to
identify, hey, what is the next step I can do to indeed get a
few percent more out of my process, Maybe have more stable
operations, Maybe look at the way we, we deliver to, to
production, How can we optimize that?
And that's something where we want to encourage teams to
ultimately get into the cycle themselves, but help them with,
with, with support from coaching support on the metrics side.
So given the insights in what is happening in the team and also
on the on the process side, help them to understand that by maybe
introducing a few more steps into their refinements or doing
something more on the retro sides that they can actually
increase the effectiveness of their team.
So that is something that's we we do with coaching, but also
with with processing tooling supports from this developer
experience initiative. Yeah, for me, it's funny that
you mentioned specifically developer experience because
when we're talking about hard skills and what makes a good
software engineer and understanding kind of the
foundation and things with regards to under the hood first
principles. I feel like everyone that helps
with regards to process, if that's a developer, experienced
person, a coach, a mentor, a facilitator, and also scrum
master, if they don't understand everything under the hood with
regards to that process or the intricacies of working together
and collaborating more of the soft skill side, then it stays
surface level and surface level with the rest of process from is
never good people and specific specifically engineers, they're
skeptical. I think by nature they might be
stubborn and if things don't work and are in the spiral of
continuously not working, they will get jaded with regards to
change and process change and anything there.
So especially this with the rest of process and facilitation, I
feel like needs to be done very well.
Have you experimented with the rest of what works well for your
context? Is it is it very data-driven or
is it more quality focused? It's a, it's a combination of
both. The people probably know about
the Dora metrics, right? So that is something that a lot
of companies use to actually look at, hey, what is happening
in team. So change failure rates, lead
time to change these kind of things.
But what most people don't know is that Dora also has a
capability framework and these capabilities, some of them do
also have metrics and are more quantitative, but some of them
are also very qualitative. And so they divide these Dora
capabilities into three major areas.
One of them is learning culture. The other is fast flow and fast
feedback. And especially if you talk about
fast flow, you talk about optimising your team processes.
There's certainly quite a few metrics that you can, can look
at your PR cycle times and things like that.
But if you talk about learning culture, this is very hard to
measure and, and as it should be, right?
So not everything is data-driven.
At the same time, we do want to enable.
There are also people to think about, Hey, what, what is, for
example, one of the capabilities there documentation quality.
What do I do in my team? Is that something that is
effective or not? You don't find that out by by
looking at metrics, by talking to people and to really
understanding, hey, do we have enough here in place?
For example, onboarding, if you have a new team member, do they
have enough to go on by what you have in your in your confluence
or in your developer portal? Or is it very much still in the
hands of people and, and, and hard for them to get out?
That is something that you that you can find out by by talking
to the team and, and, and helping out to set that up as a
second step. Yeah.
Yeah, I like that a lot. I feel like developer happiness
as a metric is something that is very hard to do.
But when you're talking about a solid process for onboarding
people, having this feeling of understanding, and there's a
culture of learning and entrepreneurship and people are
all effective in what they do, I can definitely see people being
happy within that team and within that organization
specifically. How do you accommodate for
developer happiness? Is it just by providing all of
this and then seeing what blooms or how consciously are you
working towards that? That has everything to do with
with finding and removing these bottlenecks, right?
So nobody likes, likes A-Team where there's very clearly a
bottleneck in, in some part of the process or something part of
the tooling. So we also run the developer
survey, for example, a few times a year to, to uncover in a more
wide manner in these kind of things.
Our developer experienced coaches who work with teams also
bring us back to, to our developer platform.
Hey, we noticed that for example, people have a hard time
finding out where APR documentation for certain
services that that is a signal that we can pick up and that we
can that we can fix on the tooling side and then bring back
again to the teams. So this this very much is about
identifying bottlenecks and taking them away step by step
and and also taking feedback seriously.
Yeah, I was going to. I was going to ask for me.
What I've seen is that gathering feedback, some people are have a
hard time doing that, but I think in essence, it's quite
simple, right? You can talk to people, you can
get surveys, you can do a team day and then have a brainstorm.
For me, the most important part, the most crucial part is what
you do from that feedback, how you take it with you and how you
implement it. Especially if this is in a in a
cycled manner. If feedback doesn't get
implemented, then people will question why they give feedback
at all. Exactly nothing is worse than
being asked to fill out another survey where you don't know what
what's going to happen with the results where it will end up.
So part of of the responsibility of my domain is to bring clarity
to that, right. So not just gathering the data,
but also showing, hey, these are some of the things that are are
across the tech team, a big topic, major theme and that is
also what we're going to focus on them in next quarter, for
example. So to really communicate that,
it's also super important to get people on board for.
Sure. Yeah, I love that.
Back to software engineering fundamentals we covered going
under the hood, really understanding things from our
first principles way of thinking.
Also figuring out what tooling is effective and not just
jumping on something that's new from a bandwagon perspective or
from a marketing perspective. What else is there with the rest
of building solid fundamentals? The other thing that I very much
encourage people who've gone through this tech Academy
program to focus on after they've had these, these more,
let's say, technological fundamentals on the belt is to
really understand the context that you're in and to be able to
be an effective product engineer, right?
So in the end, code is a tool. We're here to solve problems.
Are you able to independently look at a problem, break it
down, make sure that there's a sort of a design around this
that is validated. So the whole process of, of
bringing an idea into into a code base that is also very
important. And, and a lot of this is taken
away when you just start out, right?
So there's more senior people who look at this and they will
create tickets for you and then maybe write design documents,
etcetera. But making this step from from
coding to actually thinking like an actual problem solver to
really end to end be able to to look at something and and
realise it. I think that is that is not a
major step that you need to make in your in your development as a
yeah, as a software engineer. Yeah, product engineer, I feel
like it's a term that's more and more now out on the market,
especially with tooling where you have to think a little bit
less about the technical side. You have some magic and it
generates stuff. Product engineers is what I've
seen grow as a role. Specifically, is that what for
you? Is a product engineer someone
that can think end to end with regards to problem solving also
from business sense? Exactly.
And I would also add to that, see the long term impacts of the
things that you're coming up with, right.
It's easy to hack something in, but it's very hard to design A
feature in a way that's future proof, but that's also operable,
right. So it doesn't cause instability.
All these kind of things that are not obvious when you look at
at the user story, let's say that's, that's also for me what
a product engineer entails. Yeah, yeah.
Gotcha. Where do soft skills play into
this part? You mentioned the curriculum, it
has a soft skills part, but for example, if I draw a comparison
to booking, their training was very much tailored towards the
more soft skills side, which I thought was was interesting.
I like that you focus on 1st principles and fundamentals and
also you specifically look towards people that have already
done something with the arts side projects or actually have a
degree, CS degree that come on board.
I think that is also what allows you to focus on very, very early
in career, 0 to one year of experience instead of what we or
what I've seen where people look into kind of two to three years.
So you can still kind of steer, but where do soft skills play a
part in this from your perspective?
So soft skills obviously very important as an engineer and the
more you grow as an engineer, the more you are also exposed to
other stakeholders, talking to to people who may not have the
same background as you, as it is also part of what we what we
offer. We at the same time also don't
want to make too hard of a distinction between soft skills
and hard skills. In the end, even if you're in,
in a course learning about Java, you're still interacting with
each other there and understanding each other and
trying to see, hey, why are we doing this?
And then we, we do encourage these kind of configurations,
not just in the soft skills trading, but also on the hard
skills side and also encourage people to ask question hard
questions, right? So we're doing this.
What does this, what does this mean in in my team context?
What does this mean for my future?
These are all conversations that are related to the technology,
but maybe in themselves not very technological.
So yes, we do offer specific training also on the soft skills
side, but I'm, I'm a bit hesitant in making this super
hard separation. And again, also the the whole
mentoring aspect, for example, this disconnection between
people taking time together to to talk about not just
technology, but also what does it mean to to have a career as a
software developer? What's, what are some of the
future directions that you can grow into?
All these kind of conversations are also very important to, to
open up and to also have, have a meaningful connection in the
workplace. Yeah.
I'm very curious to hear your perspective on self study
because I've seen in the comment section and I know people
listening, they might not have a career yet as a software
engineer. They might be doing something
else. So they might be in education,
but especially people that don't come from a traditional
background. I saw a comment lately and that
was like I'm a taxi driver now but I'm learning web
development. What would your advice for your
kind of from a road map perspective, what would be the
start and how does that progress into them actually getting that
role? Obviously it really depends on
sort of the, the area of tech that you want to get into.
But in general, I would say whatever you do, start building
stuff from the start. So nowadays, of course with
chat, GPD and all kinds of other tools, it becomes even easier.
But the trap that a lot of people fall into is that they
watched like 30 hours of YouTube tutorials and think they, they
made, made a, made a good step, but haven't opened an, I haven't
opened an IDE or didn't write or try anything at all.
I think that is in the end, trial and error.
Just just make sure that you, you build stuff.
That is the most important part. I would say.
Obviously there is need for people to also engage with, with
content, right? So I'm, I'm myself also, I'm an
author of Pluralside, for example.
So I'm, I'm quite close to this and I get a lot of messages from
people who, who are on such a platform that, that get a lot of
benefits out of this. But you only learn if you also
start doing. I love that.
What is your perspective on AI tooling in this building frame?
Because if you're looking towards end goals, if my end
goal is to build a product or an e-commerce website, I can, I can
generate a lot of that stuff, but would I then learn how to
actually do that? No, I would achieve my goal in a
different manner. Would people from your
perspective that Start learning now?
Should they leverage AI tooling or how can they use it to learn
effectively? That's a great question.
And we're still finding that as I think, yeah, so, so my take is
yes, you can use it to to set up a lot of things for you.
I would more use it as a tool for validation rather than
something for for you to generate things.
Right. So if you are not able to
actually explain what comes out of this model and, and if you
are not able to understand why the code is there, then you will
have a very rough problem also maintaining that and extending
that. And of course then you can say,
OK, well then I have some agents, AI agents do that for
me. But ultimately there, there's,
there will be a gap of understanding where the model
trips up and, and you are not able to get it, catch it.
So use, use AI models to validate your understanding, try
to generate maybe a few things and see, do I actually
understand what's happening here and not ask the model right that
that's great. But don't focus on on getting a
polished product out of it and then getting sort of the, the,
the, yeah, the products there. In the end, it's it's really a
tool that you can use, especially if you're like taxi
driver who's who's going to learn coding.
It's a tool that you can use to, to build your knowledge.
You can also use very much to cheat, of course, and to just
sidestep all of this hard work of, of trying to understand
this. But I don't think that will in
the long run help you. Yeah, in the end, it's a lot
about discipline. Indeed.
Yeah, I feel like I've experimented with Cloud code and
it has a learning mode, so I can generate whatever you're trying
to do from a prompt perspective and it'll stop.
And I'll say you have to do this part.
That was great. And I haven't, I haven't done it
a lot, but the fact that it's there and they're experimenting
with not just generating but also facilitating learning, I
think that's fantastic. I didn't know that, and that
that sounds like indeed exactly something that you would want to
do at at the point. So then fill in the blank, let's
say, or take the next step yourself.
Yeah, yeah, absolutely. Thank you so much for coming on.
I've I've had a real blast. Thank you, President.
Cool. We'll round it off here.
Thank you so much for listening. We'll see you on the next one.