Matt Vaughn, Author of Angular Architecture Patterns

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Matt Vaughn.

Based near Denver, Matt is a full-stack software architect and developer, and popular speaker, who builds enterprise applications and focuses in particular on the Angular web application framework.

You can follow him on Twitter @angularlicious and check out his websites at angularlicio.us and angulararchitecture.com. You can also check out his Angular Architecture podcast at angulararchitecture.com/podcast, and read the blog at angulararchitecture.com/blog..

Matt is the author of the Leanpub books Angular Architecture Patterns: Apply Enterprise Principles and Patterns to Build Amazing Applications and Effective Angular Code Reuse Strategies and Techniques.

In this interview, we’re going to talk about Matt's background and career, professional interests, his books, and at the end we'll talk about his experience using Leanpub to self-publish his book.

So, thank you Matt for being on the Leanpub Frontmatter Podcast.

Matt: Certainly, my pleasure. Glad to be here.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you found your way to a career in tech?

Matt: Good question. I live near Denver, Colorado. I was born and raised here in Colorado, lived here all my life. A brief stint - I did attend the University of Miami and studied jazz performance, and also studied jazz performance at the University of Denver here, locally. So music really was my first love, I think, for just things in general. As well as sports, I'm a big sports fan. I see you're probably a hockey fan too.

Len: Oh yeah.

Matt: So growing up in Denver, the Denver Broncos, were my favorite team. I play saxophone and have played all throughout school and into college. And even did a little bit of gigging after school, and I played in several bands in clubs for a bit. I got married, started having a family, and started thinking about, "What do I need to do to make things work?"

Technology just kind of fell into its place, and I started developing web applications back in 1998. So it's been a long time, and the technology has changed a lot over the years - but that's kind of how I fell into it, just out of need. It was first a hobby, and became something that I thought I was good at. I took a dive, and decided to do it full time.

Len: You write in your author bio about being self-taught.

Matt: Yeah.

Len: How did you go about teaching yourself? It's really interesting - there's sort of like the time capsules in this interview of like the period of history when someone started learning stuff.

Matt: Well back then, there was no Stack Overflow. There was no YouTube. If you really wanted to learn technology, you would have to buy books and read them. And I didn't know, even know at the time, that there were actually books on tech and how to build web apps and things like that.

I was out with my wife one afternoon and running some errands. She ran into a different store, I ran into the book store - and I saw on the shelf, this used book on ASP - Active Server Pages, it's a Microsoft technology with VBScript. So that kind of dates me, pretty old technology. But I saw that book, and I'm like, "That's exactly what I'm doing at work." And I'd been struggling for months trying to figure things out. I opened the pages of the book, started flipping through it - and all the answers were there. I bought the book. It was the best $19 I think I ever spent. And from that point forward, it was just buying and reading books.

I got an opportunity to join a consulting company here in Denver. And what I did, is I actually printed all of the code for every application that we had in our environment. There were probably like 50 applications. So I picked the biggest ones, and I printed all the code. And to and from work, I commuted on the bus. I would just review the code, and just look at the code and study it and learn why they were doing it, what they were doing - and trying to figure out how it worked. For me it was first just reading and studying, reading and studying continuously, for it seemed like years.

But then when I got into more consulting, the mentors really helped me and guided me and pointed me in different directions. For example, design patterns. I heard architects talking about it. I had no idea or clue what they were. I just took a few notes. I would need to figure out what this is. So I went and found a book on it, started reading it, and started figuring out how to apply these things in the applications I was building.

And in another consulting company, these two architects - they probably thought I was a little Padawan, and I certainly was. These guys, they taught me so much amazing things about technology and architecture and just how to think through problems, how to organize your code, how to structure it.

They always challenged me to do different things. I would come up with ideas, and they'd say, "Figure it out. Show us what you have." And I'd go home and spend nights and weekends just figuring things out, and building things.

I've built, over the years, two or three code generators. I have built frameworks for processing business logic. Different business rule engines for .NET, C# frameworks. I've built a TypeScript rule engine that you can use with Angular applications. Things like that.

So for me, self-taught means just a continuous learning process. I think really it's just having the right people point you in the right direction, saying, "These are good things to learn, and here are some resources here and there." Or just figuring out where those resources are.

And for me, it wasn't an idea or a possibility for me to go back to school and get a CS Degree. I already went to college. I already have a family, I have a job. I have a lot of things on my plate. So continuous learning - even now, today, I've been doing this for quite a while - I'm still hitting the books - like today I spent at least two hours, or an hour and a half, just studying how modules work in depth in Angular, from this website.

And when I understand those things, I take copious notes. I have notebooks going back over 20 years, in fact - cleaning out my office here, I have every notebook that I've ever used at work here on my shelf behind me. And that helps me to learn things, because if I can teach them or write them down and see the picture, and how they relate to other things, then for me, that helps me to learn things much easier.

Len: Thanks very much for sharing that story. It leads me to ask a question that actually comes up pretty often on the podcast when I'm interviewing Leanpub authors, which is - if they didn't go to Computer Science, they didn't get a formal Computer Science degree - do they wish they had if they'd had the opportunity to do so? And if they did get one, do they regret having done so? Or if they were starting out now, would they just do it completely differently, given the Stack Overflows and all of the incredible resources available?

