Isaac Lyman, Editor of Your First Year in Code: A complete guide for new & aspiring developers

Len: Hi, I'm Len Epp from Leanpub, and in this Frontmatter podcast I'll be interviewing Isaac Lyman.

Based in Utah, Isaac is a software engineer and popular writer whose work can be found on dev.to, Medium, and his website at isaaclyman.com.

Isaac is the editor of the Leanpub book Your First Year in Code: A complete guide for new & aspiring developers. The book is full of practical advice from a number of different people for getting started in a career as a programmer.

In this interview, we're going to talk about Isaac's background and career, professional interests, the book, and at the end, we'll talk a little bit about his experience as an author.

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

Isaac: Thank you for having me.

Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could talk a little bit about where you grew up, and how you first found yourself interested in software and programming?

Isaac: Absolutely. I have pretty much grown up my whole life in Utah, and my older brother is a computer programmer. In fact, right now we work at the same company. But when I was probably 12 or 13 years old, he was in high school and already gainfully employed as a programmer writing Visual Basic, I believe? He had a couple of PDFs on the family computer, and I opened one up one day. *C++ For Dummies** was the title.

I read through the first several chapters, and then I hit the chapter on pointers and got confused and gave up. And then I kind of - it was rinse and repeat on that for a while. I played around a lot with basic C++ and really got interested in all the things code could do. And over the years I branched out into Python and HTML, and a couple of other languages.

But where I really struck gold was my second year of college, when I ran out of money and managed to pick up a job in technical support on campus. There were days when there was nothing broken, nothing to fix. So on those days, rather than spend a lot of time watching Netflix or whatever my co-workers were doing, I spent some time building a website. And that was the first version of isaaclyman.com, which is - well it wasn't as nice as it is now. But I learned JavaScript and HTML and CSS and how they all worked together, and that was the beginning of my career really.

Len: And as I gather from your bio, you were an English major in college.

Isaac: Yes, that's correct.

Len: I have a doctorate in English myself, after which I went into investment banking. So I'm familiar with the pattern of majoring in English, and then doing something that people normally wouldn't consider to be related to it. What drew you to study English? Isaac: Well, my original plan was to go to law school, and English is a very traditional path to law school. Almost so traditional that they don't recommend it anymore, because you want to stand out. But I had done so well in English in high school, and had such an interest in it that I decided to do it anyway.

It's interesting that you bring up how English majors tend to branch out. Because looking at it, it seemed like all of my classes were geared towards becoming an English professor. Which obviously, not everyone who majors in English can do that. What's surprised me has been how transferable those skills are. If you can look through a five-page essay and spot a missing semicolon, you can probably do the same with 100 lines of code. And so, and that's just the beginning. I found that it's not as big of a leap as most people think it is, when they hear kind of where I came from.

Len: Yeah, one of the cute phrases I have for explaining one of the benefits of studying English seriously, is that it gives you a power you have to possess, in order to perceive it. And it's only once you've understood how to construct persuasive arguments based on evidence that you've gleaned, spontaneously in multi-clausal sentences - like this one - it's only once you've unlocked that, that you see really how applicable that power is in all different aspects of lives and careers.

And you are the founder of a company called Novelist LLC, that has a product, Edward the App, which people can find at edwardtheapp.com. I just signed up for it and started poking around it myself, and I was wondering if you could talk a little bit about Edward the App, and what it is, and how you came to create it?

Isaac: Here's the elevator pitch - whenever I meet someone that's tried to write a novel, according to my research, most people have tried to do that in a standard word processor. So, Word or Google Docs or WordPerfect or what have you. And those are fantastic pieces of software, but people find out pretty quickly that they're not made for long form writing. Anything longer than 20 pages, just becomes impossible to navigate in a word processor. One of my goals is to write a novel, and I always get stuck around that point where the novel - after 20, 25 pages just becomes an impenetrable linear wall of text.

And so, I took all the things I learned about writing over the years, and all the things that I wished word processors could do - and put them into a web app. It's pretty small right now. We've got just over 800 users worldwide. But the people that catch the vision tend to be really obsessed with it. Because it's focused on novels, and it does things that no other app does. It's really unique.

