#143 Bert Jan Schrijver took his career into his own hands

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Bert Jan Schrijver 0:00
The best source for ideas is just looking back at what what did I do in the past year that's interesting to share. The second source is some some weird hobby projects that I did, because then you're a bit more in a niche. So I did a whole project where I used $7, digital TV sticks and some software to receive transformer signals from airplanes. And I could plot all the airplane movements above Netherlands on a map. Well, I'm the only person in the world who's stupid enough to spend too much time on a project like this, right? So so if you're in a niche like this, it's typically easier to get accepted, because one other source is to kind of look back at the experience I gained in my career, best off what happened in the projects in the past five or 10 years. So so to say, and then the fourth one, and I wouldn't advise this what's what's currently cool in tech, or what do i think is becoming cool that I don't know anything about, but I can figure out just enough to submit a proposal to a conference.

Tim Bourguignon 1:11
Hello, and welcome to developer's journey, the podcast bringing you the making up stories of successful software developers to help you on your upcoming journey. My name is Tim Bourguignon. And on this episode 143. I received that Bert Jan Schrijver. Bert is the CTO at open value and focuses on Java, continuous delivery and DevOps.

Tim Bourguignon 1:36
Beware, the list is long, he's a Java champion, Java, Rockstar, Java one Rockstar speaker, Dukes Choice Award winner, leader of the Dutch Java user group, king of the Andals and the first men, Khal of the great grass sea, breaker of chains and Duke of Dukes, obviously, by the way, the last part may or may not be accurate. I know. Bert loves to share the experience with speaking at conferences writing for the Dutch Java magazine, and helping out Devoxx for kids with teaching kids how to code. Bert, welcome to DevJourney.

Bert Jan Schrijver 2:09
Thank you for the great introduction and some parts in the in my bio might or not have might or might not have been true.

Tim Bourguignon 2:18
You're not a Java champion?

Bert Jan Schrijver 2:20
I didn't say which part.

Tim Bourguignon 2:23
There you go. There you go. Okay, today is a very special day. Because we are live at the Javaland conference in Germany. I mean, live due to COVID. We are in our respective basements and attic. But we are live anyway. I'll try to keep an eye on the chat and, and wiggle some questions if I see the opportunity. So are people listening to this live? do ask questions. We'll we'll see what that leaves us. And as always, our discussion always starts in the same way, Bert, the show exists to help listeners understand where your story look like and started and imagine how to shape their own future. So as always, let's go back to your beginnings. Where, would you place the start of your Developers journey,

Bert Jan Schrijver 3:06
I think pretty early in my life, when I when I first got to touch a computer. It was a Commodore 64. And obviously, I've first used it to play games. But after a while, like a book or playing games, and I figured out that there was a way to to program the computer and to to make it do what I wanted it to do. And this was for me a realization that that there was like a whole creative process surrounding giving a machine instructions and get it to do what you want it to do. And I find this fascinating a young age already. I think OLS also did this he already got acquaintance with the frustrations that a typical developer has, if you want the machine to do something, and it doesn't do what you wanted to do. So I guess my journey as a developer started when I was around eight or something, be it well not really in a professional sphere but but mainly more as a as a way to spend time as a kid when it was raining outside. So to say common.

Tim Bourguignon 4:07
I'm sure it was sunny as well. And you just were who were hooked to the TV? Yeah. Did you did you learn on your own? Did you get help getting into this?

Bert Jan Schrijver 4:19
I didn't have no I didn't have much help. We didn't have some some books about programming. But there were like fairly boring books about creating like file management applications or stuff like this. But one of the ones I got a book about writing games, how to how to develop computer games, and on a Commodore 64 is invoked. Lots of creating sprites and peeking and poking and all this this stuff. And I didn't really understand much of this because I didn't really have the patience to read through the whole book from two ends. So we'll just skip through that the stuff where the game listings were and then carefully typed them over from the book into my computer. And then run them. And then they wouldn't work because I had made a typo somewhere and try to figure out what was wrong by by looking at if there was any errors or line numbers or something. But basically, I had no idea what I was doing. And I still have this from time to time. But but but not constantly.

Tim Bourguignon 5:16
Don't we all? Don't we all? Do you have the checksums, at least on every line to realize which line and a problem? Yeah,

Bert Jan Schrijver 5:25
if I was lucky, though, it would say that which line there was there was an error. But if I had not made a syntax error, but somewhat a typing error, and the whole screen would become garbled and garbage, then then I simply had no way to find out and, and sometimes I would just throw everything away and start over and try again. And there was one one epic game that I never got to, to get to function correctly. And I think it was a couple of 1000 lines of code type in, I think I tried three times and then gave if

Tim Bourguignon 5:54
you learn how to finger type. That's Yeah,

Bert Jan Schrijver 5:57
definitely. I yeah, I learned how to type quickly there. That's, that was a good start. Yeah. Okay.

