An interview with Leonardo Giordani
  • February 8th, 2019

Leonardo Giordani, Author of Clean Architectures in Python: A practical approach to better software design

1 H 3 MIN
In this Episode

Leonardo Giordani is the author of the Leanpub book Clean Architectures in Python: A practical approach to better software design. In this interview, Leanpub co-founder Len Epp talks with Leonardo about his background, studying telecommunications in Milan, the Amiga computer and its issues running DOOM, the importance of test-driven development in programming, clean software architecture, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on January 29, 2018.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.


Clean Architectures in Python: A practical approach to better software design by Leonardo Giordani

Len: Hi, I'm Len Epp from Leanpub, and in this Frontmatter Podcast, I'll be interviewing Leonardo Giordani.

Based in London, Leonardo is currently senior infrastructure engineer at We Got POP, a company that makes innovative software used in film production workflows.

You can follow Leonardo on Twitter at tw_lgiordani and read his blog, The Digital Cat, on tech subjects at

Leonardo is the author of the Leanpub book Clean Architectures in Python: A practical approach to better software design. His book is meant to help people discover test-driven development methods and practices for creating clean architectures in their programming, regardless of their particular architecture or development methodology.

In this interview we're going to talk about Leonardo's background and career, professional interests, his book, and at the end we'll talk a little bit about his experience using Leanpub to self-publish his writing.

So, thank you Leonardo for being on the Frontmatter Podcast.

Leonardo: Thank you for inviting me, it's quite an introduction.

Len: I usually like to start these interviews by asking people for their origin story. Can you tell us a little bit about where you grew up and how you first became interested in computers and technology? You write in your book that you got a taste of the free software movement in the 80s, and I was wondering if you were into programming as a kid?

Leonardo: I was born in Italy. I grew up in a very small village in the Dolomites, which are the mountains between Northern Italy and Austria. Believe me, those are among the most beautiful places in the world. I know I can sound a bit biased. I'll send you some pictures and then you can decide.

However, there are that many - how to put it - backwater villages there. I don't mean it in a negative sense. On the contrary, life runs at a slow pace, you are immersed in nature. Things are somehow simpler there.

However, technically speaking, they are on the outskirts of the world. So sometimes nowadays when I investigate computer history or facts on the Internet, I realize that my timeline is a bit shifted, because what happened in USA at a certain point, happened in Italy - like three years later it happened in my village, five years later. Sometimes it's like, "Really, Intel produced the 486 in 1989, what?"

I spent 19 years there attending school, and living my life as a teenager. In 1987 - I checked the date yesterday with my father - I got my hands on a ZX Spectrum, which my father brought as a part of a computer course for him. That unfortunately never happened, but my father was always trying to get something new to learn.

However, I got the computer and this very simple textbook - a bunch of sheets about programming. I remember this cartoon character like holding a box with a number in it, and with a name printed on it. This was my introduction to variables. And that's where everything started, with this cartoon character.

I started trying to code things, like colored lines, boxes, loops, printing. "Hi, how are you?" and so on.

One year later, 1988, my father bought a PC. An Amstrad 8086. And then I started learning Pascal with these amazing Borland versions, still one of the best things I ever used.

Then I got in touch with Assembly programming, which I completely fell in love with. I had this book by Peter Norton. I still remember it. That was guiding the reader to programming a simplified version of the Norton Utilities.

It was amazing, mind blowing. I eventually had to move to higher-level languages, but I have to say that what I liked the most is still low-level assembly programming. This is one of the best things I learnt.

As for the free software movement, I probably should change the date to late 80s or 90s, because it's more realistic. However, what I want to say there is - I grew up in a world where computer science was still in it's infancy. And the atmosphere was still that of a free sharing of knowledge. I distinctly remember this. I didn't have any BBS connection at the time, it was too expensive, so I wasn't in contact with any real community. But the feeling you had of the whole thing, like to magazines for example - how can I describe it?

It was like a bunch of explorers helping each other to conquer this new country. Computer science, do you see what I mean? It was something other than the corporate view of, "This is my secret code, don't mess with it."

It's a complex topic. But what happens now with open source, what happened in the late years with open source, stuck with for example these things. For me, these things are somehow natural, because they are back to the origin of how software was conceived, so to speak.

Len: And how did you develop an interest in cryptography specifically?

Leonardo: I always loved math, and also algorithms - well maybe algorithms not always, but I remember when I discovered - I had some text file on my PC, it was explaining how the compression algorithm worked. The zip algorithm was incredible. So, loving math and algorithms, I would say probably cryptography's the perfect match.