It has a tab-like interface, where each tab is a chapter of the book. And it has outlining tools and plotting tools that let you avoid staring at a blank page ever. Because that's kind of paralyzing.

And then it also has - and this is something that I haven't ever seen in another app - tools that help you brainstorm: prompted writing. So if you're looking for a prompt to help you flesh out a character or a setting, or you've just got writer's block and you need some random stuff to get your brain juices flowing, there are automated workshops that you can hop into with the click of a button. They'll give you random prompts, just to get things moving again. It's hoping to be a complete solution for people who want to write a novel, especially if they've never done it before.

Len: Yeah, it's really interesting. At Leanpub, we've got some experience ourselves with writing tools. And in particular, one thing that I like about Edward the App is the outlining features that I discovered. I'm a big outliner myself. Is that something - when you're writing, do you outline first?

Isaac: Sometimes I do. In the writing world, they tend to divide people into two buckets. There's the outliners and the pantsers. Pantsers being people who fly by the seat of their pants, so to speak. Stephen King for example, is a pantser.

He just kind of writes without knowing what's going to happen. He dreams up situations and watches, so to speak, how his characters react. But as I looked into it, my understandiing is that everyone is an outliner, just sometimes not in the same order. Some people outline ahead of time, and pantsers are really just people who outline after the fact. Because there are all kinds of things you've got to tie together in a novel, and you really can't do that without some kind of overview.

So the goal of Edward is to be agnostic as to that, as to which bucket you're in. If you like to outline ahead of time, you can definitely do that. There's a dedicated page for it. And if you like to outline after the fact, that's just as easy. Because you've got the side-by-side view where you can read what you've written and then take notes on the other side, without ever navigating away.

As for myself, I kind of fly between those. Sometimes I want to outline something ahead of time, and sometimes I just need to take what I've got and see where it goes. And so, Edward being the app that I wished existed, it doesn't really have a preference between those.

Len: It's really interesting to me that you bring up Stephen King being a pantser - that's a new term to me. But it totally makes sense. I stopped reading the Gunslinger novels. I don't know if you read any of those?

Isaac: I haven't, no.

Len: I stopped reading them because it became clear that he had no idea where he was going. And I felt like I was being - pardon my French - fucked with by the author. I mean, it's interesting. Because from an author's perspective, being a free pantser might be very attractive. But once a reader figures out that you have no idea where you're going, they can sometimes feel a little bit let down.

Isaac: Yeah. Well, and one of the jobs of an author, if you're a pantser, is to make sure the reader doesn't know that you're a pantser. I think of it like deposits and withdrawals. You have to deposit loose ends and things that don't make sense yet, and mysteries, so that you have something to resolve later - so your story feels like it was planned. And of course the other option, I mean - if you know who Brandon Sanderson is - he's probably the world's foremost outliner. He's just got hundreds of pages of outline written before he even starts his novels. I think it would be very hard for him to achieve the level of tightness in his novels if he didn't outline like that. It really is incredible how airtight his plots are. So there are advantages to either side.

But yeah, I think if you can tell that the author is pantsing, that's a turn off. And that happens to me more with TV than with novels. But I think it's the same thing. You've got to feel like they know where they're going.

Len: Yeah, I stopped watching Lost for the same reason.

Isaac: Yeah.

Len: It's interesting - sorry, I should qualify. I said the "Gunslinger novels," that's just my pet term for, the Dark Tower series.

Isaac: Oh, okay.

Len: And yeah, Brandon Sanderson. So I - just looking him up, but yeah, he's the one guy who finished Robert Jordan's Wheel of Time. Which was, like - I get the impression from what I've read of those novels, very outlined.

Isaac: If you're a Brandon Sanderson fan like I am - you understand instantly why they picked him to finish a dead guy's very intricately plotted universe. Because you just know he's not going to leave any stones unturned. You can just trust him to be very, very intricate on the way he picks that up.

Len: And in Edward the app, there's an analyze feature - I was wondering if we could talk a little bit about how that works?

Isaac: Yeah. So right now that feature is more or less in beta.

There's a couple of different analyzes you can do. There's one called the "AI Ghost Writer," that uses artificial intelligence to write the next sentence of your novel, based on what you've already written. What it spits out is mostly nonsense, because computers can't write novels. But it's interesting, and it's a good way to think about where you're going.