So the form of that question to you would be - you said you've already been to college, you had a family, you had responsibilities and things like that. But if you could have, would you have - do you think it would've been better to have done a degree?

Matt: Well, I think it might've fast-tracked my career a little bit. Having to kind of learn on your own and teach yourself over the years with books - I think I probably could've used my time a little more wisely. But I think I learned a lot of different things along the way. And I would say that - personally for me, I wouldn't trade that. Now, I see what Computer Science teaches our developers and engineers today. And I really appreciate having them on my team to work with, because of their perspective and things that they know. And I've learned a lot of those things as well. But there are things that I have really paid a lot of attention to and studied in depth, that they really didn't touch on very much in college.

So there's a balance there. When I think of teams and development teams - I want diversity on my team. I want people with different backgrounds and different skill sets and resources. I don't want every developer to have the same skill set, to look just like the next guy, next to them. That diversity is really what creates innovation and different ideas and such. So, I wouldn't trade it. In fact, the same question about - would I go to school for music again? No, I wouldn't.

Len: Oh really?

Matt: I think that kind of structure - I mean I love the people, the bands and the music and the experience. But learning music theoretically first, I think it takes away the basics or the - really the base elements of what music is. Music is something that you hear and feel. And you can think about it later, but that's really what it is first. And that's why people fall in love with it.

But if you learn how music is constructed, and how symphonies or compositions are made, and all the different structures and the harmonics and the melodies and all that stuff - when you listen to music sometimes, you think of that. And it takes away from the enjoyment of it sometimes. So I find myself having to really focus. I have to focus on not thinking about that, so I can really enjoy music sometimes.

Len: I think I know what you mean. My own version of that from my experience, was I studied English literature. And I remember one time explaining my doctoral thesis proposal to my supervisor. And she said, "That sounds terribly unpleasant." And it - honestly, it had never occurred to me that like reading seriously, could also be for pleasure.

It was just the unpleasantness - it wasn't that I wanted it to be unpleasant or it needed to be unpleasant to be serious. It was just that pleasure was just - and passion - were just like completely orthogonal to what I was doing in my analysis of things from an academic perspective.

Matt: Right. A lot of people just read to escape.

Len: Yeah. And it's interesting too, when you do study things on a theoretical level - it is difficult to then use them, to relate to them in the same way other people do. And there's this element where it dramatically increases the quality of the experience that you have. Like if you're a trained architect and you're looking at a building or something like that. But it does take away - it can take away a kind of straightforward enjoyment of things.

Matt: It does, yeah. And it's - if you were a chef, can you really go to a restaurant and enjoy a meal? You're probably thinking, "How do they do this? What are these spices?" Things like that.

But - and on the other hand though, I think - being a musician first in life. When I approach problems at work or technical or business problems or solutions that we need to solve technically - for me, it's really very easy to decompose things, and to see how one thing relates to another, and how they relate from one end to this other end, in terms of workflows and sequences, and things like that.

And for me, designing software is easy. I enjoy starting with the blank sheet of paper. Give me a concept. We can build this. I love doing that.

And I think it partly comes from a musical background - jazz and just loving things conceptually like that, and just knowing how to think through problems in a different way.

Len: In the next part of the interview when we get to your book, I'm sure we'll be talking about design patterns and what you mean by architecture in the context of software and things like that - and I'm really looking forward to that. But before we do that - it's become a common feature of the podcast in the last couple of months, to devote a little bit of time to talking about how the pandemic has affected the area where the interviewee lives and the people around them - how it's affected their lives. So if you wouldn't mind talking a little bit about how your community's been affected, and how it's affected you?

Matt: I didn't realize how serious it was until work started talking about it, and they said, "We're going to schedule a day where everyone works from home, just to see if we can make it work." And actually we started a day early. Someone thought they had coronavirus, and they worked literally 10 feet from me. And so everyone was basically told that we were going to start working from home. And the person was tested. I didn't know if I was exposed or not. I have family here, young children, my wife - she's very concerned about those things. And I literally had to self-quarantine in a basement.

Len: Oh my.

Matt: Until we got the results from this individual at work. And so I was - I started this off in - it was around the first week of March. I was self-quarantined in my basement, in this room here, without my backdrops and cool lighting and microphone. I had things switched around a little bit.

And so I worked down here. I slept in the basement. I ate my meals down here. It was kind of a rough start for a few days. So it really kind of got me to appreciate how serious things are.

And then the news and everything really made it more of a reality and such. And even newscasts, they would have drones flying over literally the parts of Denver where I work. The same street even. And no cars. Nobody on the street. No people walking around. And this is a very popular area in Denver called "RiNo", It's popular for startup companies. It's popular for microbreweries, restaurants. So there's people there early in the morning till late at night continuously. And it was just odd to see it just completely shut down with nobody there. So when I saw that, that hit home. I mean Denver's been my town forever, and I've never, never seen it like that, so -

But I think, from a professional level, it's helped me to connect more, with my team. 90% of the work we did on the last project was while we were quarantined. And we released a product in less than four months. I would have to say it was either defect-free or they couldn't find one the day it was released. So it was a very high-quality effort by the entire team. I think the tooling that we have and the collaboration that we did - just remotely, together working - was really cool, and it shows that it can be done.

And it can even be better sometimes than working in an office. Everyone's there, but everyone has their headphones on, and no one's talking to each other. So it seems like people are communicating more, now that you're kind of stuck at home, it seems like.