But I actually struggle to remember when I first started - seriously, so to speak. I believe it happened later around 2000, 2001 probably, because I got this book entitled The Code Book by Simon Singh. It's a brief history of cryptography's. It's 400 pages or something. It knocked me out. It was like, this science is amazing.

And then when [reding the book] I got to the World War, the second one - I was like, "Give me an Enigma machine now," I want it. And then I bought The Codebreakers, which is a book by David Khan. It's like 1,000 pages of, "Give me an Enigma now." It's really amazing. These are history books, but I got involved with the things. And in the meanwhile, I started looking into the more theoretical side of it.

Some years later, I took the Stanford cryptography online course. It was amazing, it was very difficult to follow. I was working at the time, so I had to study during the evening. However, it never became my job. But I would say probably it is the second thing I love the most, after programming.

I would say I definitely like this war between cryptographers and code breakers. It's like a puzzle. It's like the war between game production companies and crackers about copy-protection systems. I'm not endorsing illegal activities, just to be clear. I'm in love with this game. Like, "Oh you think this is going to be impossible to read? I'm going to outsmart you and read it." It's amazing.

Len: You studied at Politecnico di Milano, the oldest university in Milan and the biggest technical university in Italy. One question I really like to ask people in tech on this podcast is - if you were starting out now with the aim of working in tech, would you go to university and study computer science? In your Leanpub profile you say you "Like both the theoretical and practical aspects of computer science." So I think I can guess the answer, but I thought I would ask you anyway.

Leonardo: I think the answer might surprise you, because it's, "No."

Len: Oh, that's very surprising.

Leonardo: Let me clarify a bit. I studied telecommunications, which in Milan was one of three major branches of electronic engineering. The other two are like pure electronics, so hardware, and computer science. And telecommunication was somehow in-between. It was like this mix between hardware and software - the use of mathematics and physics for something practical. It seemed to me like a big world I could explore. Computer science at the time, it looked - this was my impression, I'm not saying that this is what it was, but it looked much more, I would say, narrow minded. I got this feeling of it being very bureaucratic, if you see what I mean? Like the communication is more important than the software itself.

I give you this example, because I got in touch with computer science, studying telecommunications. I studied operating systems because I liked the subject and I took the course. I was already using Linux, so I was into the kernel, maybe not kernel programming, but understanding what it was.

So I took the course. And the first part of the course ended with a project which was part of the final exam. It was a simple, let's say, concurrency problem. Like a system that spawns multiple processes, and had them communicate to a messaging system. It was like a post office. I enjoyed it a lot. Actually I enjoyed it so much that I wrote six blog posts on that project, and I opened the blog to publish those posts. So I was really into it.

I remember at the exam, it was like demo time and teacher asked me, "Okay, do you have your project?" I was so excited to see all these processes spinning up and getting in touch with the main processes. Somehow a micro-universe. And the teacher was like, "Yeah, yeah okay, can you show me the documentation, specifications, use cases?" I was flabbergasted, speechless. Because I thought, "Can't you see the beauty of this thing?"

I don't like methodologies when they are so - arid, detached from the real stuff. Again, this was my perception. I might be completely wrong, but in the end I enjoyed telecommunications for the reason I mentioned. And I will do it again. Well no, no wait. I don't know if I would be able to take 30 exams again. But I enjoy this.

Len: Thank you for the wonderful stories. I should say - it's funny you say that about exams. I was thinking a similar thing the other day, whereas I might see myself as being wiser than my younger self, I certainly don't think have the kind of energy to tackle exams in the way that I could when I was younger.

One thing I like to ask people about on this podcast is what the startup scene is like in countries where they've lived. I know you don't live there anymore and it's a very broad question about a very big country, but can you tell our listeners a little bit about what the tech startup scene is like in Italy?

Leonardo: Sure. I'm not an expert, but when I left Italy two years and a half ago, it was in a sorry state actually. There were some companies, some startups here and there scattered around the country. I really struggled to find them. I was looking for a new job. I liked being in a small company more than in a big one. The thing is, there are not many investors and somehow the bureaucracies are - it's tough. It is enough to cool down initiative in some people. In me, for sure. Other people, fortunately not.

But I saw something change in these two years - following on Twitter, getting in touch with some people. It seems to me that there are more startups, like in Milan for example. It's the biggest industrial city, so it's a good measure of what's happening in the country. Still, I believe the comparison with London is disheartening. It's completely different. But I don't know, times are changing.

If someone from Italy's listening, I want to say, "Just go on." Because I personally completed lack any entrepreneurial skills. I'm not the type. But I can see myself in the future helping small companies maybe, at least on the technical side - not founding anything.