Tim Bourguignon 6:03
How did this passion for for figuring out what the computer can do evolve into something more like an idea of a career maybe not to Korea yet, but the idea of, Hey, I could be doing that. For real. Yeah, I

Bert Jan Schrijver 6:17
think once I, the next computer we got was a was a PC, and I could program in turbo Pascal and create actual executables. And there, I kind of got the idea that Oh, wow, if I become really good at this, I can basically create anything at once, right? So in that times, games, like Doom were popular. And I was like, Okay, if I get really good at this, I can make a game like Doom, and maybe even people will, will pay me to, to make to make games. So I wasn't really into games, but more the concept of creating stuff and making it into a living. And I think once I got a bit more serious with, with programming around I don't know, the age of 16 or something that either Okay, well, maybe this could be something that I can can make my career into it. And it was quickly decided by me that I would do some kind of technical study afterward. So I went to university. And I didn't learn much about programming there. But obviously, I got a degree which helps getting into a programming programming job. And that's where I Ninian's. I learned to finally write some some nice code instead of just odd hobby and crap code I've been writing so far.

Tim Bourguignon 7:34
It's crap code, but professional crap code.

Bert Jan Schrijver 7:37
Yeah. So now somebody is paying me. And in the end, it must be it must be good, right? Absolutely. Absolutely.

Tim Bourguignon 7:43
When I look at the code I wrote for 1014 years, I'm really scared. Do you still have this idea of writing? The new Doom?

Bert Jan Schrijver 7:51
No, not really. Because Because once because now I'm when I was when I was younger. I always saw projects as a nice challenge, right? Let's, let's write a new doom and something completely lost something really big. But once once now I have like 1020 years experience in the industry, I know that the bigger the project, the bigger the chances are, that you're never going to finish it, or you're never going to get it right. So now I actually like small projects, because there isn't there's an easy horizon. And you get quicker, like satisfaction from from finishing something. I think that's also why, for example, agile methodologies work, right? Because you don't have like one, six or 12 month project, but you have lots of really small projects where you can celebrate after every every sprint or two weeks.

Tim Bourguignon 8:38
What is small enough that it's interesting, and that it doesn't land on the project graveyard. But, but still still bring something to the to the equation?

Bert Jan Schrijver 8:48
Yeah, I think something like that I can finish in in a day or a couple of days, something, something like this. Otherwise, it becomes a project, right? If it's something you can do in a day, then you can do it can do it on a rainy Saturday or Sunday. And then it's still fun. Once once it needs multiple days or multiple weeks, you might need some planning and it will take longer time and you might lose interest. So small things.

Tim Bourguignon 9:10
I like Mac one a day a day in the Java world that you're just barely over with the setup.

Bert Jan Schrijver 9:16
Depends on how much time you have to get done the setup, right?

Tim Bourguignon 9:19
That is, that is okay. So you are at university and and you graduate and enter the software world. How did that go?

Bert Jan Schrijver 9:30
Like most like most things in my life at that time, coincidentally, so looking back, I didn't really take my career in my own hands until the second or third job or something I took. So so I was living in a student dorm in Amsterdam at the University of Netherlands. And I was close to finishing my study sir there. And one of my former housemates have to just learn at a job at a company in in Utrecht in the Netherlands. He came back to the house to say hi and to have a couple of drinks. And he said, Yeah, I've working at this company, what to do. And it's fairly interesting. They have like some, some standard components, and they write some custom software and throw it all together and they sell it. And then maybe you maybe you want to work there as well. And I was like, Okay, well, maybe, maybe I'll let you know. And then and then he leaves, he goes home. And one hour later, I get an email from this company like, Hey, this is this guy said that you were have shown interest to work at us, and he can send us a motivation and your CV, then we're happy to talk to you. And was like, was this But okay, well, I've got this memo anyway. So let's write a motivation and create my CV and send it to them. So I then got to do an interview, cut off his interview, I think, Wow, this can be fairly fairly interesting. So then I did like in some, like a capacity test and a second interview, Lana to job and start there. So I didn't really look for anything. Well, it turns out that that that my former housemate was receiving a big hiring bonus for every new employee he would bring in. So that was what was in for him. For me, he was just like a coincidence, I hadn't really even looked looked for jobs. But I guess that's how the market was, like, a while ago. And once once I started there, I found out that actually, the software engineering was pretty, pretty interesting. And I learned like, how to do projects and how to structure your work and how to document stuff and how to how to write write code, and how to write tests and how to do projects. And at this job, it wasn't technically like, mega interesting. So it was not really new technology. And it was not really cutting edge. But it was really broad. So at this job, I could learn about software development, but also functional design, technical design, a bit of software, architecture, bit of infrastructure, did some team, some roles a team lead, gave some internal training. So I did read a lot of things, I kept saying yes to everything. And then once I noticed that I was doing like, 1020 different things on a day. And I said, Okay, now it's time to scale down again, and focus on the things I like to do. And this was about a time that I, that I switched jobs to another company, which was also kind of a coincidence. So a colleague invited me to go to a, like a knowledge session at this company was a groovy training, I think, and I went to this training, and I, I participate, and there was a challenge in the end, and I won this challenge. So then the company obviously contacted me to start working there. And I was, I wasn't really looking for a new job. But at this time, I was like, Okay, I'm not, I'm not learning that much new stuff anymore, my current job, maybe it's a good time to switch to switch jobs. And I just said, said yesterday and moved on to your job. And there I met somebody, a mentor, who really taught me what working with the latest technology was, but also what like really crunching in a project was, so I work with him on my project that kind of got into trouble. So it was a team of eight or nine people, and a couple of testers and a couple of information analysts and this project was about to fail. And then we would get like in a bad situation with the client demanding money, etc. So we decided to try to save the project with the two of us, by over a weekend, build a concept proof of concept for a complete new setup, and then demo this to the client. And we convinced them to throw everything away their head, and start again with with with a new course that we set out. And then with just two of us in three months, we got the Project Life without any like open books. But that was a bit well, bite hard work, so to say. But it was it was rewarding. And there are really found that as well. If you have two capable developers that are able to to make choices for themselves, like technical choices, and are not stops by any like, I don't know, regulations, or standards, or architects or other people who want to slow you down, they can really go really, really fast. And this is where I first found out as well as be amazing. If you are somewhat competent, and you're able to make all the own technologies in your project yourself, then you can build good stuff really, really fast. And this is where first got to think like, okay, maybe maybe this is the career I want. So it's the first time I kind of took my career in my own hands, so to say, Do you mean taking your career in your horn

