Leanpub Header

Skip to main content
The Leanpub Podcast Cover Art

The Leanpub Podcast

General Interest Interviews With Book Authors, Hosted By Leanpub Co-Founder Len Epp

Listen

Or find us on Stitcher, Player FM, TuneIn, CastBox, and Podbay.

Simone Cuomo, Author of Beyond Coding

A Leanpub Frontmatter Podcast Interview with Simone Cuomo, Author of Beyond Coding

Episode: #225Runtime: 01:04:19

Simone Cuomo - Simone is the author of the Leanpub book Beyond coding: A guide for aspiring Developers and junior developers to learn anything there is to know to successfully start their career in tech. In this interview, Simone talks about how he got started in career in tech, imposter syndrome, setting specific career goals, the importance of being honest with others and yourself about what you do and do not know, his book, and his approach to writing


Simone Cuomo is the author of the Leanpub book Beyond coding: A guide for aspiring Developers and junior developers to learn anything there is to know to successfully start their career in tech. In this interview, Leanpub co-founder Len Epp talks with Simone about his background, how he got started in career in tech, imposter syndrome, setting specific career goals and how to achieve them, the importance of being honest with others and yourself about what you do and do not know, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on May 18, 2022.

The full audio for the interview is here: https://s3.amazonaws.com/leanpub_podcasts/FM203-Simone-Cuomo-2022-05-18.mp3. You can subscribe to the Frontmatter podcast in iTunes here https://itunes.apple.com/ca/podcast/leanpub-podcast/id517117137 or add the podcast URL directly here: https://itunes.apple.com/ca/podcast/leanpub-podcast/id517117137.

This interview has been edited for conciseness and clarity.

Transcript

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Simone Cuomo.

Based in Swansea, and currently working for the JavaScript consultancy This Dot Labs, Simone is a software architect, speaker, and a mentor who has helped many people from all kinds of backgrounds get their first job in tech.

You can follow him on Twitter @Zelig880 and check out his website at zelig880.com.

Simone is the author of the Leanpub book Beyond coding: A guide for aspiring Developers and junior developers to learn anything there is to know to successfully start their career in tech.

In the book, Simone covers all the important areas you’ll need to think about to prepare for and start your carer in tech, including an introduction to software development, in-depth interview tips and explanations, clean code practices and the structure of typical career paths and negotiation.

In this interview, we’re going to talk about Simone’s background and career, professional interests, his book, and at the end we’ll talk about his experience as a self-published author.

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

Simone: Thank you for inviting me.

Len: I always like to start these interviews by asking people for their origin story. I know you have an interesting one, and I was wondering if you could talk a little bit about where you grew up, and how you found your way to where you are now - where you’re living, and your career?

Simone: It is indeed an interesting story. I am originally from Italy. I was born and I stayed in Naples until I was 19 years old. None of my family is in IT or tech, or anything like that. I lived my life working as either as a lifeguard or in a bar, and then as a waiter in Italy.

And then I decided to move to UK to learn a little bit of English. As I was in Italy, I know that English was very important and was necessary. I left Italy when I was 19, and I went to Swansea in the UK, just with a return ticket. I was supposed to go back after three months.

And as we all know, things don’t go as planned. I went to the UK, I found a job. The job required me to stay a bit longer than three months. And then I moved there. Again, always as a waiter. I started a degree in business management economics. Again, nothing was related to tech or to what I ended up doing. I did my degree in business, and I ended up opening a café with my newly found wife in UK.

Funnily enough, Italian as well - so we both found ourselves 3,000 miles away from home. Wwe finished university. We opened our own café, and we had the business for around three years.

At the end of two years, is where things changed a little bit. We decided to sell the café. And from a business degree - I really loved the counting, I really love economics - I was into economics, so that was my dream. I found myself thrown in a T-junction. And for some reason, I call it fate - there’s more information in the book, but a friend of mine just told me that I had the right skills to be a developer. Funnily enough, I looked around the internet, I could see that there were some positions, and I spent couple of weeks learning JavaScript on YouTube.

I was playing around, trying to do WordPress website and, “I’m a developer. I’ve done the website in WordPress.” And then started to go deeper. I was like, “Okay, no, I’m not a developer yet.” And then I learned more, and I did some OpenCart. Then my brother said, “I need a site for this.” I spent two or three weeks playing around. I managed to then - I sent applications to a couple of positions around my area, and I was offered a job for two of the applications I sent on the time, it was within of two weeks. And, yeah - that’s how my career started, very unexpectedly. I still find it hard to explain to my mom what I do. She still has no idea. It’s been a great experience.

Len: Thanks very much for sharing that. I want to ask you a little bit more about where you’re from. You just said you’re from Napoli, and you’ve got this very striking line in your book, where you say that there’s a saying. “People that are born round don’t die square.”

Simone: Correct, it’s -

Len: I was wondering if you could talk a little bit about that? That’s a very powerful little saying.

Simone: One of the guys who actually read the book tweeted to tell me the same thing. It’s, “Oh, we don’t usually use that in UK, and it’s very powerful.” What that means is that - when I was born, I always had a lot of aspirations. I was very driven, I wanted to do more. I used to tell my mom, “Oh mom, I’m going to do this.” And dad, “Dad, I’m going to do this.”

But the reply I usually had from my parents is nothing to do with the parents, but it was the culture. They used to tell me, “Look darling, if you were born a son of a doctor, yeah, you may become a doctor. If you were born a son of a businessman, you would probably turn there.”

But in Italy, things don’t work out - or more precisely, Naples - things don’t work as you think. If you’re born in - as it was in the past, if you were born in a specific job or sector, it was very hard to move around.

I lived my life and worked very hard, with the possibility and aspiration to move, and everyone around me would used to tell me, “Nah,” it’s not a fairy tale. That’s probably one of the reasons why I never went back, after I moved to UK.

Because the mentality was different. The mentality in the UK is, if you work hard, you get paid. If you work hard you’ll succeed. If you work hard, you move forward.

When I was in Italy, I used to work for hours and hours, all the summers, and all the winter. But at the end of the day, I was not the one to be attributed the praise. It was always the upper manager. It was always the boss. That’s the environment.

I was very, very lucky to be able to keep my self-motivation, and lucky also to have found the UK - I have to be honest - I put my hands up for this country that has supported me since I moved.

