#34 Richard Rodger on software development as a resource allocation problem
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, and welcome to developer's journey, the podcast shining a light on Developers Live from all over the world. My name is Tim Bourguignon, and today I receive Richard Roger. Hi, Richard, thanks for joining.
Richard Rodger 0:43
Hey, Tim, how you doing?
Tim Bourguignon 0:45
Pretty good, pretty good. Um, you are a developer, and enterpreneur, founder or CTO and author, I think active in the open source software communities and leading in communities well, and this is just the beginning of your bio, which I rewrote because it was too long. I think we have to hear it from you. So can you tell us which are the big milestones in your careers that led you to becoming such a broad developer abroad t shaped developer, maybe we can say, to develop such and such an expertise in many, many fields? Can you tell us just your developer's journey?
Richard Rodger 1:26
Sure. I would, I would just add a little bit of explanation. The reason I do so many things is because I'm, I'm pretty
Richard Rodger 1:35
bad. And all of them.
Richard Rodger 1:38
I think my my one true skill is synthesis. So sometimes, if you can bring different things together, you can create something new and interesting. My developer's journey starts in Africa, South Africa. So as a kid, I was completely obsessed with computers. So you know, these old 80s TV shows from Erika, Knight Rider. At the age of all these things, I was a super big fan. But Knight Rider was my favorite because it had a artificial intelligence in the car. I really wanted to program computers. And I grew up in a really small farming town and far north of South Africa. And I think there was like one computer, the whole town that did accounting for for like the local farmers cooperative or something. So my, my parents went to Johannesburg, and they bought me a spectrum 48 k computer and the some of your listeners might be familiar with this. With the spectrum it was it had these kind of like rubbery squishy keys, and he plugged into your TV, and you could start programming basic. And I didn't have any games. All I had was the manual.
And
it kind of started from there.
It kind of started from there. And
you know, it's it's a journey that kind of stops and starts. I eventually ended up in in Ireland with that South Africa in the 80s. And I remember my my grandmother bought me an Amiga 500, which is still the most awesome computer ever invented. And so in those days, there wasn't open source. So there wasn't a network. You know what I had to do? I spent I think it was something like 90 pounds. Okay, so in in in euros today, that's probably like 200 euros or something, something crazy to buy an assembler, a commercial assembler. So I have the tourniquet and Richie
you know, the C programming language
Richard Rodger 4:10
book, I
Richard Rodger 4:12
managed to get hold of a copy of that. But I couldn't afford a C compiler.
I had to buy an assembler instead.
So I had to hand compile the C code into six 8000 machine language, and then make API calls into the amigas windowing system. That was pretty slow. It sounds more impressive than a pause. Like I literally just got windows open and then you did very very basic stuff.
But it was that was still pretty cool.
And then, you know I kind of discovered
girls and rock and roll and stuff. Like that I sold my computer by a stereo.
Richard Rodger 5:06
I stopped coding for a long time
Richard Rodger 5:08
until I went to university. And so I ended up.
You see, the reason I say that I'm
not an expert at anything is I I tried to do theoretical physics.
Richard Rodger 5:21
But I wasn't.
Richard Rodger 5:23
I wasn't intelligent enough for theoretical physics. So they wouldn't let me in. So I got I got a consolation prize, which was mathematics and philosophy. which turned out to be really good, because philosophy, you don't have to work. And mathematics is
the mathematics department had
a whole load of really crazy funky post grad students who were Unix dissidents who set up this really awesome network for everybody in math in the mathematics department. So we have like, VT 100, terminals, green screens, you went into the like the attic of the mathematics department. And you know, these are like 24, seven terminal rooms where you could code
Richard Rodger 6:08
with
Richard Rodger 6:11
VI, right? So not vim
Richard Rodger 6:12
VI,
Richard Rodger 6:14
original vi on like some really ancient version of BSD. So you know, the, the introductory courses, were all this stuff, like, you know how to use how to use the internet, like network news, that type stuff, gopher, remember gopher. And you know how to code and C and c++ and Perl. So I did a lot of coding and not much mathematics. Really, not a lot of philosophy either. Although I can spell the reason I can write is because it's the last thing. So that's actually that's actually I would really recommend philosophy to
anyone. That's a good subject.
So So in my final year and university, I failed probability theory, but I got 90% in c++.
So average pass.
And I was you know, I was ultra University. I didn't know what to do. But I was I was getting these like summer jobs where I was like working in a warehouse.
I work for I work for
I'm going to sign and try and say correctly care her, you know, that the the steam cleaning vacuum? company? Yeah. So I worked for them in Vienna for summer in their warehouse, underneath a steel tin roof. And it was like 40 degrees. It was just, you know, at some after that summer, you know, I was speaking to my friends and in university, and one of them had got a job building websites. This is like 1996. And he was like, yeah, it's cool. You know, you stay inside an office. You know? So that Okay, that's what I'm doing next summer? No way. am I working? In no way? Am I doing manual labor anymore. And it kind of took off from there. I I saw I managed to find out the email addresses of 40 companies in Dublin in Ireland that were building websites. And I wrote a little Perl scripts, spam all of them.
Richard Rodger 8:21
What's my resume?
Richard Rodger 8:24
I got three interviews that I got one job offer. And that kind of started from there. And of course, by the time I left in 97, I mean, things are going crazy. the.com first.com boom was just taking off. I mean, you know, all those silly ideas that seems stupid at the time and but are now like billion dollar companies. Like in the course of that period of time. Like I built a real estate marketplace. I built a taxi app, like all that stuff, right? Except was like 15 years too early. weren't my ideas, by the way. I mean, we were just like a consulting company. We just build stuff for people. We thought
crazy, but we took their money.
Richard Rodger 9:08
And
Richard Rodger 9:11
I went through this period of about 10 years of really intense software developments in Perl and then Java. And I didn't really care about management's or business or anything like that. I was just because I didn't do computer science. I had everything to learn, but I was learning what I was being paid. You know, so I decided that for a while that was kind of crazy. So I went I did another degree in computer science as an evening degree, you know, you could study the evening and I you know that I finally learned proper stuff like, you know, complexity analysis and this type of stuff. And a little bit a little bit more of the proper theory. My code got a little bit better
Richard Rodger 9:59
and I think
Richard Rodger 10:03
I'm not sure how it happens. But it was after the.com, boom, after everything had gone kind of crazy that I kind of got the interest in starting a company. So it's, it's kind of an inverse relation, you think, before the.com, boom, that's when you would want to start a company. But afterwards, after I sold the dead companies, that's kind of when I started.
But I was sort of obsessed with this idea of
being like an indie developer. So that's like, where you, you have a website, and you have some software products. And you make, you know, not crazy amounts of money, a small amount of money, selling your software to people. You know, and then you don't have to have a boss, or project managers or any of those crazy people that make developers unhappy. And you can just build your own thing. But I was, I was a really bad business person, my first cup of tea, I spent more time building a custom built from scratch, I wrote every line of code, ecommerce application, did everything shopping cart, payments, product pages, everything, built it myself. just crazy. I mean, you know, these days, you know, you focus on the product, you don't go build your own shopping cart. That's true, or time to build a shopping cart and website than it did to build the
Richard Rodger 11:33
actual product.
Richard Rodger 11:37
But you know, that was stuff that was my first business and it kind of didn't work. And then I ended up, I ended up working. So I learned a lot, I now live in a small town called Waterford in southeast Portland, was founded by the Vikings 11 years ago.
Richard Rodger 11:55
And
Richard Rodger 11:57
it has the the Institute of Technology here, it was one of the very first to teach computer science in Ireland. So it always had a strong, it always had a really strong computer science faculty. And I ended up I ended up working in the research group there. coding, but also commercializing research. And that got me exposure to proper business people and proper business thinking because in order to write research proposals, you have to justify the commercial side. And I and you know that their whole job was to find startups or create startups from the technology that they were building was old, and it was all telecom stuff. And I was, so I was involved with the startup there that was eventually bought by Red Hat. So that was really exciting. That was a fantastic experience. And I sort of decided then, to try something, again, didn't have any idea what to do. But myself and a couple of other people. Because we didn't really have any ideas, we we just did a consulting company. And that was in 2011, just the time that no GS start becoming popular. And we decided to pick no GS as our technology. And, and we were super, super lucky because no GS took off and became really popular. Whatever opinions about it, it became popular. And if you're a consulting company with the popular technology,
then you have a successful business. And you can make
all sorts of mistakes, which we did. But
Richard Rodger 13:39
it
Richard Rodger 13:43
is lets you kind of cover for those mistakes. And that's how I got into microservices,
which is my, my favorites.
software architecture now.
Because if you've ever tried to build a
large application in JavaScript, you have to have that it's really hard.
Richard Rodger 14:03
gives you those structure. There's no object oriented
Richard Rodger 14:08
patterns that really work. It's a crazy, crazy language. And you just you just end up if you write more than 2000 lines of code in one file, you're in trouble.
So you have to you end up you end
up splitting it apart into micro services, because otherwise things end up crazy. So that's kind of that's where I ended up using this this architectural approach, I guess. And now I So eventually, I got tired of building software for other people and kind of wanted to go back to my own one and building my own my own software for my own company. So that's why I've left that consulting company to start a proper sort of Silicon Valley style startup now, but also because I believe that we microservices approach will let me build stuff with a small team really, really fast.
And that's kind of working, which is, which is nice.
So that takes us up to today.
Tim Bourguignon 15:12
Cool. Cool. Nice. So so you you went to the you tried the Indian route, and then took some some detours and came back to the Indian route, actually.
Richard Rodger 15:28
Yeah, yeah, I,
Richard Rodger 15:31
I had a lot of difficulty when I was younger, working in large organizations, and understanding political hierarchies, and understanding the value of sales and marketing and the difficulties of coordinating large teams of people, I understand it all now, because I have to figure it out and learn it's to make money myself, but when you're a young developer, you can be very idealistic.
You can be a bit of
not a very nice person, I suppose.
I mean, I didn't have lots of fights with people or anything. But, you know, I think a lot of project managers had a lot of stress,
because I wanted to make perfect software all the time.
Which is about idea, software's.
If you're not producing software that has a measurable,
repeatable level of errors,
you're not actually making efficient use of resources.
There's a game on my conference talks that talked about this. So the space shuttle software is probably one of the most perfect pieces of software ever built. It costs something like $1,000 per line of code, and every release had like one bug. This is over like millions of lines of code. You know, and it was, you know, fully documented a test of the multiple layers near the the capability mature maturity model comes from that software team. And I think we, as software developers, bring that mentality to loads and loads of inappropriate contexts, like building websites, where it doesn't have to be that good. You know, you can have an acceptable error rate. You know, what's more important is to, is to try and understand the business goals. And how you can efficiently Yeah, how you can efficiently deliver the business goals. Even if you do have errors. I think we forget the practicalities as developers sometimes.
Tim Bourguignon 17:46
How would you convince your younger self, that this is the route to take,
Richard Rodger 17:54
I would have paid more attention in philosophy class.
Richard Rodger 18:00
This is not a tech.
Richard Rodger 18:04
So you know
Richard Rodger 18:05
how you know, you know, one way that I developed an intuition for this idea was an addiction to civilization, you know that, you know, the computer game civilization, which is about resource allocation, which is, that's what running a business is, right? You've got limited resources, you have to allocate them efficiently. And if you think about software development, the limited resources is your mental, your mental ability, right? The ability to hold the architecture all in your head at the same time, your your basic mental energy levels and how much time you can actually spend coding. I mean, that's the problem with younger developers is they have so much mental energy. You know, they can brute force solution, sometimes sometimes if they're good. But ultimately, it's a it's a resource allocation problem. You only have so much mental capacity to build a complex thing. That if you aren't careful about how you use it, you end up with projects that are late and over budget. And that I think would appeal to the scientific and philosophy, philosophical side of my younger self is just to connect those things together. As opposed to being, you know, ideological about building software that had zero bugs.
Tim Bourguignon 19:34
Yeah, it makes sense. Makes sense? Um, I would like to to jump to one thing you said, if I may, um, you mentioned during your your your introduction or your, your your career that you went back to, to evening university or to an evening degree in Computer Sciences. Why did you have the feeling you need this Because you were you were running or you were part of a running work running company, you were producing apps, you were kind of having
Richard Rodger 20:09
having
Tim Bourguignon 20:11
a great start in your career. So it sounds?
Richard Rodger 20:13
Yeah, it's a good question. Because some of the best software developers I've ever worked with tilt themselves, you know, some of them didn't even finish high school.
So it's not necessary to do formal education at all.
I mean, what one reason was, I was embarrassed, because although my average grade was a pass, it wasn't a very good pass. Because I, you know, if you do mathematics, you have to work very hard, you have to study, you cannot memorize it, you cannot just, you cannot just do some work in the last week and then do the exam, you can do that philosophy. If that's if it's easy to pass, it's very hard to fail, but in in mathematics is very unforgiving. If you don't do the work, you don't, you don't do as well. And I was embarrassed that I didn't do a good job in that degree. And when you're young, you think you have loads of time. And I'll do another one, and then prove I could actually do well, I did, I did, I got the first the second one. But that's because of maturity more than ability.
Richard Rodger 21:22
So
Richard Rodger 21:24
but I did feel that if I was going to make software, my actual career that I would need a proper qualification. And I wouldn't think that now
I would completely disagree. Now.
You've got to remember, if you grow up in
Ireland, in the 1980s, there's no jobs, the only possibility that you have to make your life better as education. And when you get that education, then you go to London, or Germany, or America or somewhere like that to get into turn a property. Because there's no jobs aren't. And that all changed. But it's very hard to segment a fish in the ocean can't see the water, it's very hard to think outside fatness, that necessity, you're stuck with a mental model that formal education gives you permission to code. Perhaps. I didn't see it at the time. But I was lucky because that particular degree was focused on older people. And it wasn't just about computer science, they did a lot of business. And they did a lot of law as well. And they did a lot of project management. So I was lucky in the sense that it taught me a whole bunch of really useful skills to be more than just more than just a junior developer. So I, you know, just by accident, I ended up learning a lot of business skills from that, from that in that that course as well, which have been really, really useful to me over the years.
Richard Rodger 23:07
So
Richard Rodger 23:09
yeah, I mean, would I advise people to do it now, I don't know. There's so much resources. Now, I'm teaching my children to code. But the way that I'm doing it, especially with younger ones is there's like these apps, there's an app called like bot, you have this little robot that you you can tell it to move left or right or forward. And you solve puzzles, it's really awesome. And but then as you go through the app, you can start defining go twos and loops and little functions.
Really, really, really sweet little app.
So you know, they, they start developing intuitions about coding.
And as you know, loads of
podcasts, for example, loads of YouTube videos, all that sort of thing you can learn, you can teach yourself so I don't know if the the the era perhaps of that level of formal education
is perhaps not so important anymore.
Tim Bourguignon 24:13
Yeah, I've taken part two to heated discussions about should new explicitly explicitly formulated. So should new developers learn to learn binary at all? Or is it something of the past already?
Richard Rodger 24:31
Okay, so
Richard Rodger 24:32
yeah. So here's, here's the thing. No, you
Richard Rodger 24:37
you useful?
Richard Rodger 24:40
I think, I think philosophically
this comes from my, my sort of basic mental stance, which is synthesis is you have to understand the basic level of everything. You have to be able to say, you know, look at this MacBook Pro in front of He explained to me how it works all the way up from the electrons to the the GUI that you're looking at.
Richard Rodger 25:10
I think,
Richard Rodger 25:12
at some level as a professional software engineer, you have to be able to explain how all of those pieces fit together. I can't, I can't design an integrated circuit, but I understand I understand the basic principles of logic gates, someone put a gun to my head, I could probably figure out how to do how to build an adder or something like that.
You know, I and
Richard Rodger 25:39
all the way up to the oldest level
Richard Rodger 25:40
of levels of abstraction around hardware drivers and network and all those things. Even if you work at the surface level, I mean, JavaScript for a living, which is just so far removed from from the physical reality of the machine. But even so that, that understanding, it just helps you make the right decisions, because you have the full context of you know, a bit bit twiddling and, and binary logic is still something you have to do in JavaScript sometimes.
Tim Bourguignon 26:15
Let's say in JavaScript, maybe if you had a new developer, with you, some some junior developer coming coming out of university that knows nothing like we all know, when you come from University. I'm starting with JavaScript today. How would you go on in teaching how to write a proper application with JavaScript, since it's your, it's your cup of tea.
Richard Rodger 26:45
It's very, it's very challenging. So I had this exact situation in my company. And what I ended up doing was moving that junior engineer to Python. And getting into write microservices in Python. JavaScript is a bad language to start with. It has a lot is lots of kind of crazy concepts. There's all this you get all this kind of power of functional programming. But then you have this prototype based object model. And then you have all the, you know, the the all that all that weird edge cases, which aren't edge cases, they're kind of by design. Python is really the place to start. If you want to build somebody into being a good engineer. It's not as bad a choice as it was, you know, because the whole AI world is based on it. Now.
You know, what I wrote my book I did,
I did the whole, I did a chapter on statistical analysis of microservices in their behavior. And I use Jupiter notebook, it was fantastic. Work tips is wonderful, you could be used flippy, flippy, charts diagrams. If you're using a microservices architecture, we'll have to say that really go by then you can have a polyglot approach. And it doesn't really matter what things are written in. I mean, think about the craziness of modern front end development.
It's insane. completely insane.
You know, the frameworks keep changing all the time the browser keeps changing. There's this hideous amount of complexity, you have to learn three different languages that are based on different paradigms, you know, they have HTML tag suit, but HTML is hugely fault tolerant. You have CSS, which nobody really understands. And of course, you don't really use CSS because you have to use sass if you want to build a large scale app. And then you have all these internet fights or people who talk about semantic CSS versus atomic CSS,
you know, which one you choose,
there's probably going to be a new paradigm in three years time. And then that's even before you start on JavaScript, and then people are telling you, you should be using TypeScript, because that's proper engineering. And oh, yeah, now you have to compile everything using Webpack, and fable.
Richard Rodger 29:09
And,
Richard Rodger 29:11
you know, I started coding
this stuff in 97. And I think it was JavaScript was just out then or the year before. version, I did it in 96, or 97, I think. And it was static HTML, no CSS, and you wrote a Perl script, which had this incredibly simple model of here's a, here's a, here's a, here's a table of name value pairs, connect to a database, write some SQL, and then throw some throw results back. If you wanna get really fancy, you could use a template and that was it. And I mean, it was easy to Learn and you can still build useful stuff. Now, I don't know. I, you, you sort of need to.
I mean, of course there are people who don't
consider themselves and there's tons of resources.
But if you're trying to take somebody and turn them into a software engineer to somebody who can build large applications, with all this other craziness going on, it's it's really hard.
I would say, just use Python.
It's much simpler to show somebody proper software design
Richard Rodger 30:42
that's in the desert.
Tim Bourguignon 30:44
And how would you go in and going or ease somebody into the idea of microservices, I'm coming at this problem from different angle. I'm mostly in in agility. And I'm now facing a generation of developers who have never lived through a waterfall project. So we are coming at this problem with a complete different angle. And I guess with microservices that might be something similar. students coming in and have the idea of microservices is completely obvious to them. Is it this way?
Richard Rodger 31:23
Yeah, that is a really, that's a really interesting observation. Wow. Because I remember when Agia was revolutionary, right? So extreme programming, all that stuff. I mean, when I read that book, it was, Oh, my Oh, my God, this is,
this is how we need to build software.
Richard Rodger 31:43
Yeah, the
Richard Rodger 31:46
the problem that we have is is
there is an idea of microservices as being just break everything down into small pieces that communicate or network, and it's all just small web servers. Or, you know, you push it to its extreme. And there nano services, we have serverless architectures, which do have their advantages and benefits for sure. But I came to microservices from a very different direction, which was a search for a component model that worked. I didn't come at it from wanting to scale, or anything like that I came at it from the problem of trying to solve technical debt in large software systems. How do you stop early decisions about data schemas and data structures? And, you know, relations between Java packages and object models and design patterns from slowly descending into chaos? Right? And so the inevitable entropy that builds up? over time? How do you it always will, it's inevitable? But how do you how do you at least control the pace or you contain it and stop it from spreading throughout your application? So I was searching for a component model for a long time. And I was very fond to the command pattern. You know, wherever everything that happens in your application is a command, you know, you can effectively define it statically. And then your your entire application is just an engine that runs commands.
Because it gives you a very nice mental model.
But it doesn't really solve the component problem.
You know, how do we, how do we get to Lego where you can have pieces of software that have business logic in them that you can put together. So when I talk about a component model, what I don't mean is, you know, a component that can do XML parsing, or send emails, or something, you know, or something like that, or template engine, or, you know, is a database driver. That's not what I mean, you know, or a little utility function. A component, when you're building a real application is something like a user module that understands the business logic of users that they can register, that they have password resets, that you can block them if they have too many failed login attempts, the business logic or a shopping cart, which understands how to calculate sales tax, you know, or a discussion component, which understands how, you know, a little discussion feature in your app might work that people send each other messages and you know, some of them are public, and some of them are DNS, this type of thing.
That sort of, for me, that's business logic.
And I want to be able to take a discussion component, plug it into my application and a user component and plug it in and that All of these different types of things so that I don't have to keep on redesigning entire architectures around these basic business logic ideas. I want to stress this is different from, you know, an authentication component that knows that gives you an easy way to do OAuth with with Twitter or whatever. This is the next level up the next level of abstraction.
And objects were supposed to do that, but they kind of failed.
And I think they failed because their interface capabilities were too powerful. So if you think about how do you interface with objects, you can call methods you can call static methods, you have Object Properties, you have static properties, you have inheritance, you might have mixings, in some languages, you know, there might be interfaces, proxies, you know, factories or factory factories, there's just all sorts of really complex ways of interfacing with an object. Compare that to a component model that is actually effective, which is the Unix command line, where the only interface is a stream of bytes. And you can create little bash scripts, you know, the pipe the bytes from one command to another and graph them, whatever, right? That's a really effective component model. It's limited, of course, but you can actually do a lot with it if you try.
Richard Rodger 36:35
But it's too simple.
Richard Rodger 36:38
So I kind of, I kind of experimented over the years with a number of implementations of the command pattern and kind of came to a point where I realized that
Richard Rodger 36:49
if you
Richard Rodger 36:50
did pattern matching on the commands, it would give you a component model. Because the user component would expose a bunch of commands to do things like register a user or log in and create a user this type of thing. And those are the commands are effectively messages that are sent to that component. And you can have generic user components that, let's say you're building a HR management system, you can have a generic user component that understands how to log people in. But then you can write another special component that understands that when managers log in, they need to see a special management dashboard. And that component can intercept messages that it can look at the content of the message and say, Okay, this is this user is of type manager, for example. And it's not really important, how you establish that it's just the some attribute of the message that's different. But if you think about what's happened there, I have a, I have a reusable generic component for users. And then I have extended this with a special case for managers, which has special case business logic for my company. But I've, I didn't have to change the internal logic or data structures
or code of the original component.
And I plugged them together. But I also didn't have to really understand much about the interface of that component. All I had to do was get in the way of some of its messages and take them over. And that is enough, in a lot of ways to build complex software systems. I know it doesn't sound doesn't sound like it's enough. But it's a component model where the interfaces are a bit more complicated than Unix. byte streams just a little bit more complicated, but much, much simpler than complex rest API's or object interfaces or anything like that. The interface is just complicated. It just has enough complexity that you can
encode different business rules.
And I built that first system that had that component model as a monolith. It had nothing to do with networking and separate deployment or any of the microservices stuff.
Richard Rodger 39:24
But after
Richard Rodger 39:24
I built it in JavaScript to manage the complexity we were seeing in the JavaScript applications we were building because if I didn't deliver stuff on time, I didn't get to pay my pay my salary and I didn't get to pay my mortgage. So it was a business necessity to come up with a faster way to build things. But then you can see how if if if the command pattern is just messages, and essentially essentially the messages are routed from a router to the right component, moving back to a network context is trivial reading. transport of a message instead of returning a function call, an asynchronous function call is now a network request. But the same basic model applies. And that has turned out to be super, super powerful. And that then dovetailed with the whole microservices movement. So for me, that's what micro services are. They are business logic components. It's irrelevant, irrelevant that they are
small, separately deployable
applications that you run with Kubernetes. And you have to have a service mesh, and all sorts of all that all that other stuff. And all of that is completely irrelevant.
People get so caught up with that, at that side of it. It's not what matters.
Tim Bourguignon 40:39
This is an interesting, interesting take on it. That's, that's a, an angle I hadn't really pondered on until now, I need to think about this. And I guess this is the essence or the, the, the way, you're falling out on your book The The Tao of microservices.
Richard Rodger 40:59
Yeah, so I kind of go into the philosophy of that whole approach in the book. But there's only one chapter that has code in it, which is, the last chapter is kind of a case study of a search engine built with microservice architecture. Yeah, I mean, I guess there's two principles that really make that work. One is the pattern matching, which allows you to have this component model with the messages. And the other one is transport independence, which is really just saying, stop obsessing about whether it should be going through Kafka or HTTP, or whether it should be synchronous, or asynchronous, or whatever, doesn't really matter. A micro service, which is like components sends a message, how it ends up at the other micro service doesn't matter. This is the infrastructure should look after that these might just be a direct HTTP call. Might be a Kafka queue, it might be rabbit mq, it might be Redis. pub sub, doesn't matter. And whether it's, you know, whether it's a worker pattern, whether multiple other micro services, see the message or not, also, you know that that's, that's a, that's a configuration issue in your in your message routing.
Now, some people turn around, they go, Oh, my service bus,
just reinvented metaphor, service bus, you're headed for cluster. But the difference is an enterprise service bus contained complex business logic, you could write code that ran in the bus, to do routing. With this, you deliberately keep your routing, ultra, ultra simple. It's just a pattern matching, and just powerful enough to provide that component model where you can intercept other messages and do different things. But
Richard Rodger 42:46
my calls,
Tim Bourguignon 42:48
I guess, if listeners want to listen to to get more of that, I think your book should be the right place to start.
Richard Rodger 42:55
Yes, yes, sir.
It's somewhat sarcastic book. So I, I'm very, very impatient with enterprise software developers. Even better.
Tim Bourguignon 43:11
It's an angry book, I suppose you could say, yeah, it's getting better the minute cool.
Sarcasm is, uh, is running high in our industry, I think we're unfortunately reaching the end of our time box. Um, do you have any advice that you would summarize or give to the listeners, some somebody starting the journey and say, This is what I would like to give you on your journey?
Richard Rodger 43:38
Yes.
Richard Rodger 43:41
You have to be very
conscious and deliberate about the mental models that you're using to understand the world. So you remember, I was talking earlier, in the podcast, that's when I was younger. I hadn't developed very sophisticated mental models of the world. You can't just assume that you understand exactly how the world works. You actually have to seek out better models.
You know, and a good place to start is understanding
human psychological fallacies, right? our biases. Yeah. So this is, you know, this, this, there's like basic stuff like anchoring, right? You know, so you walk into a supermarket to buy wine, and there's really, really cheap wine that you're not going to buy because it's probably vinegar. And there's really, really expensive wine that you're not gonna buy either because it's outside your budget. But then in the middle is wine, that's probably double the price, triple the price of the really cheap stuff. But still less than half the price of the really expensive stuff. And you look at that and you go, Oh, that's reasonable. That's, you know, I'm going to buy the middle way. But that's not an accident that's completely delivered. The that does that pricing structure has been constructed to take advantage of a psychological basis because Cuz you've been anchored to the really high price, and you think the middle price is now a reasonable price. or things like, you know, I think it's called the availability fallacy where you know, you, you read a really cool article about some data structure, you should start using it in your code in your head, as opposed to thinking, well is this is this an appropriate structure for the problem that I'm trying. So this is a really great blog, actually. It's called the farnam Street, blog, fa, r nm. And they have a whole list of all these really cool mental models and psychological biases. And I mean, you know, if you, if you want your project to be late, and do no work for the next two weeks, website, check out they have a good podcast as well. So, you know, it's not just about if you're, if you're in your 20s, as a software developer, it's not just about role intelligence, and little Brain, Brain Power. It's also about how you protect yourself from the weakness of the human brain, which is very, very weak. So that's, that's I think that's the place. That's that's the right sort of approach to take. You know, if you don't have good mental models, you won't have good outcomes.
Richard Rodger 46:32
Amen. Thank you.
Richard Rodger 46:35
Thank you to Tim. Yeah, that was pretty, very philosophical discussion.
Tim Bourguignon 46:39
It was it was
Richard Rodger 46:40
what I thought.
Tim Bourguignon 46:44
I think it was not mathematical.
Richard Rodger 46:47
Absolutely.
Tim Bourguignon 46:54
Before we, we call it today, um, what's on your plate right now? And when? Where can people find you and start a discussion with you?
Richard Rodger 47:05
Yeah, so I'm doing a new startup called box geek.com. And I'm a conference speaker, and there's no proper online applications for conference speakers to help them manage their conference planning, that sort of stuff. So I decided to build one.
And, you know, it's
it's all built using micro services. We do a whole bunch of open source, we open source about half the application. It's based on actually captured by by book The the underlying architecture. So I'm always happy to always happy to talk about that side. But it's that component model that I that I spoke about. There is a open source project called Seneca j. s. org that implements it in JavaScript, but you could implemented in any language. So that's another good place. And Twitter as well, of course, rjr dgr is a good place to annoy me if you have questions.
Tim Bourguignon 48:12
Cool, then I think we have a wonderful, thank you. Thank you very much. It's been a pleasure talking to you and recording your developer's journey. And the listeners will talk to each other in two weeks. Thank you. Bye, bye. Dear 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 in two weeks