Tim Bourguignon 14:25
and at this company or from their own doing something else?

Bert Jan Schrijver 14:30
So this was also the time that this this company was about to get acquired by a much larger company. So I saw that the Java unit where I was working there was going to deteriorate quickly pretty quickly. So then I started looking for another job. And this was the first time that I actually started looking for a job myself, because the previous two times were basically a coincidence, right? They they found me so then I thought like what's what do I really want? I only want to work with really good people. Preferably who are better than me, in a small company with lots of love, public, listen, lots of personal contacts. And who likes to do fun stuff like I don't know, go skiing and drinking beers, etc. So I found this company, it was fairly close also to where I lived. So I joined George's company. And from then on, everything went a lot faster because this this company was j point, which is a company in Java shop in the Netherlands. And they they are, they were focused on finding the most amazing consultancy assignments for for for really good developers. And like the five years I worked there, I learned more than I learned in the 10 years beforehand, because I was more in a situation where I could really excel as a developer. And also, because of frequently switching through projects, learn new things really, really quickly.

Tim Bourguignon 15:53
What does it look like this setup where you can really excel? What what are the key cornerstones of such a setup? Yeah, well, I

Bert Jan Schrijver 16:00
typically summarize this is hire driven people who are smarter than you, and get the f out of their way. So basically, build an amazing team together of good people. And in this case, it was a fairly full stack team. So we had a couple of back end developers from the developers, infrastructure engineer, test automation engineer and an information analyst. And these were all fairly fairly senior, and they had to trust from the organization that they, they will do whatever was necessary to build software that would add value for for the project. So we were mostly talking with the customer about, okay, what should this this application do? And how should it work, and then was completely up to the team on how to build and how to implement this. Whereas with previous companies, I was used to that, if you want to do something, we need to ask the director or the CTO, right? And this typically was, they were like, no, let's do like we always do it. Well, in this case, it was, okay, how shall we solve this, this way, or this way, or this way? And I really felt empowered as an engineer to make choices to the best of my ability without being slowed down by regulations or rules or, or more traditional choices.

Tim Bourguignon 17:20
Now that make law makes a lot of sense makes a lot of sense. And has that impacted the way you lead teams afterwards, trying to re enact this this setup in every teams you worked with?

Bert Jan Schrijver 17:32
Yeah, definitely. So I think that I always strive in in every team where I work or work with, to give the team as much independence as possible, because I found over time that if there's one thing that makes teams or organizations slow, and even software, its dependencies. So ideally, a team, from my point of view has all the capabilities it needs to go from idea in your head to working software in production, without being dependent on anybody outside this team. And if you get to the situation that you can really become really fast. And even within some large organizations, for example, like that, like the Dutch police, I managed to work with teams who still who still had this by kind of creating like a, a startup bubble within the larger organization where we were we had everything in our own hands instead of depending on I don't know, other people's infrastructure or release managers or whatever.

Tim Bourguignon 18:28
How do you convince some management levels, that this is the way to go?

Bert Jan Schrijver 18:34
Yeah, you need to be a bit lucky there on one hand, that you find people with the right mindset. And on the other hand, I was lucky enough to be able to choose projects where I want to work. So I would say no to a project, if I if I would have the idea that there was no chances of changing things or improving things there. So I think two of the better projects where I've worked, I was in direct contact with, let's say, the IT department manager or the engineering manager, and had a real good understanding with these people to well basically get leverage for creating this autonomy. Because they were they were also into like seeing results. They were sometimes a bit scared of the amount of autonomy that the teams demanded, but they were seeing results and the more results they see, the better they can sell this autonomy to to their boss or to somewhere else in your organization,