And then there's a couple of more basic analyzes - one of them tells you what words you use the most, barring extremely common words like articles and conjunctions. And then one that lets you measure your usage of a particular word over time.

The analysis feature is going to be phased out soon, because it's not very popular, not very well used. And I'm going to be replacing it with an artificially intelligent writing assistant. If it detects that you're kind of stuck and not going anywhere, it's going to pop up a tip or a suggestion that's specific to your writing and where you're at.

Len: On that note, there are programs that people have written that write novels. There are some writers who write like they are programs, who write novels. What's your opinion on the state of affairs - the next 10 years with AI and - let's say not novels, but stories. Do you think AI's will be able to write good stories in the next 10 years?

Isaac: I'm going to say no. That may be an unpopular opinion. But with my understanding of AI and my understanding of writing - I mean those are my top two things I understand - or that I claim to understand - I don't think the next 10 years or even the next 20 years is going to have a very good unsupervised AI written story, even a short story. And you maybe see those tweets that are like, "I forced an AI to read 500 novels, and this is what it came up with." And some people don't know, those are jokes. People are writing those and passing them off as AI, because it's funny to do so.

But as far as - let's see, I'm trying to think where else I've seen this. There was an AI that supposedly wrote a chapter of Harry Potter. And if you look into it, that one was supervised as well. The AI was presenting options, and humans were choosing which of the options to place - based on coherence and humor. I think the lesson there is that AI is really good at helping us understand data and see patterns and trends. It's terrible at making decisions for us. So I think the future of technology and writing, specifically AI, is that it will help us to understand ourselves and our writing. It will help us to have ideas and to understand options.

But you set an AI loose, I don't think it's ever going to write the next Stephen King short story or even the next dime store romance novel. I don't think that they have the capacity at this point - or are even close to having the capacity for coherence. Which is something that we demand so strongly from writing. So yeah, I'm going to say no on that one.

Len: I think I probably know a lot less about the technology than you do, but I'm totally with you in that conclusion. I think most people are bad at writing and bad at understanding things, to be frank. And the idea that the very people who are bad at writing and understanding things, are going to create the technology to do those things - is kind of counterintuitive, to put it in the best way.

So with that strong opinion stated, so you have edited a book called Your First Year in Code I was saying before we started the interview that we were really glad to see this book when it popped up on Leanpub. It's a great book for people who are getting started. And one of the things that I particularly like about it is its approach to telling you the things that you otherwise normally wouldn't be told.

I've got a little story that I like to try it out on the podcast every once and a while, where - everybody hears the story about how Quentin Tarantino was working in the video store, and then suddenly he was a famous director. But he's actually told the story, connected the dots - where he was, one of his co-workers worked out with Harvey Keitel's girlfriend - and that's how he got his script for Reservoir Dogs to Harvey Keitel. And actually hearing the dot to dot details of how to get started in things, is something that people usually skip over. What was the inspiration for this book? Was it your idea, or was it something that you came up with in discussions with others?

Isaac: It was originally my idea, yes. The situation I was in, I had a lot of old blog posts kicking around that were still racking up tens of thousands of hits, that were aimed towards beginners in code. I used some of the things I learned in my English major, and some of the things I picked up just writing - to write things in a way that was just simpler than other writers. I mean the things I was writing about have been written about hundreds of times, but generally by people who perhaps weren't able to get themselves in the mindset of an audience who has never touched code, or is very new with it. So I think that was the sweet spot - I knew there was a market and a demand for well-written content about code, that was written very simply - and that had an understanding of the mind of a person who hasn't been coding for 20 years.

So I had all this content, and I decided it was probably time to put it together into long form - into a book. And where I wanted to go with that was a book for absolute beginners. There were a lot of things that I knew - I know I have blind spots and biases, and I wanted to cover as many bases as I could. So I put out an open call on dev.to for people to join with me and contribute to the book. And within a couple of weeks, almost 100 people had signed up to either contribute content or beta read the book, or participate as a translator. A bunch of different ways of contributing.

I set us a pretty tight publishing schedule. This all happened in March, and I wanted to publish in July - last month. And so in pretty short order, we had whittled down those 100 people to the ones who were really committed and had the time and the availability. And we got a lot of excellent content and compiled it all together into one book.