Len: Thanks very much for that. That’s interesting. I’ve had, I think, and probably a lot of people listening have had kind of similar experiences growing up, where you might be in a very loving family and a very loving environment and community, but there might be some gravity there that, to put it negatively, is there to keep you down.

Simone: Correct.

Len: And often in your place. And in the metaphor you’re saying, “in your shape.” Being able to leave and go somewhere else can be very, very freeing in a way. Where it’s kind of like, you can be more yourself, in a place where you’re not from sometimes.

I specifically had that experience moving to the UK myself a long time ago. I grew up in this part of Canada where there’s not a lot of opportunity. And the kind of attitude you were just explaining, is there. Or was there, at least in application to me. There was more opportunity for me in a corner of London, than there was in the whole country.

It was a very exciting experience - I mean, you can think of all sorts of romantic analogies, but it’s kind of like, if you’re an orca and you’ve been raised in a water park or something, and you’re finally in the ocean, and you’re like, “Oh yeah, this is what it was supposed to be like.” It might be scarier, but still, this is the way it was supposed to be.

And so, actually, I’ve got a question about that. When you moved to the UK, you could just move there, right?

Simone: Correct, yes. It was still part of Europe.

Len: You didn’t need to get a visa and stuff like that?

Simone: No. That was the beauty of Europe. I was just able to just get a plane.

Len: Right. And is that true for people from Italy now?

Simone: Not, unfortunately. Now, to move to UK, if you are a part of Europe, it’s a bit different. You can move if you have a professional job or skilled job. And there is a minimum wage that you will have to earn when you move in.

I don’t know the real details. I know that things - since Brexit, they’ve been changing things slowly, to actually make it where, as it was before - free for all. But there is a little bit of - you don’t need a visa to come in, but you need to have paperwork, that is more than I have needed before.

Len: And as a non-European, when I started to work there, I had similar restrictions. This is just very particular for people who are thinking of moving to the UK. Do you know if people from Europe - in addition to getting a professional job, does the employer have to make a statement that, “I couldn’t find anyone in the UK to do an equivalent job?” Because that was true for me. They had to say, “Oh yeah, there’s something special about this job or this person that means we couldn’t find anyone here.”

Simone: No it doesn’t go as far as that.

Len: Okay.

Simone: From my understanding, for European people, it’s not the visa, it’s not the working visa, it’s not a sponsorship, as they say. It’s more about, just an agreement that you tell the government. “I am working, and I’m earning this much.” From my understanding, no, there is no limitation on that.

Len: Okay, great - thank you very much for sharing that. I’m partly asking, because I know that, part of your work for, it’s “This Dot Labs,” is that correct, the JavaScript -?

Simone: I work for This Dot Labs - yes, yes. They are based in US.

Len: They’re based in the US - and they’re fully remote, I think - is that correct?

Simone: Correct.

Len: I was asking, because I knew you’d know something about recruiting and some of the rules around that. But just asking sort of anecdotally - has it become more difficult for companies in the UK since Brexit, to recruit, let’s say, let’s limit it to programmers, from Europe?

Simone: Yes, extremely. What they did, when Brexit happened, people saw that, people in the UK thought, “Oh, we’re going to get the power back to employ who we want.” But what has actually happened, is many skilled people now - there’s loads of doctors not coming anymore. There’s loads of people that aren’t needed, and they’re not coming. There’s been a bit of a show stopper for people not crossing the channel anymore.

And as you go around , you can actually see it everywhere. Loads of restaurants have signs outside to say, “Sorry, we couldn’t get staff. The service is going to be very slow.” There are practices, and things actually slow down, and things that they have to do the same - the things happening with - you can feel it around, that it’s not been the greatest. But there was more than that at the end of Brexit decision, so I’m not here to make the choice on everything. But yes, it’s been quite complicated.

Len: Thank you very much for saying that. I’m not trying to put you on the spot and make you commit to a position from one side or the other. But I would just - as someone who’s - like you, has moved from one place to another - regressive changes, I mean, I can take a position, I was against Brexit.

I would say that one of the big problems with regressive changes, where limitations on freedom are imposed that were previously released, or something like that - is that, if you go back and say, “No, no these freedoms are back.” People are not necessarily going to believe you. And now they’ve got this understanding that like an election, a referendum, can overturn it. And so you just can’t trust it. That’s one of the reasons that those fights are so momentous, right? But as you said, there was a lot more than European migration going on in that decision.

Simone: Correct.

Len: You’re going to be a great person to answer this question, which comes up frequently on this podcast, which is - if you were starting out in a career now, like you just moved to the UK for the first time - you’re 18 years old, let’s say. And you’re like, “I want to have a career in tech.” You knew that then. Would you get a Computer Science degree, or would you go the self-taught route again, as it were?

Simone: I have a lot of experience in this. Really, truth be told, a Computer Science degree’s not needed. There’s nothing wrong itself with Computer Science degree. It does keep the foundation that you need, and it helps.

But unfortunately, I thinkm on average, in all the companies that I worked with, a consultant with - the average is always around 50% or 60%/40, where 60% of people do not have a Computer Science degree. I’ve seen principal architects not having a Computer Science degree. I don’t have it now, and I’m software architect. So I would say that not having the degree does not stop you to get a job.

What I usually say, that is a word of warning for people to actually do a Computer Science degreem is that, unfortunately a Computer Science degree gives people a cushion. People expect to know enough to be able to get a job. What happens usually when we interview people and there is someone that comes after university, they expect to know enough that they should get the job. They expect the job to be - they say, “I’ve done three years.” Some people do it after six months and a hundred days. “Why should I not be ready?”

The problem is the frame of mind. What I wrote in the book as well - there’s a whole section. Because I’ve interviewed so many people in this position - people’s position, is that - when you really get your first job, no one absolutely cares about, if you know how to do an object, if you know what an array is, or whatever.

Because in reality, what you learn is, there’s a very, very small possibility that what you learn is precisely what you need in the current job. At your very first position, wnat people need - it’s your drive. It’s your willingness to learn. And also, it’s your willingness to say, “I don’t know enough, I will learn.”

Usually it’s that, that is missing from people that come from university. Because they can’t. They show you an end-of-year project of someone from university thy are great things. But it is not as [significant] as you would expect of someone that has years and years of experience.

But they challenge stuff. Usually come and say, “Look, I’ve done this project.” What do you expect? And there’s too much of a drive to try and show that they’re better than they are. That usually will put them in the wrong spot. That’s what I would say usually for a Computer Science degree.