Len: As I gathered researching for this interview, you spent much of your career in Milan, working on a satellite imagery processing system. And then a couple of years ago, as I think you just mentioned - you switched industries and you moved to London. What prompted that big career move?

Leonardo: I learned a lot in my previous company. I had a lot of freedom and responsibilities. They hired me after I just got my degree. We built some very big systems for this satellite imagery processing. Some very big things. Some from scratch. I learned a lot for the better and worse. Anyway, I learned a lot.

After 13 years, however, it was time to move on. Basically I realized that the place wasn't challenging me anymore. What I did was enough for the company. I hope I will learn new stuff until I die. But however, it was time to do something different.

I surveyed some startups in the country, more in the Milan area, but around Italy. And then eventually, I tried to go to the US. My idea was - I tried a visa. What's the name? Visa lottery. If I win the lottery, it's a good sign that I have to go there. If I don't win it, maybe I have to stay here. I tried in Dublin, and then a friend of mine told me, "You're crazy, why don't you go to London?"

And the thing is, I had this sort of prejudice. I don't know why. I really don't know. It was like I thought, "London is all about finance." Obviously there's a lot of finance there, so I assumed it was all about financial software. And I felt like I don't want to be in such a stressful environment. I'm a slow thinker. So when people press me, it's like, "No, no please." So I excluded London. And this friend of mine eventually told me, "You're crazy, try it." So I tried and I found a job in like two weeks. Actually I found three offers.

I have to blame the boss of my company, Kate, because she definitely sold me the whole thing. However, as I used to say sometimes half joking, I'm a back-end infrastructure engineer, and basically, my job doesn't change if the company goes from satellite imagery to producing shoes. I say half joking, because obviously the requirements of this present company are different.

So we provide services to film productions. We have a web application, different types of data. Users online 24 hours a day. Previously, I ran long processing jobs and I didn't have any user online. So different environments. But I don't feel like I went and did opposite directions, so to speak. I feel like I'm a bit behind the scenes. It's interesting. I don't see film shoots and stars and directors - I see load balances in databases. But it's part of the whole thing, so it's good. When I go to the cinema, I think, "Well they did this because of me somehow."

Len: That's just fantastic. What a great story.

One of the fun things about this podcast is that we get to talk to authors living all over the world. You've been based in London for two and a half years now, and I was wondering if you would talk a little bit about the mood in the tech sector there, on the subject of Brexit. Is it something you have reason to be personally or professionally concerned about? I lived in London for about nine years and thrived there professionally in a way I never could have in Canada, and I found the multinational nature of life in the city to be exciting and inviting - which I confess influences my thoughts on the subject of Brexit.

Leonardo: Well, it's a dangerous topic. Tomorrow I have to go to the office, so I don't want to risk - I'm joking. Jokes aside, the real thing is - I believe nobody seems to know what's going to happen. Personally, I don't know - we tend to think that people run countries are - at least this is something I tend to think - that people who run countries are always in control and they clearly understand consequences and power balance and this complex stuff.

But it's not true. I mean, it's not true. There's this Spanish sociologist called Mikel Azurmendi, who recently said that, economics can always explain why things happen later, but never predict them. I think this is very true. So actually what will happen to this country after Brexit? God knows. At least He knows, but I'm not that concerned personally. Because this thing about visas is - the US is already like this, so it's not a big issue.

But I'm concerned for the country, because everything could happen. I'm not an economist. I'm not an expert. For the mood, I don't know? In London, people - the vote was mostly against it. So people are concerned. I can't really say what's the mood in the rest of the country, because I don't travel that much. It's definitely a big thing. I don't know if this is a good answer?

Len: Yeah, I think that's a very good answer. In particular I appreciate your observations about politicians and economists. I think it's - a lot of people are coming to the understanding that there are people who are presumed to be experts in areas where there might not even be the possibility of real expertise.

Leonardo: Yeah.

Len: Moving on to the subject of where there are experts, and you're one - the subject of how to write software and your book. On your LinkedIn profile, you write about how your view of software engineering is based on four pillars - reality, knowledge, team and perfection. I'm interested in all of those, but I'm particularly interested in asking you what you mean by reality. Could you talk a little bit about that?

Leonardo: Thanks for the question, it's something I really want to talk about. I believe one of the biggest risks for any business - on a smaller scale for engineers, for a developer - is that of engineering, over-engineering solutions. Like you need to send an email and you build operating systems. It sounds funny somehow, but it's one of the most common errors.