People are more caring. I walk my dogs in the neighborhood on a daily basis, and my two huskies - I have two huskies. And it's different to see people, "Hey, how you're doing?" They're waving at you and talking to you. And it's like - six months ago, you'd walk and you'd see nobody out there, and nobody would be waving to you. I think it just makes everybody a little more awake to life, and what it means.

Len: One ne striking memory I have is - when things sort of got serious here in Victoria, in British Columbia, and when people started really changing the way they behaved. I saw something - I saw more people walking around, that's still true. But couples holding hands. That just wasn't something people did here. But I've worked from home forever, and I work looking out over my balcony, and I see this street all day. And - yeah, couples walking around holding hands became a thing.

Matt: Yeah. Families pushing their children in the carriers and walking their dogs. I've never seen so many people walking their dogs since this last spring. And I think it's awesome.

Len: Yeah, me too. So do you think - do you miss the office?

Matt: I miss some parts of the office. I like going in first thing in the morning. Getting a cup of coffee and maybe chatting with the cubemate next to you, and just seeing what's going on and such. I miss a little bit of that. I miss kind of not knowing what day it is of the week. For some reason when you get out and about and you're traveling to and from work, you kind of know what day it is. I seem to kind of be in a rut - not in a rut, but it's a different routine. And it's atypical, so I think it throws me off track a little bit. I love food and restaurants and such, so I love going out to lunch - and I have all my little favorite eateries in Denver and such. And I miss that, probably the most.

Len: And do you get a sense that those things are going to be coming back soon in Denver?

Matt: A lot of the bigger restaurants and ones that are chains or whatnot - they're doing fine, and even some of the microbreweries are coming back and such. And a lot of them have been doing curbside takeout ever since.

But one of my favorite little restaurants in North Denver, I've tried calling there a few - about three times over the last few weeks, and I checked online too - and it says they're closed permanently. And I was like, "Oh, that's my favorite restaurant." And when this thing took off, I'm thinking, "If there's one restaurant in this whole city that I don't want to see go away, it's that one." And it's gone.

Len: Oh, I'm sorry to hear that.

Matt: I don't know if they'll come back. But yeah - I mean, I'm the kind of person - I've been going to that restaurant for about 25 years, and I order the same thing every time. So I have my little restaurant spots that I go to, and I just order the same thing. And I have restaurants literally that I've had the same meal, the same thing I've ordered for 25, 30 years. So, yeah, I'm kind of set in my ways there.

Len: I'm a lot like that as well, and I have a single thing that I like to get at restaurants, once I've settled upon it. And the anticipation of that thing, is a big part of the enjoyment of going.

Well, I really hope that things get back to being as safe as they can be as soon as possible for you, and so you can start going back to these places.

Getting back to the main course of the interview - so, just before we talk about your book, Angular Architecture Patterns, I wanted to ask you about code generators. You mentioned you'd built a couple of them earlier on - if you could just talk a little bit about what a code generator is, and what it's used for?

Matt: Yeah, certainly. Well, you want to use a code generator to basically scale your efficiency or velocity of a team. So a lot of times in software development, especially enterprise development, there's a lot of code that is very cookie-cutter, very recipe-driven. It's the same over and over again. Maybe the inputs change, and there's very little in terms of variance. But there's a lot of that code. So you can create templates and you can have inputs if they're well defined. Basically, these templates can generate certain parts of your code. And when you do that, you can literally shave man days or man weeks - and sometimes man months of time off of a project.

Back in 2005, code generation was a pretty hot topic. There was a lot going on in that space. And there still is. But I think it's changed and morphed into like scaffolding. So you use inputs and things to generate or scaffold code, and then you customize it. And so it gives you a little more flexibility, but it still gives you like 80%, 90% of that code generation aspect.

But at the time, I was working for a consulting company. We were working on code generation engines and such, so that we could bid these projects, and give them a fixed price. And because we can do it much faster and much more quickly, our margin of revenue is higher because of that.

And so, we were using it that way. And for me, there's some aspects of that in terms of how it relates to architecture. Is that - one, you have to have an architecture that is very reliable and consistent in how its done and how its made, and the certain layers of the application, and specific parts.

And if you see these patterns - that these are the same thing over and over, then it's a candidate for code generation or scaffolding. And so, yes - I've built generators that can build an entire service, like microservice stacks from the web API - all the way down to the database. And the inputs are - a lot of times, the database schemas - we create entity models from that. And then those entity models have attributes on all the properties and such. And all that information is just like metadata that provides the input. You match that with the template, and then you output code that can be compiled for an application.

It saves a huge amount of time - but they're very tedious to work through. Sometimes you could spend two or three weeks or more - a month, maybe a month or more - trying to get everything just right. And you generate over and over, and you're like, "Oh that's wrong." Then you fix the template, then you redo it, and it's kind of an overturning process until you get it right. But once you have your engine and your templates good, then you're ready to go - and very effective.

Len: Let's move on now to talking about your book Angular Architecture Patterns. You've talked about architecture a couple of times already, and I was wondering - you have a little section at the beginning where you talk about the meaning of the term "architecture," and the context of software, and why it's an important concept. I was wondering if you could talk a little bit about that?

Matt: When people hear the word architecture, they may think a lot of different things. And when it relates to software, I think it really kind of means the same type of things or concerns that people who have been using architecture for centuries of time.