It’s not needed, but if you’re able to have a good frame of mind, and actually know that you are ready to learn more, then the Computer Science degree will give you those conditions to actually get further up. Because as you reach a senior or an architect level, you need a real deep understanding of fundamentals.

I found myself in that level where I had to do loads of studying to catch up on the people who had the Computer Science -

Len: And did you find, when you’re becoming self-taught and you decided to try going down this path - you tell the story in your book, that you kept alive the possibility of being an accountant as well, at the same time as you were trying this out. Do you think that spending a few years in formal study, even if it was on another subject, was very helpful for you, when you were going down this path independently later, of learning, basically?

Simone: Correct. As soon as I say, “self-taught,” usually people reply and say, “Oh, that means that universities are useless.” I always reply that that’s not the case. Because what university does, they teach you how to learn. They teach you how to take ownership and complete tasks. They teach you how to actually be in control of yourself and your tasks. I do not feel university is the same.

You don’t have anyone next to you to say, “You have to study.” You don’t have anyone next to you, to say, “You have to get ready for the exam.”

It’s that self-learning, the end frame, the motivation - the more you go in the lab and get ready for study. It’s that drive, is what actually is needed in life. Then you can study Geography, you can study Physics or Computer Science. You need that. There is something to be taken out of university, for sure.

Len: I’ve got to say, I completely agree with that. It’s interesting though. I mean, in Canada, I think, there’s - you can split up the world into two kinds of people, an infinite number of ways - right? But there’s some people who just need or want more formal guidance, and there’s other people who just want, “Leave me the fuck alone,” right? I was definitely in the, “leave me the fuck alone” camp when I was an undergrad.

I did a doctorate in the UK. That was very different from the North American model, right? In the UK model in the university I went to, it’s just - you’re “all but dissertation” basically from day one. My joke was, you get there, and they’re like, “Welcome.” They fly you out like a little kite, and then they tie the end to a rock - and they walk away, and they come back three years later, and go, what have you got for me?” For some people, that’s absolutely the best thing. For other people, it’s - you come back, and the kite’s just in tatters on the ground five feet away, and it’s been there for two and a half years.

It can depend, but I would say, definitely I agree with you that one of the things that one can get from just a few years in university, is - having an environment in which it’s safer to learn how to learn on your own, and how to be independent, how to be a professional, right? You’ll learn in that environment that you shouldn’t be late with your assignments. You need to plan ahead. You should probably attend your classes. Things like that.

Simone: How to handle the clients. That’s something that you will get in work. The pressure of adding something that will need to be ready tomorrow. I like to mention, sending professional email, delivering to people that are professional. That’s needed, no matter what position you get later down the line.

Len: Yeah, definitely, definitely.

Typically the structure of these interviews, is - we talk about the person’s background and career and stuff, and how they got to where they are, which we’ve done. Then we’ll talk about their book. But sometimes the book is about their career and things like that, right? Two sections melt merge into each other.

Simone: Yes.

Len: Your book talks a little bit about how to begin a career in tech. I was wondering if you could talk a little bit about your experience with your first job or two, and imposter syndrome?

Simone: Yes, yes. That’s probably - as I say in the book - and, again - I don’t want to get to the book straightway. But I know that it is not easy to get. What I’ve done in the past year, is I’ve tried to help people that were probably in the same situation, where they were very driven. They wanted to learn.

I know how complicated it is at the start, to feel ready to actually go for work. I was really lucky that when I got my first position - not actually the first position, my second position - I had a few people around me, a few developers, that were supporting my growth.

There’s two different senior developers. There’s the senior developers that usually look you from the up/down - and show you how to do things, that show off.

Then there’s the other senior developer that actually sits with you and tries to explain. I was lucky enough to have two people - they were very close to me, they supported me in my career. But every day you wake up and you will always think that you didn’t know. Every day you will go to work, and you were not ready for it.

When I went from my first position to my second position, the imposter syndrome was really strong. Because every time you’d think, “Oh,” and - I know more, and they just have to go to the internet and do a little bit of practicing to say a question for interview.

You will never know the questions for the interview, and that brings you down. Or you meet someone new. For example, I always used to do lots of meetups, and I always used to go out and about when we were still able to meet then. Conversations would go on things that they would know. People were talking APIs. People were talking about the “backend server.” It was like, “Oh, I don’t know about that.” You will go slowly in the corner.

But it’s absolutely normal not to know, because there’s so much in it to be known, there’s no way for you to actually know all of it. It’s the understanding that, as long as you are okay to know what to be reading, and be happy to say what you know, that’s when you start the process you just have to go down.

I used to do a conference talk a few years ago, where there was this simple image of a very small circle, it is your knowledge. Then there were hundreds and hundreds of other small circles around. Sometimes your knowledge overlaps with someone just a little bit. Sometimes your knowledge doesn’t overlap at all.

But it doesn’t mean that someone else’s circle is bigger than yours. It just a misalignment of knowledge. With the book and with everything everyone will stand with for a bit, is - it’s trying to help people understand this overlapping of knowledge. Some people don’t understand it. But it’s only that they focus on what they know, and then help people with that - usually that’s enough to bring them forward.

Because if you start to compare yourself with the people around you, you’re stuck with, “I need to know HTML or CSS or JavaScript. I need to do server, I need to know how to apply.” Or, “I need to know backend.” People will start to do everything. But it’s not needed. You just need to know your circle, and specialize in that and grow it slowly.

Len: Thank you very much for that. It’s reminding me, there’s a - I thought it might’ve been in your book, but I was just looking here - I think it’s in a blog post, where you talk about your ten - I think it’s a very recent one, where you talk about reaching your tenth year in your career?

Simone: Yes.

Len: You have this chart, where there’s a line starting at the left at the bottom, saying, it’s how much you know, and your attitude towards it, right? The bottom left is like - you started going, “I know I know nothing.” Then the first peak is like, “I know everything.” Then it goes down again. As you mature, then you become, like depressingly overly realistic, or something like that. You go back down to the feeling that you had at the beginning, where it’s like, “Oh now I know how much I don’t know. As opposed to knowing there’s a lot that I don’t know, I know exactly how much I don’t know.” Then if you work at it, you can progress, and the line just goes up to the right.

Simone: That’s precisely the circle. You start to learn, you think you know nothing. You think you know everything. Then you get exposed to someone with a different circle, and you start to understand what you don’t know. You slowly expand your circle.