Tim Bourguignon 19:28
in this phase of your life, where you're still saying yes to everything.

Bert Jan Schrijver 19:31
No, I was, I was a bit more focusing on quality and less quantity. So I add and that the interesting thing is when I just started in my career, my goal was to to grow first was to a senior developer, and then to a team leader, because then I could tell a lot of people I would actually do it and I didn't need to do that much work again. Then I worked as a team leader and as well, this is no fun. I'm only making Excel sheets, right? So let's let's go back a bit to development. And then I got promoted to being a software architect. And this was in the beginning nice because I could write like designs and have other people build it. But then I was missing like building building this myself, right. So over time I met had some diversions, but he and I would just mainly get back to to writing code. And I think the situation that were in the NFL most comfortable was of a, let's say, hands on software architect where I could both both do some hands on work and actually write code myself, also design some stuff, and also help teams to become as productive as as possible. So that was interesting is that over time, my viewpoint changed a bit from Okay, the end goal is being an architect, because then I design everything, but I don't need to write code anymore to But wait, that's no fun at all, I want to at least write write some code myself.

Tim Bourguignon 20:51
Charity majors describe it as the pendulum, the developer, x developer, architect, developer manager delivers something penultimate, you always go from one to the other. And realize, well, it was better with a bit of development. So you go back to development well, but deciding was nice as well. If you go back to design and find your sweet spot, I think you found it, you find it somewhere. Okay, I would like to go a little bit different direction in all the titles I listed from you, including breaker of chains and, and King of the handles. There's a community Part Two to this. Where does the community come into this this into your life? You mentioned once in this company, where there was a talk, but where did you start partaking and being really active in communities? Yeah,

Bert Jan Schrijver 21:38
I think in the, in the second company where I worked, where we had this, this mentor who I did this well, project that was amazing hard work, but I've good results. This mentor also pushed me to, to start participating first to, to consume stuff from the Duchy of community. So this was to the Netherlands of youth group, to go to conferences and like learn stuff there. And then he started pushing me to also start participating contributing there. So I first started by joining the editorial board for the Java magazine, which is a magazine we print and lens, four times per year, about 5000. People we send it to, and it's actually like printed on paper, which is fairly old school, but people seem to seem to like it. So they can take it to places where there's no Wi Fi coverage, for example. And here, I learned that while there were there were there was an amazing community of passionate people who love to spend some of their time to finding good articles and writing good articles and reviewing articles. And doing it all for the love of the community, right? This is all volunteer, it's not like you get paid. And because I saw like how amazing this community was. And also was getting pushed to contribute myself, I started presenting at events here and there, like some small little dogs. And then, because of my participation in the community, once the no joke was looking for a new person to join their board. I was one of the first day they asked and after some contemplation and discussing it with my employer, because it would take time, like organizing events, etc. You're not doing only in the night, sometimes during the day. I said yes. And started to join the analgesic boards. And there became responsibilities responsible for mostly the technical side of things. So the content of the Java magazine, the progress of the conference, we organize things like this. And this was a lot of work, but also a lot of fun and really good for my network, both inside the community in the Netherlands, but also outside the Netherlands because we would like visit visit conferences, to go to Java one for example and and meet all the Java user group leaders there and discuss how they were doing thing. So for me for my network, this was amazing because I met people from Jacuzzis all over the world while doing this.

Tim Bourguignon 24:04
So you need either something very, very right or very, very wrong from going from consumer to editorial board and chalkboard.