You can relate it back to building pyramids. They had tools, they had materials, they probably had a plan, they had a design. They must have had a model of the pyramid as a smaller shape or size, and said, "We want to build something like this, but it needs to be huge, right?"

So to have the goals and the objectives that are well defined. And they have to choose their materials, and choosing materials to last. They've got to figure out, "Well, how are we going to work with these things?" They probably had to build tools to work with those materials.

So when I look at modern architecture in software, it's really the same thing. We need to consider all facets of the application or the objective. Not just what you're building, but what tools are you going to use? What are materials are you going to use? What is the design or the plan?

Now for me, I think of it as this triangle, and if you are missing one of those elements - if you don't have a design or plan, how do you know what tools and materials are going to work? If you have a design and plan and you don't consider tools, and you just start working with materials - how are you going to make that work? So in talking about those three things, you need that objective goal-setting, you need the design and analysis phase in software, that it's missing.

A lot of companies just fail to do this, or go through it too quickly to identify the information of what an application is. It's the "W's." It's "who," it's "why" they're going to use it. Who's using it? When are they going to use it? Where are they going to use it? What are they going to be doing?

If you define all those things, you really truly understand what you're going to do. But most software and technical people jump to the "H" part, "how?" They jump to "how" first. Because it's really the fun part, writing code.

But for me, if you do those other things first, then it makes writing the code much more enjoyable and easier. Because things just work out much better. Because you have those things in place.

And so to me, that's what truly architecture is. It's part all of those things. It's the experience of the individuals that understand the business and the objectives. It's the experience of individuals who know the tools and how to use them. And also, how to execute that play or that recipe or that pattern, or those architectures. To execute and maintain that discipline to not deviate.

So can you imagine? If people deviated while building pyramids, they wouldn't be around today. If they switched materials half way through or stopped using the plan or the pattern - so that's kind of how I approach software development, is from those aspects.

Len: It's really interesting, yeah, there's another important "who" in the design of software, which is the coders. It might not just be you that's working on this code all the time, it's probably going to be a team of people. It's going to be passed onto other people in the future. And so that "who" has to be kept in mind as well, when you're doing design, right?

Matt: Exactly. So that's - part of that execution phase is to make sure that what you're writing is consistent, it's maintainable, it's readable, it's of high quality - which means that there's tests to verify and validate the things that you said work - according to the plan, actually work. You quantify that. And you're writing the code as if you're writing it for your team member next to you. Or for you six months from now, when you have to come back and revisit or add a new feature or fix something. So it's that kind of mentality that - it's a team approach, it should be a team approach.

And I think those aren't easy skills to acquire or easy to do, so it takes a lot of discipline and hard work, and it's a continuous effort. You just don't have great architecture once in the beginning, and you still have it at the end. You have to continue to look at it and say, "Oh did we do this right? Oh no, we have to fix that to make sure that it's according to the plan or our standards."

That way, that "who," that person who comes back - it's enjoyable for them to work on it as well. And that's usually not the case in software development - people don't like doing maintenance work or fixing bugs. Because it's horrible to find - one, where to fix it. And when you fix it, you probably break two or three other things. So that's not a happy place.

Len: Yeah, it's interesting. We'll maybe talk a little bit about your concept of a "code scene investigator", which I just absolutely love that.

But you mentioned something very important there, which is the positive impact that planning in advance can have on revenue. And it's really interesting you said that. Because one of the reasons - and I know this mostly from interviewing people for the podcast, not from personal experience or professional experience so much. But one of the reasons that many companies don't actually do a lot of planning in advance, is that there might be someone on a manager level or an executive level who's like, "How much code have you written already?" And then they have these metrics for like how much progress has been made. And a product manager might have to report on how much progress has been made. So, "What have you built?" And so, doing extensive planning in advance can sometimes, from that kind of structural perspective, look like nothing's getting done.

But one of the things that I've been told by battle-hardened people before, is that if you can bring up the positive impact on the company’s revenue when you're justifying this kind of change in a company’s development culture - that can really help. So if you were trying to - if there's someone listening to this who's like, "Oh man, I wish I could convince my boss or my team lead to do more planning," what would you suggest, or one or two things they can think about doing when they're presenting their case?

Matt: You're quoting the guide that I just wrote. I think I wrote a sentence there, it's, "If you do the right things now, it's going to enable you to do the right things later."

Sometimes it may appear that you're moving slow in the beginning. But to me, most of these applications - if they're long-lived, it's more of a marathon than a sprint. So you have to really think of the longevity of the application that you're working on. And if it is a key component of revenue for your company, that's the way you're going to look at it.

So you're not going to cut corners in the beginning just to appear like you're making huge progress. Because what that'll do, is it'll create a certain amount of technical debt, that sometimes you can't overcome. And if you think of a team of just even a few developers - say you have three developers, and they work for five days one week - it's 15 man days of development. What percentage of that is technical debt? And then you extrapolate that over time. How much technical debt are you acquiring in just a month or three months, or six months? And after one year of that, you probably have so much technical debt that you'll never overcome it.

So really, in the beginning is the right time to do it the right way - to make sure you have everything in place. Make sure the foundation is there, so that you can build upon it. Because going back to the foundation after the house is on it, ain't going to happen. You're going to have to tear it all down if you want to do something like that. So that's why even in home building or whatever, I mean - the time and attention is on the foundation.

