Hi everyone, my name is Patrick Aku and today's episode is all
about becoming a better software engineer and it turns out that
non-technical topics are more important than technical ones.
Joining me today is Farjat Dovari, software engineer and a
strong believer in collaborative software design, simplicity and
autonomy. It doesn't matter if you're
early in career or a seasoned software engineer, this episode
is for you, so enjoy. I think the best way to learn
anything is to build something. Yeah.
And especially if it's technical.
And similarly when when it comes to skills also, the best way to
learn is to put yourself in a situation where you have to use
those skills and try different things, fail and see what works
and what doesn't. So yeah, that's what I always
do. I I fully agree with you with
that. Like a clear goal, especially
from a learning aspect is really going to help drive and move you
forward to it. I mean, those goals have always
come kind of professionally because on a, on a personal
level, like, man, I do technical stuff professionally.
Do I want to do that on a personal level?
I usually go wide and I have other hobbies than more
technical things. But I really admire people that
like senior language want to play around with, they have a
really good use case and execute on that.
Yeah, that's really cool. Yeah, yeah.
Well, do you remember Stack Overflow like when, when it was
not like on decline because of the eye?
No, I don't know if it's really on decline, but I think there I
saw like some report that shows me too, things are not very
well. But back then what was super
interesting was that there was a community that was focusing on
teaching people or consulting people in identifying the
problem and solving that. And language didn't matter.
Like, if you looked at the contributions of top users of
Stack Overflow, you would see that they answer questions from
a wide range of, I don't know, tags and technologies.
But they always had this approach that they like
communicated back and forth with the person who asked the
question to understand why they have this problem and then avoid
the XY problem situation. Do you know about XY?
No, no. So XY is a situation where
someone who's like an expert or not an expert, someone who wants
to solve a problem thinks that the solution to their problem is
something they go and ask about that a special solution or that
special thing that they're stuck on.
And then that leads to waste of time and effort from other
people because others help with that particular thing.
Whereas this might not be the actual solution to the problem
that they had or or this might be the wrong problem to solve.
So it's always better to go with the real intention that you have
for the requirement that led to a technical solution and maybe
someone has a better idea or a better approach.
Yeah. And sometimes like the tools
that you're using, for example in the Stack Overflow, and we're
talking about, that's a regular expression, is a very popular
tag and people try to, for example, parse HTML with that.
But this is not built for that, right.
So HTML is not a regular language.
So a lot of questions are, Yeah. I mean, a lot of answers are
like, yeah, just don't use this, yeah.
They'll do that do. Something else?
Yeah. That's quite funny.
Like most of the questions that like that pop up for me is
you're, you're talking to a person that loves go, then XEB.
I also give go foundational trainings and recently I I did
that at bull.com, for example. And then people ask, OK, what if
I want to do XY and Z and go? And then it's like, OK, I can
answer that question, but it's more of a question of, OK, do
you want that? Why would you want that?
And that's usually the the approach I take.
Yeah. And then people are like, huh,
yeah, maybe this is not a good use case or maybe I shouldn't do
this in the 1st place. Yeah.
But then from a curiosity perspective, they're like, but.
But still, yeah. Absolutely, yeah.
But sometimes also trying dumb ideas or, I don't know, like the
the things that you think are not going to work is very
rewarding. It is, yeah.
Like you do something just to learn what goes wrong and how,
how far they can go. Yeah, in terms of being wrong.
So that's also a good way of learning.
I think so. I think so too.
I mean, for me, I'm always trying to balance technical
depth and technical skills versus other skills that I think
I need as well. And maybe it's because I'm a
specific type of person, but I see a lot of things that are
interesting to me. Like curiosity is a big driver.
I've done a year of product management and I think that
still is fascinating. Yet I still miss the kind of
hands on experience. And I like technical depth, but
I don't have that like inkling to do it on a personal level.
Like with my personal time, I like facing challenges, not
professionally and like solving those goals either by myself or
with the team. Usually with the team gives me
more fulfillment. So balancing than technical
skills as a software engineer versus other skills that I think
I need has always been tricky. Yeah, yeah.
Indeed, Yeah, I like that to use the word balance because there
needs to be a balance. And I think we had some
conversations earlier about like, how do you like balance
that technical stuff and non-technical stuff?
And yeah, looks like, yeah, a common misconception here is
that a lot of people think that building software is mostly
about knowing your tech and how to use technologies and how to
put things together. But yeah, all other skills like
that are required. If you like, put them on the
table, maybe they get a bigger portion of your timer.
I don't know, like they might be even more important than the
technical things to do something right or to to build something
that's useful. Yeah.
I I wonder if that's so I think I agree with that.
Like if I look at my time spent previously on successfully
deploying software to production, whether it be a
first release or continuous release or a new added feature.
I don't know if it's the fact that I was in an organization
with aligning with people with different kind of goals and
agendas and interests. That that's why like the
non-technical side or the non-technical skill was not
necessarily needed. But more of the aligning people
or figuring out what the right value is or what problems to
solve. I don't know if it's because of
me being part of an organization.
Let's say if you and me do a startup and we have just the two
of us, probably we align quite quickly and then we start from
from scratch. So the building part of it, more
of the technical side is going to be at the forefront, Yeah, I
think. Yeah, Yeah, I think so.
Yeah. Well, so if when you have a
smaller team, of course, the challenge of communication or
like splitting the roles is less important because like there are
two people, everyone knows that they need to take different
roles. And then you probably have the
same mindset or same goals when you want to start a business
with somebody else, right? So that's very unlikely that you
want something totally different or need to sit like, I don't
know. For hours.
For hours and then and talk about work.
Yeah, yeah. But when when the organization
gets bigger, the challenge of people also increases.
So you have to find a common ground with others, make sure
that everybody knows where they need to go, make sure that
there's safety for everyone to speak up and come up with new
ideas. Of course.
Right. So and, and make everyone happy
so that they don't feel like they, they, I don't know, code
monkeys and just executing orders and, and these are all
the, the non-technical aspects of building software or building
anything. I think so, yeah.
It's not very technical, especially at scale.
Yeah, I mean, I was wondering, because we had this conversation
before the show and I was wondering why that is the case,
right, That there is this notion that grading software is like a
super technical job. I mean, I agree to a certain
point where the people aspect is huge.
I wonder if it grew like that, because right now if you look at
knowledge, like a lot of stuff is out there online with AI, we
now have intelligence as well. So when we're trying to figure
out something from a learning perspective, information is out
there. And maybe 20 years ago it was
not as much out there. I mean, definitely so.
And it has gradually increased. So getting something up and
running was already a skill in and of its own.
And now getting something up and running gets easier and easier.
So it's I think more about solving the right problems and
finding alignment and then being productive and effective with
what you're doing. Yeah, exactly.
I think there's a set of problems that require a lot of
special specialized knowledge and like a lot of focus on just
the technicalities of how things work.
Like for example, if you create a database or like the kernel of
an operating system. Of course, that's mostly about
like the technicalities of how things work.
Even then, you still have to have like a community and a lot
of people who want who you would want them to contribute to the
project and and all sorts of things.
So again, people aspect is there too.
But if you're solving business problems, like in a company, of
course, it's, it's less about, I don't know, like building
something super technical. And it's more about, like you
said, talking to stakeholders, understanding the problem,
prioritizing things and, you know, making sure that you're
going in the right direction. Like sometimes things are not
very clear, but at least you have to take bets and make
decisions and then collaboration, of course, like
the taking these bets become super important in in this
setup. And, and you do this with all of
your yeah, like communication skills mostly and and use less
of your coding skills to to move forward in there.
Yes. So I think it has to do with
scale and the types of problems that you're trying to solve.
Yeah. Yeah, I wonder if for someone
starting out like they will absolutely likely focus on their
technical skills, right, Because usually that's the barrier of
entry. Can we execute?
Can we see that you learn? Can you think on the fly?
But the communication, yeah, it's going to be huge aspect of
that in and of its own already. I'm wondering what your advice
is for people that are more so starting out, what would be the
the tipping point where indeed they they kind of have hard
skills and then they focus more on soft skills.
Because I've also seen people where they think they know a lot
of hard skills and they focus very much on soft skills.
And then they try and leverage because of, for example, product
managers. They might have a certain
technical background and they use that to drive decisions
forward, but it's not really their responsibility anymore.
So like, I feel like that tipped in the wrong skill then with
regards to hard skills and kind of the responsibilities they
have. Yeah.
Yeah, well, there are two, I think you mentioned 2 two
things. So 1 is like the separation of
responsibilities, which is an interesting topic on its own.
So let's talk about this after the the career path.
But if you look at the, the software engineering as a career
path, of course, when you're an entry level person joining an
organization or a team, the expectation of the organization
and, and the expectation of you from yourself should be to just
like have like have influence just on yourself.
Like learn how to work with the code base and how to do the,
the, you know, basic things that they, that are expected from
you. So this is the entry level.
Then you grow a little bit like you learn the skills and you
manage to have like a balance between, you know, using your
technical skills and like talking to different people.
And then you become a Meteor engineer.
And as a Meteor engineer, well, your area of influence is mostly
your team or your peers. And well, the expectation from
you is always on that level. So you have to have the, the
right skills to be able to communicate with the people that
you often work with. And after working with people,
of course, you get a feel for how things work and you know who
you should listen to. You're probably have some other
senior people in the team who make some tough decisions and
what not. And then you become even more
senior. And then there you have have to
have more influence. So the, the the more you move
forward in your career. Of course, you have to find ways
to communicate with a broader set of audience and and talk to
more people. And then your communication
skills need to be stronger and stronger.
And then you probably even won't have enough time to use your
technical skills as much as you had like when you were a mid
level or an entry level civil engineer.
And that's why a lot of, I don't know, architects or you know,
people who have to talk with many, many, many different teams
And people don't write code. And like, for example, a product
person, of course a product person needs to talk with a lot
of stakeholders and do a lot of coordinations and make decisions
and whatnot. So even if that person has
technical skills, probably they can contribute, but maybe it's
not their job to do that anymore because they're more interesting
things for them to do. I've thought about it like,
because that's the part I miss. And then indeed, what you
mentioned really really was also my head.
Like there's only one person that does all the other things
basically. So my time is better spent doing
that rather than scratching this this itch that I have for
fulfillment. Yeah, but also I don't like
separating concerns or like the the the interpretation of
separation of concerns when it comes to some technical stuff.
So for example, they say that well, I want one person to take
care of database and for infrastructure and I want one
person to take care of, I don't know, something else in
technical stuff. And then you create basically
silos and communication overhead between those people and also
about talking with with the stakeholders.
You know, so when when you say that, yeah, an engineer's job is
to just like write code and then turn specifications that are pre
written into like some solutions.
And then the job of like a person who communicates with the
stakeholders is just to talk to them and then write those
specifications. I don't think that's a winning
combination. So there needs to be some kind
of overlap or at least some involvement like across these
different aspects for like for something meaningful to happen.
Yeah, I fully agree. Like I've been experimenting
with that. When we kick off a new milestone
that we're going to research and design that I want to involve
everyone. That's what I've done a few
times. But then I've noticed that
involving everyone, the full engineering team very early on
where things are very unclear, their feedback has been or
things were very unclear. Yeah.
And I'm like, yeah, that like it makes sense.
So now I'm experimenting with only involving a few people.
And then when things are more clear, like communicating that
more, which would be more like the time spent on communicating,
then later on is bigger, but things might be more clear, but
then we might not catch everything in advance.
So it's it's kind of trade-offs that I'm trying to figure out.
I've also like I fully agree with you where we do need
feedback from stakeholders fully allow the team.
I mean it's not even an allow. They know basically they can
reach out to whomever. But then the opposite, that's
where I'm like, OK, sometimes that's not always the best thing
where people on stakeholders directly reach out to the team,
not just through product person with regards to priorities or
when is what done. And then that kind of amps the
the stress level of the team so that I'm a bit more cautious of
maybe a bit more mindful and, and guarding in I would say.
Yeah. I would say like going through
product person is some kind of solution to a problem, right.
And if you look at the problem is that there's no structure or
no common understanding of how things should work to build a
software. And when a stakeholder that has
like some kind of urgent need and has no context of everything
else that's happening to the team, reaching out to the team.
When that happens, of course, things could go wrong, right?
But then this is the problem. And and you could also solve
this in in multiple different ways.
So for example, if you have some collaborative sessions with
those are stakeholders where everyone are there and you do
this like very often. And of course they can still
talk, but they also walk out the room very happy because they
they Co create with the team and the team kind of understands the
perspective of the stakeholder and you kind of like let them in
into the process of building the product.
So I think this this is a more effective approach than the
proxy approach. Of course I know that you didn't
mean the proxy. Yeah.
I think a very, very common pitfall I see in many teams is
that of course, because they want to be very protective of
the priorities, they put proxies.
Yeah. And then that's also like a
roots, too many problems. I think that's what I did early
on, like because product management was new to me.
I was like, well, it makes sense that things go through me.
Like that's what I've seen from the software engineering hat,
let's say. But then I realized that I'm,
I'm a bottleneck, like, and if I'm not available, things either
come to a standstill. People don't know what to do.
So then opening up those communication lines has been
really helpful. Yeah, indeed, Co creating also,
I mean we haven't had any Co creating sessions, but complete
transparency with regards to demos, what we're doing, what we
are going to do, what works well, what doesn't work well,
our learnings as well from retros, that's all been shared.
So that really helps. Yeah, I think get a common
understanding of what, what goes on.
Yeah. And the heft of my time has been
educating other people how to create a software.
Basically, yeah. Yeah, exactly.
When, when there's a road map and we have a million items
running in parallel and everything is high, the
priority, I'm like, this is not how reality is.
Basically, we have to scratch that, wipe it off the table, and
people get really scared. Yeah, yeah, yeah, yeah.
But then we have a better way of working, although some people
are happy because we deliver. Yeah.
What is promised? Exactly.
And that's like how the team grows, right And stakeholders
can grow with you as well. Like they they learn how to
think along with you and everything will become better as
as you do it more I think. Yeah.
But for me, the the funny part is so I can leverage the
technical experience to kind of go against certain processes
that have been put in place or certain status quos because I
have a vision of because this is what I believe in.
If someone doesn't agree, we have a conversation basically.
And I'm not black and white, like I am quite flexible with
regards to my thinking, but I also believe it's something.
So that's what I stand for, and that's what I'll fight for.
Yeah. For people that come into
positions and they might not have the right background, I do
see a lot of people kind of going with the flow, following
status quo. Why are we doing this?
Well, that's what I got taught, or that's something that we've
always done. And that's where I'm like, yeah,
we don't really improve or we don't really innovate.
Yeah. And sometimes I think that's a
shame. Yeah, I think the worst thing
that you could do to yourself or the environment that you operate
in is to just like follow. And yeah, following is good.
Of course, if you want to change anything or if you want to
challenge the status quo, it's probably best to like, yeah,
walk a mile in other people's shoes and then start to talk
about, yeah, of course. Like at some point you have to
be a little bit critical and then use your critical thinking
skills to come up with some improvements for yourself or
your environment for the product that you're working on.
And of course, like, yeah, if if you just go along and.
Yeah. Don't challenge anything and
it's not good for you and not good for the organization and
the environment that you operate on.
Yeah. I feel like when you touch some
kind of the different stages in your career, like very early on,
looking at your own sphere of influence, trying to be
effective and productive in what you're doing and solving the
right problems. And then kind of going beyond
from that team aspect. I think that's where it starts.
When you're looking into, OK, what makes this team effective,
not just me as an individual, but what processes or what ways
of working are there and what's my opinion on them?
Because I feel like not everyone has an opinion.
But when you actually look and see and think, if you were to be
responsible, would you do the same things?
That's when it kind of, you might think, oh, that I'm
reinventing the wheel, but for me, that's where it starts,
right? If you have a through critical
thinking, if you have a good idea, I like the flexibility of
trying things out and experimenting.
And teams that experiment, for me, they're always learning
basically. So that's definitely what I
advocate. For indeed, yeah, even sometimes
those experiments are the things that have been tried before.
And maybe there are some somehow controversial or, I don't know,
the industry might think that, yeah, this is not the right way
of doing things. But still, like there's value in
trying different ideas and, and seeing why it doesn't work and
how of course, like there, there needs to be a limit or a balance
in there. But yeah, I think you should
never say that we're not going to ever try something because,
yeah, well, I'd read somewhere that it doesn't work, you know,
and. That's the like, that's the sad
thing from certain leadership or what I've seen going from
organization to organization, There are there is kind of this
aspect of do I let people experiment or do I prevent
mistakes that I know are going to be mistakes?
And I am more so of the mindset of let people make mistakes.
You give advice if they don't follow it, let them learn.
And then there's kind of the balance of how big of a mistakes
that you like allow and stand for when it comes to security or
impacts critical paths that maybe you you're a bit more
strict. But when it comes to something
innovation, like, yeah, people learn, let people fail and and
grow from there. But I've also seen people where
it's like, no, this is what I know, which means I've tried it.
And then that's more of the black and white thinking, which
I don't like. No, and and you won't be able to
influence anybody to follow the like let's say you're a leader
somewhere and and you want to lead other people to follow a
vision. And if they don't experiment
some kind of pain, sorry, experience some kind of pain, or
if they don't experiment with different solutions that they
have in their minds and understand why they don't work
that way and why they should go your way, they will never listen
to you. So one, one thing to do is to
like enable the team to do like experiments and fail fast
without making a lot of cost or, I don't know, like casualties.
And then yeah, let them after they, they realise and learn
what could go wrong, then you tell them, hey, you know, I have
a solution for the problems that you're facing.
And then they will listen to you much better and they will follow
you. And that's how you also gain
credibility. And when people say like
leadership without authority and whatnot.
So that's I think like in line with this way of working and not
like the approach that they, I say that you should do this
today. And, you know, listen to me
because I say so. And I have tried everything
that. Yeah, yeah.
Yeah, like the collaboration aspect, it's, it's really what I
enjoy, like thoroughly talking to people, figuring out what the
right problems are to solve. Testing also in production.
When when I first joined a project and we did a lot of AB
testing, honestly my mind was blown.
It was like, oh, everyone thinks it's this now it's this
e-commerce. Someone clicks on a product
tile, it opens up in a new tab. From a user perspective, I hate
that. From a conversion perspective,
it worked wonders. Well then you don't have a leg
to stand on. Basically, that's what we do to
optimise conversion, even though personal preference, yeah, they
keep that out of there, but that that's clearly something I
enjoy. I've also worked with engineers
and I don't know where that mindset sometimes come from, but
they really get the energy out of technology innovation with
regards to technology. And for me, that's not always
what a business needs. There's a very specific niche
where you really solve interesting problems from a
technology standpoint. I recently had a conversation
with Bofan Laut. He's the CEO of WE V8 Vector
Search Database. Very interesting problem.
You're creating a database with vector search capabilities with
regards to embeddings, those are probably very specific technical
problems when we're talking about the majority of
businesses, they're not going to be all database companies.
They don't all need that level of expertise, which means the
engineers that work there need to solve business problems, and
those might not be the most interesting problems from a
technical aspect. Yeah, or, or some business
problems that they face or some problems that customers bring to
them could stem from, like, for example, the wrong use of their
technology. Or maybe because they have more
experience with certain things, they can nudge their customers
in a direction that they use the technology in a way.
Or they change the problem a little bit and, I don't know,
refine it and hammer on their problems so that they can solve
it with the tools in a much better way.
And that's also like something that's super important.
And well, yeah, so it's again, we got back to the point where
it's not technical even when it's in a very technical domain.
What I've seen is that some people like those types of
engineers that I'm describing, they still try and find a way to
work on innovative technology professionally, even though
that's not what a business might need.
And that's where I see things sometimes also go wrong, where
you see like an exotic technology all of a sudden be a
backbone of an infrastructure or an organization where it's all
of a sudden hard to hire people or find people that really know
what's going on in this set of the code base or this set of the
technology. I don't know how to solve that.
Like, for those types of engineers, would it be better if
they're not in that organization or an organization which tailors
more towards very specific niche problems?
I don't know how to solve that. But I have noticed that not
every business problem is interesting for engineers.
Yeah. It's yeah, I guess it's when we
talk about the individuals, of course, like when when we talk
about the behaviour of an individual and when it doesn't
match with what you expect inside an organization.
The easy answer is to say, yeah, well, this engineer is, I don't
know, having some is not a match or is not a fit, but it's always
a little. I think it's more nuanced than
that because the environment you're in also has a lot of
influence on how people work. Imagine that you work in an
environment where there are so many like shackles around you,
and then you're not really allowed to experiment or talk
or, I don't know, like you're not involved in anything.
So these people will probably fall back to playing with
technology and want to just touch the technology because
that's their that that's the amount of authority that they
have and they want to use it and they want to feel good doing
those types of things right. So if your organization gives
like space to people to grow into having that type of
mindset, then you can expect people to like show that
behaviour and then you can like work on growing that aspect in
in their behaviour. So I think this is also very
important when we are talking about individual performances
that your environment should also cater for it.
Yeah, yeah. The environment having influence
on like the behaviour of people is something I've really
underestimated. I've been in organizations
where, I mean, coming from CIBA, we go from organization to
organization. You have preference in how you
execute, which is sometimes against processes or status quo
by virtue of trying to be effective in executing.
And that blows people's minds. Sometimes it's like, oh, this is
what you can do and this is no longer needed and this is
actually not useful. It's quite, quite funny to have
that because from my personal side, like I go from
organization to organization and I have done that quite often.
And for people that have been within the same organization,
they are kind of, yeah, not part of the wallpaper, but those
processes are like ingrained in their behavior.
And it might be eye opening to then have a fresh perspective.
And I don't know what would happen if those people would go
to another organization and kind of bring that like experience
with them. Yeah, yeah, indeed.
Yeah, I think it's funny to have that realization.
I don't know if I would advise like going from organization to
organization, but there is a lot to learn from looking behind the
scenes of of what goes on. Yeah.
And outward facing, I always wonder.
Well, I think the disadvantage of going from one organization
to another too fast is that you don't stay there to see the if
like the the outcome of your decisions or other people
decisions that you have witnessed during your time in
that organization. But you know, if you manage to
somehow find a way to keep in touch with people and like we
say, customer intimacy for like a part of the, the ZBIA core
values, of course, like if you managed to find a way to do
that, then of course you can like learn and take those
experiences somewhere else. What I see in consultancy a lot
is that people join an organization, bring like a
solution or, or a toolbox of the solutions and they build the
same thing as the other organization and they move on
and do the exact same thing. And then the whole industry gets
affected by that or like a a large portion of clients and
companies get affected by that. But that's not like the best
that you could do, you know. So it's always good to find ways
to get some meaningful feedback about what you're doing and be
critical about your solutions as well before you move on to your
next challenge. And I think that's also very
important for people to keep in mind.
Yeah, it's interesting because for me, the the best we can do
is very subjective. Yeah, and it needs to be a match
with what the organization wants.
If we have an amazing technical solution, but that's not what a
business wants, because a business wants speed and
validation of assumptions, then it's kind of a mismatch, right?
And then looking from a certain lens you can say that's an
amazing solution, or looking from another one you can say
that's a complete mismatch, which makes it not an amazing
solution. Yeah.
But also thinking along with people that have those
specifications and want those solutions can be very rewarding
and useful. Like if you just go to an
organization and then do what they say without talking to them
and maybe like teaching them how to, like, think about some
aspects that they haven't thought about, then they might
actually change their opinion and say, Oh, no, actually I
don't want this solution. I want you to advice me on what
solution I need. And then you Co create.
Yeah. And then it's much better, I
think than this execution. Yeah, this is like a, an
amplified version of the Stack Overflow example that you gave.
Yeah. Where you there's a certain ask
and it's like, is this the the right way to do it or should we
do this in the 1st place or what are the other options?
Yeah, on the table. It's very hard though, when like
time is tough and it's crunch time, people usually panic.
And that's exactly the opposite of what I think you should do
because then it's like, OK, the decisions that we make, they
matter, or really do they? At least we have to verify the
assumptions that we have. And that's going to take time,
but it's time well spent. Basically.
If we go in a certain direction, it's a bigger bet, which means
the losses will be more severe. But that's usually what I see
happens. Like panic mode, someone says
this direction, it's like all in it's code time.
Exactly. That's also very human though.
Like The funny thing is there are a lot of human aspects
within organizations. I wonder, like maybe it's
because I've been recently talking to a lot of people that
are in smaller organizations and more have more responsibilities
just by virtue of being in a start up phase, what that
environment looks like. Because then you're, you're
dealing with a smaller set of people, less people problems, I
think. Or maybe when there are
problems, they're more severe just by virtue of having less
people. But the environment's very
different, which means also the learnings from an engineering
side are going to be very different in the 1st place as
well. Yeah.
Well, so you see that, for example, a start up with seven
people can challenge the biggest organizations with many, many
people and unlimited resources. And the reason I think is kind
of related to the the way that you describe this start up
environment, people communicate with each other better.
The kinds of problems that they run into are very visible
because that's like a very small group.
And then people who can take action are usually part of this
group in which they notice that these problems exist.
And, well, if, if you want to solve a problem, you're just
like one call away or, I don't know, like a few steps away from
the, your colleague's desk to talk about it and then address
it. But in a, in a large
organization, so a team might be suffering and the, you have to
wait for the next, I don't know, performance review, I don't
know, metric review session to see that, Oh, this team actually
suffers based on the metrics that we defined.
And then you have to go down and then talk to that team.
You know, sometimes these hierarchies and those processes
that we have, I'm not judging them, but in general, like the
pitfall or the problem is that they, they can like make things
very slow and, and they might kind of like turn into a
handicap for you to understand what's happening in the
organization and which areas could use some improvements.
So yeah, I think that's, it's, it's very nice to have a lot of
resources and a lot of people to rely on, have backups and
whatnot. But at the same time, it's very
nice to be effective and reachable.
Yeah, yeah, yeah. Zooming in on that hierarchy
because I, I agree, that's also what I've seen.
I've now seen organizations trend more towards engineering
managers, for example, that are always have a certain technical
aspect of their role and they try and steer for 5050.
And then it's probably up to the person what that balance looks
like. But I like that that there's
people responsible for personal development and growth within
certain teams that also do hands on work and that are not like
fully all in in only people management, which I think is a
good thing for organizations with more hierarchy.
That's where I've seen leadership or managers actually
be out of code. And then it's very hard to get
by in like to get even on a level of empathy, like figure
out what people are dealing with or from a person that's a
software engineer, Like having an understanding that my manager
understands my problems because if they don't experience the
problems, then how can they? Because the problems from 10
years ago, not the same problems anymore.
Yeah, indeed. Like those are more problems
that I see with that type of hierarchy then.
Yeah, indeed. Yeah, yeah, exactly.
Your so there's a book called It doesn't have to be crazy at
work. So it has some very good ideas
or I don't know the controversial ideas as well
about how how you should run a business.
So it's about people who run the company base camp and also they
have a service hey.com like these, these different services.
And so in one of the first chapters, there's a sentence
that I like a lot. So your company is a product and
you're responsible for building this product.
People inside the company need to know how to use this product
and your product needs to have a good user experience.
So think about this and then apply this.
And then of course, like it doesn't matter how large your
organization is. So you have to you still have to
create some process or think about not processes or like
think about a mechanism there for detecting problems as
addressing them as soon as you can and then running the whole
business more efficiently. So I think yeah, it sounds.
Fascinating to me, yeah. Like from I think an early age.
Well, I think this is what I wrote down on my high schools.
Like at some point I want to own my own company.
And I feel like now time is catching up.
I am talking to people and it's very inspiring to see how they
do that and like having a company and treating it as your
product and like building and growing that out.
I still think it's an ambition of mine.
It's something that at some point I'm going to dive deep in
and and try and experiment. I wonder if for you it's the
same because you have a lot of organizational knowledge, a lot
of theoretical knowledge. I don't know what your ambitions
are with regards to your own path.
Yeah, at some point, at some point.
Well, yeah, I like. Well, I'm not sure if if at this
moment I'm ready for the challenges of running a full
business. And of course it needs some
knowledge on that front too. So I'm mostly like involved with
technical problems and not necessarily like those
technical, but tech roles, you know, like staff engineer, like
principal engineer, you know, these types of roles.
And to run a company and to know about business, it's just like a
whole different world. And of course, at some point I
will be ready for that. I'm going to definitely try
that. That's nice.
I like that we share that ambition.
Like I talked to another colleague of ours.
I'll introduce you in a bit. I think he's he's in now, but
what's holding him back is like a really good idea.
And I could see that like, I think I have many ideas, but to
be like, OK, this is the idea I want to execute in is hard for
me. I've seen very successful
organizations building around and tailoring towards developers
by virtue of having like an open core.
Yeah, either starting a community around something open
source and building a platform around that.
Yeah. Or starting with something
closed source and then opening it up and building a community
around that. Yeah.
Tailoring towards towards developers.
Yeah. Seems like a very attractive,
Yeah and fun business model to be honest, because that's when
you also kind of keep that technical as core of your
business. Yeah, I think if I built
something that would probably be related to developer tooling or
you know, something that that that's that has technical people
as the customers, like some B to B business model.
Yeah. But you mentioned something very
interesting about the ideas. I think in this age and in this
era, like having an idea, well, it's very good, but that's not
the the most important thing. So it's everything is like
collage, right, Because people have figured out a lot of
different problems. So it's it's about building a
product. So you need to figure out what
would solve a problem or, or which like portion of the market
you can target, find a niche, do something different and then
build a user brace around this. And I think this would be more
challenging. Than like necessarily coming up
with an idea, at least to me, you know, and then like building
around that idea. So, so having the sense of what
how to build a useful product and how to build a user base
around it, I think it's much more challenging.
Yeah, and I feel like like looking at that and that's my
ambition. It's not a skill that I'm
developing. And if that's going to be the
most crucial part, it's like, how do I develop?
That is what I'm wondering recently.
Yeah, I I saw a video that opened AI released I think
yesterday. When it comes to a new
functionality they have, they call it deep research where you,
for example, from a product sense are analyzing the market
and you're saying, OK, this is my context, this is what I'm
looking at. Can you give me data on XY and
Z? And it might take 10 minutes for
this program to actually crawl whatever information sources it
can find online or not, and then give you the answers that you're
looking for, actually doing the research for you with regards to
market segment, user penetration and so on and so forth like
that. For me, the tuning is getting
more and more advanced to indeed figure out what the right
problems are to solve. And that's for me, very
exciting. Yeah.
Well, finally very exciting. Yeah.
OK, so here comes an interesting or controversial take on AI.
Now, I think many of the problems that are currently
being solved with AI are not really problems that you should
with Gen. AI mostly, I mean like are not
the kind of problems that you should solve with Gen.
AI, OK. But like the the type of
problems that require search like in a very large like corpus
of data, I think that's that's where these tools can excel.
And you know, of course, like this tool that you describe
sounds like a very, very good application of this
functionality. Yeah, yeah, I'll definitely try
that. Well, you have to pay 200 bucks
a month. You have to have like the the
highest tier license, but it will be available at some point.
Yeah. Like I, I agree with you.
Like I like the the funness of generating content.
I think I don't know how much it has influenced social media or
my LinkedIn, for example. I, I see people make a lot of
assumptions that, oh, this is bots or this is fake and this is
generated. I have no clue to be honest.
Like for me, those are all assumptions, but it's the fact
that people have that tool like very, very readily available.
I can see how that happens. Basically for me, indeed it's
going to be leveraging whatever manual processes and, and
automating that. But even that from what I've
seen, like the embeddings in a vector search database, it's
very similar to like search and keyword rankings and stuff like
that. Like they are still software
engineering problems that we're, that we're having and that we're
solving. Not necessarily data science
problems, although data science people are now actually playing
around with Gen. AI and LL apps, which I think is
quite interesting. Like, that's how a lot of those
facets and worlds are colliding and coming together.
Yeah. When I played around with
embeddings and I was playing around and a colleague actually
said, yeah, this is what Elasticsearch does basically
under the hood. And this might be slightly
different, but then you also have variances.
And how do you split up your embeddings yet there's different
variances. And that's also quite relatable
to how you do search. Yeah.
I thought it was quite funny. Yeah.
So one question for you, do you
think that with all these advancements, the number of
skills that a person as like a as a someone who works in an IT
organization or as someone who calls themselves a software
engineer is increasing? Like for example, maybe 10 years
ago you would be like a back end developer, yeah, or a front end
developer or a database engineer.
Now you are all of these things at the same time in one team.
The newsletter example that you mentioned in the beginning is
another top ten engineering skills, right?
So maybe like in the future it's expected from.
Do you think that it's the case that it will be expected from
software engineers to also know those kinds of skills and then
wear more hats than they are wearing today?
Yeah, For me it's going to be depends on the organization.
Like what I've seen is when especially during COVID for
example, or people are being hired, people also being laid
off. And the people that were laid
off are were more specialists in the type of work they're doing,
right? If I have a generalist that can
do kind of a little bit of everything and times are tough
and I have to make decisions, then a specialist that can only
do one thing is someone that I might let go of compared to the
other basically. And now with tooling and
intelligence, I think learning is going to be faster.
So it depends on, yeah, the organization, what is expected
of you as an engineer. Indeed, I think you can do a
lot. But I've always believed that
with a small team, you can achieve a lot.
That's even without AI, like what the cloud provides us in
kind of reducing a total cost of ownership from a team and
certain decisions that you can make in your infrastructure to
have things up and running smoothly with almost 0
operational overhead. I think that was already there.
So now if we go even smaller. So if I don't look at a team of
four people, but a team of one. Yeah.
A team of one is also risky, right.
If I have software as the backbone of my organization, I
have one person responsible. That person gets hit by bus
screwed. Yeah.
So then am I going to have two? Well, if both are on holiday,
and that's also a problem. So I will always have to have, I
think, a a team of people that executes.
Yeah, but now the the cross functional aspect of teams I
think in with the recent advancement can can be stronger.
So like, instead of having one person who knows about one
thing, you could have like multiple people who can, who
might not be specialised in everything, but who can have
like a wide range of skills or who, who can deal with problems
in different domains. And I think this is kind of
exciting for the future. I think so too.
Like the for me, that team aspect, I hope is going to play
a very crucial part in that because a team that knows each
other, that knows, for example, I know what your preferences
are. I know what you're good at.
I know what you're learning path is, what you want to grow in, in
ambitions. You know that of me as well.
And we have kind of the experience to communicate
effectively with each other just by virtue of having done many
things and going through like rough times and good times.
Basically. That makes a team resilient,
right? And new people can come in and
people can go, but the core of that team will be stable, I feel
like. Which means that if it's a
problem and you and I both haven't kind of figured that out
yet, we'll be like, oh, we'll figure it out, right?
Because I feel like you can be way more confident in the team
and your role in that team then maybe sometimes in an individual
because you have your own insecurities.
You might be like, oh, this is a whole lot of responsibility for
a whole lot. I don't know.
So that team aspect is going to be very crucial, I feel like.
Yeah, exactly. And that the whole team can
actually go and solve problems instead of splitting the problem
and saying, hey, you do this part, just focus on this part
and the other person just focuses on the other part.
And then you in the end, the great yeah things.
Which is going to take the longest.
Yeah. Like for me, the only problem I
see is like this chicken and egg, where there's a lot of
knowledge out there. You can learn quite quickly.
But this foundational knowledge that you need an experience, you
will always need experience. And for people that are coming
into organizations, indeed, if they get that generic role or it
is expected of them to kind of do a little bit of everything
just by virtue of having intelligence.
So knowledge and learning goes faster.
They will miss the experience of having done that specifically
for a little bit longer. Yeah, that's a good point.
Yeah. And I don't know if that's a
valid concern, but that's what I've seen.
Like if I were to be responsible for front and back end and a
little bit of product, I've done all three, like as a specialist
sole responsibility, which makes me more comfortable to do that.
And then within a team, that can be my comfort and that can be
other discomfort in other parts of the team.
But then together you figure it out.
If you have a new person which hasn't had any type of
experience but all of a sudden starts very generalistic, I
don't know how that's going to grow.
Oh, so maybe their balance is to swing between the different
roles. Like, sometimes it can be a very
specialized person in one area, and then you can go back to
becoming like more of a generic person or a generic role.
And then if you keep doing it, then you kind of like accumulate
some knowledge. And at the same time, you are
not disconnected from some areas that you often don't touch when
you're like an especial, like a specialist focusing on just one
aspect of the job or the problem.
So yeah, based on this conversation, I think swinging
is a good thing. Yeah, yeah, I think so too.
The funny thing for me is when I started out, like I I might not
have had the best foundational knowledge because I didn't have
a a traditional education, computer science, but then I
find myself being very good at executing.
But then certain things executing, I was like, man, this
is taking a long time. I have to Google things and I'm
not quite sure with regards to what I should do or which
direction like. And that's when I realized like
my foundational knowledge needed some tweaking.
So then I swung back and forth between executing and working on
that more foundational knowledge.
And that, I think has really helped.
But now you're in a position where you might not have the
right foundational knowledge yet.
And that's going to be, I think, crucial where we figure out how
to get the right level of foundational knowledge to be
comfortable and executing and then learning on the go.
Because the biggest skill, I agree with you, is still going
to be learning. And now it's just going to be
amplified and you're going to have more tools to learn faster.
The time is still the same, which means, yeah, it's going to
be a funny, funny way of working, I think.
Yeah, indeed. Cool, Man.
I've really enjoyed this conversation.
For a judge, this was a lot of fun.
Yeah. Same for me, I have lots of food
for thought. Yeah, same here.
I'm definitely going to re listen to this because I think
this was a good one. Yes, thank you very much for
hosting this. Thank you.
Thank you for coming on. I'm going to round it off here.
If you're still listening, if you're still with us, like the
episode, If you liked it, let us know in the comments section
what you thought and we'll see on the next.