Len: I'll ask you a version of a question that's often asked on this podcast. Do you wish you'd studied Computer Science?

Isaac: Yes and no. If I had studied Computer Science, my concern is that I wouldn't have enjoyed it as much. I kind of wish I had studied economics. Which is an odd thing. I loved my economics class in college. I feel like that would have given me some math skills that I don't really have, and that I'm having to learn on the fly at work. And it's a more science-y field, so that would have been helpful as well. But I also got a lot from my English degree. Like I said, transferable skills that really makes programming - it lets me bring some unique skills to the programming table. So I have mixed feelings on that one, I guess?

Len: It's interesting - I've interviewed people who did study and regretted it. Who didn't study Computer Science and regretted it. Who think it was the right decision when they were starting out, but wouldn't necessarily be the right decision to do it now. And it seems to vary a great deal across people's personalities and experiences. So thanks for that great answer, it's always nice to hear a new perspective.

And so, what is the thing that you wish you had - if you could pick one thing you wish you'd known before you got started in your first job as a programmer, what's that bit of knowledge?

Isaac: Oh - that's a good question. I wish I had known that imperfection is - it's okay in code. I've talked about this online a little bit. But, as a junior developer, I often came into a project or a concept with this idealistic attitude - best practices and modern ideas and design patterns, and all these things that I wanted to apply. And I've learned that good software is built on compromises. And maybe that applies to other fields as well? But I've learnt that it's okay for something to not be as fast as it could be, as long as it's fast enough. And it's okay for something to not be as extensible as it could be, if it's extensible enough. I've learned the art of - I've heard it called "satisficing," where if you're doing something good enough, beyond that there's just diminishing returns most of the time. And if there are problems, then they'll come up and you can address them.

But, yeah - I wish I'd had a better understanding of essential compromises to software. So many software books present this ideal, perfect, celestial idea of code. This really elegant project or these 10 lines of code that are just absolutely perfect. And that isn't the norm, and I think we do people a disservice when we focus too much on those - rather than on the somewhat clunky, maybe imperfect piece of code that does the job and only took 10 minutes to write - instead of five years and a research team.

Len: And did it take you a while to gain the confidence to have that approach? I imagine that - I mean, I'm not a programmer myself, but I imagine that when you're getting started, it's sort of natural to feel an imperative to get everything perfect. Because you may be worried about getting fired or something like that.

Isaac: Yeah. I'm lucky in that my first job out of college, my team was spectacular. Shout out to Devin and Brian and Dan. They were really practical, down to earth people that didn't care one bit when I made a mistake - as long as I fixed it. And there was never any sense of comparison, or king of the hill, or trying to out program each other. It was all about, "Let's get this done, and let's keep ourselves sane." And they taught me most of what I know about good code. And so, no I didn't really have - I had a pretty safe environment, is what I'm saying. I felt emotionally safe. And so I think that came to me a lot quicker than it does to a lot of other programmers.

Len: I've met some people who've been burnt. In fact, for some people, their whole career feels like a big burn - depending on the kind of corporate environment that they might find themselves in.

On that note, you co-wrote an essay in the book called, "Getting your first job." I was wondering what advice you might have for anyone listening to this podcast, who's going out to try to get their first job. What are a couple of things you'd recommend to them?

Isaac: That chapter is very practical. It's very bullet point-y. And so I'm trying to think through and pick maybe some of the best gems of wisdom from it.

One thing I'd say is, don't undervalue yourself, and don't tell yourself "No." I mean, if you're not qualified for the job, they will tell you that. You probably don't need to make that judgement for yourself before the fact. And a lot of people go out with this attitude of - if it's an unpaid internship, if it doesn't pay enough, if it's a bad environment, "Maybe that's all I deserve?" And I would say don't let yourself think that way. Maybe try to see the best version of yourself, or find a mentor to help you see that version of yourself. And then that's the version that comes out in the job search and in the interview and follow-up calls. Just to make sure that you start off on the strongest foot you can.

And the other thing is - don't give up too soon. It can seem like a really tough job market for junior developers. Because everyone wants a senior developer who knows 15 frameworks and twice as many languages - who doesn't exist, by the way. And they want that senior developer to accept a salary of half the average wage in the United States. There's a lot of really ridiculous job postings out there. And it can make junior developers feel like they don't belong.