The home I live in right now, they did a soil test. And where I live, it's expansive soil. So they had to do caissons down to the bedrock. And then on top of the caissons, these steel girders across. And then they laid the foundation around it, and my house does not move. So it's probably even better than the house next to me, who doesn't have that. But the foundation is the important thing. So that's really what you want to do - is if you want to be able to be nimble and fast in the future, and continually as you develop - then do it the right way from the beginning.

Len: In your Architecture Patterns book, you also talk about the distinction between adhering to principles, as opposed to following rules. That distinction really appeals to me, and I was wondering if you could talk a little bit about what you mean by that?

Matt: Yeah, well I think in general - human nature, people don't like rules. And I don't like them either. I think I'm a rule-breaker. And I think people who have known me all my life can probably document all kinds of scenarios in my life where I've broken rules or whatever, or kind of bucked the system.

But for me, principles never change over time. Rules change according to culture, time, politics, what have you. But principles are pretty much - they're just bound by something that makes sense. And they last, and they're easy to grasp and understand.

For example, in software development, there's a single responsibility principle, and a separation of concerns principle. If you studied two principles, those two - if you studied those two - I guarantee you're going to go 80% or 90% of delivering awesome applications. Your software - it's going to look great, it's going to do what it needs to - just by following those two patterns. But that means a lot. So it's like - well, how do I implement those principles? What does that mean then? So that's really when you start studying architecture.

And maybe talking about the *Architecture& book - what is a layered architecture? Well, that gives you your separation of concerns. And you have these boundaries between these layers.

Okay, what about single responsibility? Well, it makes sense in life. In your house, where you live - everything has a little responsibility. Every room in your house has a responsibility. Every thing in your house has a responsibility. Your lawnmower is responsible for mowing the lawn. So you keep it in the garage or the shed or whatnot. It's not in your living room. It doesn't belong there.

So just like our software - there are things that shouldn't be here or there, they need to be moved to the right place, or put in the right place. And so for me, these principles really guide that. And if you're following those two things, two principles - I mean, there's a lot more principles out there. There's books on them. There's the SOLID principles. There's clean architecture patterns, principles and such. Just follow those things.

In talking about that, it just reminded me - I ordered this book, it's the 20th anniversary of the Pragmatic Programmers book. A friend of mine I was working with gave me a copy of this book, and it's probably one of the best gifts I ever I got. Because this book is just end-to-end principles. And they're very easy to learn and follow through. You'll learn them and start applying them immediately, that's how effective they are.

That's the cool thing about principles. They're easy to learn and to start applying. Once you have the principal in mind, then you start seeing where you can apply them.

Len: That's just a really fascinating way of putting it - that they're a kind of a guide. But they allow you - when you're in a situation, a principle allows you to see what's before you, and what the opportunities are.

Whereas, if all you've been kind of doing is following rules in any area, when you end up in an unfamiliar situation, all you have available to you is to ask, "What's the rule for this new situation?" You don't have any kind of generative capability.

Matt: Yeah, it's kind of like someone who's a cook, and the only way they can cook is by following a recipe. But if they don't understand the principles of cooking, can they ever create something on their own without a recipe?

Sometimes people are like that, "What do I need to do? Tell me - what's the recipe, what do I need to do here? What's the sequence, the one, two, three of it?"

To me, it depends. It's up to you. It's up to the application, the context. It's so many different factors. So learn your principles, and you'll find that those will guide you a lot further than trying to learn rules.

Len: I could talk about this topic for a long time. But there's actually a really important application of it too, just general civic conduct.

You mentioned that people don't like rules. People don't like to follow rules. And so people who relate to of conventional things in our life, like, "You need to signal when you turn," as just a rule, then they might not - they might feel angry that they have to do it. They might not do it if they don't feel like it, or if they just don't think it applies.

But if you understand, "No, no, this is a principle. You signal every time you turn, because you're not fully aware of everything that's going on in the environment. There are other people looking at you, and you're telling them what you're doing. So now they know what decision to make." So when you see that it's a principle, rather than just something imposed on you - then you don't feel like you're being abused or manipulated or punished for being made to follow it.

Matt: Right, yeah. Yeah, definitely.

Len: And so, the last thing I wanted to ask you about this book was - you've talked about patterns, what is a pattern in this context?

Matt: I think patterns have emerged over time. I think the patterns may have always been there in real life, and in nature.

Look at our solar system. There's patterns there, right? And how things work in that. There's patterns here on our planet earth. The water system and different things, and how things work and such.

And so sometimes the patterns have been there probably all the while, and we just discover them or give them a name and such. I think what's happened in software engineering - is that really smart people just do things in a very effective, efficient way.

And by doing that, you look at that and you say, "Oh, that's a great pattern. Let's give that a name, let's use that." And sometimes you may be doing something very novel, and a new pattern emerges based on a different pattern, or something. So it's not to say that there are no new patterns. Because there always are different ways of structuring things, or organizing things differently, and such.

So patterns are just a way to communicate about something that really exists. And if it's logically in code or in software, or if it is a pattern in building architecture or building anything, and such.

It's just a way to communicate about something. So when you talk about a pattern and somebody can recognize that, or they can go somewhere and read something about it, you're on the same page. You're running the same play.