I'm very good at it. I start thinking, "What if this, what if that?" And then something that should end in two days ends three months later, maybe? It's not bad to think what if, but this might get out of control easily. And this is why in that LinkedIn profile you mentioned, I was quoting Reinhold Niebuhr, when he says, "Nothing is so incredible as an answer to an unasked question." I find this is very precious advice for my job.

Because it's what you have in front of you, reality. The facts. That client, that limitation. For example, something that you know technology cannot do. This is what guides you in achieving a better solution. Your goal - sometimes it means that you have to give up that amazing feature that you really desperately want to include. The latest, coolest JavaScript library - whatever.

But this keeps you on track. I'm not saying that someone shouldn't try to solve problems, on the contrary. It's - the problem dictates what you have to do. So this is why I say that reality is an ally. Like in a war, do you see what I mean? In life, not only in my job.

Len: Just as a brief aside, one of the reasons that it struck me so much, is that I've had some limited experience working with developers on projects myself. And one thing that struck me was, there was a certain type of person who would say - if they were given a requirement, they would say, "Well I wouldn't use that."

And it always struck me like, "Who cares? This isn't about you personally." I mean that in a kind of a harsh way. A lot of people really put themselves in front of reality, rather than behind it. You need to have a concept of something outside yourself that you're trying to think and correspond with.

It doesn't mean you have to agree, but it's just recognizing that your own thoughts are not co-extensive with reality. Your knowledge is not co-extensive with knowledge. And your preferences are not universal.

These sound like basic things to say. But a lot of people, the way they conduct themselves in their lives, don't hew to those principles. So I really appreciated that, coming across that concept in your bio there and in your explanation just now.

Leonardo: Thank you. Because what you said is really what I was trying to say, in better English.

Len: As I mentioned in the introduction to this interview, your book is called, Clean Architectures in Python: A practical approach to better software design. I wanted to ask you just a basic question. What led you to write the book?

Leonardo: As you mentioned in the introduction - I am running a blog, and writing some posts since 2013. At a certain point in 2016, I wrote this big blog post about clean architectures. Because at the time I got in touch [with these concepts] through an Italian colleague of mine. Robert Martin was saying in Ruby on Rails Conferences - he was starting to talk about this clean architecture. So I got in touch with the topic, I liked the things and I wrote a blog post. It got well received.

And so after a while I was reviewing it and I found a couple of - maybe not errors, but things that - well, this could be explained better. So I wanted to expand it. I was working on it. Unfortunately it was already very long. So I started thinking, maybe I should split into a series of smaller posts.

At the same time, I was going at some conferences - Python conferences, I was giving this introduction to TDD. It's a workshop I give sometimes - four hours doing TDD with people who don't know anything about it.

I saw that people were really interested in this approach. They were happy discovering that there's some way to write better software. But they were like asking, like, "How do I start doing the real stuff?" It's like the joke - I found online this small joke about doing tutorials. It's called, "How to do an owl," like the bird. And it's two steps. The first step is two circles, and the text says, "Draw some circles." And the second step is a beautiful hand drawn owl. And it says, "Now draw the rest of this freaking owl."

I understand why beginners feel like that. Because it's what happens to me sometimes. Say you give me - this is how you define a function in Python. Now go and write a new Facebook. There's something missing isn't there?

I'm not saying that my book explains how to write a new Facebook from a Python function at all. But I felt like I wanted to give the readers of the blog like a good introduction to a process from the ground up. Let's start with an empty page and build something.

I was trying to find the best way to do this thing when I found this post by Tracy Osborn, who is a Leanpub author. The post was about self-publishing. And I thought maybe a book is the best way. And here we are, testing this idea.

Len: It's funny, I'm going to indulge in another aside here. When you were talking about your story about the owl example, how there's a sort of gap that's often there that people who've become experts don't realize they've left in their explanation - and on the subject of film as well, it reminds me of an example I love to give of this.

Conventionally we hear the story, "Here's the biography of the famous director. He was working in a movie store, and then what do you know? Now he's directed Reservoir Dogs."

You often wonder, "But really, how did you get from A to B?" And with the story of Tarantino, he actually at one point does say exactly how he did it. He was working in a video store and he had this script. And his colleague's girlfriend worked out with Harvey Keitel's girlfriend. And so through that path, he got his script to Harvey Keitel. Who then got in touch with him and said, "Let's make this movie."

Anyway, I wanted to say I'm very sympathetic to the metaphor that you gave, and the particular problem. Because it is so common. Not just in programming, but in all areas where people are trying to explain things. There is so often this big gap, and it's always just such a revelation when someone doesn't leave that gap.

