Christina Moulton is the author of the Leanpub book iOS Apps with REST APIs: Building Web-Driven Apps in Swift. In this interview, Leanpub co-founder Len Epp talks with Christina about her career, sailing, her book, and at the end about her experience as a self-published author.
This interview was recorded on March 16, 2017.
The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.
This interview has been edited for conciseness and clarity.
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub podcast, I'll be interviewing Christina Moulton.
Based in Ottawa, Canada - the nation's capital - Christina is an iOS app developer, who works on creating apps for iPhone and iPad at her company, Teak Mobile. She also writes tutorials for developers working in the Swift programming language. And there's also a mysterious reference in her Leanpub bio to sailing, that I'm going to be asking her about.
Christina's the author of the Leanpub book, iOS Apps with REST APIs: Building Web-Driven Apps in Swift. Her book is focused on helping readers build their first app using Swift, in a way that is not overwhelming, or as she puts it, giving you "[o]nly the nitty gritty that you need to get real work done now."
In this interview we're going to talk about Christina's professional interests, her book, and at the end we'll talk about her experience using Leanpub a little bit.
So, thank you Christina for being on the Leanpub Podcast.
Christina: Thanks for having me.
Len: I always like to start my interviews by asking people for their origin story, so I was wondering if you could tell us a little bit about how you got interested in programming, and how you ended up being an iOS developer?
Christina: Sure. I actually fought being a programmer for a really long time. When I was 18, I was facing down the "what do I do" for school, the "what happens after high school" thing? I ended up going to Waterloo for Systems Design Engineering, mostly because their core program meant I only had to do four months of school at the time. And because it was kind of choose-your-own-adventure engineering; they make you take all the core engineering requirements for licencing in the first two and a half or three years, and then you have to put together a defensible curriculum for your fourth year. And the list of electives you can pick from is something like 1,000 courses long.
I ended up taking a lot of math and a lot of geography, combinatorics and optimization mostly. The mathematicians had really interesting techniques, and the geographers had piles of data, and they just didn't seem to ever get together and apply the techniques to the data.
I did a little bit of grad school after that, just continuing on with the project I've been playing with with that. So that was a tiny little bit of programming, but in that very messy, horrible academic way, cobbling MATLAB together with a little bit of Python, and just trying to get stuff to spit out data, really.
Then I graduated, and as it seems to work out, the jobs were mostly in software. So I ended up at a small environmental software company. They did a little bit of teaching and training as well, and they built software for environmental emissions modeling. So the government said, "If you have a factory in Canada, you have to run this Fortran model, and spit out this data and make sure that you weren't putting out too much emission on days that had certain weather and blah blah." So they built a nice GUI around that. That was interesting, it was fun. It was actually in Delphi, which was a wonderful language that I'll probably never use again.
Len: I actually interviewed someone who was on the early Delphi team, just the other day.
Christina: There were some great things about it that we just don't get anymore, with data binding and stuff. It seems like it's taken us a very long time to get back to the maturity that they had in certain features. Eventually I got bored with that, and then moonlighting a little bit for a guy who had worked at Apple and had a little bit of contract work in iOS development. He slowly got more and more demand for that, and I started working for him more and more. I ended up spending I think about two years working with a little consulting firm that he had, just doing contract work.
Eventually I got tired of working for someone else, and I didn't want to be all project manager, and I didn't want to be all coder. It just seemed better to go off on my own, and pick up my own contracts, so the sales person was the person writing the code, so that I didn't have to deal with all the internal communication that always seems to get lost inside an organization that way.
Len: Being independent is something a lot of people are drawn to for a lot of different reasons, even though it comes with its own burdens and responsibilities.
I was wondering actually if you could explain a little bit about what you learn when you learn Systems Design Engineering?
Christina: The theory is that you're supposed to learn how engineering works, and the different methodologies and things that fall in behind stuff. The reality is, you still have to take fluid mechanics and whatever the same math and half of the same courses. But we did have probably about a quarter of the curriculum that was either design focused - so even in my very first term they made us take the mandatory drafting course, which I'm terrible at.
But they also managed to shove into the curriculum a little design project course, and bring in people on things like idea generation and creativity and focus and how to work beyond what is just a simple mechanical problem, into something that's broader and larger. Some of the guest speakers in that were people who ran art studios.
And even at that very first term, when you're getting exposed to a lot of user-centered design, a lot of user experience stuff - in second year, we had a course that had a lot of the user experience, user-centered design, and somehow we fit that in, because it was supposed to be half how to design; but the curriculum was kind of, how to avoid engineering mishaps.
And so instead of just saying, "Hey, if you build a bridge like this, a bridge is going to fall down," this said, "Okay, well what kind of organization and design and thought process led to the Tacoma Narrows Bridge? Why did they miss out? Why did they not think of that?" So, a lot of the psychology and the thought process behind stuff. And I think we had three or four design courses that were, explicitly, go do a project with facilitated guest speakers, usually with a bit of a focus. Early on, idea generation; later on, improving, refining. That kind of stuff.
Len: And is that bridge collapse that you refer to - is that the one from which Canadian engineering grads rings are made?
Christina: I've heard that story. They may have been originally, they're not anymore. There's too many rings. The bridge wouldn't have been big enough.
Len: When I was in my undergrad days I had a friend who told me that story about how, when people graduate from engineering programs in Canada, they get a ring, and that the ring was, by legend at least, fashioned from metal from a bridge collapse, and engineers wear this to remind themselves of the responsibility that they have in what they're doing. [Note: apparently Len's old college friend, who told him about this when he got his own ring in the 90s, was laboring under a common, if romantic, misconception, as this page explains - eds.]
And what was the focus of your graduate work?
Christina: I didn't earn a real final title in the end of it. It was something like taking a land use problem where you have thousands and thousands of possible solutions, and we can sit and we can model, and we can say, "Okay, there's all these different ways we can do it." And then how do you evaluate which one's best? But you're never going to get everybody to agree that improving the way that animal habitats in the area are linked together by corridors, is more important than having enough commercial land use.
So we took the big space of thousands and thousands of solutions, and worked to cluster them into options where you couldn't necessarily say one was better than the other. So if we had something that was just as good for the animals, but not as much commercial use, we'd throw that one out. But if we had one that was better for the animals, worse for the commercial - another that was better for commercial use, worse for the animals - we'd try to build up clumps of clusters that were similar to each of those.
Then we could come down to a handful of representations of what possible solutions might look like. Which is something that would be a little more useful at a town hall, where you can put up a poster of five to ten different options for land use, as opposed to, "Here's the hundred thousand possibilities."
Len: And so you moved from that to working in industry, and then to being independent and doing software development.
And then you decided to go sailing for two years. I want to ask you a question about that, because that's just fascinating to me. If I understand correctly from your blog, you learned to sail from a book initially, which sounds very brave to me.
Christina: Kind of. I took, I think, two weeks of sailing classes when I was really young. I grew up in a fishing village in rural Nova Scotia, but I didn't really remember any of that. And then after I graduated from the university, I wanted a hobby, wanted something. So my husband and I bought a 17 foot Hobie Cat and a book, and learned.
A Hobie Cat's almost like a bicycle version of a sail boat. You know you're going to get dumped in the water, you know you're going to get wet. You're just farting around on usually a fairly small body of water. So go out, make your mistakes, have your fun. And then when we got closer to heading off, it was time to go with a serious sailboat that actually hade some mast and we actually had to know what we were doing to manage it.
Len: And so you eventually decided to go on a very long journey. What was that like, being itinerant in that way? And on the water, I imagine most of the time.
Christina: We sailed about 15,000 miles in two years, which is actually a fair bit for people doing this kind of thing - unless they're crazy circumnavigators, and they want to go all the way around in a relatively short time. It worked out to like 30 to 40 hours a week underway on average. But generally we did that in big spurts. Most of the time we just sailed during the day, doing our little hop, going wherever.
But a couple of times here, we'd do a major re-positioning. One of them was from Virginia, right down to the British Virgin Islands in the Caribbean. We did that twice, that was 12 days straight, and about 1,500 miles. That isn't so bad, because after a couple of days of sleep deprivation, you really stop forming memories. You just kind of go out and do it, and live with it - and then you land there, and deal with customs and go out and have a big margarita and tacos. And then you enjoy the lifestyle down there.
There's actually a really great community of "cruisers," and, coming back, it's the hardest thing to get used to is, I can't randomly accost people in the grocery store, just because we have something in common. Whereas if you both live on boats, and you can figure that out - because they're carrying their wallet in a dry bag, because they don't want it to get wet in the dinghy on the way back to the boat. It's pretty much fair game to walk up and invite them to dinner or for drinks or something. So it's a really cool and neat community. There's not a ton of people out there, but there's definitely enough to stay social.
Len: One thing I've always been really curious about with that is can you just - as they say in Australia, can you just rock up to any port - and park and get out, or do you have to arrange anything in advance? Or can you do what you want?
Christina: Through North America and the Caribbean - if you don't have a pet with you, you can generally show up and then just find customs. There are slightly different rules, depending on where you are. For example, with the US, only the captain goes to customs. So you have to nominate a captain, and they go. They take everybody's passport. Sorry, I did that backwards. In the US, they want everybody at customs. A lot of other countries, they only want the captain to go, and bring everybody's passport. And everybody else kind of stays on the boat, confined until you're cleared.
If you have a pet, there's a number of countries that want you to arrange to have a vet and meet them, or to deal with a bunch of paperwork in advance. So we traveled with our dog. And sometimes it was great. The French countries - you show up, you find generally a little computer station or a little office somewhere, sometimes it's in the laundromat or a bar, and log into the customs online, and type in your passport numbers and stuff. And the bartender or laundromat owner checks your paperwork, and says, "Oh yeah, okay you're fine."
And then you get places like Antigua, the British Virgin Islands - generally four million British colonies - and they want piles of paperwork for the dog, and make an appointment when you show up. "Land on this specific spot, in this specific dock. And you stay here, and you don't move." And you go to three different offices, trying to get the paperwork all sorted out. And then you have to go back to the first office. And then you have to go back to the second one. But yeah, if you're just a couple of humans on a boat, there are very few countries where you need prior permission. You mostly just show up.
Unless you need a visa, depending where you're from. That's the only thing. But 99% of the time, it's the same as arriving on an airplane - except for the States.
Len: I'm just curious, in all that time, what's the most interesting thing you saw on the water?
Christina: The oddest thing we found - it was our first trip from Virginia going to the Caribbean. We were probably three days offshore, and my husband was up on watch. I was asleep, and I got up. And he's just kind of very perplexed. He's staring, he says, "There's a boat out there, and it's not moving." So as the sun came up, you could see a little shadow on the horizon. It's like, it's right on our path, like we're headed within like a hundred feet of the thing.
And we got there, and we discovered that it had no one on it. It was hundreds of miles out in the Gulf Stream. And it turned out that the storm that happened the day that we had intended to leave - another boat had gotten caught up in it. Just a whole bunch of circumstances that put them in the wrong spot at the wrong time. The Coast Guard ended up pulling them off. They were only 30 or 50 miles off of the US coast. But I guess the boat drifted a bit, and the Gulf Stream picked it up. And it was out there bopping by itself a couple of days later.
Len: Wow.
Christina: It's a little eerie.
Len: Is that the kind of thing you then call in on the radio to report?
Christina: Call on the radio is just mostly for hey nobody run over. We happen to have a satellite phone on board as one of our backup communication systems, so we did call the Coast Guard. I was able to get confirmation at that time that - yeah, "There is definitely nobody on there, you don't have to worry about it." There's a big debate in boating on whether or not you would sink boats and that. But I guess in this case, the coastguard opted not to. She was out there floating around with nobody on her.
Len: That does sound eerie.
As I understand it, you, moving onto your book, you wrote the book at least in part, while you were on this journey.
Christina: Yes. Most of it started as blog posts - or the first quarter or so started as blog posts. And when I started seeing that I was getting enough interest, and people cared about the topic, and I'd settled on kind of one topic, I wrote probably about 80% of it while we were traveling, while we were transient. And then we came home to visit family over the summer, and I just took a week and a half of sit, focus, and finish it while I had good internet access.
Len: And had you written a book before, or was this your first time doing that?
Christina: No, this is definitely the very first thing of that magnitude that I've written. I think it's actually longer than my Master's thesis.
Len: And what was the experience like? Did you find you had issues being motivated? Or did it just naturally flow out of you?
Christina: It was fairly natural while I was travelling, it - the first six months, it was great to kind of have no commitments. After that, it was time to have a purpose and a reason to do things. And my other motivation was - after we sold the house, had the boat, had everything lined up, my husband was just finishing off his two weeks' notice at work - and Apple announced Swift. Which meant that I had just left with a valuable skill set, and a programming language that would probably not be used when I was coming back.
So there was pretty good motivation to write enough Swift and enough things to show that - yeah okay, I can do this, I'm capable and I'm not going to be making my initial mistakes on client projects. So between that and just not having a lot of other time parameters and being able to very often go to a bar, I could get into it for a couple of hours, hack up some code examples and stuff, and then go back and write when it felt like a good time to do it. It worked out fairly easily.
Len: And when you started learning Swift, and now that you obviously have fully grokked it - what's your opinion of it? Do you think that it's a home run, or are there things that still need to be worked out?
Christina: Hopefully there's still stuff that needs to be worked out, because they're still intending to make changes. There's actually a little thing on one of the mailing lists yesterday that they're going to look at things like JSON serialization, and passing data back and forth, and turning from objects to JSON. Because we have so many parsers in Swift right now, and they've all got pros and cons. But definitely it seems to be a pain point.
It's funny, at first I didn't notice much difference. It was just like oh well Objective-C Swift, whatever - they're slightly different, but I don't mind.
Recently I have a client that I've just started working with the last month and a half, and they use Objective-C, and I really noticed now how much more productive I am in Swift. There's just a whole lot of stuff that's easier to do, and a whole lot of stuff I don't need to think about. It's just a much safer language.
There are also then, obviously, things that are much more difficult to do in Swift. But they're things that you don't want to do that often. So overall, I'm a huge fan. Absolutely loving it. But I'm still okay with them making improvements - as much of a pain as migrating versions has been.
Len: Speaking of making improvements, I saw in the thanks section at the beginning of your book that you worked with a technical editor, and I was wondering - for those listening, who might be thinking of writing a technical book themselves one day - what was that experience like?
Christina: So Michael’s not a general professional technical editor. And there's definitely a value to those. I just felt after having gone through a couple of versions of Swift, and having written the book, and been in the weeds in that code for so long - I knew there was stuff that I hadn't cleaned up well enough as Swift had matured. The way I did things on day one, was not where I should've done things a year later. But it was hard to see that myself. So I had actually another freelancer go through it from a technical perspective - through the book, and through the code, to help make things more consistent, more modern, easier to follow, and that kind of thing.
It was a good experience. Definitely a nice quick [process] - hand stuff off, get it turned around. And it was hugely valuable. The great thing about self-publishing is, I didn't have to do that until I was sure the book was going to sell. So I didn't have to go through the hassle and the time and the effort and the expense - whether that would be to me or a publisher - of bringing in someone else to evaluate something, if I wasn't sure that it was going to be worthwhile.
Len: And what was the signal that you got, that told you it was going to sell?
Christina: I was mostly just getting enough comments on blog posts. And people both reading them, and then wanting to apply them to their own projects, and coming in with, "Well I tried to do this, but I'm running into this error." So I knew people were not just browsing through and skimming the blog posts that I'd written, but were actually needing to do that kind of thing in their jobs, or their hobby projects, or whatever.
So the intention of the book was, guide them through the process to build a bigger, complete app and all the different steps. When I write a post about how do you read data from one server, and half the questions are, "Okay, so how do I write it now?" - okay, now I know I need to write that. Or, "What about authentication, how do I deal with this?" Almost every chapter was a fairly direct follow up from a question that I got from a reader on a blog post.
Len: That's really interesting. After you published the book, was getting feedback from readers something that you engaged in, or invited explicitly?
Christina: Yes. I still get a fair number of emails. I don't know if they're necessarily book readers versus blog readers. I don't tend to differentiate. Sometimes they tell me, sometimes they don't. But I definitely get a fair bit of it, and I do tend to encourage it. Actually, of my last four freelance contracts, two of them were book readers. They were people who worked in generally a slightly smaller organization. Not something tiny, but not IBM or anything.
They saw that there would be some value to an iOS app in their organization. They had a web service back end already existing for some kind of web app. But they just thought like, "A little slice of this would make an awesome iPhone app." And they bought the book, and put together a little prototype themselves internally. And usually, I would get an email from them eventually saying, "Oh hey do you do any consulting? Because we'd like to build this out. And we have got this whole prototype. And my boss is interested, so now I've got to build it."
And if I go back in my email, I'll find like four months earlier, one or two little technical questions from when they were first starting - where I had no idea this was someone doing this kind of work, that they were trying to get something going, and might eventually be a consulting client. But it would be like, "Okay, I've got this really weird authentication system, how do I get this to work and submit my token properly?" So I didn't expect that. But there's definitely been at least two.
Len: And did you publish the book before it was finished, or did you publish it when it was "done done"?
Christina: Pretty much when it was done. There were a couple of chapters further on in the book. The first quarter was stuff that started as blog posts, and then just got reprocessed into a nicer format for the book. And then as I wrote it, every few chapters I'd hit a topic that worked well as a blog post. And I'd slice that out, and post it and see, kind of given this, "What are people asking, what are they doing, what are they saying is unclear?" But yes, it was published as a complete entity, although it's been through a couple of edits now.
Len: That's a really interesting process. So you're writing a chapter for a book, but you publish a version of it as a blog post while you're writing it.
I wanted to ask one of my last questions. What was it about Leanpub that drew you to us, rather than one of the many other options you could've chosen?
Christina: It was nice not being able to fuss with all the layout all the time. Because I'm definitely quite capable of spending three days tweaking a CSS file, and not actually writing any content. And the workflow worked really well while I was travelling. To be able to just hammer out a bunch of Markdown and then sync it up to Dropbox, or push it up to GitHub, when I had internet. And then deal with whatever the updated formatting was in the compiled version later. And Markdown was really easy to reuse on my blog. It's based on a static site generator that uses Markdown.
Len: We've never had anyone working in quite that manner before. And it's interesting to hear about the advantages of doing the formatting work under those circumstances. That's so interesting that you say that. I mean, I'm like that too, and so are I think most people who write - they end up just formatting. It's such an interesting trap to fall into.
We get this question from people every once in a while. They'll be at the beginning of their process of writing their book, and they'll email us with like a long list of "Why can't I?" And I'm not saying this critically. I mean, I come from this position internally myself. But, "Why can't I change the spacing between the last paragraph before a list and the list itself?" - I totally understand where it comes from, but what we always try to say to people: "Thank you for your feedback. We are always trying to improve the options, we'll keep it in mind. But if your book isn't done yet, we really seriously recommend that you not worry about any of this until it's done."
There's actually a very practical reason for that. In an age where people are more and more reading on ebook readers or in apps like the Kindle app, the reader actually has a lot of control themselves over what things look like. And also, things look different on different devices. So getting really pre-occupied with - readers aren't so preoccupied with, let's say appearance, like they might have been in the past. Because they might make the font size bigger. They might make the font size smaller. They might change the color even. The reader has a lot more control. And so as a consequence, they're not really necessarily as concerned with minutiae when they're reading ebooks.
My last question is - if there were one thing we could fix, or one thing we could build for you - if you have any thoughts on that, what do you think that would be?
Christina: I think the only slight annoyance I ran into was formatting code samples. I could either have syntax highlighting, or I could have, I think it was line numbers. No - it was the insert and delete functionality. So it'd show a line being struck out of a code sample. I think if I used that, I think I lost the syntax highlighting. It was something tiny like that. And it was the kind of thing that I looked at. I'm like, "Oh should I - ?" But really, it really doesn't matter. It's one or the other. It'd be handy, but I can see technically why it may not be worth the effort.
Len: We've definitely had that request in the past. I have to defer to my colleagues on that one, not being a programmer or having written a programming book myself. But as I understand it, there's something just tricky about that particular instance. I suppose it's possible that something might be done about it one day. But currently I think this also has a little bit to do with the way things appear in different formats. It's tricky to do the insert, delete thing with the syntax highlighting. But thanks very much for your vote, it counts.
[Editor's note: there are two reasons why syntax highlighting is currently disabled in code samples that contain inserted or deleted code blocks. First, the inserted and deleted code formatting is based on an older version of Pygments which we have forked, and there were issues keeping the language definitions for syntax highlighting compatible with both that version and the newer version which we use for normal code samples. We try to keep Pygments updated in order to support more languages, like Swift and Kotlin, when they are added to Pygments. Second, since inserted code is often indicated with just bold text, that does not stand out if the code is syntax highlighted. So, the syntax highlighting was actually making things worse in those cases.]
I just wanted to say, before we go, Christina, thanks for taking the time. I enjoyed learning about your career path, and also about the sailing.
And I wanted to say thanks very much for being on the Leanpub Podcast, and for being a Leanpub author.
Christina: Great, thanks a lot. I've really enjoyed talking to you today.
Len: Thanks.