In this Episode
W. Jason Gilmore is the author of the Leanpub book Easy Laravel 5: A Hands On Introduction Using a Real-World Project. In this interview, Leanpub co-founder Len Epp talks with Jason about some of his favorite projects from the past few years, including the creation of a system for predicting what books a publisher should be publishing, and a couple of really cool services built using the Laravel PHP framework, Jason's latest job as the CTO of DreamFactory, and finally they discuss the most recent update to Easy Laravel 5.
This interview was recorded on August 27, 2018.
This interview has been edited for conciseness and clarity.
Len: Hi I'm Len Epp from Leanpub, and in this Leanpub Frontmatter podcast, I'll be interviewing Jason Gilmore.
Based in Ohio, Jason is the bestselling author of a number of books, including, Easy Laravel 5: A Hands On Introduction Using a Real-World Project and *Easy E-Commerce Using Laravel and Stripe: Selling Products and Subscriptions.
He's also a popular author with hundreds of articles published online, and the co-founder of the very popular CodeMash conference.
In this interview, we're going to focus on what Jason has been up to in the last few years since I first interviewed him for this podcast, and we'll also talk about his latest updates to his book, Easy Laravel 5.
I should mention that this interview is part of a series of interviews that we're doing to mark the 2018 Laracon EU conference in Amsterdam, which Leanpub is a minor sponsor of this year.
So, thank you Jason for being on the Frontmatter Podcast again.
Jason: Thank you very much for having me Len, I appreciate it.
Len: Normally in these interviews, we talk about the author's personal and professional background, but in this case we've already covered that ground in a previous interview.
So, I thought I'd just ask you what you've been up to in the last three years? Could you talk about some of the projects you've been working on? I know you worked on a Rails project for an app for the interior design industry.
Jason: I did. Since we last spoke, I've worked on a number of projects.
Just a bit of background for the listeners. I spent the majority of the last 20 years working as a, an independent contractor and consultant, spending the majority of that time working on web-related projects, primarily pertaining to e-commerce, but also doing some analytics work. And more recently, work in the telecom industry.
Since we last spoke, I think I've worked on perhaps four major contracts, one of which was, in fact, a Rails project for a great architecture and design start-up called the Gather app.
What the Gather app is, it's a SaaS, and it focuses on the architecture and design industries. What it does, is it allows these interior design firms, these architectural firms, to manage all of their project assets in a single location, and then provide their customers and teammates with easy access to those, so they could comment on the different assets, such as the type of material being used for a wall, or what types of chairs might be placed in a particular room.
So it's a project management application, but it's also an asset management application. It allows these companies to better manage these projects in a highly visual way - which of course would be very useful for those types of companies.
Len: And could customers interact with this as well? So if that design company had a client, could they show the client designs through the app, and things like that?
Jason: That's exactly right. There was a significant role-based feature, in which the companies could invite their customers to join a project. In doing so, they are provided with access to the project descriptions, the assets. They can add reviews and comments regarding these different assets, and ultimately it just helps the project flow much easier, because no longer is the firm and the client required to constantly meet in person to look at either versions of the assets on paper or on a laptop. They can instead just share these project attributes at will, by way of the app.
Len: That sounds like a really good idea. I have a friend who obsessively spent a couple of years designing a house from scratch. Talking to him about it, from the beginning of the design to the final construction of the place - it was the interactions with all these different people that he had to do in person that was one of the hardest sort of aspects of things to manage.
Jason: I would certainly imagine so, particularly given the highly visual nature of that project. Of course you want a wall to look a certain way, or you want a lampshade to be a certain color. So it certainly helps to have everything placed in front of you in this electronic format, which you can return to and comment upon, and make changes as necessary. So it's a great product. It's thegatherapp.com. I'm sure we can include the link in the show notes on this, anybody wanting to check it out.
Len: I'll definitely add that. We were talking before this interview - you also worked on what sounded like a really interesting project, working on an e-commerce analytics application for a globally recognized publisher. I was wondering if you could talk a little bit about that really interesting project?
Jason: Yes, this was another pretty large project that went on for quite some time, and really was probably one of the favorite projects that I've worked on throughout my career. So as you well know, working in the publishing industry - it's very beneficial to a publisher to be able to accurately predict what topics are going to be naturally of interest to readers, and that's a very difficult task to do as well.
In another life, years ago, I actually worked as an editor for two different publishers. We spent a lot of time trying to make these predictions. And you would of course do so by talking to people in the industry, and doing quite a bit of reading online, and basically attempting to fit these pieces of a puzzle together. Which, ultimately, hopefully give you an idea as to what the market for a particular book topic is going to be down the road.
When I say "down the road," typically you're looking at anywhere between six to twelve months for the particular type of books that this publisher published. It's also a very time-consuming and costly process to put these books together. So you want to get it right more than you get it wrong, I guess is what I'm ultimately saying.
So what we did - and this was very much a mad science experiment, I guess - what we wanted to try to do is figure out if we could grade topics, and effectively assign almost like a credit score to a topic, in order to determine its worthiness down the road.
We wound up tracking - I believe the number was 10,000 topics by the time the project was made available, or the application was made available to the editorial staff.
And we did exactly that. We graded each topic, and we did that by mining the web. Whether it was Twitter or - Amazon was a big data source of course, because you wanted to know what similar books, how they were doing. Really any related online data source that we could monitor, we attempted to do so.
We brought all of that data together, and a lot of it we pushed into a Neo4j graph database. That allowed us to make connections that were otherwise very opaque. If one of us as a human was staring at all of this data, it wasn't obvious at all a customer who purchased book A, whether they were going to be interested in purchasing a completely unrelated book C or book D.
All of that data combined with a Neo4j database, did a miraculous job of helping us ferret out those interesting relationships - and really did have a positive, I should say - I certainly hope the project's still ongoing now, and does have a positive impact on that editorial staff's ability to make those decisions. It was a very fun project, very fun indeed.
Len: That sounds really fun and just really fascinating. It reminds me of a blog post I read recently. I think it was from a little bit, a little while ago, but it was by someone who blogs about self-publishing, and his post was called, Please Don't Buy My Book.
What had happened to him, was he was self-publishing on Amazon, and Amazon has this feature called "Also Bought," which anyone who's been on there is probably familiar withit. Like, "Other people who bought this thing you just bought, they also bought this other thing." And so what this author had done, was he had done what one conventionally thinks is the right thing to do. When he launched a book, he told all of his friends and family about it, in order to boost sales.
Unfortunately for him - let's say, I forget exactly what it was, but let's say he wrote a book about vampire werewolves. None of his friends and family typically bought vampire werewolf books. And so when they all jumped in and bought his newly published book, it sort of scrambled Amazon's algorithm. It buried the book, because it looked like this book wouldn't succeed, because there was no kind of coherence to the community of people that were buying it.
Jason: I'll be darned.
Len: You were just making me think of how interesting it is that with all this sophisticated analysis of data going on, if you're pitching a book to a publisher, and they've got a tool like that, but you don't have any transparency into it - I'm just thinking about this from the perspective of an author - it might seem like yet another barrier to getting a project accepted. Was the publisher communicating the information it was finding to potential authors?
Jason: I don't know. I don't have any insight into that. Just reflecting back on my past experience as an editor, you certainly drew upon as many data sources as you could. Because you wanted some analytical backing regarding your decision-making process.
But at the same time, a lot of it was intuition. Will this particular author do a solid job of putting together this particular book? Do they have enough expertise? Does the topic seem like it is going to resonate with a minimum number of people that would make the project economically viable?
Sometimes those decisions are - I think it's more of an art than a science, in some cases. You're just relying on past experience and intuition to make those decisions.
If anything, I would imagine, it played some role, but I really doubt it was the final word in the decision making process, to be sure.
Len: Thanks for that really good answer. It's interesting - a lot of people sort of fetishize computer technology, and think - well, now that decisions are behind algorithms, that's somehow categorically less fair or more arbitrary than it was before. And it's like no - in the past, it was often personality. It was what mood a publisher was in when you pitched them an idea. Things like that might have been much more likely to drive decisions. And actually in many ways, having tools like the one that you built driving decisions, can actually make things more fair and objective even.
Jason: Absolutely. The book business is in many ways no different than the movie making business or the music business. You're attempting to gauge consumer taste and interest, right?
That's a very fickle thing to attempt to discern. Some publishers and producers seem like they get it more right than wrong. But they're certainly in a minority. They're all tough businesses to be in. So of course you look for any way to make those decisions better, and to make them more effectively. I think hopefully that tool wound up doing that. But regardless, it was a lot of fun.
Since we've got a little bit of a Laravel theme going on here - there are a couple of projects that you did in Laravel that I wanted to talk to you about, that sounded really cool.
When we were talking before this interview, it reminded me. I was interviewing Taylor Otwell, the creator of Laravel, just a couple of days ago, and I asked him, "What's the typical product that Laravel is used to make?"
And he said something like, "You know what? There are just so many, I can't pick any example out from the ether." And he talked about a couple of really interesting applications he'd seen using Laravel - one of which included an app that was used in the airline industry, that pilots used. I thought, "Wow, that's just amazing that something that's open source is being used for that."
I mean, that something like Laravel was being used for that kind of application, and how mature it must be regarded to be used for something like that.
You worked on a project that involved robocall blockers, which sounded really interesting to me. If you could talk a little bit about that, that would be great.
Jason: Absolutely. This was certainly high on my favorite project list. The robocall blocker is called, Nomorobo. So, "no more robocalls." The company was founded by Aaron Foss. I wound up working with him for two and a half years on the project, and now we're great friends.
Aaron has just come up with this ingenious way, frankly, to stop robocallers. Much of the technology used in this detection and prevention process is Laravel.
So Laravel, and we use Lumen as the API - the mobile API is better used for the iPhone application and the Android application. We also use machine learning to determine - So, there's a large honeypot that is running. And that honeypot is picking up these robocalls, quite a few of them to say the least. We use machine learning to determine whether it is a robocall that's being made to one of these honeypot phone numbers, and then to classify it.
The robocalls are classified into, I believe, 39 different categories. Because the honeypot contains phone numbers with area codes all over the United States, you can actually determine in real time whether there is, for instance, an IRS scam that's going on in a particular city or a particular area code. And from that, you can start to sort out all sorts of interesting things.
That whole project, the vast majority of it was built atop Laravel. Lumen, it handles a tremendous amount of traffic. It integrates with certain telecom APIs. The metadata is distributed out to various third parties. It's used within the iPhone and the Android applications, and was really a lot of fun to work on that project.
It was also, frankly, very gratifying. Because some of these phone scams were actually quite dangerous to the call recipients. That IRS scam's the best example of one, because there are plenty of people out there who are falling victim to these IRS scams. They're sending these scammers money, and it's created quite a mess. There's also a lot of health insurance-related scams out there as well.
To be able to play a small role in helping to stomp out those robocallers on a nationwide basis, was very gratifying, and I was very glad to be part of that project.
To be able to play a small role in helping to stomp out those robocallers on a nationwide basis, was very gratifying
Len: That's a fascinating idea. I had not thought of the idea - it seems obvious once it's said, but the idea of having a honeypot out there, which I imagine was a large number of phone numbers that were probably made available to be found by scammers. Were there any human beings actually answering any of those calls to the honeypot?
Jason: Not sure I can get into any of that.
Len: Okay, fair enough, fair enough.
Jason: A little light on the details pertaining - that.
Len: That's fair enough. You were just reminding me of a friend of mine, who, whenever he got a robocall - where it was one of the calls where as soon as it realized there was a person on the other end, then you'd get switched to an operator who would try to scam you. And he would deliberately, just kind of pour himself a glass of beer, and try and waste the person's time for as long as he could possibly get away with it, until they until they figured it out.
Curiously, they would always get really angry as soon as they discovered that the other person was screwing with them. I don't know, I just found that fascinating, about the personality of the kind of person who goes out and scams like that - and then gets indignant at their own time being wasted by someone they were trying to trick.
But yes, that sounds like very good, and I imagine very interesting work. Because in security-related work like that, the bad actors are always adapting. They're watching your techniques and your tactics.
Jason: That's certainly correct. I would imagine anybody - at least in the US, and I would imagine Canada as well - who receives robocalls on a regular basis will recognize the change of tune that I'm about to describe.
One of the latest strategies is "neighbor spoofing," is how we referred to it. It would be - you'll receive a phone call from a number that looks like your own phone number. So the area code and the first three digits are identical, and then the last four digits are almost exactly like your phone number. We believe the thinking there is that it, because it looks like your own number, you're just concluding that's somebody who you know. Because they're in your area code, they have your same three digits, and the thinking is you're more likely to pick up the phone.
Certainly the robocallers do adapt their strategies in an attempt at, well, being more efficient at what they do. So hopefully, not only Nomorobo, but hopefully the other call-blocking solutions out there, are doing a good job of detecting and then adapting to those problems. It's a tough problem to solve, and largely a 21:10 thankless task, believe it or not.
Len: Well, thank you from me, and I imagine many, many listeners to this podcast for that kind of work. We all very much appreciate it.
You also mentioned that you worked on a Laravel project for an intranet in South America. I was wondering if you could talk about that project?
Jason: Sure. It was another great project. It was an intranet application for a large agricultural concern. Their primary products are, if I recall correctly, avocados and grapes. So they're a large avocado and grape grower. And they approached me with this great idea about building an intranet application for food management. The company owner was an incredibly smart guy. He taught himself programming. In fact, he had started building this app, and was looking for assistance.
So they contacted me, and we set about this months-long odyssey of adding as many management features as we could to the app. Everything is-Laravel based. By it's conclusion, we were managing fertilizer application records, farm equipment management, payroll, vacation, information about different sectors of the farm, in terms of what crops were planted there. We plugged into real-time weather sensors, that were spread throughout the farm, in order to provide real-time weather data associated with each sector.
Let me think, what else? We were calculating the - comically I don't know the English word for it, because I learned a lot about the farm in Spanish - I don't speak Spanish. But the Spanish terms for different things, the evaporation rate, I guess it would be, of the watering.
So, if the sun's at a certain angle and the temperature's at a certain degree, then the application of water changes. Because of course it evaporates either faster or slower.
We actually added calculators for making those sorts of determinations based on the information that was being fed in from the weather sensors. Great project, great company - and it was a lot of fun - another one of those projects that, although it was of course just internal to the farm, was having a major impact on their business.
Those are the fun projects. Because you know that all of this hard work is really, really being put to good use.
Len: It sounds really interesting. I've read a little bit about, I think, what you're describing. The way technology is transforming farming in particular, with respect to micro-climate data collection and analysis, so that farmers can actually know how different parts of the very same field, should be managed, based on things like elevation.
I grew up in a farming community. And so you always knew, farmers knew that, "Oh, that part of my land behaves this way during this part of the year. And another part of my land might behave differently at the same time of year, or under the same circumstances." But now, people can collect data on like every couple of square meters, as I understand it?
Jason: Yes, absolutely. Anytime I walk into a grocery store, I will never look at avocados or grapes in the same way, because I have a deep appreciation for the incredible amount of work that goes into growing, and then of course harvesting, and then transporting those, or any type of crop. Hopefully that internet application is helping them do it at least a little bit more efficiently.
Len: I don't recall exactly how recently it was. But you're now CTO of a company based in Silicon Valley, called DreamFactory. I was wondering - before you talk a little bit about your role as CTO, if you could talk about what DreamFactory does, and how you came to be involved with them?
Jason: Absolutely. DreamFactory is an API automation and management platform. What it does is it natively supports somewhere north of 50 different data sources. For example, MySQL database or an Oracle database, or the Amazon S3 file system. What it can do is generate REST API's for these data sources in literally seconds.
So if you enter an associated set of credentials for one of those data sources, it will turn around and generate a REST API for you, fully documented by way of automated Swagger documentation, that's generated along with the API. Secured by way of, at minimum, requiring an API key. And going beyond that, if you want user-level authentication, you can easily bolt on either basic auth or ELDAP, or active directory, or single sign on.
In a nutshell, what it does is it turns what used to be - and still is, if you're doing it manually - an incredibly tedious and error-prone process associated with writing these REST APIs yourself. It completely removes that. It turns it into a turnkey process, there's no code required. Literally within minutes, you can go from no API to a fully documented API - secured, that you're now starting to integrate into a client-side application.
To think of these APIs as certainly very important plumbing for your application - because you need to talk to these underlying data sources. It does all of that plumbing for you, and it allows you to instead focus on the more important customer facing aspects of your application, such as the UI, the UX and so on.
Len: And did they approach you, or did you approach them for the CTO position?
Jason: It was just one of those wonderful coincidences in life, I guess. They had approached me to just do some contract work. That went very well, and we hit it off. It was great to work together. Basically that contract morphed into a longer-term contract. And before you know it, I think it was pretty obvious to everybody that we enjoyed working together, at which point they invited me to join the company as the CTO.
I think I started the end of May. It was clear from day one that I had made the right decision, because I'm having more fun than I've had in a long time, working with and talking about DreamFactory. It's a great, great staff, and we're working very hard every day to build the best API automation and management platform out there.
Len: Speaking of staff, so as I understand it, DreamFactory is based in Silicon Valley, and you're all the way over in Ohio. Is that correct?
Jason: It's correct that I'm in Ohio. DreamFactory's actually based out of Las Vegas now. So that's probably something we need to update on the website.
The company was in California, and now it's based out of Vegas. But you're correct, I'm in Ohio and our CEO is actually based in Australia. We have support staff and sales staff both in Vegas and California. Like so many companies today, we're largely remote, and it's working out fantastically. It's working out really, really well.
Len: Do you have any particular techniques that you use for remotely managing the team, or interacting with the team?
Jason: We do, it's very simple. Like so many other companies out there, we're on Slack, and communicate quite a bit throughout the day via Slack. Not so much on the text side of things, although there certainly is that. But we do hold quite a few calls over Slack. That seems like it's working out very well.
Of course, like any software company, we have an issue management system. We use Jira for that, to make sure that that's regularly updated and taking full advantage of Jira's various capabilities.
That's about it. We keep it simple. The use of both just the audio only and the video call capabilities of Slack, allows us to work as if really we were working in the same office together. So that's been very advantageous.
And of course, like so many other companies who have adopted remote working, it allows us to find fantastically well-suited candidates to join the company - no matter where they live. Because it's just really not that - I was going to say, "Not that big a deal." But it's really not an issue at all for us. It's worked out very well.
Len: It's really interesting. I've spent a fair amount of my time working remotely. This might date me a bit, but things have changed quite a bit in the last 10 years - quite dramatically, with respect to the easiness of remote working I would say. Particularly, you were mentioning video. It kind of just works now.
Len: In a way that it didn't in the past. And so you can have natural, easy, switch them on, switch them off conversations. Just like you could in the past, by walking up to somebody and saying, "Hey, do you have five minutes?" Or something like that.
There's something qualitative, at least in my observation, that sort of changed just in the last few years, where it crossed that last mile that it needed to cross, to being really easy to get that done, so that it wasn't tricky and didn't fail.
Jason: I completely agree, and just referring back to Nomorobo - and Aaron, the company founder. I had mentioned that Aaron and I in the years since I started working with Nomorobo, have become great friends. And this despite me spending 99% of my time working from my home office here in Columbus, Ohio - and Aaron working out of an office on Long Island.
But almost every day during the time we worked together, it was conducted - actually at first over Skype, and then the company adopted Slack at some point. But we were on video call almost every day, Monday through Friday, just discussing various ongoings with the company.
We did not meet in person, I think - I know it was for more than a year. But we finally did get together, actually in Cincinnati, just south of me.
You'd have thought we'd been working in the same office together the whole time. There was nothing to it. Very natural, it was just like we were working like we had any other day.
But you're right. That was the first client that I can really recall - so that started in '15, where we regularly used video calling every day, because it had gotten so much better at that point. Whereas in the past, it just never seemed to quite work. And you're right, it has a tremendous impact on the quality of working remotely. Because, again, you're seeing your colleagues on a regular basis, and it just has changed things for the better, quite a bit.
Len: It's really interesting, one of the analogies I use when trying to describe technologies crossing that threshold is - imagine if you had a hammer that just didn't work 10% of the time?
Jason: That's right.
Len: You can't forget about the hammer if it doesn't work 100% of the time. If it works 100% of the time, you can actually forget about it - the technology, as it were, fades away and you're just doing your work.
I mean obviously chat has worked for a long time. But something about the combination of video, and the very particular product, Slack, has made it just so efficient and natural to work together across these vast spaces, that we don't even notice that we're doing that anymore.
Len: Moving on to your book, Easy Laravel 5: A Hands On Introduction Using a Real-World Project. I know you did a pretty big update in February this year. I was wondering if you could talk a little bit about what that update was?
Jason: To the listeners out there, as Len well knows, I love talking about Leanpub. Because the ability to write and update these self-published books with Leanpub, has just made it so, so much easier to do.
From the time the very first edition, if you will, of the book was published back in 2015, I have made hundreds of updates to the book.
So of course, all of my self-published books are on Leanpub. From the time the very first edition, if you will, of the book was published back in 2015, I have made hundreds of updates to the book. I manage the book on GitHub. I make my changes, I push them up to Leanpub.
It's a very convenient process. And in doing so, I can fix bugs and improve wording and change code, etc. in a very fluid fashion.
What I like to do on occasion, and I've probably done this - oh, maybe half a dozen time - is I like to roll out a more ambitious update to the book. The most recent ambitious update, came back in February of this year. That update included a number of changes and improvements. I think I added two or maybe three new chapters?
But more importantly, and more significantly for readers, I completely revamped the companion project that's associated with the book.
With all of my recent books, I am very much a proponent of the reader learning by doing. I don't know what this number is, but o the certainly more than 10,000 reader emails I've answered going back 20 years now, probably the number one question is, "What should I build?" And I don't have an answer for what a reader should build. So I try and help them answer that question by providing a companion project.
Len: And in this case, it's the HackerPair project.
Jason: That's exactly right. So in the February update, I ripped out the old companion project and replaced all of that material with a new companion project called HackerPair. HackerPair was this idea I had. It's almost like - you can think of it as a social network for tech learning and teaching.
So if you are really into Python or Rails or what have you, you can indicate on the demo site - it's just a demo project - you can indicate, "I would like to teach Rails," or, "I would like to teach Python, and I'm in this particular city or zip code." Or then, somebody who wants to lean Rails or Python or what have you, can do a search for individuals willing to teach on that topic within X miles of said zip code.
What a project like that does from a teaching perspective, is it incorporates many of the most popular Laravel features - user authentication, registration, database relationships, forms integration. In the case of the radius-based search, it integrates - I think it's called the haversine equation into one of the models.
So it provides a lot of opportunity to introduce Laravel features, by way of a project that is something that you might see it a real world. So that was the major update in the February release.
Len: I see on your web page, easylaravelbook.com/purchase, where people can go to buy the book, you actually offer three products for sale there. One of which is the book, one of which is the book plus videos. And one is the book plus videos, plus consultation. This is a model we've seen other authors use. How have you found this has worked out for readers? Do you get quite a few buying the consultation package?
Jason: Relative to the number of books sold, no - it's a lower number. It's a more expensive option. Not everybody needs it, etc. However, it has proved to be a tremendous marketing tool for consulting and development contracts.
For instance - so this is all bringing everything full circle. Nomorobo - I met Aaron because he purchased the consulting package, so I could have a look at a particular bit of code that he was working on for Nomorobo.
The agricultural contract came by way of the company owner's purchase. I think he had purchased actually two hours' worth of consulting. The time spent with him was teaching specific - I was teaching him Laravel. And in both cases, it was just kind of a natural fit to work together. We got along well. And the next thing you know, both of those purchases turned into consulting and contracting engagements that, in the case of Nomorobo, spanned almost three years.
So it's a great, great tool and I recommend that any Leanpub author who spends time doing contracting, consulting - I absolutely recommend they do the same. Because it's a great way to meet at least some of your readers. It's a great way to - obviously you have a great upsell of course, with the package. And it's a potential way to land new consulting and contracting projects.
Len: That's really a great story. You've reminded me, if you'll indulge me - my co-founders Peter and Scott once landed a very big client who we worked with for many years, ecause one of the clients' employees had pirated one of Peter's books, and had pirated one of Scott's books. And then they realized that they both worked together. And that's how we got that big client.
And so, I just wanted to add that in addition to selling books, it's just so important to understand that being discovered, somehow, is the most important thing for getting clients and building your profile.
Jason: Absolutely, yes. And as I mentioned, I've worked in publishing in years past. And so often you hear individuals - most of whom comically or coincidentally have never actually written a book - say, "Well, there's no money to be made in tech publishing." And the most accurate answer to that is, "You're right." If we're looking at this from a pure royalty perspective, a pure sales perspective - at least by way of traditional publishing. Only - I don't know? 8 to 10% - and I guess I'm making a little bit of a generalization here, but it's based on past experience - only about,- let's say 10% of these books actually make a significant amount of money. Many others either break even or, frankly, they lose money. But now of course, that completely changes from an independent publishing perspective. Because your margins are so much higher.
But leaving all of that aside - leaving the sales aside, the royalties aside etc. - you greatly increase the likelihood of, as you just mentioned, being discovered. And whether you are seeking full-time employment with a company, or you're seeking new contracts or consulting engagements - well, there's a lot to be said about hiring somebody who "wrote the book" about the topic.
In all honestly, by way of writing the book, you learn a heck of a lot more about that technology than you otherwise would have. Because, of course, it's so important to get it right for the reader. You want to make sure that you're accurate and you're presenting practical information. So, you become much more proficient in that topic, by way of writing the book.
And then in return for hopefully all of that work you've done researching, writing the book, you earn more exposure, and wind up talking to a lot more fellow programmers and companies and organizations than you otherwise would have, if had you not written the book.
So is there money to be made in writing a tech book? The answer is absolutely, yes there is. It's just not going to all come from a single source, like mainly sales.
Len: Thanks for that really great answer, I couldn't have said it better myself, that's for sure.
Speaking of speaking to other people, I guess my last question is - I'd like to catch up with you a little bit about CodeMash. We spoke about that in our first interview three years ago, and I was wondering if you could talk about how the conference has gone since then?
Jason: In the years since we last spoke - it must not have been too terribly long after that, I actually "retired" from significant CodeMash involvement. When we founded the conference, I think it was 13 years ago, so 2006, 2005, one or the other - you'd think I would know this! - I wound up sitting on the board and I was the speaker chair throughout that period, for 10 years.
And then after the conclusion of the 10th conference, I just concluded, it was time for somebody fresh and new to take my place. I actually wasn't even married, nor had children at the time we founded the event. Well, now I have three young children.
Jason: Three very young children. And of course they consume quite a bit of daddy's time. And as anybody who's managed conferences would tell you - doing so is like having a second full-time job. It's just a tremendous amount of work, especially given that the size to which CodeMash has grown over 13 years - I think at the last event in January, there were 2,200 attendees. Something along those lines.
Jason: But then in addition to that, there's a conference within a conference, called, KidzMash. KidsMash is CodeMash geared for children anywhere between the ages of two and 15 or 16, or something like that. They spend four or five days learning STEM topics. So whether it's Lego, robotics or origami or balloon animal making or building a light saber - you name it, there's this conference within a conference. I think last year, there were a thousand kids at that event.
So that's a very long answer to your question. In the last three years, I've actually attended as a spectator, or an attendee to the events, rather than as an organizer. It's been pretty interesting seeing the event through an attendee's eyes.
I can certainly say that the organizers continue to do a tremendous job, and outdo themselves every year. For those listeners who haven't heard of CodeMash before, I'll just throw in an oh by the way.
Oh by the way, it's held at what I believe is the largest indoor water park in the United States every year. It's a place called the Kalahari up in Northern Ohio. And so not only do you have a great opportunity to learn tech over the course of the week, and any topic pertaining to technology, but you also get to enjoy the water park.
The organizers bring bands in. So there's bands at night. It's just a very good time, very family-oriented of course, thanks to KidzMash. It's just a great time and I highly recommend checking it out if you've never been there. And that website is codemash.org.
Len: Well, thank you very much Jason for taking the time out of a busy day as a CTO and a father of three young kids, I really appreciate it that you sat down with me again to have a chat.
Jason: Thank you so much Len, it was a lot of fun.
Len: Thank you.