A big part of your book, you mentioned, is about TDD or test-driven development. For those listening who might not know, can you talk a little bit about what test-driven development is, and why it's important for building good software?

Leonardo: Sure. Long story short, the idea of TDD is that, before you write a single line of code to implement a feature you want, you have some process, we call it a test, that says, "Well, that feature is missing." And when you implement the feature, the same process once again, it gives you a pat on the back and says, "Well done, this feature works." So these tests and these check processes are always run against the code while you develop features.

This allows you to check that when you change the code - because eventually you are going to change the code - you are not screwing up what you did before. Like, you are removing features, introducing bugs. This happened to me a lot of times, and it still happens. Fortunately I have tests sometimes that say, "No, you are not going to do this, because this reintroduces a bug that you solved one month ago."

I believe it's a very important methodology. It can lead to better software - and also can lead to good sleep. Because when you know that the new version of the software you just deployed in production is running, is not buggy - you sleep well. It's not buggy.

Okay, so not buggy means it's not effected by bugs that you tested, okay? TDD is not a magic wand that fixes everything. It's not a fairy tale. But it's a good process to face software maintenance and development. So why not?

Len: You've written on your blog in a post on studying retro programming and the Amiga that "Learning architectures is a perfect way to become a better programmer." Just to get started on the topic, some of our listeners might not be all that familiar with the concept of architecture when it comes to computer software and hardware. I was wondering if you could talk a little bit about the concept of architecture in this context? In your book, I believe you used the example of a shop to explain the concept.

Leonardo: Good question. The purpose of engineering is solving problems, right? And it turns out that there are multiple ways to solve a problem, even in the physical world.

Let's say you need water at home. You can dig a well and go there with a bucket. It can be an aqueduct or pipes, and have it from the tap at home. These are different architectures, different solutions to the same problem, with different costs, different maintenance problems, different flexibility.

For example, the cost of an aqueduct is higher upfront. It's cheaper to dig the well, probably. But the aqueduct saves you from going out every 10 minutes. So on the long run, it's better. But maybe you don't have enough money, so you have to go with a simpler and cheaper solution - to dig a well. At which point the question is, "Okay now you go for the simpler solution, but can you easily switch to a better solution later in the future?"

Then you have the different layers of the architecture. Because when you decided to build the pipes, you have to decide the material for the pipes, the configurations of the building and so on. I don't know, because I'm not a plumber, but this is the extent of my example.

Moving to the software world, you might say, "Let's build an app to solve this problem." This is what my startup does. But then you have to decide the language. You have to decide the framework, the way you distribute it, the way you upgrade it. And so on. All these things are part of the architecture, how these components, these small parts of the business, if you will - work together. I believe this is something that extends outside the software world.

Actually, Len - you run a company, you know this better than me. It's not enough to have the product. Then you have to sell it. Then you have to get in touch with your customers, like you are doing with me now. So it's a process. And a lot of components that can be maybe - they can be perfect, but linked in their own way - and this leads to failure. Maybe it is better that they are less than perfect, but linked in a good way and you can go on. But this is the architecture idea.

Len: I think that's a good lead in to my next question, which is - when I was researching for this interview and I came across your post on the Amiga, I gather there was a specific issue with the Amiga's hardware that made it uniquely unsuited to run the game Doom.

I find that quite curious, and in so far as that's true, it sounded like a very good example. I mean, most people think of computers as they kind of ought to - as these sort of universal machines. But actually, of course, some hardware is more suited to some tasks than others. I was wondering if you could talk a little bit about that example, if you know the answer - about how integrated hardware and software can be?

Leonardo: Yes, this is a tricky question, and the answer is a bit complex. Actually, you should ask Fabien Sanglard, he just published a book on the DOOM game engine. I still have to read it, but the previous book published on Wolfenstein 3D was simply amazing. So well written. Anyway, okay, I might try to give you a quick answer. I hope Fabien will not chase me.

DOOM was a game with certain requirements of speed and graphic quality. And the guys at ID Software, I'm pretty sure they used all sorts of dirty tricks they knew, to achieve that goal. Because DOOM was an earthquake in the software world, it was amazing. And the PC was a terrible machine for games. Well, actually was a terrible machine, full stop. But architecturally speaking - so more on this later, but let's say that the way hardware worked on the PC and the way the software had to work to access the hardware, that memory - was convoluted, to say the least. It was really, really strange. I don't know why they came up with such solutions.

However, PCs had one thing in 1993 when DOOM came out, which is power. Computing power. The minimum system requirements for DOOM, if memory serves - they were like a 486 microprocessor running at full speed - so 66 megahertz and 8 megabytes of RAM. At that time, it was a lot. It worked on lessor PC's, but with lower resolution and was a bit slow.

