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 [email protected] 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.