#30 Adrian Bolboaca on choosing the appropriate tool for the job at hand
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:05
What is a good software developer? What do excellent developers do? There are probably as many answers to these questions as developers in the world. So let's ask veterans and newcomers what their story look like. Let's learn directly from them. Welcome to developer's journey.
Hello everyone, and welcome to developer's journey, the podcast shining a light on Developers Life from all over the world. My name is Tim Bourguignon, and today I receive Adrian Boubacar Hi, Adrian.
Adrian Bolboaca 0:45
Hey, Tim, how's it going?
Tim Bourguignon 0:47
Pretty good for you. Thank you. How about you?
Adrian Bolboaca 0:50
Well, I thank you for inviting me, I kind of tired but I will try to make this work in a way and try to put as much as content in interesting for your listeners as possible.
Tim Bourguignon 1:04
I'm sure you will do great. When you will start speaking about your own journey you will lead up I'm sure you will. But let me give you a short intro. But here what I know about you, actually, so you are a programmer or a trainer and a coach. And your passion is actually helping teams produce high quality software. You're supporter of deliberate practice of experiments. And in 2016, you published a book about hosting and facilitating cool treats. Is that right?
Adrian Bolboaca 1:34
Yeah, yeah, that's true. I eat In fact, it's co co created with my brother with Alex. So we're co authors of this book.
Yeah, we we have
artificial experience with this because Alex was when he was the first facilitator to get with Mario Yakubu on code retreat in Europe. So after that, I started stealing, let's say some of his experience. And then I started doing a lot more of the is so yeah, it was a great experience writing this book.
Tim Bourguignon 2:15
Just for the listeners who don't know what a chord retreat is, is a one day event where you can try to learn software practices without any pressure without any any pressure for the outcome, and do the same exercise over and over again. Just for the sake of practicing one aspect of your craft. Yeah, yeah. summarize it. Yeah. Yeah, that's true. I think the the next global day of coding training is coming in November, isn't it?
Adrian Bolboaca 2:46
Yeah. Yeah, exactly. It's once per year, everyone around the world will try to tries this format is countries. Yeah.
Tim Bourguignon 2:54
I encourage people to do this. That's, that's really nice. Yeah, okay. But let's backtrack a bit as Beth curry, we jumped on the code retreats bandwagon already. But we want to hear about you. You and I met met in March in Paris, we were at the same conference. And you were you were holding a talk about evolutionary design? Tell us tell us the journey up there. How did you end up being in software development? Maybe How did you end up being in the same field? When your brother? And how did you become someone who is called upon to talk at conferences? What's the story behind
Tim Bourguignon 3:34
that?
Adrian Bolboaca 3:37
Yeah, okay. So it's a, let's say a longer thing. I, I tried to Well, I always liked doing stuff, creating stuff, since I was a very small child, I would maybe build things with concrete or with wood, or, you know, or with electricity, or I would maybe create a things with from parts by like radios and stuff like that. So I always like to create, say things. And then it was kind of natural for me to continue on, in high school on on this path of, let's say, more technical things. So, I, I had a continued education with a lot of math and physics, but I not a lot of informatics. strange enough. I chose to go on, let's say the more theoretical approach. And I think that was very useful for me till now and while you'll see a bit later why and I really spend started doing programming going in university in the first year? Well, because well, in high school, it was a lot of theory and lots of mathematics, physics, chemistry, and all, all these things. But I think those are very useful if you really want to get very deep into oil software. And also, in what software can help other domains or other areas, you need to understand a lot about these things. And, yeah, for me, it felt natural that I start, I continue working in an area where I build things. And I was kind of passionate in university of trying to understand what, what this programming is. So I was just continually trying to create programs and to learn how these things work. I, in university, I had very, very, maybe weird types of languages. Because I think I learned a lot of them why even those weird ones like prom. org that are that's more like University, academic language. But even like scheme and Haskell and Math Lab, Java dotnet, which are more, let's say, enterprise II, but also a lot of SQL. So I think, for me, this thing was very useful of having a kind of a pressure from Well, the whole system system, the whole educational system from the university and the professors and everyone that basically, every six months, every semester, you need to learn two or three new languages. So that got that showed me the fact that it's not the language that's so important in anything that you do in software development, but it's choosing the language for what you do. And sometimes the choices can be, well, let's say more or less based on what you like. But quite often, the choices are based on what you need to do, depending on the problem you have. Like, it makes sense to use a very fast functional language for somewhere or somewhere where you need a lot of transactions, a lot of computations per minute. But it makes sense to you use something that's more structured, who has more typing in in an area where you need a lot of domain.
And you need one, and the domain and the domain is complex, so complex that you maybe you even need the experts in the domain. So I don't think he could fit the functional language in that approach. So I learned a lot of these things from my professors. And another thing that is very, for me striking now is that I, I learned a lot about databases and how they are formed from math, you know, because coming back to high school, I, I really learned learned that I needed to learn a lot of math. And now, if I talk about these things, like you know, a database is basically just a structure of mathematics and how you structure sets in, and you need to normalize them. And if I talk about these things, I think 97 to 99% of whoever I'm talking to will say What do you mean? And I find this striking because databases are in so poor shape, and it's always annoying to see that data is stored in a bad way. And but people try to reinvent other tools and other tools, but even with the new tools that don't use them well. So, um, let's say that in my II, there's this thing I learned that theory, mathematics, physics, even chemistry to some extent, can help a lot to understand what What software is because well, software started as mathematics in the early 20s 30s 40s 50s. Like it was, software was created by mathematicians. And it makes sense that all the languages that evolved after that all the languages have started to be used in industrial applications, like C or c++ or even Well, the other ones, COBOL, and so on, that are well, not so used now anymore, are our languages that are based on mathematics, and functional programming, even more is based on analytics. So if you don't understand this theoretical concept is very difficult to understand what a monad is in functional programming. So that's why I keep, let's say, pushing young people, students not to skip over these things. Because quite often I hear that No, these are useless. If you really want to learn how to code. Yeah, of course, you can learn how to code but when you reach the complex things, the the intricate parts of software development, then you need to understand the basis of of this coding. And mathematics is one part of it very important one.
Yeah, so then,
after, let's say, doing a lot of work, while programming in university, I started working also in during university as a as a junior programmer. But I never gave up this idea of trying to, to be a full stack developer, because I don't think in the world today, when technology changes so fast, I think it's a good idea to say I'm a Java programmer, I'm a dotnet. programmer, I'm a hospital programmer. Because you can mix them. So when you see so I don't just
Tim Bourguignon 12:31
say, when you say full stack, you don't mean just going from up to down or down to app from UI to the database and back, but also mixing up languages. Yeah,
Tim Bourguignon 12:40
modules in between.
Adrian Bolboaca 12:43
Yeah, exactly. Because maybe full stack can mean that is JavaScript and PHP in the front end, but then you use, I don't know Java in an API in the backend. And then then you need some good SQL skills to create a stored procedure. So I do find myself now, and I tell this, even during my workshops, that my purpose as a programmer, is someone who helps businesses, so their processes, improve their processes, and help helps businesses prosper. So that's what I need to do. That's what I want to do as a programmer. That's my, my view. And then if I don't know, many options, and I can come up with something that may work or not, or something that's not that effective. But the more languages, you know, the more approaches you know, it's more probable that you use the the best plan or the better one for that specific client. So yeah, that's my view of software nowadays, this is how or how we ended up to be in our age. And it's very different than what it used to be in the 50s or 60s. But I think, for me, software development starts to be more like I think that a lot of people should understand. You can see that software development is everywhere, like everyone wants to teach children to code. And I think we're all surrounded by software. So it makes sense that all we understand what it's there in our devices in our even home, household devices. But really understanding how to choose a solution for a specific problem that needs you really need to search for a lot of options. And I don't really agree with Well, how many companies approach this is to say we No Java. So we'll do a Java project.
Tim Bourguignon 15:04
There was there was my neck, my neck. What do you say to those companies? I mean, they have a point, when when they have only people who can do Java, or it would be silly.
Adrian Bolboaca 15:13
Yeah, I tell them. Oh, yeah, of course, I tell them, make sure not to disappoint your clients. And maybe it's better to,
to say no to projects, you're not
you Java, Java won't work. So it would be fair to take on those projects where you know, Java blew up very well. And you'll help your clients rather than come up with solutions that are way too heavy or way too difficult, where we inappropriate for their context and their needs.
I mean, it's fine.
Tim Bourguignon 15:52
Yeah. But then you have to accept that you have it and cannot solve any problem, which is the thing we tend to, to, to stick to well, we have a hammer, and we can hammer on everything.
Adrian Bolboaca 16:06
Yeah, I know. Especially. But that's that's exactly what that's the problem with. And going back back to this idea of crafting softer. And, you know, that's why, well, this thing started with with this old movement, because if you look in the old age, what what does it mean to craft? Well, it means to choose the appropriate tool for the appropriate task. So that's why if you look, there's about of tools, for everyone who, who used to do these crafts thing in more whatever area, like the he in the middle age, you know. So it's not possible to have only one, two and use it for everything. I know this because I like to, also to tinker and to fix things. And you know, when I go somewhere, I know I need a lot of tools. And I know I if I want to be fast, I will take a lot more than usual. So but then you need to know those tools, how to use them when to use them. Maybe you need to have tested them before, to feel them. So I think that's the idea to have a belt of tools. And of course, an ecosystem of as rich as Java could help. Help many, many problems. But not all of them, you know, this thing. And that's another thing like, can say I know Java as a language, but the whole ecosystem is very complex. So it's the same as having a belt of tools, trying to understand all the other things from the ecosystem, like with the same dotnet or with these more languages, that evolved by having a very big ecosystem around them. So again, you need to learn them, you need to understand the whole ecosystem of tools and and to have to use them to try them. So then, we get to the other thing about deliberate practice, having time to learn having quiet time to try them. And that's what happens in coding though, Joseph and code retreats and and just maybe giving people time to use them, try them. Don't try not to, for everyone, for every programmer in the company 100%. Try to give them slack. So they could try these. Otherwise, they will just have a smaller amount of tools, and they will start being less and less productive, as compared to what could be out there and help them improve their efficiency. Yeah, so that's why I teach to to clients. And that's what I tried to how I try to change
Tim Bourguignon 19:18
your clean goods, companies are receptive to this.
Adrian Bolboaca 19:23
More and more is because the company the market has this pressure of while you need to deliver faster and faster. So in order to deliver faster, probably you need to use the latest tools. And to use the latest tools you need to have time to learn them.
So there you go.
of makes sense.
Tim Bourguignon 19:51
Yes, it kind of makes, it makes total sense. But it's hard to to, to argument against numbers. So when when you have a deadline Line up your nose and you're supposed to deliver soon, and we're always supposed to deliver soon. So it's a never ending battle appeal battle. And so finding the right it's always hard.
Adrian Bolboaca 20:15
It's a very funny story funny, but interesting, like, we had the client and
we've done
an analysis for their whole process. And our conclusion was that they should sell less. Okay, so if they'd like to have more money, more profit, they should sell less. And that was very puzzling for them. How can that happen? You know, if you want to have more money, more profit, you need to sell more, right? But the thing is that they were they weren't focusing on the right clients. So they were doing things that weren't that effective with a lot of clients. So rather than just focusing on fewer and more good bad results, both economically and both for their developers, and then it took them like two years to come back to us and say, Yeah, you're right. And then we started to change a beta organization. And in a few months, they started seeing that they starting being a lot more effective, and the profits increased, and the programmers were happier. So but I think it depends on on what you said, the number is depends on what you, you look at what and compared to what it could be, or, you know, that thing like, okay, you can measure now the, how much money you make, but what if you could make more? What if you could deliver a lot faster? If she take a bit of time now to stop. And then it makes a lot more sense. So that's what I'm trying to do it to make this system where they take a bit of time off, then they will be a lot more productive because of tools because of knowledge because of process because of as well, many things.
Tim Bourguignon 22:18
And the movie a small sidetrack if if if I mean, you're you're mixing a lot of different hats, you are a programmer, yes. You're also in involved in architecting systems and maybe into infrastructure as well. You're training your country now that much, you're at different levels in the organization. Why that? And and how did you come to be? or How did you come to realizing you have to do this?
Adrian Bolboaca 22:50
Well, I'm not doing infrastructure I'm not, I'm not good at infrastructure, I can know how to set up a thing, but sadly, not doing at all the rest, yes, pretty much how I'm? Well, I think they all connect. And I even while I even have this opinion that if you want to have be a good HR transformation coach, digital transformation coach, on the process side, you either need to be very good technical, to have this ability to improve the tooling and the technical processes, the architecture, the design in the organization, or you should come with someone who has a pair who could do that. Because what often happens with organizations is that you have these process coaches, agile coaches, whatever, so they look more on how people communicate, interact, and make this a lot more effective. But in the second part, then you need immediately to understand how to improve the tech side, because that will be the bottleneck. So if you don't know how to do that, or if you don't have a parent to work with immediately on that everyone will be very frustrated. And I see this over and over again. So that because I I started seeing this problem of bad processes, trying to push when I was hired in the company, a few companies back. So I was trying to push this thing of good architecture, clean code unit testing, test driven development, from my, my part as a programmer. I said okay, it's not enough. So I need to understand how I can learn, I need to learn effect how to how to change things. So I started learning a lot more about change management, and how to communicate with managers and how to communicate with people that will, let's say they care about these things, but they need to understand them in their own language. So that's why I started doing more and more of these process things. But at the same time, I kept my Well, my this notion of understanding the technical things. And I know if you have if you want a good transformation from any process to any other process in an organization with programmers and testers and and ops and DevOps, and if you need to understand them, and do you need to give them the feeling that it will be better for them. And you need to give them tools and options and solutions for their immediate problem. So that's how I ended up doing these things. And I think architecture is one of the tools. I don't treat architecture more than that is a tool you need to know, in a bigger software system, you need to understand architecture. That is simple does that.
Tim Bourguignon 26:22
That's interesting what you wish you all said, I, I, I will always remember the this. This, the sentence Amitabha told me once. I said, Well, I read the DJI Manifesto, was it? Well, of course, I've read Manifesto, have you really read it? What's the first sentence as well, people interactions over processes and tools, no, no, the first sentence, that word. And there's this first sentence, which is overlooked all the time. And this is through working with our customers, by helping them and, and doing it, we have come to value. And this helping them and doing it is very important. coaches have their feet on both sides in the helping and in the doing and I can totally relate to what you were saying about being on both on the technical side and the on the organizational side, you have to have, at best two different persons playing on both sides, and then closely, communicating communicating with one another. This is what has been one of the pain points of a project I had recently where I was pushed on the organizational side, because there was a lot to do there and couldn't play on the technical side. And, and I had to have someone to play on the technical side for me. And we could quickly then communicate with one another. And without that all the teams where this person couldn't be as a technical coaching. We couldn't leverage really what the what we're doing. It was really, really visible. But something was missing. I can't believe. Yeah.
Adrian Bolboaca 28:09
So yeah, he kind of is visible like that. Yeah, for me as well. But unfortunately, you know, when a company says we need to transform our organization, because we need to deliver faster, let's, let's say the most common approach. They don't know what they need. So they don't know, they cannot know that they need a technical coach and an agile coach, and I don't know what chain isn't. They don't know. That's why they hire consultants. And some consultants do that. Some don't. So it's kind of difficult. It's that thing, you know, where is the thing? You don't know that you don't know? It's the most difficult.
Problem? Yes, it is probably.
Tim Bourguignon 28:56
And thus, the importance of networking and having good relationships with people who get cold your project and realize, well, we need a technical coach, who could I call?
Tim Bourguignon 29:07
And then nickel? Yeah,
Adrian Bolboaca 29:08
exactly. Yeah. Yeah.
Tim Bourguignon 29:11
Yeah. And we talked very shortly on architecture as one of the tools that you need to build. In Paris, you made a whole presentation about a different approach of architecture, the the evolution, evolutionary design, as we touch a bit on that.
Adrian Bolboaca 29:31
Yeah, sure. This is one of my favorite topics for last, maybe four or five years. I still can't come back to it more and more. I do make a distinction between evolutionary architecture and evolution design, the point of view that the design for me is something that programmer does. Daily, Weekly. Daily hourly, every, every minute when we write code. Well, the architectures is more or less like a direction scaffolding. Some people call it for, like, non functional requirement. But then when the Agile world peoples started saying, It's not like that it should be cross functional requirement, whatever. So a lot of something like hearing about security performance changeability, testability, all these things. So when I talk about devotion design, I don't talk from this point of view, at the higher level, I talk more at the level of trying to evolve a system, assuming that you already know these cross functional requirements, you have made this analysis, you talk to your customers, you understand, to some extent, the risks and you know, where you need to go. So you already have this in place. And then your design is, let's say, for me, as well. Many of my friends tell me, he's just research research. So I know some things but I'm still developing and evolving them as I go. So probably each few months, maybe half a year, I have new ideas that add up to the things I had already. And maybe in the future, I will come up with a book on this topic, or one hour, I'll have enough, let's say in my head to do this. What is evolution designed for me is an in a way, the next step after really working well with driven development. Because driven development is a tool is a process that helps you
evolve the code,
evolve the design, in an incremental way. By adding each test, adding behavior, adding something, and that works, continues. So it's very important to have this in mind. This is where I started from. So working a lot of DDD puzzled me on why do I take these decisions? Why do I choose these things? So then I started to try to, to understand why I work in this way, and talk with others and bear with a lot of people are really a lot of people and understand how they work.
Tim Bourguignon 32:55
And
Adrian Bolboaca 32:57
I saw that there are some patterns we use. So people who worked extensively on with DDD, let's say, five, 610 years, 15 years, they started evolving these heuristics, I call them No, the these ways of working together, and these will you're working with the code. And it's very interesting that you start having a feeling about how the coach work, but also you start having this this knowledge that a certain path of evolution, starting from from that specific test is a good way or is not a good way.
And this is just
personal knowledge coming from a lot of practice. So what I'm trying to do is I'm trying to put some rules, some laws on these things, and trying to understand these things. Why do people evolve code like that? And how feasible is it to evolve it like that?
Tim Bourguignon 34:08
If I may, reformulated it, there's to check if I understood it well. So TDD is test driven development invites you to write a test that describes behavior, and then write the code that goes with it, and just write the least amount of code possible to risk pass the test. And then refactor your code so that all tests pass and everything is nice and shiny, you know, or how it should be. So maybe you have to change the design a little bit to to, to make it better for the new idea you just had with this new test, and then write a new test and start again. And do observing this, you realize that the design constraints that emerge out of this are kind of always the same, or people that are used to TDD are always using or evolving the code in the same way Is this what was your mini
Adrian Bolboaca 35:02
Some,
some things are the same. Yes, some aren't. And this is puzzling, you know, then why? Why is it different? And then it's very interesting that I found that quite often it happens that people go on different paths of evolution, but they end up at the same solution.
So, you know, then
how can this happen?
And these are the questions I'm trying to answer with all this with this talk and with Well, my writing on evolutionary design. And basically, what I tried to solve is, is there a way we can understand how in very small steps of adding behavior, we can go to a solution that solves our business problem very fast? Can we have a way of sort of computing or of deciding if that is the shortest way or even that is a correct way of solving our business problem? And it's not a simple problem, it's not a simple question. And because it's a complex domain, where or, well i or i am working complex domains. And it's difficult to, to understand how these things go. And code is abstract. So then I end up to be very philosophical, as I was in the talk on various, because this is what happens when you want to take something that's very abstract, and distill it to two patterns, distill it to principles to laws, starts being kind of difficult to get. And then I always coming back to, let's say, my very old, early ages, I always love philosophy. And I probably started reading those a lot of philosophy, I'm especially fond of his extension is. But not only that, formally, I started reading philosophy when I was like 11, or 12. And yeah, I've always loved well, thinking in abstract place. So I'm, I'm very happy when I hear people talking in more or less in abstractions, rather than trying to be very
Earthbound.
For me, it feels like the natural environment. Well, then there's another very interesting thing with philosophy and with talking abstractions, is that when we we need want to explain a very complex thing, we already have this abstraction with just call that name, call that concept. And if, let's say both of the people who discuss understand the concept, they can move forward, so they can advanced, advanced the discussion and maybe find something that's very interesting. So that's why I really think we need abstractions, but we need to be educated to understand these abstractions, like the four elements of simple design, and that can back well created or invented or, you know, if you say the four elements of simple design, this is an abstraction of four very interesting observations in test driven development. But in order to understand what that means, really into work a lot and write a lot of code and to will practice your brain to understand how that is. So that you when you talk with someone else about the 49, simple design, more or less, you have the same idea about it and you understand it. So, yeah, is the same with design patterns, is the same way the behavior driven development or domain driven design, or no, all of these things are complex because we work in complex domains.
Tim Bourguignon 39:47
How would you increase encourage people, let's say let's say newcomers, or maybe less experienced developers to step into such trouble waters, about design patterns about metaphors, analogies, abstractions, etc. How would you advise to get in there?
Adrian Bolboaca 40:11
Well, I can tell them what I have done. Why was just what For me it was kind of special because I, I had these courses, workshops in university on design patterns, on on a lot of things about design, in fact, and solid principles. And we used to talk in the third year about cohesive systems. And so first of all, get some, some theory, if this didn't happen in, in, I don't know, high school or university, try to learn some theory, try to read books about these things like, well, the well known book from the Gang of Four design patterns, or the the Robert C. Martin book about the solid principles and try to read those. And then what I have done is I tried to use them in my code, but not in my production code. Because what happens after we read the design patterns book is that everything will be a design pattern. And the code becomes uselessly complicated. So then try to make some of your own pet projects, work on them, and get feedback from someone who knows better find a mentor. That's what I've done. I've always found someone who knows more than me, and and I was asking them, how is this code? How is this code? What do you think about this? But after a while of working on my projects, I started understanding them better. And they had feedback that no, I pretty much know how to use them. And only after that I started using these in high production code from work. So it's, it's theory, it's practice, you're on your own. It's my mentorship. That's my approach. And that's what I would recommend.
Tim Bourguignon 42:31
That's a very wise way to do it. Thank you. And I should of course, when he talks about mentorship, I'm all about it. So. Yeah. That's great. Well, thank you very much. Thank you very much, very wise and great. advices in there. Um, did we miss a topic? Did we miss a topic you wanted to talk about?
Adrian Bolboaca 42:53
Um, well, I just wanted to because I promised I'd come back to why the physics was very interesting. I, let's say that I, I done a lot of physics and physics problems in high school, and then University and I always enjoyed it. But no, he kind of tend to forget it if you don't use it for a while. And last year, I wanted to client and they were they they are having they're doing some
in on the call those
embedded systems, let's say just embedded systems, okay. And they they work. They're very technical. So one of their stories was something about how to measure current, and how to change from polar coordinates to I don't know, which coordinates now though. I've done these before. And I started telling them, hey, you should do this and that, and then I started immediately remembering of that new like, Whoa, how do you know this? You know? Oh, you know, it's just something I've done. So, yeah, this is why I keep coming back to this idea that you need theory, you need to understand, well, a lot more than just programming because it can happen in 1015 years, 20 years, I don't know. And you work with some team or you work in a team. While you maybe need physics or chemistry, or I don't know what. And knowing that or having known it is a lot easier to start off with because oh We softer tend to know makes progress in a lot of domains. So you need to get used very fast to the domain that you're, you're working. I agree with that. So. So I try to tell any students learn as much as you can don't don't say stupid don't say, you know, says useless sometime in the near future or sometimes a lot later in your career, you might use that. So if you're there, take the time and learn. It's the important thing. Yeah,
Tim Bourguignon 45:40
I have exactly the same, the same experience I I have an engineering background that was not in software at all. And I switch to something at the very end of my studies. And I worked in an in automatics, medicines and programmable components, and I worked in radio oncology, and on medical devices, etc. And I found it really always really helpful to be able to relate to the product to really understand how the product is working, even though it has nothing to do with software, and kind of have a feeling of what's going on in the companies as a whole. And not just on the engineering department on the software department. That's always very, very helpful to build bridges to network to, to understand what people are going through, etc. And, and one of those orders. At university, I did learn some interesting stuff. But most of all, I learned how to learn. And what you learned about chance went changing domains and going on to new domains and having to learn fast, what's happening is exactly this is going into a completely new branch of the industry that you don't know anything about, and just being helpful. From the very first thing. And this is this is a skill that you can learn at university and the universities that really prepare you for that.
Adrian Bolboaca 47:03
Oh, exactly. I totally agree on that.
Tim Bourguignon 47:07
So yeah, I agree. Do some physics. Um, so we've reached the end of our time box. Um, do you have anything on your plate coming up? So in the next months, I would say, at some conferences, we had some some new book if you new book is coming up in the next few months, so you describe it pretty well. Ready.
Adrian Bolboaca 47:32
Now well, I, I am,
I published last month, a book on facilitating technical events, which is more or less based on how to facilitate an open space. Like Socrates unconference? It's a case study of Socrates unconference, but you can use this MOOC for facilitate any kind of events of technical events, it goes from planning to talking with your life, say clients, like, would would benefit from this, and then two formats, and so on. So it's kind of 735 80 page book that I just published. So what else I want to do I want to finish, I'm working on a book on code, repeat sessions and calling it so it's about the explaining how to facilitate around 70 sessions of Bronco retreat. This is again for object facilitators. So I explain in detail how to facilitate these technical sessions 45 minutes from the code. Do you mean I don't know what
Tim Bourguignon 48:49
you mean, the different the different? exercises, so no talking? Yeah. Silent period. The TDD
Adrian Bolboaca 48:57
Yeah. Okay. Yeah.
Yeah, and I have at least have around 70 of them now. But I still need to write on some of them and and try to finish it. Maybe one or two months before the global day. I don't know how I will work on that. But I tried to keep me on a tight schedule so that I finish it at noon time. Yeah. So that's what I'm doing on deliberate on evolutionary design. I don't know. I just, I don't I don't feel I have enough now for book. But maybe after the book on Goodreads sessions. I'll start working on it. It feels like the natural moment, but it will take a few years.
Tim Bourguignon 49:47
Probably. I'm sure your brain is working on it right now. Even even though you
Adrian Bolboaca 49:52
Yeah, yeah, that's Yeah, yeah.
Tim Bourguignon 49:53
Yeah. Well, definitely. Okay, cool. Um, Where can the listeners find you
Adrian Bolboaca 50:01
Well, I have a blog, it's blog dot add Randall Barker co founder dot Pro. Or you can google me anywhere. It's Twitter at de bourgh, a DI d o LD. This is pretty much how I communicate to the world nowadays. So
Tim Bourguignon 50:22
yeah, I will add this and the links to your books are in the show notes. So listeners can go just below and click and get a direct link there.
Tim Bourguignon 50:32
Well, thank you, Brent. I
Tim Bourguignon 50:35
thank you very much for coming and explaining your dream. Um, that was very insightful.
Adrian Bolboaca 50:39
Yeah. Thank you for having me.
Tim Bourguignon 50:42
And this has been another episode of their journey. And we'll see you in two weeks. Bye.
listener. If you haven't subscribed yet, you can find this podcast on iTunes, Stitcher, Google music and much more. And if you like what we do, please help your fellow developers discover the podcast by writing it and writing a comment on those platforms. Thanks again. And it's been two weeks