It’s something that I always tell people. It usually happens on your second year of experience, is the time where - the first, second year is when you reach the top. When you really think you know absolutely everything.

I still remember an interview with a junior developer. He came in, he had one and a half year’s experience. He came to the interview. It was like, “Okay, can you tell me, what are your experiences? What do you know about JavaScript or HTML?” He turned to me and said, “I know all the JavaScript and HTML you can. Everything.” At that, I completely stopped. I was like, “Wow, that’s amazing. You can tell me everything about the old API and the video API?” He was like, “No, I haven’t done that.”

They thought they knew everything. Because they just knew what to do, what they did in their own work. Then, as soon as you break that - you really go deep down, and think, “Okay, I don’t know everything.”

Len: One of the things that I think is so generous about your writing on this subject is that you’ve been through it. You know what it’s like, and the exuberance that one can express, and feel is quite natural when you’re gaining your sea legs, and you get excited. Like, “I’m not getting seasick and falling over all the time now. I can climb to the crow’s nest”. But there’s still a lot to learn when the first storm comes, or what have you.

You don’t so much talk about the negative version of this, but in order to progress in a career - and this is true in other things, not just in tech - but you can just coast, putting it negatively.

That’s perfectly fine if you’ve learned all you need to learn, and you’ve attained the job security you want, and if you’re making the amount of money that you want, and you see a natural kind of, “I’ll go up every couple of years in terms of the titles at my company,” or something like that.

No judgement, that’s perfectly fine. But if you do want to really do the exponential thing in terms of knowledge and career growth, you have to make a decision that you want to do it. You have to have the passion to do that.

You had a moment in your career where you - I think you tell the story, I think it’s either in the book or in your blog post? Where you’re like, “I sat down at the kitchen table with my wife, and I said, ‘In five years I’m going to be a tech -‘”

Simone: “I want to be -“

Len: And you did it. But you had to have a plan. I was wondering if you could talk a little bit about what that was like? You were probably thinking every day, “What can I do into my daily practice, to try and get somewhere in a couple of years?” I was just wondering if you could talk a little bit about what your thoughts were at the beginning about how to do that, and how they changed over time - until you did get your first tech lead position?

Simone: There wasn’t much thinking behind the agreement of, “I’m going to be a CTO in five years,” okay? It was probably my biggest ambition, and me really wanting to put forward. But like you said, there was a plan in going forward. What they usually do is - two things - number one - I think this should be important that everyone shows - you should always have someone, a role model - someone that you can look at. Someone that you always look at, and think he does something better than you do.

What I usually do in my work, if I’m a junior developer - I wouldn’t get the CTO or a senior developer. I will find another member of staff with a senior year experience that will be better than me, or a mid-developer. I will learn multi-task differently than to me trying to learn it. I will try to set myself those boundaries, and level up with them.

Let’s say, for example, I notice that he can take bigger tickets than I do, while I can just take a back ticket. I can see that when we are meeting, that person can drive and express more - and I cannot do it. I keep my eyes very open, no matter what this person answers. I do continuous learning, and continuously setting a self-standard.

And, again - they don’t have to be too far up or too intangible. Because you cannot be a junior developer, and say, “In the next six months I’m going to drive this differently.” You have to take something that is within reach, and it has to be in the short-term.

I have done this all my career. Mid-developer, senior developer. The guy that is very good at joining meetings. The guy that is very good, and the managers really like him, because he gets things done. Usually, try to see different things - a little bit of good from everyone.

But what is also important, is for me to stop and always think about where I was six months ago. I do that self-learning. But I also stop. Because sometimes when you always look forward, you feel like you’re never achieving. Because you always have something more to do, and something more to do.

The one thing, I usually do that as well with my - when I coordinate a project, I always like to do very small tickets - very small, tangible action. Because there’s nothing worse, when you’re every day for a week - you wake up, and you’re working on the same thing. You will feel demotivated. It’s really good when you go small tangible actions. If you actually change it, and say, “Okay, today we just are creating the recipe base. Tomorrow I’m going to read. The day after tomorrow, I’m doing the write.” You feel achieved, because you see the progress.

Sometimes in life, it’s not always easy to see that progress. If you stop and you think about yourself six month ago, you will find the progress. Because even if you don’t want to progress further, you will mature - even if it’s just a matter of age, and that maturity then brings you - it gives you more energy to think forward.

Len: One of the really interesting challenges of advancing in a structured, corporate environment, and deciding that you want to advance, is that you then need to be very concerned about how you’re perceived. Because when your advancement is based on other people’s decisions about you, and other people’s defending you or promoting you or attacking you, how you’re perceived becomes very important.

That brings up questions around honesty, which is a theme that runs through your work. There’s a really great story that you tell about how you’re in a meeting. This was, I think maybe, your relatively early days of being a tech lead.

A question was asked of you, that you were expected to be able to answer. You invoked, “Well, I’m going to have to ask someone.” It was someone lower down in the rungs, who wasn’t in the meeting.

Then there was a - “colleague” is a friendly word - but there was a colleague of yours who then said, “Simone shouldn’t be in his position, here’s the proof right in front of you.” I was wondering if you could talk a little bit about the choice you made to express the truth of the matter, and what happened?

Simone: When I become a tech lead, I raised my concerns with my wife, because I felt like I was not the right person for the job. The main reason for it, because I had three, four years’ experience - five? Some members of my team had over fifteen years, fourteen years’ experience. Some of them were in their thirties. Some were still in their twenties.

As you expect, as you just said right now - as you progress, you don’t always have to think about your bosses. But you also need to look over your shoulder - because there will be people again. You need to make everyone happy, and really try to answer the situation.

I always use honesty as my power, as my strength. I didn’t know until really late in time. That was probably one of the first occurrences. That honestly was actually what brought me where I was, okay?

For people that have not read the book - yes, I was told that I was not the right person, because I was actually not able to answer a question that was supposed to be a tech lead question. But truth be told, is that - actually the fact that actually I was able to address my weakness, to share my weakness in public, to tell everyone about my weakness, that was my strength.

Because we go back again to that - now after many years’ experience, your circle can grow, can get very big. But it’s never going to cover the whole spectrum. That means that you need to really be - if you’re honest with yourself, you will be able to say, “Look, wait a minute - my secret’s very big and it goes on the table with that side. But maybe we should actually go and ask someone else?”