Think of that coach who's calling the play on the field. It's a pattern. In hockey, there's a play run - the forwards have a certain route or pattern, are going to take towards the net or something. If they don't follow that pattern, nobody is going to know where they're going to be, or should be.

But if everybody knows the pattern, then there's that sense of knowing how to do something, and how to run that play. How to execute. How to structure this.

In sports, it's definitely there in sports, in most sports. Hockey, basketball. Football, for sure. There's lots of patterns and plays and such. And everybody has to study those playbooks, study the plays, and know if they do need to make a micro-adjustment, they're still running the essence of the pattern, and sticking within the frame of the play - and it's still effective. But they may make micro-adjustments. And you see quarterbacks do that all the time, when they walk up to the line of scrimmage.

We have to do that also in software. I mean, you're not going to say, "Here's the pattern, and it's going to work 100% of the time." There may be circumstances where you have to deviate, but that's a micro-adjustment.

This is actually the perfect opportunity to move on to talk about your guide, Effective Angular Code Reuse Strategies and Techniques. In there, you write about playbooks. And not just in the abstract sense that you were just describing them. But actually, it just so happens that there are development teams that have literal playbooks that they write - that they call playbooks, and these guides for what to do.

But the funny coincidence is that just last night - I'm re-watching the show Smallville. I don't know if you ever saw that? The show about like Superman as a teenager, basically.

Matt: Yeah.

Len: And the episode I was watching last night - there's a football game at the beginning for the high school team, and it's raining really heavily. And the quarterback gets sacked because he took too long, and didn't even try to pass the ball.

the coach gets really angry at him. And it's at night - by the way, too - so it's dark out. And the coach says, "Why didn't you throw the ball? We were running this play, and you were supposed to throw it at so and so." And he goes, "Well, because the rain was so heavy, I couldn't see him." And the coach - who was the villain of the episode - grabs him by the face mask and goes, "You don't need to see him, you know where he is. We've run this play 1,000 times," right? And it was just so striking. But anyway - I thought I'd bring up that funny coincidence that just last night, this sort of perfect example of exactly what you're describing.

Matt: Exactly. That's a great analogy.

Len: Speaking of funny, you actually have a really fun section, where you talk about like the importance of re-using code, and why that can be so valuable. You have a great line, "If you want a chicken sandwich, do you purchase some chickens and raise them in your backyard?" And of course maybe in COVID times, people are doing that a little bit more than they used to, but but it's a really important idea that we don't - when we do things in a normal life, we don't build everything from scratch. And building software - there's a really important application of that idea in software as well.

Matt: I think when you learn how to code and build things - or if you're a musician, you know how to compose and write music. Like, "I'll write this from scratch," right? And I think developers, particularly - I've seen cases where they build amazing things, yes. But you didn't need to build that, and it doesn't even relate to the business that the company is trying to achieve here. That's really cool that you did that, but it adds really no value.

So for me, I think it's unpopular sometimes, just to say that. To be like, "Well, that adds no value." It's really the use of that that is the value. So whether you make it or not, it's the use of it.

I learned that from one of my uncles, who dealt in restaurant equipment. "Hey, it's not the stove in your restaurant that's going to make you a great restaurant, it's using that stove." So he would always tell his clients, "Lease the stove. Don't spend all your capital and all that money upfront buying all this new equipment, when you can lease and get going, and use it and start making money."

And so you apply that same simple little principle to "build it or don't build it?" type thinking, and you just build the right things that add value. And then you can focus on those. And that'll make what you build a lot more high quality, because you're really focusing on the right thing.

Len: There's a really interesting issue there, which is that a lot of people who write code, love doing it. Which is a good thing. But what it does mean, is that you can just find yourself down a fascinating path - that's inherently enjoyable, has all kinds of like reinforcement feedback in it. And even whole teams can go down these paths and build something really interesting, that is totally unnecessary.

Matt: I've seen people take a three hour or a three day project and turn it into a three week or a three month science experiment. And that's great if the company can afford it and there's no deadline or deliverable. And, "We're making so much money, who matters. Do what you wan to do." If that - great. If that's your situation, great. But a lot of companies don't have that kind of capacity to allow that.

I learned that early in my career. I had an architect tell me, I was saying, "Well, we should do this, it's so cool. This would solve that problem. I could do this and we can build it, and it's going to take like two or three weeks to build it." He's like, "Matt, if you want to do something cool, do that on your own time. Nobody's stopping you." And at first when he said that, I was really upset, and I'm like, "Why would he tell me that?" And then later he told me.

The reason why he told me that is, "We need to focus on our client and give them what they need for their business, and to solve that solution - and give it to them as quickly as possible, so we're not delaying their execution." It made a lot of sense.

And so we did revisit, and we built what we talked about - but it was much later, when it was the right time and place to do it. So that could happen, but really it's all about, "Does it add value or not?"

Len: I would say that was a risky move, telling you to do it on your own time. One approach we've taken towards that kind of thing in Leanpub for the sake of retention and attracting very talented programmers - is actually, like explicitly giving them a science experiment as part of what they do. Like there's going to be - all programming involves a fair amount of drudgery and repetition and things like that. And you can be a brilliant person sitting there doing a non-brilliant person's tasks. And sometimes, actually having a portion of a developer's work time be devoted purposefully to something that's really - I mean, as you say - if you have the resources available to do so - and the independence available to do that, that can actually be a really good thing for attracting good people and keeping good people around.