The Amiga is a completely different machine. The bare Motorola CPU wasn't as fast as a 486 at all. The Amiga is an amazing machine, (or it was... it IS, it's immortal!). It is an amazing machine, because it has co-processors that work together with the CPU concurrently.

But you have to write the software to explore this feature. Otherwise, you just have a very slow microprocessor. Definitely slower than a 486.

So if you think about it, PCs - it went the same way with GPUs later. You might run a PC game without a GPU - so basically using the CPU for everything. I believe it would be painfully slow. Because the GPU is a co-processor doing an incredible amount of things.

So I believe ID didn't try to port DOOM for the Amiga for this reason. It would've meant rewriting the whole thing from scratch. It's interesting, however, that this architectural thing - sometimes, it's linked with the failure or success of a product. Actually, as I mentioned - the Intel 86 architecture. The way the hardware is structured and the way the software has to be written to use the hardware is terrible. But it was successful for several reasons.

It's too long a story now, but another example, instead could be a cell processor that was inside the PlayStation 3 developed by IBM with Toshiba and Sony. That was a failure. Because the cell processor was meant, in IBM's dreams, to be the new x86. The new Intel processor to replace them.

It was too different. I remember I went to a course on how to program this cell processor in 2005, I believe? It was too difficult. It was back to the assembly days, which was fine when we were programming an Amiga, a C64. But in 2005, no way.

Obviously this is one of the reasons of the failure of that thing. It's more complex than this.

But just to say that this architectural thing is important, and about what you asked - yeah, the Amiga can run DOOM. There are ports that - when the project was open sourced, people developed Amiga versions of the thing. I don't believe the porting was easy. It's not just recompiling the source code with the Amiga C compiler. and that's it. No way, because it's a completely different machine.

Len: Thank you for that great and detailed answer. It's just so interesting to hear the stories behind all this technology that we have around us, and to know its history as well.

Can you talk a little bit about what it means for architecture to be clean?

Leonardo: Yes. So clean - it means that you know exactly where a component is. Why the component is there. And the data flow in-between components is clear.

So forget for a moment software or hardware. Think about a company. You know where someone is and why they are there. So you need someone in the corridor, and you think, "Oh why that this person is doing this job?" It's not just a number. I'm not really sure what this person is doing in this company.

Picture an untidy room. You see the main things - you have clothes everywhere, open boxes. Socks on the bed lamp. And then you are like, "Where are my keys?" And you spend one hour looking for them because it's a mess. And eventually, you find them - well, hopefully.

My point is, even unclean architectures or unclean rooms work. But time is money. So in a software system, when you have to change something, it's good to quickly find what you have to change and be sure that like turning off the bed lamp doesn't set the garage on fire. You see what I mean?

It's like sometimes systems - even systems that I created, so I'm to blame - sometimes systems are so convoluted that you act on one thing, you change something on this side. And this has a method on something completely different. This is a bad sign. Because - yes, the clean architecture is the name that Robert Martin gave to a way of structuring software which existed previously. It's just a name for something that we did and we forgot, like he says. And it was clean. Smart is another name if you want.

Len: It's funny, you reminded me - when I was a young university student, I was a sort of relatively tidy guy and I had a really, really messy roommate at one point. I remember him trying to make fun of me at one point, because I kept my CDs in alphabetical order. And for my part of the fridge - the juice went there, and the bread went there. He tried to make fun of me once for being, I guess, kind of arid about things, and I said, "No, you don't understand, I'm lazy. I'm really, really lazy. And the last thing I want to do is have to hunt through a stack of CDs that are not ordered, in order to find the one I'm looking for. When if I just sort of implement some order at the beginning, I'll be able to find what I'm looking for more quickly." It's interesting, as you say - the messy room still works, but time is money.

Moving on, I was wondering if you could talk a little bit - so, you decided to write this book and then you found out about Leanpub. Why did you choose Leanpub as the platform for publishing your book and writing it?

Leonardo: Well, Tracy Osborn is the one to blame. Because I read the post and whatever. But I already knew Leanpub, because a friend, a colleague of mine and a friend of mine, showed me "Ansible for devops", by Jeff Geerling. So I already knew about this self-publishing platform. And after I read Tracy's post, I didn't know what to do, so I started Googling things like "Self-published technical book," and whatever. I knew LaTeX, I knew other things. So I was starting to find a way to do it. And Google showed me Leanpub is one of the first results if you look for self-publishing.