Because that person - it’s a circle, it’s this whole circle. There’s absolutely nothing wrong [with] your expertise to be able to say that. Of course, you need to be able to get information, to learn from it. There will be times where that may not be possible. But that honesty - what that honesty actually was me really understanding what my circle was.

Me really understand what my code [?] - and by the way, it was a CSS question. It was as simple as a CSS question, but with a developer that was actually specialized and worked for years and years just doing CSS. Why should I make the decision on something, that someone else can actually make a better decision on?

This shows where the imposter syndrome can get away from yourself. Because you - if I’m able to say, “I don’t know,” I’m also able to say that, “I’m not hiding, I’m not hiding, and giving an answer that I’m not ready for.” That was probably the turning moment, where I was able to really -

It happens, many, many, many times after that. Because there are people that may want your position, and for people to want your position, they need to show that they’re better than you. There were many occurrences of this. But that was probably the first occurrences, where - the fact that my manager supported me, because they were the one actually who made me realize that I was - at that moment in time, I didn’t know yet. I think that was a turning point.

Len: Just so we don’t leave people with an ambiguous cliffhanger - in the very meeting after this person attacked you, then one of your managers came to your defense, and said, “No, the reason he’s here, is because he gave that answer,” right?

Simone: Correct.

Len: Interviews have come up a few times already, and we’re not going to give away the whole book - everybody should buy Beyond coding. But there’s a really great section in there on interviews, and for anyone listening, going into your first interview can be very daunting. You should definitely prepare. I was just wondering if you could talk for a couple of minutes about - If someone approached you and asked you, “Could you be my mentor for a little while, I’ve got my first interview coming up for a tech job.” What are three or four things you can think of that you would tell them, if you only had - let’s say one brief coffee or something?

Simone: It’s funny that you say that - I actually do that on Twitter. If I find people on Twitter that are learning how to study, or they say that they need to do a first interview - what I usually do is, I go through the feeds - if I can see that they’re really driven, that they’ve really tried - I reach out to them, and I have a coffee chat. That’s actually precisely what I usually do.

In order to answer the question, because it’s so - in the book, I go in many details. I’ve done many interviews. In my previous job, I think I’ve interviewed probably three, four hundred people. Because we’ve grown from being just five, to being a team of 130. I interviewed every single person, and we usually employed one person every five interviews. If you compare that to the, we had a lot of interviews there.

In my current position as well, I am also doing loads of interviews. That gave me a little bit of strength on understanding what the interviews - how the interview, hiring - how to understand if the person in front of you is good or not.

As I mentioned at the start of this podcast, if you are at the very start of your career, people will not look at what you really know. What people really are interested in is the way you learned it, how you learned it, and how eager you are to learn more about it.

If I would have to give one suggestions to anyone that had to go to an interview, it is, don’t go in and think you will succeed in the interview. But what you do, when you go there - every question they’re giving - if you don’t know the answer, ask more. Ask for a link to study more, and to learn about it.

If someone come to me to an interview who’s a junior developer, then I say something like, “Hey, do you know [?] processor?” They say, “No.” For me, it’s not a negative part. Because he’s junior, so maybe he doesn’t know that? We’ll find a different answer.

But if that junior then asks me and say, “Have you got a link?” Or says, “I’m going to go and check it out, because I think it’s important.” That’s the drive you need.

Because a junior developer doesn’t know everything, okay? When you join the company, the employees know that they will need to give support. If you show that you don’t really need hand-holding, but you just need some guidance, and that you do it by yourself - you are 50% of the way through. That’s the first and foremost most important thing that I usually say.

The second then is, finding the imposter syndrome. Always find people to specify in something. There’s one thing that - really disliking - when someone comes to an interview and say, “Hi, I’ve done hundred days of code. I’m a junior fullstack.” I wrote it in the book as well. Fullstack means that you got a little dot everywhere in the map. The circle.

What usually happen when people try to do that, is they got very scattered knowledge, and shortly they cannot really focus. Like when people say, “Oh, I know enough of HTML, so I’m jumping on JavaScript.” Well, you’ve done it for ten days; no you don’t. It gives the wrong impression to the person. So, again - you need to impress the person, and say, “I may have to learn. I want to learn. I’ve done enough, if you tell me what to do more, I will do it.” This is usually the only drive you need. Again, your answer can be wrong. You may not be -

Also - again, we go back to honesty. I think this is the last thing I’ll say. If you go to an interview, and you’re trying to answer the question, and you really don’t know - the person in front of you will realize. Because there are some - juniors don’t realize how much you really have experienced. So if someone asks, and you don’t know, and you try to give an answer from something that you know, the person fronting your test will know that it’s wrong. There’s a power in actually being honest in an interview. Because by saying that you don’t know, may actually give the interviewer a chance to ask a question that you may know.

Something that I usually tell people, is - if you don’t know something precisely - let’s say, again - you go back to [?]. If someone goes, “[?], do you know [?]” If I don’t know [?] by no less, instead of saying, “No, I don’t know,” I would usually say, “I don’t know that processor, but I’ve worked with this.” Or, “I worked with Tailwind. I may be wrong, but this is something similar?” This can drive the conversation.

Also, show your honesty in agreeing that you don’t know something. Because, again - the person in front of you will know. There’s nothing worse than having a junior that lies in front of you. Because if they lie there, they will lie on their work. But you want someone honest. Someone that can tell you when they need help.

Len: You have more experience interviewing than me, but that sounds like really good advice, particularly about honesty. It reminds me - this might be outdated information now, but back in the day, there used to be a rumor in the investment banking world, that Goldman Sachs had, notoriously, one of the most difficult recruitment processes. One thing that they would do, reportedly, was - there would be one interview where the plan was to corner you into a position, where they found something you didn’t know, and confront you with it. This is an environment where you’re supposed to know everything, right? Give the appearance of knowing everything. But they’d deliberately, and harshly corner you, to see how you’ll react, right?

There’s chest-thumping reasons to put someone through that. But there’s also other reasons to put someone through that. For example, if you’re working in the tech world, if you’re working for a consultancy, and there’s some company out there that’s looking for a consultant, and you’re competing with other consultancies - they send you to represent the company. You get asked a question that you don’t know the answer to, your bosses aren’t there. They’ve sent you off to try and get this contract. They’ve got to have confidence in how you’re going to react. I say all this, to say to someone who’s like - if you’re in an interview and you find yourself not knowing the answer to something, it’s important to understand - this doesn’t mean you’re a fool or you’re an idiot, or anything like that.