Matt: Oh yeah, definitely. And the consulting company I was working for at the time - they actually gave us several days a month to actually do that, and devote time to building out those frameworks and those tools for the company and such, and to investigate or learn how to do it. And so they recognized the value, and I think a lot of companies now are recognizing that. They have like Hackathon days or Hack days or Develop days. where they're letting their developers take time, as part of their career development, to study and do Pluralsight videos or training, or in-depth research, and things like that.

I've seen that, and that's really - I mean, I love doing that too. So I take advantage of that when I can. And if I can't, I will do it on my own time. So I get it in no matter what.

Len: The last question I want to ask you before we move onto the next part of the interview is - I mentioned earlier, you've got this concept of a code - A CSI or Code Scene Investigator, in your guide. And that is just like - it was just one of those things where it's like - everything came together in my mind around what that concept is. Because I mean - I'm Leanpub's resident non-programmer. I do do some programming. I do spend am amount of time looking at code. But I know exactly what you mean by that. Like, you've got to have forensic capability. You've got to look for clues. It can be kind of intense. Something very bad may have happened and you've been brought in to try and - just at first, figure out what happened, and maybe even who did it.

Matt: Yeah, there's that chalk outline there on the street. I think - as a consultant, and going into different companies and seeing things under the hood - you'd be surprised what's behind the magic curtain, I guess, in some places.

But yeah, I think it's probably from a lack of - a lot of times, a lack of technical leadership. It's also a lack of just being disciplined and sticking to a process or such during the execution or development.

But - and it's not like developers don't want to do that. Sometimes they just don't have that. Maybe they've joined the company and it's already been two or three years in development. You can't rewrite everything or change everything - it's just the way it is. So you have to kind of adjust to that and say, "Okay, well here's the crime scene. Let's figure out what happened here. And how do we fix this, clean it up, figure out what we need to do to make sure it doesn't happen again" and learn from it and move forward.

But for me, a lot of it could be avoided if you do the right things upfront. And a lot of that is - really making sure you have that plan, that architecture, those designs and such. But then make sure you have the discipline to make sure it maintains that.

A lot of teams go through that process. They have peer reviews and merge requests and pull requests and things like that to review code. But that's different than actually reviewing code informally or in a different context. Like, "Okay, let's walk through this whole thing. Let's run through the tests and see how the tests are doing. Let's see this or that."

And when you're doing those things, you're actually self-correcting as you go. So you pay as you go. And you have a lot less, or even sometimes no technical debt, in some areas of your app. So you eliminate the Code Scene Investigation. No yellow tape around this component or, no yellow tape around this module. It's like, "Oh, don't go in there." Everybody, every app has that little thing.

Len: And the tools that you have available can actually change the way you go about looking into the sources of problems of course.

This reminds me of a really great John Mulaney joke I can't help but share. So he's talking about - in one of his stand ups, he talks about what it must've been like to do like to do crime scene investigation in like the 1920s, before they had any DNA testing or anything like that. And so he envisions like a detective in Chicago at a crime, at a murder scene. And a sergeant comes in and goes, "Detective, detective - I found a pool of blood in the hallway." And the detective looks at him and goes, "Gross, now back to my hunch."

I definitely recommend anybody who's involved in software development, to check out this guide. The book of course, but also the guide Effective Angular Code Reuse Strategies and Techniques. Both of these, both the book and the guide are about Angular - which we didn't even get a chance to talk about.

But I actually kind of didn't want to ask you about it, because I wanted to talk about all the other things that these books are great for. Which is all these principles and strategies and stuff like that. So even if you're not into Angular, this is a great book and a great guide.

Moving onto the last past of the interview, where we talk about what your process is as an author. There are lots of platforms out there for writing books and publishing and selling books. Why did you decide to use Leanpub?

Matt: Certainly, it took me a while to find the right tool. And when I came across Leanpub, it started checking all the boxes. For one, I wanted to write my book using Markdown in my code editor, that I use to write code and document and do other things - so it just felt like a natural to do it that way. I also like the aspect of version control, and being able to have a GitHub repository that maintained all that source. I could do commits and branches, and do all the stuff I would do writing code - as I'm writing the book in kind of the same kind of thought mentality.

And it's very safe. It felt safe and secure that way, and being able to push to repository and have the links or the webhooks to kick off builds or previews of the book. That was pretty awesome.

So those were probably the top things for me. And I also liked the aspect of - it seems like a lot of technical authors are on Leanpub, so it is great kind of opportunity there. It seemed like a good fit.

And then the ability for someone to even create their own price for a book. Or if you wanted to offer the book free, for quite a while now I've been offering the Angular Architecture Patterns book for free. Just because I feel people should just learn about this in any way they can. So I have been offering these publications for free.

But it's interesting. Even when you offer it for free, there are still a lot of individuals who want to support the effort - and they'll buy the book. And I'm like, "Okay, thank you so much." That's just great.

And I didn't write the book to become popular or famous, because I don't really think I am popular or famous - even in the Angular community there's so many great people out there. I just thought that I had a unique approach, or a way of describing things, or a message that I wanted to deliver.