So I read a bit about the Markua processor, and at that point I knew instantly that I found what I was looking for. Because I write the blog and the book. I wrote the book in my spare time. So half of the book was written on the bus in the morning - half an hour at a time. So if 60% of the time is spent formatting a title or the footnotes, publishing becomes a nightmare, I'm not interested in that sort of thing. It's already too much for me to think about the content. Then it was in English, I had to proofread it and whatever.

So for me, the real plus of Leanpub is the platform, definitely. The idea of the magical typewriter, as is discussed in the documentation. Then obviously, the fee and the high royalties are good points, but minor ones, as far as I'm concerned.

Len: I can see from the changelog in your book that people have been giving you some feedback, and you've been incorporating their feedback into the book. This is a really interesting thing that quite a few Leanpub authors do, and they often have their own process. I was wondering if you could talk a little bit about how you manage getting feedback about things like typos from people, and then incorporating that feedback into your book?

Leonardo: It's a technical book, so I expected readers to be familiar with Git. I'm hosting the source code of the book on GitHub. So I just invited people to submit issues or pull requests there. Users kindly submitted fixes for typos, bad grammar. I just merged the pull requests or fixed the typos, and that's it.

Actually last week - something different happened, because a reader found an issue with the code. The code is not wrong, but they basically showed me my code base in a specific case that I did not test. And I was so happy, because this is TDD in practice. I mean, TDD does not mean perfect software, but it means that it was extremely simple for that reader to write a test and fix the problem. And now I want to incorporate this thing in the book. So I really want to say, "This was the code previously, but then a reader jumped in and said, 'No, you have to add these things.'"

So this will be a section of the whole thing - it's like meta-publishing. The only thing at this point, is that I have to change the book, and I have to change the code repository which is linked. And the repository is tagged to provide references in the book. So this whole task is a bit tedious.

I had this problem previously in some blog posts, to keep in sync the article or the post and the repository. I believe I'm going to end up sooner or later to write some tool to deal with this thing, because I'm really sick of doing it manually. But at this point of the whole story, it's a completely manual process.

Len: One thing I found quite striking about your book is the cover. It's a very important thing for people who are publishing books, whether they're a publishing company or a self-published author, to choose an interesting cover. And yours reminds me a little bit of the style of Guillermo del Toro. I believe you found it on the website I was wondering if you could talk a little bit about that image?

Leonardo: Definitely. It's interesting, I never connected it with del Toro, but now that you mention it, it's like, "Yeah, you're right."

The picture is part of the ceiling of the Sagrada Família, a church in Barcelona which is the masterpiece of Antoni Gaudí, who was one of the most important architects in the world.

That church is one of the most beautiful things I've seen in my life. Full stop. So I chose it on purpose. Not only because it's beautiful, but because the Sagrada Família is a building where everything has a purpose. There is no single part of that church that is there just because it's beautiful or for no reason, just like that. Because Gaudi had something in mind. And obviously being a church, the reasons behind things are connected with faith. So I personally appreciate them twice, because I'm believer.

But that's besides the connection with the clean architecture. I believe it's very clear. Because in a clean architecture, not a single part is random. And looking at the Sagrada Família, I think the result of this thing - this way of structuring things, is not only functional. It's also incredibly beautiful. So I don't know, may our software be the same, functional and beautiful. That's why I chose that picture.

Len: Thank you for that wonderful explanation. I'll make sure to have links in the transcription of this interview, so that people can find their way to images of this beautiful building.

Leonardo: Thank you.

Len: Going from the sublime to the gritty, I suppose - pricing is one of the biggest decisions you make when you self-publish a book, or when you publish a book traditionally - as I've said before about covers. Your book has both a free minimum and a free suggested price. I was wondering if you could talk a little bit about why you decided to make your book free like that?

Leonardo: Sure. The first thing I want to say is that writing is not my job. I already have a job, I get a salary and that's enough to live. So what I'm going to say obviously is valid for people that are not professional authors, like me.

That said, so there is a way of publishing for free - as you mention it in the introduction, it's the same reason behind the blog or why I release open source software, I go to conferences to give workshops.

I strongly believe in sharing knowledge. It comes to me now that I'm here, in this very moment, telling you this on the other side of the world, basically because some people shared their code in the 80s. Because some people find the time to write Stack Overflow answers. Because someone wrote - I don't know? Bash, the Linux kernel and so on. There's too many things to mention.

I feel like I'm returning the favor somehow. And probably not to the same people, because they are much more advanced than me. But I keep the fire burning, so to speak. It's like, how does it go? Like standing on the shoulders of giants. It's like I am a dwarf and I stand on the shoulders of giants, and then give my contribution, and the giant becomes taller. And then someone comes.