Bert Jan Schrijver 24:13
Yeah, yeah. Well, I would say I did things right, because nobody kicked me out so far. But it was nice to to experience to be able to first kind of feed on this community and consume everything they bring and then do your part. And what was really like an eye opener for me is that there were people thinking that they were interested in what I had to say. And this was a bit strange like I'm not doing that, that that much interesting stuff, right. But I submit something to a conference and and then it gets accepted and I go on stage and people listen and people actually enjoy or this is this is this is an interesting concept. I had never thought of it this way. How do you find ideas that you will present or write on Yeah, I have a couple of sources for this. The I think the best source for ideas is just looking back at what what did I do in the past year. That's interesting, maybe interesting to share. Typically at work, like I worked a lot with Jenkins to offer tax or Gatling in a project. I think the second source is some some weird hobby project that I did, because then you're a bit more in a niche. So I did a whole project where I used $7, Chinese digital TV sticks, and some software to receive transformer signals from airplanes from ships. And I could plot all the airplane movements above Netherlands on a map, for example, well, I'm the only person in the world who's stupid enough to spend too much time on a project like this, right? So so if you're in a niche like this, it's typically easier to get a set up because not many other people are doing Yes. And I think then, there are two other sources I said three, but I know for one other source is to kind of look back at the experience I gained in my career. For example, over my career, I've drew out use Linux a lot. And I found that the Linux command line has helped me a lot in doing like file operations, searching things, filtering, things transforming. And I found that the power you have there was underestimated by a lot of developers. So I tried to pitch to create this into a talk like a mastering Linux command line, it was called. And to my surprise, people were interested in this in this as well. But and also the things I tell about continuous delivery. And DevOps is mostly based on previous experiences. So I'm mainly doing like, best off what happened in the projects in the past five or 10 years, so so to say, and then the fourth one, and I wouldn't advise this, but this was what's what's currently cool in tech, or what do i think is becoming cool, that I don't know anything about, but I can figure out just enough to submit a proposal to a conference. So I did this once when Jenkins two was just about to be released. And Jenkins was was really popular at the time. And I figured this Okay, this is going to be big, like pipeline as code in Jenkins. So the cocoa papers deadline for the Java one conference was approaching. And I just went through the Jenkins website. I copy pasted the first three lines of description of Jenkins to edited the bits, came up with a catchy title, submitted it and forgot about it. And then two months later, I get a mail like, hey, you're accepted to speak about Jenkins two at job one. And so Cisco, what did I Oh, yeah, I think I submitted this like right before the deadline. And then I had like four months to gain experience to talk about this, which was kind of stressful. So I forced I was in the end of one assignment. So in the final month of this assignment, I've kind of forced this company to move to Jenkins to and at the beginning of my next assignment, I, I kind of tried to convince everybody that it was time to move to Jenkins, too. So just in time, I got enough experience to share. But But I wouldn't do it that way. Next time, because it's better if you already have the experience that you're pitching. If your nerves can handle that. It's a great way to learn. Yeah, sure. Yeah. He was a nice pressure cooker product, but it was not really relaxed.

Tim Bourguignon 28:17
Yeah, that's true. That's true. How many did you make? Maybe I'll probably you don't you don't feel this anymore. But but the beginning, I always often hear well, but what I know is not interesting. It's, you can find at least three dozen videos on YouTube who explain which explain what I want to say way better than me. Why should I talk? would you would you respond to that? Yeah,

Bert Jan Schrijver 28:39
I've had experience like this fairly recently, I think up to last year or something. Where topics that I thought that everybody already knew, like, I did a talk about an introduction about the principles of continuous delivery, and DevOps. And this basically was was something I put together based on previous presentations I had done so I put together for a presentation on the client who asked for this. And then I thought, Okay, I have this material. Let's just submit it to a couple of conferences and see what happens. Probably, they think it's too basic, and nobody is interested. So I submitted it to the devoxx Uk conference in London. And to my surprise, I got accepted to present this talk. I'm like, Okay, interesting. But we'll see. And then they have the system where people can can attend these can favorite talks, right? So you know, how many interested there is. And then it turns out that my talk was the most favorite to talk in its time slot. And I was moved to the biggest room of the conference with this basic topic. So anyway, that's interesting. So I went on stage and I did my thing and told a lot of stories, and maybe even involving automatic toilets. Don't mean remember, but probably I did. And people thoroughly enjoyed it. And I got really good, good feedback on the talk and really high ratings. How's looking back on like, That's weird. So that's kind of like an entry level topic that I was assuming most people knew. But still, they found it interesting. And then was talking about to attendees afterwards, that for some of them, this was this was really new. For some of them, it was a nice refresher of some things they might have already known or not. And for some people said, it was just nice to get a like to get some new ideas and to get a confirmation on what I've already been thinking all along. And then I got an idea like, okay, so maybe, maybe it doesn't always need to be about the the the latest technology that you're doing the most amazing, scalable, super secure, hello world demo with or sharing really high load, high data for secure experience with projects. But maybe, maybe it's also interesting to talk about basic concepts like I don't know, how does the internet work? And that was really interesting to me. And I've I've always said in, in speaker mentoring programs that I run, that the people come up to me and say, Yeah, well, this is never going to be interesting. How do we know if something is interesting? Well, you don't need to decide whether something is interesting. If you if you think about a topic, you need to decide whether you think it's interesting for you to talk about this. And then just give this topic to a meetup organizer, or conference organizer or a magazine publisher, and let them decide whether they think is interesting for their audience. So it's not really up to you because you don't know their audience, the organizers know their audience. And that was really interesting for me to discover this. So to say that that's very true is for her to give it to the to the committee is really important. You never know what's what's happening. And behind the scenes of they want to create a storyline with with talks building on top vanilla, etc.

Tim Bourguignon 31:35
That's not that's very, very true. You just spoke about the speaking mentoring program. Tell us about that.