I've had other publishing companies contact me about publishing books, and they basically gave me the outline. That kind of doesn't really fit on like how I work, or how I even want to approach the topic. Being able to do it my way was pretty awesome. So Leanpub was perfect. It checked all the boxes for me.

Len: Thanks for sharing all of that, and for the positive words. We always really appreciate that. But yeah, it's interesting - in addition to being a platform that typically attracts technical people, Leanpub also tends to attract kind of independent types as well. So these are - sometimes it's people who've been approached by a publisher in a way that they didn't really like, or gave them a sense that it wouldn't be a good fit with the process. And other people are people who actually did go through it and hated it - and come out in the end going, "I still want to write, but I just wish I had more - I just want to have all the control." And they're willing to forgo the resources that a publisher can give you. Because of the trade-off between the independence and the resources that are made available, it just falls on the wrong side of the ledger for them.

One thing you mentioned as well, is - for those listening who don't quite know - Leanpub has a variable pricing model. So if you publish a book on Leanpub, you can set a minimum price and a suggested price - and then people can choose what to pay.

And as Matt's experienced, it's something we've seen that's just thrilled us over the years. Is that often if - even if a book has a minimum price of "free," people will take the little slider and choose to pay for it. Because they want to support the author. And we just love seeing that - and trying to establish that different kind of connection between the author and he reader, differenly than you might get through just a normal marketplace, where it's just a straight up economic transaction, and you try and get the most for the least.

So you're publishing the, Angular Architecture Patterns book in-progress, I believe it's marked as 90% done right now, or something like that?

Matt: Yeah.

Len: I was wondering if you could just talk a little bit about what your approach to in-progress publishing? Did you set yourself deadlines, and did you have like launch announcements for new chapters, and things like that?

Matt: I think there are a lot of different kind of techniques in doing that. I mean, you could go chapter after chapter and use social media or your website or LinkedIn or whatever to kind of promote that and gain the followers and such. I actually wrote 80%, 90% of the content before I actually made it available. I wanted to have it mostly complete.

What's not complete - I think there's some diagrams in there that I really need to polish and make and create. Or create some new handcrafted drawings that I use in my sketchbooks and my notebooks, that I have stacks of - and just put those in there. Because I think it's interestin - this is how I do it, on blank sheets of paper. This is how I go through that process of drawing things out. I don't use Visio or any of these diagramming program tools as much anymore.

To me, a pencil and paper is my go-to now. And so a lot of the diagrams are kind of like that. I always had this idea, "Well, I'm going to go back and fix those diagrams or make them all pretty," and this and that. But I think they're effective. They do give the context and such - but yeah, I think it's a great model to be able to continually revise and republish new content or fix something. And everyone who wants to be notified of some new addition or whatever, they can come back and download the new version - and that's awesome.

Len: The last question I always like to ask Leanpub authors when they're guests on the podcast, is - if there was one thing we could build for you, or one thing we could fix for you - what would you ask us to do?

Matt: Well, I'm kind of graphic design impaired. So I think a book cover generator would be really cool. There's probably apps out there that do that kind of stuff. But for me, that was the hardest thing to get together for the book. The content, the chapters, the details, the code samples - all that was easy for me. But figuring out what a book cover should look like, that was like the hardest thing in the world.

Len: That's a really interesting suggestion, thank you for making that. There are apps out there that do that, and there are sort of like relatively affordable resources like fiverr, or something like that, where you can find designers.

But it is actually - it is something that would be very useful to authors. Like even if it weren't amazing, just to have - because right now when you publish a Leanpub book, the cover we generate for you is just some black words on a white background. And having anything better than that - because the thing is that the cover, especially in self-publishing, a good cover gives people - it's not just that it's attractive; it gives people confidence that whoever wrote the book put some care and attention into it. And that can make a big difference if someone's deciding, "I'm going to buy this self-published half-finished book." Having a really good cover can really help get them to the other side of that transaction.

Matt: Yeah, it's like, "Oh, the cover was good." What I find interesting, I didn't know how this would even turn out. But I thought, "Oh, I imagine at least half the people are just going to return the book or not like it." But that hasn't been the case. So that, for me, I guess it's the kind of - the impostor syndrome in me, I guess? Thinking, "Oh, I'm not a book writer." Well, I'm not a book writer, but I just have something to share - this is just a way to do it.

I think a lot of people should - if they've ever wanted to try it, I think Leanpub makes it really easy in the process. If you're a tech guy and you already have a code editor and GitHub account, you have content already, I bet - that you could already just kind of just move right on in. And there you go, you have a book.

Len: Yeah, it's really great to hear that. I mean, sometimes we get people - and just like with any product, we get people who are like, "This thing makes absolutely no sense, what's wrong with you?" And other people are like, "Oh my God - you built the thing that makes sense to me, that I never even knew could make sense to me:,

Matt: No it's awesome, yeah. I love the notifications I get from Leanpub when there's a sale. Or even, I've purchased books from other authors, and so when there's an update, I'm like, "Oh, Manfred Steyer has a new update on his enterprise architecture Angular book, oh I'm going to go get that." So I try to keep pace with that as well. I like that kind of interactivity between Leanpub, and - if you're an author or you just like to read technical books, you could always stay connected.

Len: Well, thanks very much for sharing that, and thanks very much for being a guest on the podcast and for being a Leanpub author - we really appreciate that.

Matt: Thank you for having me, my pleasure.

Len: And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.