Treat it like - this will happen to me in my career, if I’m junior, if I’m senior, if I’m internal or external - it’s going to happen. You should think in advance about, how should I act? When you realize that, then honesty becomes the best answer, I think?

Simone: Correct.

Len: Yeah.

Simone: It’s funny what you said about “no matter experience.” That is - I love to listen to podcasts, and one of the podcasts that I listen is the one from Wes Bos - Syntax FM. Wes is a very well-known good developer. He knows a lot about React. He is a very well-known person around the industry.

What they do every now and then, they will interview where they answer question interview questions to each other. There’s nothing more beautiful than to see someone that everyone sees, and put on a - “This is a God, this is amazing.” Going and saying, “Oh, I don’t know that question.” It’s stunning, it’s amazing - and then people go, “Oh I’ve done this in my hundred days of code, don’t you know it?” But that’s the truth. People should listen to more. Because, again, he gives them perspective. And, honestly - he doesn’t try to give an answer, if he doesn’t know, he does not.

Len: Some of the advice you give - for example, when confronted with a situation. It’s like, what is that? It’s like, “Well I don’t know that, but here’s what I can tell you about something related to it.” Or, “Here’s what I was planning to read about just next week,” or something like that, right? And, “Here’s how I go about learning things when I don’t know them.”

I’ve got one, actually I like to ask these very specific questions. Because often the hardest advice to get is about the most mundane things.

But I’ve interviewed a few people, and we’re in the age of Zoom interviews now, right? Sometimes someone’s in a t-shirt and a ball cap, and sometimes they’ve got their suit on with a tie. When you’re interviewing people now, what do you expect their background to be - like the literal visual background to be? What would be normal for them to be wearing, that you wouldn’t really notice it? What would be something you’d notice and take note of?

Simone: It’s funny that you say that. We did a round of interviews a few months ago. We do lots of interviews. Usually, nowadays - I think going to an interview with the full suit and tie and well-dressed and hair done - it doesn’t seem to be expected, okay? I don’t know if it’s just for me? But you can even see on TV nowadays, lots of people, usually they go from their home. They’re not fully dressed as they were once, the normal process. Something changed there.

We did this interview where this guy actually showed himself up fully suited. We thought - joking - I actually thought - my co-worker was like, “Oh, this feels weird.” The reason for it, is because it felt like the person wasn’t really up to date with the industry. He wasn’t applying for a junior job, so I would never do that. But it was actually someone who worked in the industry and was trying to come in as an experienced person. He felt like he was - so, strange, it shouldn’t be the case.

Usually, also in the past - I personally never took notice of how people would come dressed up. The one thing that was very important, was meeting time. I think there’s nothing worse than someone has an interview at one, and comes at ten past one. Because if you really mean it, you’re going to be outside at least half an hour early. That’s the only thing that’s really mattered. But if you’re not well-dressed or anything, I wouldn’t say that it mattered. But yeah, don’t go full tie and things - I don’t think it’s the right time now.

Len: That’s funny, you just reminded me of a very old story from a cousin of mine. When he was applying for - actually it was an accounting job, his first accounting job. It was a relatively small firm, and it was winter in Canada. But he went in a suit. Because he was going for a job interview to be an accountant, right? And he gets there, and the three partners are all sitting there just in jeans and sweaters. You can imagine, it was obviously awkward from the beginning.

At the end of the interview, which went well, one of the partners good-humoredly said, “You know Tony, we’ve had this really good interview and you’ve given really good answers. But doesn’t it feel strange to you, for us to be sitting here in just jeans and sweaters, and you’re there in that suit and that tie?”

He had to make a decision. He took a breath, and he leaned forward and he tapped on the desk and said, “I wore this tie because I want this job.”

Simone: Oh wow.

Len: Everybody erupted in laughter, and it totally deflated it.

Simone: Yeah.

Len: It’s just another example of being honest. Like, well, “This is a bit awkward.” It’s like, “I wore a suit, because I want the job. I don’t know what else to say.” It might’ve been the wrong move, but the motive was right.

But anyway, those things can be very hard. I just want anyone listening to know - actually there is no way to know.

Simone: No.

Len: Just hold yourself to a high standard. Think it through. Maybe talk to people if you can. Reach out on Twitter to people and ask things like that. Often people are very willing to help and be nice about things like that. Don’t be embarrassed to ask.

Just to finish on this - another very specific thing that I think you say, that is very good, is, do research on the company before you go into the interview.

Simone: Yes.

Len: This is absolutely crucial. It’s not just that - like it might not come up, anything specific about the company. If it doesn’t, you should bring it up. Not just to demonstrate that you’ve done your homework, where you understand how the game is played and you’ve looked into it. But because you don’t want to work at every company.

It might feel like that when you’re looking for your first job, and I mean - of course, if you’re in financial circumstances where you need it - then you need it, there’s nothing else to say about that.

But some companies, you don’t want to work for. There are companies where there will be a - for example, if you buy what Simone says about honesty, there will be companies where that will be held against you. Where there might not be any - everybody in the meeting room might be, “Yeah, that’s right - he was honest about not knowing something, and that means he doesn’t know how the game is played and he shouldn’t have his job.”

And you should feel empowered in interviews to ask questions. Like, “What’s a day of work like here? I know that you guys worked on this project with this client,” or whatever. That’s both impressive to the interviewer and sets you apart. But it also shows that you’re serious about thinking about working there.

Simone: Yeah. Like you mentioned, you need to show that you mean it. You need to show that you want it, okay? It doesn’t just have to be a, “Oh, I’m going to have a walk for thirty minutes and do an interview.”

It’s - like I said about arriving half an hour early. There’s nothing more powerful that you go to an interview, and they tell you, “Oh you found the place okay?” You say, “Oh yeah, I’ve been here for half an hour.” Usually someone says, “Woah, that’s okay.” You then answer and say, “I didn’t want to be late.” That sets the standards for the interview that someone really means it.

Like I said as well, knowing the company - being able to share that you read about the company. Finish the interview to say something like, “Look, I really -“ Like you mentioned, it gives more insight about the company, and finish it on that note.

Say something like, “I’ve always wished to work in a company that does X, Y, and Z.” Say something that wasn’t mentioned in the interview, to show that you’ve done research. That’s priceless.