Bert Jan Schrijver 31:40
Yes. So I organized j fall, which is that the biggest Java conference in the Netherlands, and over there, we we got some feedback over time, that people were seeing the same speakers over and over again every year. And these are amazing speakers. And they typically do good, but but if you go to a conference, like five or six years in a row, and you see the same faces five or six in a row, maybe you get a bit bored. So we thought, okay, it might be good to try to stimulate getting some new people on board. And we would have like one or two or five new people every year, but not not that much. So don't worry, we're thinking how can we get new people on board, but by helping them. So we announced it to do a speaker mentoring program from the Netherlands Java user group, free to attend for members. And this was basically divided in I think, three sessions. So the first one was on picking topics, writing abstracts, and having them peer reviewed in a group. A second one was where we had a seasoned speaker, sharing their experience. So I think we think are to go on young ones, where we were selling like stories about his career as a speaker. And this was a speaker that lots of the attendees looked up to. And then the third session we had was basically practicing. So every participant would have like five minutes to, to present something doesn't mean remember what, and then the participants and the mentors would give feedback. Okay, next time, don't put your hands in your pockets, or you're going way too fast, or try to, to look up every now and then. And not just stare at the floor, like we did real basic, basic, but honest tips. And the nice thing is from this program, lots of new speakers emerged. And some even like made it into the top 10 sessions in their first year of appearing there. So that's really cool to see that that's that at least we were of some value by helping them getting started in their speaking career.

Tim Bourguignon 33:29
Do you do some kind of mentoring as well, outside of the speaking context?

Bert Jan Schrijver 33:35
Well, not really like as an opening mentoring program, but a lot for my colleagues at open value.

Tim Bourguignon 33:41
Okay, how do you you set up such a mentoring with with someone?

Bert Jan Schrijver 33:45
Yeah, I think that's, that's something that's different for every, for every person, every person has different needs in, in how they want to be helped. So for people a bit more in the beginning, let's say the first five years of their careers, they're typically looking typically looking for practical tips, like I have this problem which which technology, should I solve this or like, which alternatives exist? And maybe there's some validation? Like I'm planning to do this, what do you think? And then people who are a bit further in the career maybe five or 10 years experience, they have typically more a bit on the the level of, of soft skill. So how can I I know that my ideas are right, but how do I convince my team or they convince my manager to do this at my customer? Or how do I manage my energy or how do I make sure that I don't don't get get overworked? And then for for people a bit even further in the career like 1015 years experience? It's more like how can I help my my team to become better as a whole? And I see that I have somebody in my team underperforming, how can I help this person in a nice way without it's still obvious that this person is underperforming to make the team as a whole better So I think in looking at your your work for an organization as a, as a developer or engineer, it kind of goes up from you start as Junior you're not productive at all. When you're a meteor you're productive yourself, when you're senior, you making autos Are you making your entire team productive. And when you grow past that, you can make an impact on an entire organization by changing the way organization works, and making a whole group of teams more and more productive by making good technology choices or adapting the way that an organization works. So I think it's about maximizing the positive impact you have on organization. That's an interesting way to put it, Jr. You're you're trying to get productive on your own.

Tim Bourguignon 35:43
Then when you're in this middle category, you are productive and yourself. And then when you gain seniority, you get others to become productive. Interesting. How would you How would you balance this with the the kind of sharpshooter or the expert? profile? somebody's not necessarily trying to make others become better developers, but themselves becoming so deep in the knowledge that they can really, really solve very, very, very technical problems? Are the not seniors? Or how would you would you wiggle this in your definition? Yeah, I

Bert Jan Schrijver 36:17
think they said this their senior on a different axis in their career. So I think you definitely need like good technical specialists. For example, I'm more considered, I consider myself as somebody who knows a little about a lot of things. And I know a lot about only some little things. So I think you need both roles. You have generalists, as specialists and generalists are typically good at seeing the bigger picture. And and helping teams to come better as a whole. But if you have like really specific challenges, like performance stuff, or security stuff, or or I don't know, JVM engineering, or infrastructure as code, you absolutely do need specialists who are really good at this, and who don't really care about making autos better, they're just really good at doing their work. And that's fine. But you cannot you cannot have only people from the from one category people on the other category. So I think that who said this, I think it was David Blevins and Daniel Bryan's I heard saying once they are sorry about, but like rock stars are Ninjas in teams, right? You cannot only ever team based on rock stars and ninjas, because they're only going to argue whether they're going to use for tax or aka or like home or whatever, right? So I had a like feedback on one of my colleagues once who worked in it, he was here a couple of years of experience. And he worked in a team with only really experienced people. And the feedback I got from the client was he has I think he's he's being really productive, because he's spending way less time than the arrows arguing about technology choices. And he would just like, listen and do what everything was right. Instead of trying to make an argument about everything. And this is a, I think, a challenge. If you put really good people together, then they all have like different opinions and are ready to do battle to defend their opinions.

Tim Bourguignon 38:04
How is it mapped to one of the companies you described? I think he was your second company with very driven people, people who really wanted to, you wanted to get out of their way so that they were they not rockstars ninjas? Do they have more profiles in there? How was the team setup retrospectively?