So that's why. As I said - it's not my profession, so I can afford it. My plan was hopefully to get enough money to pay for the Leanpub fee, so that I get even. I did it, so thanks to anyone who gave me some money. As for the rest, as I say in the book - download the book and spread the knowledge, which is the best thing you can do to return the favor.

Len: Thanks for that also beautiful explanation and for your generosity.

Just to explain a detail there that might be confusing to some people listening - you can actually have a free minimum price and a free suggested price for a Leanpub book, and people can still pay, because we've got these pricing sliders that show you how much you pay, and how much the author earns. And actually quite a few people - even though Leonardo's book is free, quite a few people have chosen to pay him in return for his generosity.

Leonardo: What impressed me a lot is that clearly some people want to give me a certain amount of money. So they paid a strange amount of money like $10.15, just to give me a certain amount of money. It was like, every time I received an email that says, "Someone purchased the book and they paid something like five pounds or whatever," I think, "Well thank you. Thank you, really."

Len: It's interesting you bring that up. That's sort of deep Leanpub. We had that experience ourselves years ago when we introduced the pricing slider that shows how much the author earns. And yeah, we would notice people would be paying these sort of odd prices. And what was happening was - they were looking at how much the author was going to getm, and that's what they were interested in.

It was kind of a confirmation of a theory. It was a very important thing for us to confirm that, when royalty rates are high enough, people are more concerned about how much they're giving the author. And when a book is self-published, people are even more concerned with how much they're giving the author, than they are with the overall price that they're paying.

Leonardo: Definitely.

Len: There's this connection that's established between the reader and the author that you can't really establish in a normal commercial exchange.

My last question about your book is that - I noticed there's a Russian translation of it in the works by Alexey Pyltsyn. How did that come about? I'm curious. A lot of authors, when they finish their book, they do think about getting translations. Did you approach Alexey, or did he approach you?

Leonardo: No, he came out of the blue. Alexey sent me a message saying that he liked the book and was interested in translating it. I was already amazed enough by the amount of downloads the book had. So this was like the icing on the cake. I saw he's pretty active in this field, because he already translated other books. So I quickly agreed, because I'm so happy about it. I was thinking, "Should I translate it in Italian?" Because I might do it. Actually, a friend of mine told me, "You might do a favor to Italian developers and leave it in English so they learn something." I don't know if the English in my book is good enough? Maybe it's true, so I'm going to leave it like it is for the moment.

Len: Well I can say - having read much of the book myself, the English is definitely good enough, and the thousands of readers I think are proof as well.

My last question for you is the question I always like to ask last in these interviews. If you could ask us to build one thing or fix one thing on Leanpub, what would you ask us to do?

Leonardo: Well I have to say that - I don't know, so far I didn't feel like I was missing some important feature, so well done.

One thing that might be useful is an offline Markua processor, but this is definitely not part of the Leanpub platform. In the platform, it's not easy to see what happens when you change the themes parameters. But I'm pretty sure I'm nitpicking. Because as far as I'm concerned, I really found the whole experience so good. I wouldn't say anything negative. Don't change it.

Len: Thank you very much for that. We can't take all the credit, of course - Leanpub has been developed alongside the experience of authors like yourself over the course of years. And it's by talking to people and listening that we help make it better for authors.

Specifically on the subject that you just brought up, we actually did have someone ask us about that earlier this week. They were specifically talking about fonts. You can choose fonts from a dropdown, but what are those fonts going to look like? And you're asking from a bigger perspective - if I change my book's theme from one set of formatting parameters to another, how do I know what it's going to look like afterwards? Actually it wouldn't be all that difficult for us to make some Lorem Ipsum books and get some screenshots and have an article in our Help Center. So I'll add that to my task for things for us to do.

Leonardo: Amazing, thank you.

Len: Because it's a very reasonable and totally, totally understandable thing.

Well, thank you very much Leonardo for this great interview. I really enjoyed it. And thank you for taking the time to be on the podcast, and to be a Leanpub author.

Leonardo: Thank you very much.

Len: Thanks.

And thanks as always to all of you for listening to this episode of the Frontmatter Podcast. If you liked what you heard, please subscribe in iTunes and rate and review the podcast. It really does help, as everyone who hosts a podcast says. And if you'd like to be a Leanpub author - either of a book or a course, please head on over to and click on "Why Leanpub" at the top. Thanks.

Podcast info & credits
  • Published on February 8th, 2019
  • Interview by Len Epp on January 29th, 2019
  • Transcribed by Alys McDonough