Len: When it comes to being on time, that reminds me - long ago, when I was looking for jobs in London, London, in particular, is the place where it might be hard to find the location. So, what I would do is - I would case the joint. I would make sure to go to the location beforehand, to find out, what’s the closest Tube stop? What’s the street to go down? It might say it’s on this street, but actually the entrance is on another street, or the sign might be above this door, but you actually need to go in that door.

These are the kinds of things that might seem like, “What does that have to do with a career in tech or finance or whatever?” But it’s like everything. It’s about being prepared. It’s not just showing it, it’s like, actually being prepared.

Simone: Right.

Len: On that note, just the last thing I’d like to ask you about your book, is that, near the end, you talk about the career path. S I was wondering if you could just give people a little description of what are the typical titles, and what’s the escalator?

Simone: This is probably better detailed for a software engineer, or for a backend engineer. But usually the path from this, okay? First and foremost, years of experience cannot be only driven for seniority. People usually tell you, “You need to work five years. You need to have X years,” Nowadays, things have changed so much. There are so many [?], the technologies are so fast moving - you can be a senior faster, just because technology is ever more than last time.

What you should say is - when you start your career, you expect to be a junior developer. What the junior developer is, and I like to - we do this in our current work, but I always like to define it: a junior developer is expected to know how to fix some bugs, is expected to know how to go and learn about things.

But a junior developer is not expected to be able to drive anything from scratch. A junior developer is that eager person that is learning. That person who is going through - usually, as I say, it’s the person that fixes things. The person that is able to get something that is being given to them - it’s already built or it’s half built, and he will do a small part of it and fix it.

As the career progresses - usually - then you may reach a stage where you are a mid-developer. A mid-developer is usually just called “software engineer,” or “developer” or “frontend.” The “medium” doesn’t really make sense in development environment. The mid-developer is probably from 70 to 80% of all the developers. Because the junior stage is a small stage. It’s the stage in which you are defining your circle of knowledge. Usually I would say a junior stays within six months to one year.

But if you’re very driven, then you can move forward - there’s no problem at all. As you move forward to mid-developer, that’s when the real learning happens. The learning is not just a technical learning. It’s also about working as a team. It’s also about being able to meet deadlines. It’s also about taking ownership, and then also being able to expand your knowledge.

What they say, is - the junior developer’s the one fixes the bugs. The mid-developer’s the one who creates, who can create small feature or tack. If the junior developer’s the guy that fixes the bug in the corner, the mid-developer is the one who creates a new feature. A new search feature on the website. You will have enough technical knowledge to do it. But it’s not just about the technical knowledge. It’s - he will be able to take ownership of that task and continue on with it.

We move forward, and we go to the senior developer. Senior developers don’t actually know a lot - senior developers, they’ve just been there before. What the senior developer is, is someone who’s done many mistakes many times, and have done it enough times to remember about that.

Again, we go back to honesty. Someone who’s able to know where he will be able to help, and when not. Usually a senior developer will be able to take ownership for more than just the task, but actually take ownership of the team as well.

As a senior developer, you should be able to support the junior developer. You should be able to set the standards that are available for everyone.

Also, there is usually a very - something that you see in coding, when someone moves from medium to senior - a mid-developer is then doing complex code, and does many things - the senior developer’s actually is the easiest code to read. It’s code that a four-year-old can see. Because the senior developer knows that it’s not about being cool, but it’s about being inclusive for every member of the team.

A very good senior developer, is the one that - when he writes the code, you go into the pull request, and you can read it through. The junior should be able to do a PR of that.

There’s this misconception that if a senior developer puts out a PR, so someone asking you for help - it’s expected that a junior should not be able to read your code.

But that’s, really - I think is the wrong misconception. Because a senior developer - if it’s a good senior, should write the code that even my child that is six years old should be able to read. Again, a senior developer should embrace it, and should bring that in forward.

I really dislike the “10x developer” or things like that. Because they don’t have meanings. If someone is really a driving star on everyone, goes beyond them - is just showing off. During Easter day on the 1st of April, I created a 10x library on my GitHub account. If you subscribe to that, you’d become a 10x developer now. A 10x is just someone who wants to get the pension. But a good developer doesn’t know that. The good developer wants to help the junior.

Finally, there is an architect. An architect actually goes completely behind, on something of technical knowledge, I think? The architect is more about many moving parts. Decisions that are not just driven by the code, but decisions that are driven by the company - by the budget, by people that they’re working with at the location. All of that comes with a lot of experience. You’re not able to become an architect in a year. But you can move forward [$here] 54:10 to collaborate, and you meet ? Very quickly.

I’ve seen people turning into seniors in three, four years - they’re very specialized. If you do a lot, you do too much - you’re not able to move quickly faster, yeah? If you try to have too many circles, you won’t be able to specialize. If you specialize in really just one thing, you’ve got more chance of moving forward faster. I hope I answered the question?

Len: Oh, you answered that question perfectly. Thank you very much, that was really great - I especially like your description of what a true senior developer or a good senior developer should code like. They should be past the point of being cool or being complex and hard to read, and realize that, “No, this is this whole team effort,” and stuff like that.

It’s actually really interesting - I mean, when you were talking about being an architect - one has to understand the things at the company level as well.

I interviewed someone a while ago, I think it might have been Gregor Hohpe who had this metaphor of - the architect is the guy who can go from Geordi La Forge to Captain Picard. He can go from engineering to the bridge, and he understands both sides. He can talk to both sides - or she, or they. But your description there - that was really excellent, I thought.

In the last part of this interview, if the guest is an author, we like to talk to them a little bit about their writing process and stuff like that. I noticed you used our upload feature, where you haven’t used Leanpub’s own writing modes and stuff like that, you’ve created your book completely independently. I was wondering if you could talk about what tools you used to create the book, like literally the ebook files?

Simone: Yeah, of course. Well, I’m a newbie. I would say if I go back, I made mistakes in the way I’ve done the publishing itself. I’ve actually created the books in Notion. I used Notion - and the reason why I used Notion, I was able to break it down all in different chapters. Even before I started the book, my first part of the book was to actually create fifteen to twenty different chapters.

Then, while I was working and I had a little idea, I would go into the chapter, and I would put bullet points in each of the chapters. I would do that in Notion.

