“I had to fix the knowledge gap. It was not a technology problem. It’s a knowledge gap. People need to understand object-oriented programming, dependency injection, and all that, so that eventually the act of mocking the Salesforce database or mocking the dependencies becomes a lot more mainstream where most teams can achieve some level of very fast test execution. That’s why I kind of took on the mission to bring the knowledge that exists outside the Salesforce ecosystem and bring it to the masses.” – Pablo Gonzalez, Director of Product Management and Research, AutoRABIT
Salesforce developers operate in a unique environment—where clicks and code collide, and agility meets constraint. But how do they align with the rigor and rhythm of traditional software engineering?
In this episode, Andrew Davis, Founder of the Institute for Transformational Leadership and author of Flow Engineering, joins Pablo Gonzalez, AutoRABIT’s Director of Product Management and Research, to explore how teams can close the gap between two distinct development worlds. Expect sharp insights, real-world patterns, and a clear path toward more cohesive, high-performing product teams.
Transcript
Andrew Davis
From Code to the Cloud cuts through the noise to get to what really matters. The insights and tactics that help you maintain a consistently secure and productive DevOps strategy.
Hello and welcome to From Code to The Cloud, a DevSecOps podcast focused on the Salesforce ecosystem. I’m Andrew Davis, founder of the Institute for Transformational Leadership and author of Flow Engineering and mastering Salesforce DevOps.
My guest today is Pablo Gonzalez, director of Product Management and Research at Auto Rabbit and author of the book Clean Apex Code Software Design for Salesforce Developers. Welcome, Pablo.
Pablo Gonzalez
Hey, Andrew. Thank you so much for having me. Just as you were announcing yourself, I.
I’ve heard you introduce yourself many times as the author of the DevOps book. And now that you introduced me as the author of the Clean Apex code book, it felt kind of weird that I. I never thought I would be on. On.
On, you know, being introduced at like that. So thanks for that. I’m doing great.
Andrew Davis
Welcome to the Authors Club, Pablo.
Pablo Gonzalez
Yeah.
Andrew Davis
You are an official member now and you got the book now in your hand. This is something that you’ve been looking forward to for at least a year, having the book in your hands. And you’ve been working on it for how long?
Two and a half years or.
Pablo Gonzalez
No, no, no, it’s been a year and a half. Like the whole process, if I count from the moment the publisher contacted me to.
To the moment I touch the book, it’s a year and a half, which is long enough anyway. It’s very long now.
Andrew Davis
Why Apex and Clean Apex? Good. You became famous as the Salesforce DevOps guy on LinkedIn.
Just such a incredible set of contributions to answering questions, connecting with people, sharing ideas on how to approach Salesforce DevOps. Why did clean Apex end up being the topic for your book?
Pablo Gonzalez
Yeah, it’s.
I’ve been asked the same question before, and I think it’s a kind of misconception that Apex development or software development in general and DevOps are different things. And so this idea that you can practice DevOps and still have horrible dirty code and it. It doesn’t work like that.
So many of the practices of DevOps do influence how you write code, and some of the practices of DevOps are only possible with clean code. So the best example is, and really what made me write the book is continuous integration.
So if you think of the concept of continuous integration, right, that you somehow push your changes to a shared sandbox, you. You run your test and you check, okay? Everything is working. I’m going to go back and keep working on it and Everyone is doing the same.
That’s a theory, right? Everyone has to be doing the same. It’s not like only one developer is merging their changes. And so for that to work, the tests have to run very fast.
Like at least, you know, minimum, or I would say maximum five minutes.
Andrew Davis
Right.
Pablo Gonzalez
If the tests take 45 minutes to run, there’s no way I’m going to be committing changes every, you know, like I would only be able to commit like 5 changes per day and then the rest of the team would be stuck. And so practicing continuous integration when tests take 40 plus minutes to run is just simply impossible. And that’s it. There’s no way around it.
And so I kind of became frustrated because as I was sharing knowledge on DevOps and reading about it, and we see all these people talk about continuous integration and somehow everyone just ignores this huge problem that if the test run slow, there is no way to practice continuous integration, period. And I saw a presentation from.
Andrew Davis
And would you say if nobody can practice continuous integration, you certainly can’t practice continuous delivery either. And so all of your talk about CICD is nonsense.
Pablo Gonzalez
Yeah. Becomes irrelevant. Yeah, it’s all.
Andrew Davis
And so all of your claims to be doing DevOps are complete nonsense if you’re not having fast automated tests. Is that reasonable?
Pablo Gonzalez
Well, I would say not really, but then people are only getting half the benefit of DevOps or sometimes even less than half.
And so I saw a talk from a Salesforce team that managed to reduce text execution test execution to like less than five minutes for like hundreds of tests.
And so they were able to do this thing where I described where people deploy changes or do a validation deployment, run all tests, five minutes, and then everyone else is doing it and they’re practicing true continuous integration. And how they were able to do that is because they are mocking the Salesforce database.
So they’re not really calling the database, they’re just using wrappers that, you know, kind of pretend to be doing DML operations and that significantly cuts down the execution time. And the thing is, when you start looking at how to do that, it’s actually very complicated. It’s not that simple.
And to be able to be able to even understand how a mechanism like that works, you need to understand dependency injection and you need to understand interfaces.
And if you don’t understand, if you’ve never heard of object oriented programming or you just did like a trailhead module, your knowledge of interfaces is probably very immature. And how do you know when dependency injection is the right solution?
You know, how do you know when your system really has boundaries that require for them to be injected versus simple modules that are okay to be hard coded.
And so I realized that the more you start thinking about this, the more I realized like, well, only like 5% of the ecosystem can practice this because the majority of Salesforce developers, including myself years ago, don’t have all this knowledge of advanced design patterns and object oriented programming skills and all that.
And so if the real way to be able to practice, or if the only way to practice real continuous integration is to have fastest, and the only way to have fastest is to mock the database, and if to mock the database you have to know object oriented programming and boundaries and dependency injection and all that, then if I want people to adopt DevOps, then I had to fix that problem. I had to fix the knowledge gap. There’s not a technology problem, it’s a knowledge gap. People need to understand how to do those things.
They need to be able to understand object oriented programming, dependency injection and all that, so that eventually the act of mocking the Salesforce database or mocking dependencies becomes a lot more mainstream where most teams can achieve some level of very fast test execution. And so that’s why I kind of took on the mission to bring this knowledge that exists outside the Salesforce ecosystem and bring it to the masses.
Andrew Davis
Would it be, would it be fair to say, or let me, let me put forth an assertion and you can agree or disagree on this, but baked into the very fabric of Salesforce and Salesforce coding is object oriented development, that the, the database tables are called objects and they exist natively in Apex, as you know, objects in an object oriented sense.
Everything that you build are classes that are Apex classes with methods in there and, and that you’ve got this minimum 75% test code coverage to go to production.
So it, it feels to me like the original authors of Apex intended for people to use proper object oriented software development in their approach and things like continuous delivery. But we’ve simply not ever reached that bar on mass as an ecosystem. We’ve had this pretty sort of least common denominator kind of programming.
What do you think? And that you’re trying to really lift the bar to where it was supposed to be all along. Is that a fair assertion?
Pablo Gonzalez
Yeah, but the thing is, just because the language supports it doesn’t mean that the people using the language will naturally have those skills.
So like, if you think, think of something like Java or Python or any other mainstream programming language, they all support all this stuff, they’re all object oriented programming and they support a bunch of advanced things. But the difference is that developers of that language have almost infinite resources to learn those things.
It’s not like the language makes it easier to use those features. It is as complicated as it is in Apex.
But there are hundreds of, you know, Java tutorials for object oriented programming or how to do X or Y Z on Python. And so the knowledge kind of exists out there.
And if you think of some of the common books in software design, such as, you know, Clean Code from Robert C.
Martin and Refactoring from, from Martin Fowler and all these type of books they’re written in for like Java or C, so those developers have had those books to learn proper software design and that’s it.
Andrew Davis
So it’s not courses in university as well like most of these people did, you know, some formal object oriented classes, whereas a lot of Salesforce folks, they’re just sort of, you know, learn from trailhead and didn’t, weren’t forced to go through learning interfaces.
Pablo Gonzalez
Well, like I, I did not study computer science at all. I studied criminology. So when I became a developer I, I had to read Java books.
Well because I wanted, because I, I kind of, I understood the knowledge I had was very limited. And so I had to read, you know, these books that I mentioned which are written for Java and C.
And the mental gymnastics to translate that into Apex is, is very hard and it’s not, is not easy and it’s a little boring and just not engaging to be reading some Java book and trying to translate all that to Apex. And so it’s not the language, it’s.
The ecosystem hasn’t had the resources in terms of knowledge courses, books that other languages have that allows people to learn these things. And so my goal was to.
Andrew Davis
Basically.
Pablo Gonzalez
Create that missing link, you know, that, that missing artifact that exists in other languages but for Apex.
Andrew Davis
Nice. I’m reminded with your criminology background of. It’s Adam Thornhill who created Code Scene.
He has a famous YouTube talk about your code as a crime scene and the power of using forensics to sort of understand what’s really going on inside a, inside a code base. Do you feel like your criminology background played into your skills as a software developer at all?
Pablo Gonzalez
Only that I’m maybe good at research or understanding that there’s a lot of different variables that influence anything and that things are never binary. So I maybe trust on that that I can investigate and research things pretty well.
Other than that I have not found my skills in, you know, taking fingerprints useful at All.
Andrew Davis
Okay, fair enough. I really appreciate you mentioning just that. The Salesforce coding or the Apex ecosystem.
I mean I would, I would reflect your comments back to say that the Apex coding ecosystem is just underdeveloped compared to the Java ecosystem or Python ecosystem. Fewer, you know, tutorials, resources, you know, not as many people going through formal training programs.
One of the, one of the reflections of that is in Java and a lot of these other languages there’s a lot of frameworks, a lot of open source frameworks that have come out to help to scaffold large code bases.
And one of the, one of the books that made the biggest impact on me early in my learning was Andrew Fawcett’s originally, I think it’s force.com enterprise architecture, what’s it called these days? Lightning Platform Enterprise, something like that.
And he’s got three or four editions with three or four different titles but Apex Enterprise Patterns.
And he sort of put forth a framework within Apex of Building for enterprise scale and you know, includes things like dependency injection and the, the, I think it’s called the Fluent syntax.
And you’re, you’ve put forth the AWAF Apex well architected framework and it’s kind of making some waves, making some ripples as the first big credible new framework since Andrew Fawcett put, put out his book. It must have been almost, must have been over 10 years ago when he put that out.
Pablo Gonzalez
Yeah.
Andrew Davis
So how would you compare and contrast these two? Why do you think it’s such a big deal that AWF is coming out now?
Pablo Gonzalez
Yeah, well, the first thing is that it’s a framework, but it’s a very different framework from fflib or Apex Enterprise Patterns because the Enterprise patterns is a framework kind of like the Java frameworks where it’s just don’t think and put things here and it’ll all work. Just put the stuff on the service class because it’s all organized to look at that and, and that’s it. Don’t think and it works.
I was recently at London Scalding and I saw a presentation about Apex Enterprise patterns. I attended the session purposely just to see, you know, did I miss anything.
And the one thing that I, I realized actually super useful from fflib is the guy who was presenting had this use case where they have a huge org and they have, they’re kind of trying to split the entire org into unlock or like yeah, unlock packages and, and all that stuff. And there are different teams and so every package has the same structure where every single object has a service class domain Class elector.
So everything is the same. So you can go from one team to another and always go to the domain class, always go to the service class. There’s no, no thinking required.
And I, I can, I, I can agree how that is actually very useful. I, I have no argument against it.
It’s just, I thought about it, I’m like, yep, that is a very useful thing to do if you have a large org, different teams, different packages. It’s a very nice thing that they’re all, they all look the same and they all feel the same. So I get that.
However, so to answer the question, I need to explain why I even came up with this. And so I never liked the Apex enterprise patterns when I started to read up on them on LinkedIn. Sorry, on Trailhead.
I understood the unit of work very well and I like the concept more than the implementation. The concept of putting together different operations and making sure that they are atomic or roll them back entirely.
That concept is solid, it’s great.
But then as I started reading the stuff with the service class and the domain class and selectors, a lot of stuff just kind of felt artificial to me or like just unnecessary complexity that I just couldn’t understand why there’s no, there’s. I couldn’t find a proper guideline that made me satisfied on why something should be on the domain and not the service.
It feels like it’s just like a, again, a set of rules. Don’t think, just, just put it here, because that’s how the framework works. So I was never satisfied with it and so I never adopted it properly.
And so when I was writing the book, I really wanted to provide an alternative, but I knew if I give another framework that is the same meaning, here’s how the framework works. Just don’t think, just put things here. It’s going to have the exact same weaknesses as fflib. It’s just going to be another flavor of the same thing.
And you know, as a developer writing a book, of course I would have loved for, you know, for people to use my library.
You know, that that’s a nice kind of ego boost, that’s a nice kind of dent that you do in the ecosystem that X number of companies are using my library to scale Apex. That would have felt nice. But I realized it’s just never going to work because then it’s just going to be the same.
You know, it’s going to be hard to maintain, it’s going to be hard for people to agree. There’s going to be a lot of Issues and, and what’s the point? And I thought, well, the real point is to close the knowledge gap.
So I wanted to instead come up with a framework that is about how you think about the same issues that fflib addresses, but not necessarily here’s an implementation and just shut up. So the framework talks about the difference between service and domain classes and what I consider to be an artificial separation between them.
And I propose an alternative way of deciding when things should be together or when should they be separate.
I also propose alternative to selectors, and I talk about the challenges of using selectors at scale and what the real value of a selector is, which is mocking the database. And I propose alternatives to mock the database that don’t require a centralized selector.
So basically the framework is kind of acknowledging that fflib got these concepts right, that we need separation of concerns, we need database interactions, we need to put things together or separate. But it didn’t teach people how to think, it just taught people where to put the code.
And so I thought, okay, well my framework is going to be different because I’m going to teach people how to think about these things so that they can make their own choices. And if their choice is to use fflive, then great, maybe there are choices to use a watered down version of FFPlake.
But what’s more important to me is that the framework is timeless and that it cannot be disrupted by some other library claiming to be better, because you cannot be better than proven principles of software design. Sorry for the long answer, but that’s the answer.
Andrew Davis
Good answer. That in my mind kind of takes us back to the. The actual principles of DevOps are relatively timeless, right?
Like fast feedback for developers, you know, embedding through, through embedding tests. And one of the other principles that I know is probably is close to your in my heart is modularization and modularity within the code base.
Is that a significant topic that you cover in the book as well?
Pablo Gonzalez
Yeah, there’s a whole chapter on modularity, coupling and cohesion and that was my favorite chapter to write. It’s funny because that was a chapter that I was kind of fantasizing to write the whole time.
So even, even when I was in chapter two, I was like, can’t wait to get to that chapter because I, I would love to write about it, but it’s chapter 10 because there are so many things that you need to cover before you can properly talk about those things. What I enjoyed the most was my discussions on coupling and cohesion, which I have found to be very lacking in the ecosystem.
And most of the times when people talk about coupling, they just talk about dependency injection. And people love talking about their dependency injection framework and how it helps them decouple things.
But what nobody talks about is that there are multiple levels or types of coupling.
And so the coupling that you can remove with dependency injection is build time coupling or metadata based coupling, where, okay, this class doesn’t know about the other one, so they can be built or deployed independently. However, the two classes still need to work together.
If one class implements a completely random implementation of an interface, the class that is using that interface is not going to behave correctly. And so they’re bound by the business process that they both support.
Also imagine this scenario, which I’m sure happened to you, Andrew, and everyone who’s listening, where how many times has the business asked you to change one thing? And you have to change multiple independent classes to support that change.
And those classes are, they could be independent, they could even be totally different things. You have to change a lightning work component and a class and maybe a field. And it means those three things are coupled.
Maybe not to each other, but they’re coupled to that central idea that they are supporting. And sometimes that coupling is even more dangerous than the build time or metadata based coupling because it’s invisible, you can’t see it.
And so how you fight that is with cohesion. So cohesion is really a technique to bring things closer together if they are related.
And so what I propose in the book is that you use SFDX folders to bring things that are related closely together. Right?
So if there’s an Apex class, lightning web component and field that always change together, then bring them into the same folder in your SFDX project so that the coupling between them now becomes obvious. They’re still decoupled from the metadata level, you can’t see any relationship, but now they’re in the same folder.
So you know, okay, these three things work together. And really that’s what cohesion is, right? If things are related, bring them as close together as possible.
And so that was my favorite part to kind of write about because I find it pretty novel.
Not outside of Salesforce, but in Salesforce nobody talks about the nuances of coupling and cohesion, and most conversations are limited to dependency injection without realizing that it only solves for one type of coupling.
Andrew Davis
As you were talking, I was struggling to recall a clear distinction, distinction between coupling and cohesion. But I think I picked it up in your talk. Let me see if I got this right.
So would you say that coupling is where, you know, a couple of components within the code base are actually dependent on each other. And to, you know, one will have an impact on the other, you might need to change both together.
And cohesion would include sort of a broader set of relationship where two things might. Might deserve some cohesion even if they’re not directly coupled, but they have some similarity. Is that fair or so?
Pablo Gonzalez
It’s funny because they’re actually three.
They’re like, if you search for the word cohesion, they’re like many different definitions and different software authors have given different definitions. They often even change their mind and then they give conflicting opinions or definitions about the concept.
I studied that topic deeply as I was writing that chapter. And so let me try to put it this way. So coupling just means that two things, I wouldn’t say they are dependent.
They’re not necessarily dependent, but there’s a relationship between them. And that coupling can be good sometimes, sometimes it can be bad.
If two things are coupled so much, the fact that they can never change without the other, or that one always breaks the other. In some scenarios, that coupling is bad because it means you cannot do localized changes without breaking everything else.
It doesn’t mean that they depend necessarily, as I said, two independent components can be coupled to the same idea. And so that’s another type of coupling. Right? They’re separate.
They could be separate metadata types, no metadata relationship between them, but the business requirement changes and they both have to change. So they’re coupled, just not to each other. They’re coupled in respect to a change. And so that’s coupling. Right.
And the other thing about coupling is that again, people love to say that coupling is bad and tightly coupled code is bad, and you want a loosely coupled architecture. But coupling is a degree. It’s not there or not there. It’s high or it’s low. And sometimes it’s impactful, sometimes it’s not too impactful.
If two apex classes are calling each other and they are completely coupled and that never causes an issue, then that’s not bad coupling. It’s just coupling. And the thing that people don’t realize is that modularity creates coupling.
If you split things apart, eventually they have to work together. You cannot have a system that is composed of a bunch of smaller parts if they don’t work together.
So they have to eventually be coupled in some way, otherwise the system will not exist. Otherwise the system will have to be a monolith where it’s just one piece. And so coupling is simply a kind of A side effect of modularity.
It’s a necessary aspect. I was about to say evil, but it’s not an evil. It’s a necessary aspect of modularity. And the key is to control the negative impacts of coupling.
And so cohesion, as I define in the book, is kind of the counterpart, kind of the, you know, that. I forgot the name, that Chinese symbol of the Yin Yang. Yeah. So it’s kind of the counterpart. And again, there are different definitions of cohesion.
But the idea is that a module is cohesive if the things inside that module work closely together to achieve a common goal. So if you look at, for example, the string class in Apex, what are the methods you have to uppercase to lowercase left, right, whatever.
They’re totally separate. Sometimes they’re not related at all, but they’re all coupled to this idea of string manipulation. So it makes sense to have them there.
It makes sense that they’re all inside the string class. Let me give you this example. Can you think of a minimal way, Andrew, to split the string class into four parts? In a way, yeah.
Could you take the string class in Apex and say, well, let’s break it down to four parts? That’s gonna make. That’s gonna reduce complexity for developers. I can’t think of any way. Most like, because it’s just easier.
All the stuff related to string manipulation is in the same place. That means that the string class is cohesive because all the things that have to do with that concept are in the same place.
And so the opposite of cohesion is where things that are related are far apart. Right.
So if you were to split the string class into four modules, you would have four modules that all of them do more or less the same or they affect the same area, which is string manipulation, but they all fall apart. One is in this class, one is in the third class, another one is on the fourth class. And some of them may even be related internally.
They may even use the same algorithms. And so the idea is that if these four things are more or less related, why should they be so separate?
Let’s bring them together into the same place to increase the cohesion of all of them. And so you can do the same with Salesforce DX folders.
If, again, if an Apex class, a custom field, and a Lightning Web component are coupled to a central idea, if you bring them together into the same SFDX folder, you increase cohesion for that module and you make that coupling obvious. So coupling that was invisible can be made visible through cohesion. It’s A very, I understand, maybe a bit of a philosophical explanation, but that’s how I understand cohesion.
Andrew Davis
It’s fantastic. And this is, it’s very personally meaningful to hear about your taking this up because it’s been like.
It literally has caused me pain over the years that, that the Salesforce world struggled to do proper DevOps.
And I mean like the, I covered a bunch of these things like modularization and testing and so forth in, in the book on Salesforce DevOps that I wrote. Now it’s been seven years or whatever. Six, seven years. But then there’s just all of this noise about Salesforce DevOps over the last number of years.
You know, blah, blah, blah, blah, blah, blah, blah. But without necessarily addressing these underlying questions, especially about modularization. Right.
And the, the importance of putting related things together, you know, so you can see the hidden architecture.
Otherwise, if you don’t, if, you know, you have some comment in your book about, you know, why the heck would anybody be using the metadata API format at this point? You know, eight years past Salesforce dx. Right.
Because otherwise what’s happening is the actual architecture and the relations chips and the code base is hidden. You don’t have any way that it’s made visible, not even, you know, through, through folder structure, which is just insane.
And anyway, I just feel like this is a massive. Yeah, anyway, you should have written the book seven years ago.
I don’t know what it took you so long to get around to writing it, but finally, finally the world has a book on high quality thinking in Salesforce. Apex develop.
Pablo Gonzalez
Yeah, yeah, well, seven years ago I, I didn’t know what I was talking.
Andrew Davis
About, so it’s a reasonable excuse. All right, I’ll let you.
Pablo Gonzalez
Now I do.
But see, the, the, the one thing I want to kind of finish with is that even like you could say, okay, now with SFDX folders, like you said, now, now you can put stuff into folders and all that, but there isn’t like, I think it’s very easy for people to say, okay, now, now we can create packages and we could put things into fold, but without the proper discussion on modularity, which creates coupling, which can be balanced with cohesion, then you don’t have good guidelines for where to put things.
Then it’s just, then it becomes just like Apex, which allowed for object oriented programming, but people didn’t use it because it didn’t have the knowledge. Sfdx folders becomes just a thing. That could be amazing.
But people don’t know how to use it because they don’t have these principles of modularity, coupling and cohesion. And so my goal, I was thinking about this, like, what was my real goal in writing this book?
Or somebody asked me at London’s calling and I thought about it. Deep. Then I thought, I would really like for this to be kind of like your. I’m sure your. Your book was a before and after.
For many people it was for me. I never understood DevOps until I read your book.
It finally clicked after I read some specific chapters about the branching strategy and git and, And I wish the book was this. My book is the same for other people that it’s. And, and largely for the ecosystem as well. Like, that would be my goal for.
And not for any kind of ego or praise, but to really make a difference in the ecosystem that we can say, you know, after these two books, yours and mine were launched seven years apart, the ecosystem totally changed. Now people are practicing real DevOps.
And let me give you one tiny example that really, really made me happy when I was writing this, one of the chapters of the book, I had, throughout the book I had contributors, I had people that were reading the chapters with me and they were helping me through our notion project to give me feedback and stuff like that. And there’s a.
There’s a chapter where I introduce the concept of deep and shallow modules, which comes from the book Philosophy of Software Design by an author named John Something. I cannot pronounce his last name, but it’s a topic that I really, really like, this difference between a deep and a shallow module.
And as we were reviewing the chapter, we had a very long discussion about that. Like, a lot of different people had different arguments about that, and that made me so happy. Like, isn’t this amazing?
A team of Salesforce developers discussing the merits of, you know, the deep versus shallow modules. How amazing is that? Right?
And before it’ll all be about Apex triggers, validation rules and all that stuff that has been discussed for years now, for probably more, you know, decade and a half. Yeah.
And so it would make me incredibly happy for a team of Salesforce developers to write, to read the book, and for them to have ongoing discussions about cohesion, modularity, deep modules. That to me, if, if I could see a team having those discussions in their weekly standup, that would make me very happy.
Andrew Davis
Yeah, absolutely fantastic. You have been so generous over the years on LinkedIn especially, I think just sharing your insights and ideas.
And this book, I don’t know, feels like certainly one of your biggest, maybe the biggest single act of generosity that you’ve made to the ecosystem to just take the time to educate people, to. To help people to think. And, you know, it was.
I feel like it was, you know, I wish I had done more of that to help people to think, you know, just to fill the gap in those seven years before you, you know? You know, but it’s, you know, you’ve done the job now. I’m so excited to read the book myself thoroughly, and then to.
For everybody in the ecosystem to read the book and to begin to have those conversations about coupling and cohesion and deep classes, deep modules, shallow modules and so forth. Pablo, thank you so much. I’m super excited. I think we’re at time now, but I.
Yeah, just really delighted that the ecosystem has access to the book now. And any final bits of advice for everybody?
Pablo Gonzalez
Just close the browser and go read the book. That’s it. Go by it and read it. You know, when I launched awav, two people accused me of being a. Of it being just a marketing website for my book.
They were saying, oh, it looks like you’re just promoting your book. And I’m like, well, yeah, of course I want to promote my book. Like, can you imagine writing a book? And I wanted to promote it in some way, of course.
And of course I want people to buy, like, you know, you wrote a book, you wrote two books. I’m not getting rich because of this. Like, I’m not getting. The royalties that I get from the publisher are peanuts.
So I get nothing, you know, from people buying the book. And so some people may be surprised that I actually want to market it and publish it and get people to buy it and read it.
So, yes, of course I would encourage everyone to buy the book, read it, share it with colleagues, and really become a better software developer. That’s it. Love it.
Andrew Davis
Well, thank you for joining us for another episode of From Code to the Cloud. We’ll be releasing informative conversations with industry leaders every month, so be sure to subscribe to the show wherever you stream podcast.
You can also Visit us at autorabit for show notes, helpful links, and access to every episode as they’re released. Stay safe out there. We’ll see you next time.