And I'd say - you do belong, and there are companies that will hire you, and places where you will fit in and be allowed to make mistakes and learn. It's just - sometimes it's a long process. Honestly, depending on the way you learned to code, it can take several months to a year to find a job. But it gets easier from there. It gets a lot better. So I hope that people who are getting started will be able to be kind to themselves, and give themselves time - because that's the hardest part, just the first job.

Len: On that note actually, one thing I'm really curious about, is remote work. Leanpub has a remote team. I love working remotely. But also my first experience with having a professional life, was not remote. And I'm wondering what you think is better, when you're starting out with your first job in programming - is it better to work in an office with other people around, than it is to start out by working remotely?

Isaac: I think both versions can work. For a company that has a strong remote culture and understands how to onboard people remotely - I think a remote job can be an excellent first job. And most companies are a little weak on that end. So it may be better in a lot of cases, to try to get an onsite job at first. Although I'm a huge advocate for remote work myself, because I'm an introvert. And so if I am at an office all day surrounded by people, I don't have much energy left in the evening to go to parties and stuff. So remote work has been fantastic for me. I currently work remote at Health Catalyst. And it's been just incredible. But people generally figure out pretty quickly what they like best. Some people really prefer an onsite environment, and some people prefer a remote environment.

One thing most of us have in common though, is we don't like the open floor plan office. Because when the sales team is at the desk next to yours making 15 calls, and you're trying to think through a difficult piece of code - that's sort of an impossible situation.

Beyond that, it's a matter of personal taste. And remote work is kind of having a grassroots - it's growing, it's becoming very popular. And I think a reason for that is because it's easier to find talent when you're not restricted to the nearest radius of 50 miles. So I think that's the direction things are going. But there are still plenty of companies that hire on site, for people who prefer that.

Len: Thanks very much for that answer. Just my two cents. I'm not so much an introvert myself, but I really hate arbitrary conventions. And so the idea that everyone needs to get to the office at the same time, at like nine in the morning - at the same time as everybody else is getting to their office, in the same part of a city - that's always struck me as absolutely ridiculous. And there's all kinds of other conventions around co-located work, that aren't really related to being efficient or getting things done, that can be very frustrating to people who are sensitive to them. Personally I'm also a late to bed, late to rise person. And so remote work works really well for me, in a way that co-located work doesn't work so well. And one of the things I think that's so great about the growing convention for remote work is that, it's just acknowledging the reality that people are different from each other. We're not all the same. And having ways of working that take that into account are just better.

Isaac: Yeah.

Len: And more realistic. Because one of the - sorry to go on - but one of the frustrating things I found in my time, doing co-located work, was that people thought it was hard ass to be dumb about how work was done. And it was always - I always found it very frustrating.

And so, you've talked a little bit about how you got the book together. Can you explain a little bit about that? So, you were managing a group of different people - how did you go around doing that? Did people submit manuscripts to you? Did you have a central database where you kept them all?

Isaac: Yeah. I managed the project with Trello, and I love Trello a lot. I think it's a great thing for simple projects like this. But I basically managed it in phases, and the rest of it was - all the communication was via email. So people that wanted to get involved would email me. And the first thing we did was talk about topics. Because I didn't want five people writing the same chapter, basically. So we divvied those out, all the different topics we wanted to address. And then it was kind of a back and forth.

I mean, anyone who's been in a college English class knows the process. There's the first draft and the peer review, and the second draft and the peer review. And the final draft and the professor's notes. So it was very much a back and forth collaborative process. A lot of hours editing on my part. And so the chapters, the book now - it looks very different from how it looked in those first few days. Because that's the writing process. It's lots of revisions and rewrites.

Len: We've got a number of writing modes on Leanpub. You chose the Dropbox writing mode. Did you - and this is where we get into the weeds part of the interview, but so - for people who are working on projects like this of their own - did you give other people access to the Dropbox folder that you were working in? Or did you sort of manage everything?