I use Notion for my work. I use it a lot, with templates and everything. I found it to be very simple. Because I was able to access it from my computer, from my phone - from everywhere.

The writing skills within Notion are very similar to the ones that are offered by Leanpub because it’s all in Markdown. What I usually was able to do - I was able to do half a chapter an evening, every evening. I was able to go back - and again in Notion, I was able to have a list where I’d say if I had written it, if I’d reviewed it, if I’ve asked someone to review it. I was able to kee those notes between myself.

The thing that I was not fully aware of is that Notion offers you too many Markdown options, that are not very supported by many people. At the end of the chapter, I always used to do this little graphic with icons, and then I would just do other things. Very simple to do in Notion, very hard to do in other tools - Leanpub is one of them.

I started to move my Notion into Leanpub, and I started to address it - and then I realized, I was honest with myself: “I don’t know what I’m doing.” I’m spending loads of hours. I was able to do a chapter every night, or every other night. I was spending nights and nights, and I was doing it - and there were mistakes, I didn’t know how to do it.

That’s when I stopped. I know that is not my expertise. It’s not something that I want to learn, because I’m not going to write a book every day. I actually went to fiverr.com and I gave the Markdown to someone and said, “Can you make it into a book?” It was turned into a book for me for, I think, $30. That’s what I paid.

Again, for me there’s $30. I spent way more in hours and effort trying to do one chapter. It was like, “It’s fine, it’s fantastic.”

But if I would go back, I would probably do a little bit more learning on what Leanpub will allow. Because what I wanted was a Markdown editor. I know as well that Leanpub offers the possibility to write in a GitHub repo - if I’m not wrong - going to Dropbox, so I would have been able to do that. Because my misunderstanding, I tried to be too cool - so I’ve added too many things. Again, I realized when it was too much, and offset it.

Len: Thanks very much. That’s a really great answer actually. That’s one of the reasons we really like to do this segment in the podcast, is for other people who are starting out, or who are learning things on their own. Everybody learns everything for the first time for the first time, right? Once you learn when to fish and when to cut bait, as it were, and sometimes handing it off to someone else who already knows how to do it, if you’ve got the money or what have you - is the best thing to do.

Other things to do is then think about, “Well, what would I do differently next time?” and all that stuff. But that’s a really great - it’s in some ways the typical resourceful author path that you took there, I would say.

The last question we always like to ask, is - if there was one magic feature we could build for you on Leanpub, or if there was one terribly awful broken thing that you found that you would ask us to fix, can you think of anything you would ask us to do?

Simone: I love the whole flow of being able to add it. It’s very easy to set up the author, the book and everything that’s around it. That’s been fantastic. I know that no one actually complained, and people that bought the book, and everyone that went through the flow.

As an author, what was complicated for me was - when I was trying to import the Markdown from Notion to Leanpub, there were errors. When I was trying to build it, it would say, “There was an error in building.” But it didn’t tell me what error. That’s why it took so long. Because I had to take all the parts out, publish it again - no.

Then what happened is that I was doing lots of changes in the Markdown, Leanpub - and then they were different from my Notion. Then I wasn’t able anymore.

I think one foremost is give more guidance of what is going wrong when you build it. Because I think I’m not the only one who used a different Markdown [dialect], and I may be wrong in that.

Then also, what I probably - the same thing that they use in Notion, so the ability for people to build up the books slowly would be very useful. What that means probably is being able to pull the notes section - where you can add a list and a sub list, and then you can cross them off as they do them. I think that’s something else that would be very useful.

Because at the moment, I don’t think there would be an easy way. You can do it as you write it down, but you won’t have a visible list.

An example would be - as they remember, “Oh, I need to mention about that time that my manager said -“ They would write those things down. As they’d write the book, it was like, “Oh, this is good now and I will take it.”

Again, but I’m a newbie writer - so I don’t know if anyone else would actually use it.

Len: Thanks very much. Those are really great suggestions, and a really great description of the difficulty. Yeah, Leanpub books are written in something called Markua, which is basically Markdown for books. It’s different from the Markdown that you might use in other apps and stuff like that, that might have their own specifications.

So if you’re starting from scratch, if you’re starting a book brand new in Leanpub, writing in plain text and Markua - then you’ll just go, “How do I do this? Oh, I’ll go to the manual and I’ll search for it, I’ll do it that way.” If you’ve already written the book, getting it into Leanpub does mean then you’re just going to have to curate it, to make it match Markua’s specification and rules, and stuff like that.

That’s actually one of the reasons that we built the Upload writing mode we used to call it “Bring Your Own Book”, as in “bring your own beer.” But like we used to call it, “Bring Your Own Book”, because people would be like, “Hey, I’ve written a book, and by the way, I’m a programmer, like I know how to do stuff. But I don’t want to have to redo everything just so I end up with the same result. I’ve already got my ebook file.” Like, well, how dumb are we? Let’s just let people upload their books. That’s what that exists for.

With respect to errors- so for anyone listening who hasn’t used Leanpub before, if you’re writing in one of our writing modes, you write in plain text. Then you click a button to create a preview. You can get PDF, EPUB and MOBI and web - and just privately to you, to see what’s it look like.

If our book generators fail at a certain step, what we don’t have is expressive error messages. You can turn on some error messages, but if you’re not very technical, then it won’t be very useful - and even if you are, they won’t be very useful. They’re there for some power users.

But having expressive error messages that say like, “Line this failed at -“ Even if it’s like, “Something at line 52 in file 123.txt, is where the error happened,” would be very helpful - and that’s something that we know, and it’s something that we’re working on.

Simone: Even a thing like, as you write it, it tells you, “This is not supported.” That could be as easy as that, even before you do the preview.

Len: Yeah, that would be really great too, and that would definitely be in the future.

Then when it comes to structuring, like notes and stuff like that, that’s definitely something that we don’t have features around either. We do know that there - I’m very much a structure type person. I like to have an outline in advance and stuff like that and for people like that, there’s - I don’t know - you have Notion or Scrivener and Evernote, and all that stuff. Someday future Leanpub may have something like that but that.

But it would be - lots of authors use things like that, and that’s something down the road. But we definitely understand the need for it.

Well, thank you very much for those great answers, and for the great interview, and for taking some time out of your evening to talk to me and to talk to our audience.

Simone: Thank you so much for inviting me, it’s been great. I’m happy that I was able to answer all the questions.

Len: Thanks a lot.

And as always, thanks to all of 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.