Bert Jan Schrijver 38:22
I think every team, when the teams were about five to seven people, I think every team had about two Rockstar slash ninjas. And then the rest was more like generic good skills, good skill developers. And I think this balance was good. Because if we had like a, like a really hard problem, we could get one of the real good people to work on this. And euros would do generally good work overall. And if they had a problem, they would throw it in the group. And then the two, let's say your ninjas would would would do have a short argument on which was the correct way to solve this, and the team could move on. But if you if you if the balance is two more two words, you only have rockstars in your team, then you will spend way too much time on on discussing which way to choose where and this situation was typically more. Okay, let's do this. And then if we find out that it was the wrong choice, we'll do something else next time. Okay, so

Tim Bourguignon 39:12
it's all in the two rock stars and angels were arguing with one another and the the Knights, the dragons and the princesses were doing the work. Really?

Bert Jan Schrijver 39:21
Yeah, they were basically like, okay, we weren't done arguing and then we'll get stuff done. So I think that's also why it's important to have a diverse team. And diverse is more than just having Knights Knights versus ninjas is also having, though it is a complex creative domain, right. So so it's it's important to have people from different cultural backgrounds from different companies. So you have as much different viewpoints to solve problems as possible. And I think a diverse team is also typically performing better than a team where everybody's from the same background, the same situation, because they can be like blindfolded, we're only looking in a specific direction. So having lots of different viewpoints from different people is typically good to quickly solve problems. Do you see it as part of your role as a CTO nowadays, to make sure teams are diverse enough,

Tim Bourguignon 40:11
are well mixed that not too many ninjas and rock stars come together, etc?

Bert Jan Schrijver 40:15
Yeah, it is, it is an important bar. But it's also a hard parts. Because more you might have a deep an idea of how the ideal team looks like. But you also have like a group of people and and the market for candidates that you need to work with. Right? I can say that from now on, I want my team to everybody in my team to have a different background. But then how do I need to match this with the stream of candidates coming in? Right, and, and if I'm hiring in the Netherlands, then chances are that 90% of the people that I meet are from a background who grew up in the Netherlands, and I don't know, played soccer when they were kids and, and went to school and at English and German in school. And, and you know, that's it. So, obviously, it is I think it's a big factor in the success of every team. But you also need to try to make what you can make with with with the people you're working with. Because you cannot always choose the people you're working with, indeed,

Tim Bourguignon 41:11
how is the remote situation again, going to change this,

Bert Jan Schrijver 41:16
I think, in the communication skills have grown ever more important than they were before. Because before if somebody was once a bit like closed in, you could still see them, you know, sitting somewhere and they have like, thunderstorms flying above their head because they're angry about something and then you could walk to them and say, Hey, what's going on? Can I help. Whereas a remote situation if somebody chooses to, I don't know, not not turn on the camera and not say anything. But basically, you know, like you're staring in a blink, blink sweet. So I think it's having having attention for people's well being and how good they're feeling and how they're feeling they're contributing. And the project has grown ever more important when we're all distributed. Because the whole way of social interaction between people are way different than when we were sitting together with everyone. Maybe you should even hear somebody cringe or I don't know, shout or swear about the crap code. They're looking at where somebody is, on the other side of the country, they can cringe and swear and shout all they want, but you're not going to hear it right. And and the same thing with with written communication via verbal communication. It's it's fairly easy to miss understand something that somebody is typing, being in a chat. Maybe you mean it as a joke, or not so serious, and somebody thinks, Oh, this person's angry. That's weird. Whereas if you say something, then you could see like the, the expression on somebody's face, and you can see whether they're angry or, or smiling or making a joke. Yeah, sure.

Tim Bourguignon 42:45
You have to take your cues from somewhere else. So basically, you're going remote, you're potentially increasing diversity, but buying in all bunch of file communication problems or potential communication problems.

Bert Jan Schrijver 42:55
Yeah, yeah. So So yeah, I think I think those two are maybe even a bit their counterparts, because probably, obviously, a diverse team typically performs better because they have more different viewpoints, right. But people from different backgrounds also typically have different norms on what's pleasant and normal in communication. And ours, we lose lots of cues, whenever we're speaking, virtually, or over chat with each other. I think that maybe teams where people from the same backgrounds have less trouble communicating efficiently, because they, they, they have a better understanding of what somebody means, like if I don't know somebody from from Norway would would have a chat with somebody from the Netherlands, or somebody from the US or from the US. And probably the people from the Netherlands will be like seen as extremely blunt, and direct, and not nice. But well, that's basically our culture, right? will will will saying whatever we think is right. So if you're together in a group of Dutch people, and somebody is being extremely right, but extremely blunt, okay, probably people will understand because that's what I used to. If you're you're doing this to somebody from the states to think like well, oh, I don't know what to say. But this doesn't really sound nice. What should I do? Is this person mad at me? Or you know, so I think in a way maybe working with the first team is even harder if you are remote because of the different cultural aspects and, and different experiences on how communication is it seen by people? Indeed, indeed.

