Hi everyone. My name is Patrick Akio, and if
you're interested in speaking at conferences, are curious to
learn how sharing can help progress your career and you
love software architecture, then this is the perfect episode for
you. Joining me today is Bertrand
Schreifer, CTO at Open Value User group leader at the NL JUG.
That's the Netherlands Java user Group, and I really enjoyed this
perspective actually. He's seen the insurance and outs
of organizations, has spoken at many conferences and even
organized a lot of them as well. So I'm sure you'll love this
one. Enjoy.
I don't know what I want to speak on, but goes to technology
really excites me. So I think I could like figure
out what a topic would be there that I think would be
interesting and then hopefully other people think as well.
But that's kind of a hurdle that also keeps me from applying and
keeps me from being on top of things.
Yeah, well, I, I do regular like public speaking, mentoring
sessions. And this is one of the topics
that always come up like what should I speak about?
And the point is usually you did interesting things, but they may
not be interesting to you anymore because you did them for
a year and you know everything about them, right?
So it usually helps to, to talk to others about the things you
did, little ideas you have and, and you often get it wrong.
So often I think something super interesting, nobody wants to
hear it. Sometimes I think something is
boring, but I submit it anyway. And, and everybody wants to hear
it. So that's something I learned
over the years. And how much work do you do kind
of going into a submission? Do you already think of the
full-fledged thing or is it very rough prototype?
Usually it's, it's the initial write down of a global idea I
have for a talk. So it's also like a little
experiment or test to see like how how people will will respond
to it. But in general, some rough ideas
on what I'm going to talk about. And then sometimes after
preparing, I shave a little bit on the on the proposal, but not
too much. But this is usually the first
step in idea that I have and and then not until it gets accepted
I start preparing it. OK, what if that because that's
kind of what what keeps me I think from applying as well.
Like I've done conversations at meetups, but it's mainly been
meetups and I've hosted conferences.
Hosting is easy for me nowadays, but like actually submitting and
going for talks specifically, I like writing now an idea, but
that also kind of is, yeah, in touch you would say stock after
the door basically, which is a good thing.
But then what if that idea doesn't really pan out and then
I've kind of committed to something that I can't really do
in practice or do in the talk? You can always say no.
OK afterwards. If you get accepted and you feel
it's not going to work, better to say now than when you're on
the stage. Right, exactly.
I didn't even think that was an option.
Well, the conference is not going to be happy if you if you
decline after get accepted. But if it's not like too short
before the conference then usually it's OK.
They have still time to to invite other people.
Yeah, yeah. Gotcha.
Would you recommend people to in general apply to conferences
also as speakers and not just go as participants?
Yeah, sure. Yeah, yeah, yeah.
Regardless of who they are, what kind of their.
You need to at least want to go on the stage, right?
And we'll take some time to to get used to it, to become
comfortable in it, I would say. But yeah, definitely.
I think it's it's one of the the better things you can do to
progress your career in tech. In what way?
In terms of getting getting out there in front of people and
without asking anything in return, sharing your knowledge
and helping others in order to dive deep enough into a topic
that you'll be able to explain it clearly.
And in order to meet people who can also enrich your own
experience with with something, build your network, learn about
use cases, etcetera. So if, if I present about a
topic in front of an audience, then I'm going to be pretty sure
that there's 50 or 100 or two people who are interested in the
same thing as I am. So I sometimes have amazing
conversations with some of the people in the audience
afterwards where they share. How do they apply this?
I don't know advice or tool or framework or whatever.
What are they doing, doing with it?
So it also helps in validating or invalidating your own ideas
there. Interesting.
So it's both from a knowledge perspective, because you have to
be deep enough into a topic to be speaking on it.
Enough to be enough to be interesting to to the audience.
Yeah. And then the networking part to
meet people, what is kind of, because I think you've gone to a
lot of conferences, we just talked about kind of the amount
and it's reduced, but it's still a lot like what have you gotten
out of that networking aspect of things?
Because for me that's networking is still very vague.
You kind of make connections and it's an investment in the
future, but you don't know what the return is.
And you give with regards to knowledge sharing, but there's
not necessarily return, right? You do this because it's a
passion of yours. Yes, that's the Jennifer be the
the main ingredient of why you do it.
But to, to give an example of return.
So I, I, I did, I was quite invested in Vertex as a
framework for, you know, building reactive stuff.
And this is what 10 years ago, it was still fairly niche and we
were one of the one of the early companies working with Vertex in
another. So there wasn't many people I
could talk to. So I went presenting about
Vertex. So I met pretty much the whole
Vertex team at Red Hat at the time, people building and and
basically evolving Vertex there. And once I, I got called by a
potential client who had in Belgium a problem with Vertex.
And they, they asked me to come help them because I was the only
one within a couple of hours travel time that they had that
they could find that knew something about Vertex.
So I took the train, went there in in Brussels and what they
showed me the problem, ran some tests, made some hypothesis, but
I couldn't really figure out the problem.
But I I I could kind of like reproduce the problem.
So went back home frustrated, wrote everything down, wrote a
reproducer, posted it on the Vertex mailing list, went to
sleep, wake up the next morning, 20 replies of people that
already solved the problem. So I could just, I could just
send whatever they replied to the client.
Yes, it's, it's done. We're happy now.
So this I think was the power of, of knowing and involving
those people because they knew well me as a person advocating
for for Vertex. So they're OK to, you know, when
I asked something to, to effort to put some effort in in helping
me and this turned out helping the client as well.
So I think that was pretty, pretty amazing to to see.
Yeah, that's really cool. Do you use that more often that
when you have a question where you think, OK, kind of I'm stuck
and maybe your team is also unsure that you go and reach out
towards the community? Yeah, definitely.
And I usually also already know the people I need to reach out
to. That's nice.
So yeah. So if it's, you know, I don't
know something, something in Spring that I know the people
actually building stuff in Spring.
If it's something about Java, well, there's a couple of
million people who know about Java, but I tend to also know
that the the Java language architects at Oracle, right?
So if it's like a really deep question nobody else can help me
meet me with, I can always reach out to the actual developers
building the stuff because I met those people at conferences.
Gotcha. I want to circle back to kind of
the topics of a talk that you see in conferences, especially
because this is going to help me because as I see topics, they're
either like depth with regards to something technical, they
could be experience based, this is what I solved in my
organization or if you're a consultancy at my client or it
could be something controversial.
It's kind of a hook, right? Are is, are architects still
needed or what do you think with regards to duplicate code?
Like it could be anything that can spur controversy because
that would that's what keep people get.
Yeah. I smiled a bit where you said
our architects still needed, because one of the things that
was, well, relatively funny to me is that about two years ago I
keynoted a a relatively major architecture software
architecture conference. And the title of my keynote was
Do we still need architects? Yeah, so it was remote, but I
could still some people could still see some people there.
So I I went live and I see those people.
Please tell me that it's not no right.
My point there was that architecture is evolving and
changing, you know, with, with getting software out there
faster and faster with cloud as a platform, with AI, that we
need to be more involved as architects and be more looking
into quick feedback loops, validating our ideas as opposed
to, I don't know, 10 years ago and you just drop down a big
design and have the team built it, right?
So, but I'd like to, to, to get at least a little one, not, not
really controversy, but to, to, to spark something in people
because it also gets them engaged, right?
If, if they're go come to my talk with the feeling.
Well I'm not sure if I agree with this guy is going to say
that they definitely going to listen with what I'm going to
say. Gotcha.
From a person that would then submit those talks, does the
topic necessarily matter? So if I go technical and I go
depth with regards to tech or if I go more experience based this
is the problem, this is how we solved it.
Or more with regards to this is my opinion on a topic you might
think is controversial. In the end, does it matter?
Or in the end, I think the, whether a topic is interesting
to a conference or an audience is, is not really your problem,
right? It is the problem of the
organising committee to figure out whether they think this,
this is interesting. So I, I often get questions from
people who want to apply to J Spring or J4, like, do you think
this is interesting to the conference?
And I said, well, I don't know because the, the programme team
is 8 people. I'm one of them.
So if I say yes, well then 12 1/2% of the programme committee
thinks it's interesting, but but the other like 90 something
percent, I still need to think something about it.
So just submit it and we'll get reviewed and you'll see whether
you get accepted or not. And I've often been wrong there,
so I don't know. 10/10/15 years ago I learned about the Galen
Framework, which is a framework for responsive layout testing.
You can test your layouts of your application in different
devices. It was being used at Marc Platts
and eBay and I think at the Deutsche Real Worlds.
I thought, wow, this is pretty cool because we often in our
team have stuff that works on desktop but not on mobile or
something. And this framework helps so
well, I submitted it to 8 or 10 conferences.
Nobody wanted to hear it. And I think that's weird, but
OK, maybe, maybe it's not for the target target audience this
conference. And then I had this presentation
about continuous delivery and DevOps that I created to to
introduce the topic to a group of not so technical managers.
So it was about principles of Coutis, Olivia and DevOps.
I had this presentation already laying around.
I didn't think anybody would find it interesting.
So I submitted it and I remember getting accepted for DevOps UK
and then it was a bit puzzled. And then it, it got, well, one
of the most favorite sessions in its time slots.
I was even more puzzled. The room was full.
I thought, I explained this, all this stuff that I thought was
basic and the audience loved it and it gave me a great rating.
And I was like, Gee, that's interesting.
It was something that that I felt everybody knew, but but
probably not. And this also started me
realising that there's also room for more like entry level topics
in in conferences, so also a relatively popular talk.
And it was boy it was called Debugging Distributed systems,
but I could also have called it. How does the Internet work?
So stuff like HTPTLSDNS, firewalls, ICMP, whenever 2
services cannot connect, what are the things that can, what
can be wrong and how can I debug it basically.
So this was also for me something that came naturally to
me because I've been, you know, playing with computers and
networks for years. But there were loads of people
who didn't have this background who this was super interesting
there too. Yeah.
From then the perspective of the organising committee, do you
break down conversations or talks that people have submitted
into like those categories with regards to knowledge or also
with regards to topics more experience based, more let's say
in depth tech or more controversy?
Yeah, I'd say that the the the goal of of any prone committee
is to create a interesting, relevant, diverse and balanced
programme. Sounds like a challenge.
Yeah, no, definitely. And also because usually you get
flooded with hundreds of proposals and for example for J4
we can only fit about like 50 or 60 in the programme.
So then, well, how how this happens for, for a major
conference like Jay fold is, well, we get hundreds of
proposals. We have 8 prone committee
members. They all rate every proposal
individually and then we get like hundreds.
They have to go through all of them.
Yes. So this is starting to, to get a
problem now because it's hundreds.
I think last year it was like 400 or something.
So other conferences often have a program committee per track
and then it's less work because you only need to do like 50
talks in the data track or something.
But we're still doing, everyone does everything until people
start complaining that it's too much.
And then we get we get back together, we sort all the talks
based on rating and then we basically select the top rated
talks. So these are talks that as a
committee we find, we find interesting, relatively
interesting. And then to create some, some
balance and diversity in the programme.
We there's tracks in, in programmes, so for example like
Java language, serverside Java web and mobile security data and
AI. And then we have kind of like a
way to to decide how many talks per track do we want.
So based on what we find is relevant, based on previous
years, based on submissions in the call for papers and then
the, the process, how we work basically is we go, OK, let's go
to the Java language track. We have 6-5 or six spots to
fill, let's pick top 6 ones. OK, are these, are these all
good? Are these interesting?
Are they not 2 talks by the same speaker, etcetera.
So once we've done this all per track, we have the same approach
for the different session types. So just a regular presentation,
hands on lab keynote, short talk, etcetera.
Once we have this, then there's we do an overall loop on
figuring out do we have reasonable diversity in terms of
speakers, in terms of topics, in terms of companies.
So we, we, we also don't want to put one company on stage with 10
talks and then another company gets 0 talks and then why do
they have 10 and we, we get 0. So this is an interesting
puzzle, but in the end, I think we're we're doing a relatively
OK job there. Obviously that the
representation of people on stage is not the same as the
representation of people we see in nature.
So to say, you know, there we still have a lot more, well,
white male speakers on stage than than people from, well,
different backgrounds maybe. But there's something we're
working on as well to to get this to as balanced as possible.
Interesting. As you were laying it out, I was
thinking it's actually in a weird way similar to how I found
people for the podcast. Like there's people that submit
and they're like, OK, I want to talk about XY and Z and usually
I say it's in person and then they're like, OK, that's too
bad. So that's for me kind of a
barrier of entry, let's say. But in any case, I do think of
specifically topics and I think of specifically people and I
think of diversity also with regards to topic and people and
background and not having the same company kind of represented
over and over. But it's on a way, way smaller
scale. Like I'm not talking about
hundreds of submissions. We only have close to 200
episodes, but it's over the span of four years.
So like the scale of things I can relate to, but it's just
it's way bigger in this case. Funny thing is the only thing
that I think is a mandatory and people have said I don't do this
and then I've said we don't do an episode.
It's kind of an intro call because it is more like a
conversation. It's more personal.
I want to know that the other person I'm speaking to I can
actually have a, a proper conversation with.
And I don't know if you have the time and bandwidth to do that.
Like on a conference, you can't do that, right?
If you have hundreds of proposals, that's not something
you can afford. No.
So it's really you go on kind of the scoring mechanisms and kind
of the tracks that you have and what people have written down
specifically. And probably then also network
and knowledge of speakers and past speakers I guess.
Yes. So there's basically 2 tracks in
how we evaluate a potential proposal.
It's purely on the topic and the content.
So it's the topic relevant, is the abstract well written and
then the speaker. So what are the street
credentials of the speaker? Do we know the speaker?
Has the speaker spoken at our events before?
What do we know in ratings of the speaker from events before?
If not, have they spoken at other events that we see as
relatively high regarded? So if somebody has has spoken at
Devox Belgium, I can be pretty sure that they're going to do
relatively well at J4 as well. Can we find videos online from
those people to see how they present?
What's their presentation style? If not, have they included a
video themselves basically, well, explaining what they're
going to talk about and kind of see like what person they are
and how do they speak? Because it what it may sound a
bit, well, let's say polarizing. But if somebody submits
something that looks super interesting, but I see a video
on them and they have such an heavy accent or they are not
really fluent in English, where as an attendee I cannot
understand what they're saying, they're not going to make the
audience happy. So as a prone committee, I also
want to get a good feeling that somebody's going to do well on
stage. And one of the key things with
us that I need to be able to understand what they're saying.
So one thing that I often also teach in the the speaker
mentoring sessions that I do with get a recording of yourself
speaking somewhere up on the Internet on the open where you
can share it when you matter, if you propose something.
And even when there's no such video, sit behind your computer,
record a short 5 minute video of you presenting something and,
and put this in your proposal. Because then the committee can
see how your stage presence will be if you clearly explain stuff,
if you're, if you're speaking in a good pace.
And this will definitely help your your chances on on getting
accepted at at any event. Yeah.
Have you ever let someone through with regards to a topic
that you thought found was super interesting, but they had like 0
St. cred? Yes, people still go through.
Yeah, because especially at J4, we want to also see it as a kind
of like a a breeding ground for new speakers.
So many of the Dutch people, if not all who are now speaking on
big stage internationally in the Java world have started speaking
at J4. So these may be speakers that we
know from the speaker metric sessions we organise or somebody
just has a really good story and, and, and then we think, OK,
let's let's just go, let's just go for it and see how it turns
out. So you cannot fill an entire
conference with these people, but, but usually this turns out
quite, quite well. And we even sometimes see people
presenting their first talk ever ending up in like the top ten of
best rated sessions. And then they, well, they, they
either have had some practice before outside of our reach or,
or just natural talent, someone going on stage.
That's really nice. Yeah.
How we kind of communicate it with Incepia is it's, it's very
easy to share something within a safe environment, right?
And that could be your organization, could be your
friends and your colleagues, and just having a session on
something that you thought was interesting is 1.
Then you can go to meet ups, which are like a little bit more
low key than a conference. And then the conference is like
the full blown thing. So you have the ability to work
your way up, which I really like.
Yeah, Yeah. So that's also generally,
generally my advice, start small group of friends, group of
colleagues inside your current team or whatever.
Then go to internal company events, go to meet ups.
From there, move on to conferences.
I've also met people who, who've seen the other way.
They're like, I'd rather go into a stage for 100 people I don't
know than for, for 10 of my colleagues, because my
colleagues are all really good and, and they, they might, they
ask questions that I, that I won't be able to answer.
Right. So this, this is something also
I, I hear a lot in, in starting speakers like, but what if
somebody, you know, gets up and asks me a question where I don't
know the answer to and say, well, in real life, if somebody
asks you a question that you don't know the answer, what do
you do? Well, I say, I don't know.
So how about if at a conference, somebody asks you a question,
you don't know the answer. You say, I don't know.
Yeah. But then they do feel I won't be
an expert. Well, you're only an expert
about the stuff you know, Right. So if you don't know something,
fine. Yeah.
What if they're going to shout it's you're you're lying.
It's rubbish what you're saying? Well, then there's something
really easy you can do to counter this.
You just, you look at them, you smile and you say thank you for
your feedback. If you thank for somebody for
the feedback, they or they, well, hopefully they appreciate
that you thank them. And, and, and one other thing in
this aspect is the audience also wants you to succeed.
So the audience will also help you basically shut down a, a, a
hackler in the audience, even if that ever happens.
And I've, I've not seen this happen, happen much, but it is a
matter of, you know, trusting in your knowledge on the topic and
knowing your knowledge. And there will always be people
who know more, who know different things.
And this is fine. I've been, I don't know,
presenting something about low testing where Kirk Pepperdine,
one of one of the most influential people in in
performance tuning in a Java world was, was in the audience.
And well, asked after after I asked him like, what do you
think of it? I said, yeah, it was nice.
I like this and this I, I don't agree what you said here and
there and said, OK, that's fine. And I'll I'll try to incorporate
into my next talk right. So in general, be confident in
what you want to share and about the things you know and and
realise that you don't know everything but there's nobody
who knows everything. So I often also like going to
talks of people on subjects where I know a lot about to hear
their opinion. Maybe I don't agree with
everything they say, that's fine.
I'm not going to stand up and shout it to them.
It's it's their story, it's their experience.
Yeah, yeah, I like that a lot. It's one of my favorite things
about like the tech community, you know, it's own, is that
knowledge sharing is such a big thing and it's organic, right?
It only works if people do it and people can take, but people
also give back. And then there's learnings and
let's say career opportunities for giving back in that way, but
they also do it not when they're an expert.
Like learning as you or sharing as you learn has become a thing,
right? I'm picking up this new thing.
This is what I see and it helps from all angles.
And people definitely root for the people that share in that
way. I really like that.
Would you say that sharing even when you're starting out?
Because I know a lot of people listening in, they could either
be early on in their career or they're looking to pivot, or
they're already, let's say, on a more advanced stage.
From my perspective, sharing in all aspects is valuable, but
then also I could see it being daunting, right?
If you don't know something, how can you share about it?
Like that's a different playing field, yeah.
So one of the things I'd like to, to, to give to people I, I
mentor is when you think about topics, think about something
you did in the past months or the past year or, or whatever,
and think about the, the things you learnt there, the, the
mistakes you made, the first you had.
And then try to compress this in, in a 30 or 50 or, or one
hour story, right. And then what you're doing
basically is you're compressing one year of experience into one
talk and giving this to the audience.
You're giving them a gift. You're preventing them from,
from making the mistakes that you made.
You're sharing your learnings with them.
You, you give them a lot more than just how to, they can also
do on the Internet. So they're really like talks
where where that could basically be a how to in the in the
Internet because can people can look that up and do it in their
own, in their own pace. I do like people sharing an
actual problem scenario project. Also, I wasn't this project.
This was the problem we have. These are the potential
solutions we thought about. This is how we picked one.
This is how we solved it. This is what we learned.
This is what we want to do in the future.
If you give this to somebody, they're already weeks ahead
compared to where you were starting with this.
And it doesn't really matter what topic it is, as long as the
topic is relevant and interesting for the audience.
So I think for pretty much everything you you would like to
share, there is an audience. You do need to find the right
audience, obviously. So I don't know.
You're not going to talk about what's new in java23@a.net
conference, for example. Yeah, that's what I was
wondering. So like a topic I had as you
were explaining, this is more from my personal experience, but
I can I can talk about anything. So that's the thing, what I've
done professionally is for the last year, it's been a year and
a quarter, I've switched from software engineering to product
management. And I do think there's some
insights in there, but then it's been a while.
So I should I, is it an option to consolidate, let's say that
learning experience and that could be a talk is that I like
talking about experiences because you're an expert in your
own experience. Like that's the easiest part.
If it's a topic and I have to go in depth then those insecurities
of I might not know everything is more apparent there than when
it's an experience based talk. Yeah, yeah.
So your experience experience is unique to you.
So it's a unique thing you have in the world that nobody else
had or maybe you know, like a twin brother who sat next to you
for the past year. But most people don't have that,
especially not at work, right? So definitely and also think
about how what, what stuff did I learn while gaining this
experience? When questions did I ask myself
what problems did I run into? This is all valuable information
for people. So for example, you going from
software development to product management, an interesting take
would be like introduction into product management from a
software developer's perspective, right?
So to know as a software developer what challenges play
in product management and how can you help your own product
manager as a software developer in in overcoming those those
challenges. In the end, it's not about
shouting to your product owner that this is not the right thing
to build, it's helping them to maximise the value that you
bring together for for the company that you work for.
Yeah, yeah. I might do something with that
actually. I think that could be fun for
sure. I want to circle back to
architecture because I think the the topic of architects still
needed is definitely something that's been top of mind for me.
Specifically because I see the, let's say, responsibilities of
architecture more and more moving towards a team of
engineers where there's no person that only does
architecture. There's no one person that is
the architect, right? But it's a part of a skill set
that engineers nowadays have. They have also been in bigger
organisations when there is an architect and they do draw a lot
of pictures, which in their term everyone wants to do the best
for the organization. I'm very naive in the fact that
I believe that. It's also it makes it simpler
because I don't have to think why are people doing this?
I think they think this is best for the organization but it
might be a mismatch with the rest of reality, right?
The people that do hands on development know what the
current state is, as well as have an idea of where things fit
in, and the people that don't have that, they might draw
pictures in terms of what's best for the organization, but
sometimes there's a misalignment there, which is quite
challenging. How do you see the role of
architecture evolving? Is it something that is still a
role in and of its own where people are hands off, or do you
see this moving towards engineering teams as well?
Yeah, it's just an interesting topic that I have strong
feelings about. So one of the, the best
architects I've worked with in my career were people who knew
what was going on in the development team and the
challenges that developers faced.
And one of the worst architects I've worked with were people who
were disconnected from this from years ago.
Like there, there were a good developers 10 years ago and
then, and then they got promoted, promoted to being an
architect. And then, and then they were now
just now drawing stuff and, and throwing stuff at teams.
So whenever you encounter somebody who does this in your
organization, you can basically activate my favorite pet beef.
And this is a seagull architecture.
So seagull architecture means when the architect is circling
high above the development team like a seagull.
Well, imagine the development team being going to the beach,
being on the Boulevard nice in the sun, having French fries.
The architect circles high above, he drops down every now
and then, he shouts, he, he drops his shit on the team, he
steals the French fries and flies back up again.
Right. This is seagull architecture.
And the, the problem with this is that the shit is only going
down. So the, the feedback loop should
go back up. And I think if you're working as
an architect outside a team, you should be actively searching for
this feedback from the development team, The stuff that
I designed, does it help you build those things that the
business needs? Because that This is why we're
here as any architect or software team to help a business
reach their goals. So the main task for any
software architect is to figure out which stuff matters to the
business. And this can be functional
requirements, non functional requirements, scalability,
availability, but also stuff like, I don't know, time to
market, which people do We have time, money, all those complete
sets of stuff that matters to a business.
Figure out those and translate those in an architecture that a
team can build. And when they're done, they help
the business fulfil their goals. And therefore, well, you can
also make mistakes. Maybe you make the wrong choice.
It doesn't work for the team or they're working, it doesn't help
them reach their goals as quickly as they should.
Then they should either come back to you or should go to them
and ask them, OK, is this helping you?
No, we, we chose this architecture or this framework
or whatever, and it's not really helping us because of this and
this and this. OK, we evaluate your solution
space for whatever you decide and figure out maybe one of the
solutions that you potential solutions is a better fit to the
actual world down there. But you do need to understand
what's going on there. Otherwise, well, basically
you're you're designing solutions in a vacuum without
knowing where they actually solve something.
That's where it gets complex, I feel like, because if there is a
role of the architect, I feel like if that is a role in and of
its own, usually they oversee multiple kind of solution
landscapes with regards to multiple teams.
And then where what problems should be solved in an
application landscapes which also which also spans over
multiple teams. It gets very complex.
And if you have multiple requests like that, like the
time and effort to actually do this the right way, which is to
engage with the teams, there's no bandwidth for that, I feel
like. Yeah, this is an increasingly
bigger problem in increasingly bigger organisations, right?
So if there's just one team, one architect, maybe they can even
be part of the team, help the team with their daily business.
If an organization grows bigger, you do need some some alignment
over teams. So what they always like to,
well to, to see myself as an architect responsible for
multiple teams is, well, it works better in Dutch, the line
and the line, basically the line over teams and the glue between
the teams. So made sure they sort of work a
little bit in the same way while still given the freedom to solve
stuff how they want, but also make sure they're not solving
the problem twice in different ways.
Make sure they work together enough.
So I think within a group of teams that to some extent work
together on the same product, it can definitely help as an
architect to basically align architecture guidelines, maybe
software development guidelines. How do you do stuff?
Which stuff should we share or not?
Should we solve something generic or not?
Which tool set do we use, which frameworks, libraries to to make
sure that they can exchange knowledge and exchange people
when necessary. Effectively, in general, you see
big difference in organisations in the responsibilities of
architects. So there's also loads of
different forms of architecture, right?
So it can be like, if you're really down at the system level,
software architecture, but maybe a bit more on the business side
there solution architecture, maybe a bit more on the reuse by
build sizes, enterprise architecture.
And then there's data architecture, information
architecture, infrastructure architecture.
So it, it highly depends on also what the needs of the
organization are, what's what type of architecture expertise
you need. So I tend to tend to mainly
involve myself in, in software architecture.
So the organization of a system and its components and the
interfaces with other systems. But it doesn't mean that there's
not a role also for somebody who thinks more in, in solutions and
how to, to turn business solutions in active applications
or services that we can build to, to solve those problems that
the business have. Yeah, I see the responsibility
of, let's say software architecture usually more and
more so be distributed within the same team with regards to
their own landscape. And then what it takes to make
their software run the way that it needs for a business can also
even in a responsibility, lie there.
So then it's kind of a distributed responsibility.
And I don't think that's a bad thing necessarily.
It's something that I've seen grow kind of in the developer
tool belt, which I think is a good thing as well.
I guess a distributed responsibility can work as long
as there's like an escalation part to make a decision in case
of conflicting opinions, right? So definitely if your teams are
are mature enough, they can do most of the architecture
decisions themselves. So what I'd like to do there
when I'm responsible for multiple teams is to create
basically frameworks or not a software framework, but a
decision framework like these are the the boundaries within
which you can make your own choices.
So well, we focus on let's say Java as a core technology.
But if, if you want to do Kotlin in your application, that's fine
because it still runs on a JVM. But if you want to do Go or
pythonor.net, we need to have a conversation.
We're, we're standardising on using Spring as a framework.
And then whatever you use in Spring is up to you.
If you want to do, I don't know, Caucus, we need to have a chat
because I need to validate whether your, your problem is is
especially enough to basically validate using something
different than the stuff we standardly use.
And this can help you basically control the the complexity of
your landscape in terms of technology, frameworks,
whatever. And this can also help keep your
landscape simple because in the end, if you give people complete
freedom, then you will have as many solutions as you will have
opinions or people in the end. And when one of those people
leaves, maybe nobody knows about that one framework anymore.
So it's also about making sure that your landscape stays
maintainable from a technology perspective in the long term.
Yeah, yeah, I get that. That's probably best for the
organization and for the business and hopefully also for
the engineers in the long run. There is definitely a matter of
freedom that engineers enjoy and they can also be into choosing
the technology stack or framework or language.
In that case, the best if it aligns with the business need,
right? This is the best because we have
to solve XY and Z and you just do it better that way.
If we're talking about resiliency and it has to build
once and then run forever, might gravitate towards Rust, which
actually is language that's tailor mate to specifically
enforce that, which is very nice.
But yeah, if that's not the case, then you need still the
buy in of the engineers and it takes specific engineers that
kind of are OK with not having the freedom to choose a language
or to choose something like that.
Yeah. So I just last week I was at A
at a meet up and I spoke about making architecture decisions.
And basically what I explained is that, well, one way I like to
approach those is to figure out all the requirements that apply.
So technical requirements, functional requirements, but
also constrains business and organizational requirements.
And then figure out what's my solution space.
And I'll make a deliberate trade off analysis on which, which
solution solves my problem the best.
And there it's also in the end, how do I get the biggest chance
that I'm going to accomplish the business goals when doing this?
And then afterwards, I had a conversation with with a couple
of people and one of them asked me like, yeah, so how can I
invince my architect to do X instead of Y?
And then I said, so have you, how have you tried convincing
him? Yeah, I, I said that that X is
just better than Y, but he doesn't understand me.
And I said, I understand that doesn't understand you.
So what you need to figure out is what drives this person?
What is important to them? Do the are they responsible for?
I don't know availability or performance or something.
Then go go find arguments that will help convince them that
that X is better than Y in terms of those things that matter to
this person. It does need to be true.
So you don't need to, you don't need to need to come up with
fake arguments, but find out what matters to a person and
then you may be able to convince them.
And this is also something that I like from that, that there's a
book that Greg or Hope wrote the the software Architect elevator
and what he says basically that as a software architect, you
need to be able to write the elevator between all levels of
your organization. So you need to be able to talk
to developers, to infrastructure people, to product people, to
engineering managers, to product managers, to the CEO, the CIO,
the CFO. And but let's say you want to
convince people to start doing continuous deployment or what
you're going to say to developers is we're going to do
continuous deployment, which means that every change you make
is going to production automatically.
And whenever something is wrong, you know right away, it's in
this change. OK, fine, I get quick feedback.
You go to the infrastructure people, you say we're going to
do continuous deployment, which means that you don't need to do
the borrowing deployment stuff anymore.
You get to automate all kinds of stuff and you can focus on
improving the monitoring stuff that you always want to do, but
you don't need to focus about deployment stuff anymore.
There you go. Talk to an engineering manager
or product manager say we could we can we use our time to market
because the feature gets deployed is live in the hands of
A use as quickly as possible. You're going to talk to the
Chief information security officer and you say we're going
to do continuous deployment. This will helps us roll out
security fixes quicker. You talk to the CFO, we're going
to automate everything. This will cut costs in terms of
we do, we're not rolling out stuff because it's all
automated. You're going to talk to the head
of HR, you're going to say this helps us in attracting more
talented personnel if we have this arranged really, really
well. So in the end, it's about
finding those arguments that matter to people and the
argument that we should do just this because I like this.
That's that's for not many people that have had an
argument. No, but also the.
It's not just in figuring out what is best for the business in
a more technical sense, it is getting buy in of out of all of
those departments specifically, which means that kind of
communication and empathy, figuring out what the other
people like are responsible for what makes them take and what
would make them happy or actually how to get that buy in
is a very big part of the role. I.
Yeah, and it's the same with with, you know, convincing
people you need to figure out what drives them.
So what I'd like to give an example.
Somebody has arguments and you want to basically counter those
arguments. Well, you let's say that those
arguments represent furniture. Furniture basically.
So if you want to, if you want to know which I don't know,
poles of the chair that somebody is sitting on, you need to saw
off, you need to 1st know which one are they leaning on?
Are they leaning on the back two poles?
Well, you saw those away, the person falls down.
But if they lean back and you cut out the first two poles,
well, they'd still be still be sitting a single right, right.
So it's also figuring out what, what matters to people.
And what we often see is that people don't give up their real
reasons or arguments in the first conversation.
So somebody is, is basically giving resistance because they
don't want to tell you that they don't want to do this new thing
because they don't know about it.
And, and in the end they're just saying it's stupid, we shouldn't
do it. We've never done it this way.
So if I've had this with suggesting a new fronted
framework somewhere, we, we suggested moving to this
framework to the front end architects on Friday and the
front end architects said no, we shouldn't do this.
What we're doing now is fine. It doesn't have any improvements
of what we're doing now. We shouldn't do this.
And then I said, well, that's weird.
So I was talking to a colleague and the colleague said, yeah,
probably he doesn't like it because he doesn't know it, but
let's let's wait a couple of days.
On Monday, I talk to the same guy.
Yes, let's do it. It's amazing.
I love it. So it turns out that he said no
because he didn't know it in the weekend, dove into it.
So then in the end, the the good stuff that was coming out of it
and, and then said yes on Monday.
So it's also about figuring out what drives people and and why
are they opposing an idea or, or or a problem or whatever you
have and then figuring out what matters to them and convincing
them on on this aspect. This responsibility of
architecture or actually being an architect is something
something you can grow towards. I think a starting position that
says a software engineer is a great start to actually then
start moving towards that if that's what you want to do.
But what stage in a career would you advise people to actually do
this? Because for me, from my
perspective, early on, I was very much like focused on
isolated problems and trying to do that the best I could.
And then I realized that the best I could is not even
necessarily what we need. So then it's validating and
seeing actually is it the best that we need.
So you go a little bit beyond kind of your own scope and then
that's the team scope. And then you go, OK, is it the
best that the organization needs?
Otherwise we shouldn't even build it like that.
You broaden your scope bit by bit.
And I feel like architecture is always this zoomed out lens that
over arches many things. So I don't know if people
necessarily early on should look into that or necessarily pursue
that or if they should have more hands on experience first.
Yeah, in the end, I think our software architecture is about
making decisions, and you make decisions by carefully
evaluating requirements and alternatives.
So the more experience you have in different situations, the
better you'll be able to understand the problem, probably
if you've seen it before. The better you're able to come
up with potential solutions because you've seen potential
solutions before, and the better you'll be able to make
trade-offs between those different solutions because
you've seen stuff that work and it'll work.
So I think the, the, the, the easiest way for somebody,
somebody wants to go into an architect role is to stay in one
place for a relatively long time.
So I don't know 3456 years because it's quite hard to start
on day one coming into a company as a software architect because
you don't know the company, you don't know the tech tech, you
don't know the people you don't know manage to them.
But if you if you grow from from a junior role to a media role to
a senior role, maybe to a tech lead role, then the step to
becoming a software architect in that company is a relative 50
small step because you know the organization, the context, you
know what matters, you know what problems are there and then
probably even be even if you haven't seen much different
fields in in your work, you know probably enough with context to
make sound decisions for this company.
And then from the, the senior role, it may be relatively
doable to go to a software architect role.
If you want to go into consulting and well, do only
software architecture roles. Well, you first need to have at
least some credibility as A and some experience software
architecture. So my advice for people who want
to do like, let's say full time consulting and architecture,
make sure that if you've at least completed 3 or 4 projects
where you work both as a developer and a software
architect, because then you see those different areas, different
technologies, different stuff that worked and didn't work.
And then you can be really valuable for the company and,
and making broader decisions. So basically, so I guess it's
all about growing both in designing stuff and taking
decisions, but also knowing enough about an organization to
actually be able to make those decisions.
Yeah. For me, what I, what I thought
of with regards to software engineering was at some point
you become very much expert in a domain, right.
And I always use E com as kind of the domain.
If you've built an e-commerce application, you become better
at it and then the challenge of that is very much maybe not
necessarily there anymore. So you'd start looking into
other domains or potentially other also buckets of knowledge.
So for me, it was going from software engineering to product
management. And still now I don't know if I
want to go product management more or if I want to go back to
software engineering because I feel like with AI I'm missing
out and things are evolving fast.
But I feel like from an architecture perspective,
especially if that's in the same organization, if you get a
better understanding of what the business needs, then you become
really valuable for that organization and you've become
very good at your job. But then indeed is it?
I feel like you need to think of what fulfills you.
Are those the new challenges of going in and out of
organizations and kind of making that your own, making impact and
then leaving? Or do you want to do that
continuously also for the long term?
That's for me, the trade off. I, I think you can be valuable
both as a narrow architect and the white architect.
So I worked at a company that did product development for 6-7
years and I grew there from, from junior to media to well,
basically the, the, the part I was describing before to a
software architect. And I was relatively valuable
for this company because I knew a lot about the landscape of the
company, the people, how everything worked, what matter
to the company, to the customers.
And I was able to make pretty good contextual decisions that
made sense for the company. But then I figured out that, OK,
I know a lot about this narrow tech stack, narrow applications,
narrow domain, narrow people. I want to learn more.
And then I, I, I went to go to consulting and then in my first
consulting gig, I, I was a bit surprised that I couldn't work
there as an architect because I had loads of architecture
experience, but it was super narrow.
So then I first needed to do a couple of more projects working
as a senior developer, maybe as a tech lead.
And then I was able to grow into an architecture role in those
projects, but only after a year or so because I still need to
know the people that attack the context.
And after that, doing this for a couple of times, well, then you
get a reason. Then you transform from a, a
narrow deep architecture experience to a more, a more
broader experience. And once you've seen different
situations, different scenarios, which stuff works, which stuff
didn't work, then you can also lean a lot on, well, there's
this like basic hard knowledge. I know that for this client,
this technology worked in this domain, but there's also
transferable knowledge. So I've worked with MongoDB
before, which is a document database.
I can probably understand the concepts of Elastic as well
within some boundaries. I've worked with Spring, then
probably I can also do Quarkas even though you've never worked
with it. So the the more stuff you've
seen, the the better your your transferable knowledge
development becomes and the easier it is to get started in a
new situation. I feel like we started out with
regards to conference topics and kind of the knowledge sharing
aspect of it. And now I realize that
architecture also can definitely benefit from that aspect of a
role. I feel like if I were to come in
and offer, let's say, a certain knowledge pocket or share
experiences with regards to what I've seen in other
organizations, it might help with regards to buying, right?
Because if people can relate to you, if they can understand
where you're coming from, if it's not just a picture on a
screen, but if it's a story that you tell, it helps with regards
to buying and moving people. And that's what you need with
regards to architecture, especially if it spans kind of
organizational boundaries. So, so how, how I see myself as
an engineer is I, I know a little about a lot of things and
I usually I have my well, virtual toolbox with me and it
has lots of small parts like this works there, this works
there. And then whenever I go to a
conference or a meet up, I look for a little piece of
information I can fit into my into my box.
So, you know, years ago I learned about gravity and my
native images. So this may be interesting if
start up time or memory usage may be super important to you.
So recently I was like re re designing a back end for a
conference app. So back up for a conference app.
You need it once per year and then it needs to scale read
fast. Ah, wait, serveless may help
there. Ah, wait, Gravia may may help
there. So I take this thing from my
toolbox and then I start diving into it deeper.
So whenever I'm at conferences or events, I try to look for
those little piece of information.
Ah, I hadn't heard about arc unit before.
I hadn't heard about open for Mt before.
I now know that ARC unit is a tool that's based on J unit you
can do to create architecture rules for your project.
That's all I know. But next time somebody knows how
can we enforce architecture rules in our code base.
Oh, maybe we should look into this and I can dive into it for
one or two hours know more about it.
The same with you know everything is going on with AI
and LMS and whatever. I was at a talk and at a
conference, people were explaining how to integrate your
own NLM in Java code with Olama and Quarkers and length J for J
and, and just knowing that these three things work together and
they may be interesting is enough for me to be able to
suggest it in in a new situation.
And and also you need to be able to dive into those technologies
to know more about them when you need them.
But just knowing that this solution space exists is already
work well for me. And definitely what I also get
from from, you know, hearing people talk about how they apply
technology is in which situation may it work or may it work not
in, in a domain where I'm active in.
So I also try to feed on on their experience with 2X or Y or
approach X or Y to see how we can apply it in other
situations. And then obviously we shouldn't
fall into the the cargo gold trap of Netflix is doing this.
So we should do this as well. Well, the last time I checked
most companies do not have millions of subscribers
streaming video content, but usually I just don't know a
web-based system to store data. But still, those experiences can
help in enriching your own experience as well.
Yeah, there's only one Netflix. I I really like this ebb and
flow and I've never reflected on it on kind of my work
experience, but I talk to a lot of people and then I get a lot
of like surfers side ideas in that being ebb and then when
it's needed, yeah, that's when you flow and that's when you go
deep. I like the versatility of having
that. But sometimes I wonder, OK, am I
then being too generalistic or whatever it should just be,
especially it's very narrow. Maybe it just doesn't suit me.
Yeah, I see it more as like, well, you're usually talking
about like tea shaped people or something, right?
Like both deep and white. So I more see it like a rake and
Hayek. So it's, it's like, it looks
like this. You're, you're white and you can
go deep whenever you need to go deep, right.
So you still need to be connected to technology enough
to to go deep whenever you need to go go deep.
But you you don't necessarily need to be an expert in in in
everything, as long as you know that something exists and where
you can find the knowledge or the people who who can help you
with this. Yeah, yeah, absolutely.
I've really enjoyed this conversation.
I must say. I love how it went from more of
the conference fashion that you have, but from an organising
standpoint as well as from a speaker standpoint to and also
get into your ideas of architecture.
I feel like the role is evolving, but it's definitely
needed. And if it's a distributed one or
a specific one, it depends on the type of architect as well.
So yeah, thanks for coming on and sharing.
Thank you. Before we round off, is there
anything you still want to share with the audience that we
haven't talked covered yet? That's always an interesting and
dangerous question to ask because.
I always do that at the end. That's my curveball.
Let me think one thing that is that is something that I feel
strongly about that has evolved over my career is choosing
between solving stuff in a generic way or in a specific
way, right? So when you're a junior
engineer, you basically write whatever comes into your mind
and it's there. And then when you get some
feedback, like maybe you should use this design pattern here or,
or we use this and then you learn about clean code and then
you become like a violent clean code fan person.
And well, you need to use these strategies and reuse and
patterns everywhere. And then, well, once you get
another more steps in here, then you, you also learn to take a
step back and figure out like, OK, do we really need to
refactor this piece of logic that we need in two places to a
separate component? And obviously, you know, don't
repeat yourself tells you this, but the what people usually fail
to realise enough, I think is that every generic solution we
make, every piece of code we extract to a generic place where
we can reuse it. Reuse can be good, but you're
also introducing A downside. And this is coupling.
So everything you refactor to a shared component or a shared
library or a shared service, you're introducing coupling
between the the two people or persons or piece of code that
are using this. And the downside of this
coupling, I think often is, is overlooked.
And well, what I usually explain when somebody asks me about
coupling is coupling is when you need to change something in one
place and then something else completely not related needs to
change as well, you don't want this to change, then you have
coupling. So a relatively controversial
statement I like to make is that duplicate code doesn't hurt
until you need to change it. And even if you need to change
it, we have quite modern ID ES with regex search replays with,
I don't know, LLM code refactoring tools.
So the, the plus side of having duplicated code is you can
evolve those pieces of code individually from each other and
and sure, what you need a piece of code everywhere, like, I
don't know, logging, metrics, authentication, Sure you're not
going to copy it 100 times, but only the if it's only the second
time you need it, maybe it makes sense to copy this and then not
until the third time you need the same thing.
Figure out like which of those parts are really the same in
those three implementations and which can I extract and which
part should I evolve independently of each other.
So like a nice, the counter argument I left like to give to
dry is wet. So wet means write everything
twice. So write it at least twice.
And until the 3rd use case, you can find what's really generic
because the the problem of going generic too early is that you
may not fully understand your problem space and therefore
choosing the wrong abstraction or the wrong solution space.
And then once the third use case come in, you figure out, oh, it
doesn't work, I need to Add all these if statements and boolean
parameters, etcetera. So don't go generic too early
and and don't don't nothing too strict about.
Don't repeat yourself because having copied code in two
places, as long as you know it's there, it doesn't hurt you at
all. It allows you to evolve them
independently of each other. And maybe you need to refactor
it to a generic scenario later, but maybe you don't even need to
do it because they turned out to be separate problems that just
look look alike. Yeah, I'm going to think about
that one because it is something that I've definitely had a lot
of arguments with with people. You're very opinionated on that,
so I'm also going to let you think about that.
Thank you so much for listening. Let us know in the comments
section what you liked about this episode.
It's the best way to support the show as well as leave a like and
subscribe to the channel and we'll see you on the next one.