Isaac: No, I was kind of the hub for everything. Not that I didn't trust my writers, but I thought it was easier for them to go via email - rather than trying to learn a system and keep everything in sync and have to worry about trampling someone else's work. I managed all that on my own. And it was - I mean, since I was working with coders - almost everyone knew Markdown, which made it really easy. So people would send me Markdown files, and I could just drop them in my Dropbox folder and have them sync to Leanpub almost immediately. So that was really convenient.

Len: I see that your book was in Leanpub-Flavored Markdown. So in your experience, you didn't have to do a lot of kind of tutoring?

Isaac: No, not at all. I mean, we ran into a couple of formatting issues the first time we ran a preview. But I Googled them, and there was the documentation page. Like some of the chapters came through with different levels of headings, and different forms of emphasis or this and that. But it was all pretty manageable to make it all uniform.

Len: And if you don't mind my asking about the details - how are you handling royalties?

Isaac: Yeah, I'm happy to talk about that. All the co-authors signed an agreement that they'd be receiving a portion. And basically, the way we're dividing it up is - of the royalties we get from Leanpub, 10% is going to the nonprofit Girls Who Code, and 10% is going to dev.to for their help marketing and promoting the book. I am taking 20%, and then the remaining 60% is being split evenly between all the co-authors.

Len: Okay. And so you basically receive all the royalties yourselves when we pay you, and then you split it out according to the agreement with all your co-authors - okay.

Isaac: Yeah.

Len: Thanks very much for sharing that. That kind of thing can be very tricky.

Isaac: Yeah, and it takes a lot of trust. I mean honestly, I'm flattered that my co-authors trust me with that. And I'm trying very hard to preserve that and keep them updated on how the book is doing and where royalties are at. But yeah, we're looking forward to that payout in October.

Len: Just on that note - in the publishing-world news, it surfaces from time to time, but transparency around payments and royalties are something that people who use Leanpub might be very surprised to discover - that -with conventional publishers] it's often actually very hard to get any transparency at all if you're an author - and you have like a signed contract with a publisher, what your sales - what even your own sales are like. And transparency can just makes things very efficient in a way that they wouldn't be otherwise.

Isaac: Yeah. Occasionally I read about an author finding out that their book is a New York Times bestseller, from the New York Times. And I feel like you should learn that from your agent or from your publisher, maybe? Anyway.

Len: Just on that note - yeah. What I was thinking of in particular was library sales. A lot of authors-- I mean, basically no author really knows what their library sales are, or what cut they're getting. Because the deals can be so byzantine, and the publishers often just keep that information to themselves.

Isaac: Yeah.

Len: It's very strange when you first encounter it - that that's actually conventional.

Isaac: Yeah. I read that on most deals with a publisher, there's an advance of five to ten thousand dollars, and most authors don't earn that out. They don't get any royalties on top of that. And so - yeah, I agree that, if you want transparency and you want to earn what your book is worth, it seems like e-publishing and self-publishing is the way to go.

Len: Yeah, definitely, if you want to be in control, you want to be in control.

So, the last question I always like to ask on this podcast of Leanpub authors is - if there was one thing we could fix for you, or one feature we could build for you - what would you ask us to do?

Isaac: Oh, let's see. That's a hard one. I tried out a few different platforms when I was first looking into publishing platforms, and I wouldn't have picked Leanpub if I thought there were any serious issues that would make it hard to work with. And even after that, I've been pleasantly surprised. And so apologies if it sounds like I'm sucking up, but I - it's hard for me to think of anything off the top of my head that I wish was better. It all seems pretty ideal, especially considering that I'm not on any of the premium plans. I'm on the free plan - so yeah, I'd have to think about that one, honestly.

Len: Okay, well thanks - thanks very much for that answer. That's actually a pretty standard answer, that people sometimes give. Which is - well, sorry - if I'm talking to someone who's a programmer and they've encountered Leanpub, they're like, "Everything just works." Non-programmers don't always have the same experience. But yeah, if you do think of anything at any point, please feel free to just shoot me an email and get in touch. Because we always love to hear from authors about their pain points or - and you've got the experience of building an author yourself, so obviously you'd be a great source of criticism for us - I think, if you ever have any thoughts to share.

So well, thank you very much Isaac, for taking the time out of your day to do this interview, and thanks for choosing Leanpub as the platform for your book.

Isaac: Thank you.

Len: Thanks very much.

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 yourself, please go to our website at leanpub.com. Thanks.