Tim Bourguignon 44:33
Let's Let's steer again, a little bit into the into the yo yo community, work with a whole list of awards and titles I gave you. Your bio, how much of your time you spent working for communities versus your daily work,

Bert Jan Schrijver 44:52
though, there were four communities as well, in the order of magnitude a couple of hours per week. So let's say that I work I don't know if they The hours and it's been a couple of hours, then it's five to 10%, maybe, but they're there. So there's ups and downs. Nice thing is that all since since I'm not doing assignments for clients, but I'm mainly concerned with, with, you know, running my company and and helping my team, I'm on a fairly fee in how to spend my agenda. So if I decided to spend the day at speaking at a conference, I only need to convince myself that this is a good idea to do so. And, and for us, it's also part of our marketing plan, right to to to share what we've learned, because we like doing this. And this also helps in meeting new people and possibly meeting new clients. But the conference, the community work has always been volunteering, and sometimes in a week is nothing because it's a bit quiet. And when we're organizing a full I'm, I'm working on it almost full time for a couple of days. So there's ups and downs here. But I think the key part is that if you're doing work like this, which is also sometimes in the evening, or in my own times, or in the weekends, you're volunteering. So then the most important thing is that it's an it's an enjoyable experience. If you're volunteering, you should only be doing it if you like it, because volunteering for something that you don't like, why are you doing it, you're investing your time, and you're getting something you don't like in return, that doesn't really make sense. So the moment you you don't really get joy from this anymore, then probably is the time to reconsider doing this, this form their work.

Tim Bourguignon 46:17
Indeed, indeed, I'm looking at the clock, we have to wrap up soon, you gave us a whole bunch of advices. And going in every direction. If you were to to picture in your mind, junior developer, somebody who is just starting and not yet convinced that they should invest time in communities, what would be the one argument the one advice that you would give them to, to try it and two together,

Bert Jan Schrijver 46:41
I think if you're just starting in your career, it's important to know what's going on in your industry, right. And it's safe to say that at any company, you're only seeing a small part of what's current and what's possible in your industry. And when you want to have a broad view of the world and what's current and also want to grow in, in advising people on technology choices, for example, then a subordinate, you know, more than your horizon of just a job, your current company. And this is what the community can bring you. You can get free advice, learn about new things that you might be able to apply in your day job, or maybe not, maybe in the next shop, you meet interesting people. And if you're lucky, you get free food and drinks. So any of those three is a good argument, I think to to get in get active in communities. But for me it was mo is most mostly learning things that I was not learning at my day job and meeting new meeting new people. Indeed, indeed,

Tim Bourguignon 47:40
thank you. Thank you for this advice. So where where would be the best place to continue this discussion with you or started discussion with you,

Bert Jan Schrijver 47:47
I am always reachable on Twitter. So Twitter at bJ skiver, you can find me I spend way too much time there. So just send me a tweet or dm and I'll probably respond within an hour or so if I'm not asleep. So that's always fun. People also free to drop me a mail. If you go to open value.nl My email address is right on there. So you can click it send me mail, we're happy to help. Also when it's about knowledge sessions for your company, Speaker mentoring, free advice. Typically I'm in for for most of those things.

Tim Bourguignon 48:20
And he almost all in real life events are where we could see you. I think you have the drug, the animal drug law next week.

Bert Jan Schrijver 48:28
Yeah. So we have I think in life events, then the first one from the energy could probably be RJ for conference, which is aimed for November, or Poby will be I hope that we'll be able to do a real live event, again, with maybe a limited set of people. We will be organizing our j spring conference. Let me let me check the date. Because obviously I don't notice by heart because it's on our website. This will be beginning of June. And this will be a virtual conference. So we dig up digital there. So it will be doable for people from all over the world to join in there. Then it's been

Tim Bourguignon 49:04
a blast listening to your stories. Thank you for sharing all this.

Bert Jan Schrijver 49:07
Thank you for giving me some nudges in the right direction.

Tim Bourguignon 49:10
That was that was cool. Oh cool. And thank you everyone for staying along with us. And this has been another episode of Developer's journey. We will see each other next week. Bye. I hope you have enjoyed the story as much as I did. In his opening keynote of the Javaland conference where we record the show. Bert told some of the stories he told us on the show. Hearing them here in a different light was really really fun and eye opening. I really admire his community work he has done so much. And he makes it almost effortless. This is mind blowing. I also love this

comment he made:
"basically I had no idea what I was doing. And I still get this from time to time". I find it so important that we the experience, developers, say you'd lower than clear to prevent false expectations to appear in the minds of more junior developers. We have no idea either. Sure, we don't. Tell me what you liked about Bert story. You can reach me on Twitter, @timothep, or you can use the comments section on our website. It's at devjourney.info. And you know what experienced developers also do. Well they share their resources. So do me a favor, forward this episode to one person who would benefit from it. Do it No. Really, right. Come on. I'll wait. Did you do it? Thank you. You're awesome. Talk to you soon. Bye.