I created a blank document on November 2nd and published my book “Junior to Senior: How to Level Up as a Software Engineer” on December 21st 2020, exactly 50 days later. This initial version of the book is 52,660 words (the PDF file is 135 pages).
Here’s why and how I did it.
Why write a book?
Writing a book is a rite of passage. I was always a hoarder of knowledge and rarely shared what I had collected, except for writing documentation and guides at work, and teaching people in person.
As is the case with most developers, my personal blog has been sitting almost empty for years: why share something if it’s you who has a problem, and you are the one solving it? The effort to write up a solution in a linear, organized way seemed excessive; I had my notes and they were enough.
After I left my last iOS development job in May 2020 I was lucky enough to afford a sabbatical. I intended to use this time to learn new tech, close some gaps in my knowledge and reinvent my career, like I did several times in the past. But before that I wanted to pay my debts to clear my head for the future—finish and release a side project, and share (through writing) what I’ve learned over the past ten years being a software developer, for the benefit of future-me and several friends who are just starting their careers.
Hoarding knowledge and research gave me answers, but how many of them have I internalized and filtered through my own experience? I always have pointers to people who know it better, who’ve had more success and who’ve put it better into words that I ever would. Won’t I just regurgitate the others’ words? Do I have anything to say?
The idea was on the back burner until the beginning of November when, coincidentally, two things happened: the Gumroad 14 day product challenge, and NaNoWriMo. Gumroad is a platform for selling things, and NaNoWriMo is short for National Novel Writing Month with the simple goal of writing 50,000 words (the psychological limit for a text to be a novel) during November. Gumroad’s 14 day product challenge was simply “create something in 14 days and sell it on Gumroad.” A perfect match if you want to write a book.
The beginning
I used Daniel Vassallo’s advice for the scope and contents of the book: “Target 2–4 weeks. Find a topic that will almost write itself (no research). Cut scope. Keep it simple.” Books are usually complex affairs, and you can spend months doing research to back up your claims. The idea to say only what I knew for certain, what I didn’t need to research, became the primary filter for the subjects I wanted to cover.
Does that mean everything I’m saying in the book is unsupported by evidence? Not at all—while writing, I cross-referenced my facts with other sources. If you’ve read the book, you know I even give links to several papers directly supporting the central sections.
The important thing is that I did the research after I started writing. I backed up and verified my claims through research rather than sourced them from research in the first place. That’s a big difference.
“Lateral Move”
Initially I thought I would write about making the so-called lateral move—a step sideways from your existing career to learn new technology, so that you could get excited about working. Being bored with what you were doing was a requirement. This was a process that I went through several times myself, switching from being a sysadmin to writing Python, JS and then to iOS.
It was supposed to go like this:
Notice the subtitle: “The bored software developer’s guide to researching, learning and getting excited about new tech.” There is a large crossover with the contents of “Junior to Senior,” but when I started writing the introduction I realized that you had to be in a very specific situation for the advice to be useful—and what I suggested didn’t suit many people either. I would be better off not following this advice myself, as I mentioned in the section Help your company teach you of “Junior to Senior”:
Earlier in my career, I have left companies over lack of learning, but looking back, I understand that I could have had more learning freedom in a familiar project and in a company that trusted me.
I scrapped everything and started again.
“Junior to Senior”
For my second attempt, I decided to let the structure emerge by itself instead of planning it in advance. I created a blank document and over the course of a couple of days wrote about 4,000 words of random notes—short bits of what I could talk about.
After organizing them I noticed that the common theme was becoming a better developer. That entailed improving how you communicated, what you knew, how you were learning and thinking about your career.
Compare the initial table of contents (with zero words written) to the table of contents of the published version of the book, they are not different at all:
This strong structure allowed me to avoid second-guessing myself and thinking I “forgot” something. Instead of worrying, I could now focus on writing. What also helped was putting the book up for preorder and getting more than 30 preorders on the first day, so I couldn’t easily go back and drastically change the structure. I had to deliver what I already promised.
It was the beginning of November, and I had a whole book to write. I didn’t know yet how large (or small) it would be, I never wrote long-form texts like this before. If I said everything I wanted to say, I expected maybe 20,000 words, or around 50 pages.
My primary goal was to release the book before the year was over, and ideally, a few days before Christmas to give a launch discount and give people the chance to use up their learning budget. That sounds calculated, but really I knew that if I gave myself 6 months, I would never finish, and I already had one long project in flight. The only way was to take a reasonable, but short time to complete the book, and one and a half months—or 50 days—seemed enough to both complete the text and leave some room for editing.
I made this banner for the preorder and intended to stick to my promise (and I did):
The process
From this point on, the challenge to write the text appeared mostly mechanical. Every day, I had to sit down at the computer and write, and I knew that if I did that, I would finish, likely on time.
How did I know? I make it sound so simple. Remember that I only put what I knew I could talk about (at length) into the book, so I was reasonably sure I could write something coherent in any section. The sections are weakly linked, it’s not a novel, so I didn’t need to go back and make sure the plot was consistent. Like in math, I could prove by induction that if I managed to write one section, I could write them all.
I knew that, but still was anxious. What follows is an excerpt from the book where I describe what I did and how it helped.
(begin excerpt)
As I began writing this book, I knew that I would face strong resistance (because “write a book” is the vaguest todo item in the world), so I used every trick that I knew to help myself write every day:
- Make other people expect your work. Probably, the best thing I did was to offer the book for preorder with a set release date. I’m very serious about my promises to other people (Rick Astley starts playing). Just the thought that I’ve promised to do something by some day helps me sit down and do the work. If you only do something for yourself, you can easily make an excuse and avoid working, but you can’t go back on your promise and make up an excuse for other people. At work, I know my teammates expect and rely on the tasks I do, so I try to never let them down. Reputation beats procrastination.
- Remove distractions, at least in the beginning. Often the bump that we need to cross to begin working on a big task is relatively small, but when there’s a distraction available without friction, we choose that instead. I write on a very slow Linux computer that can’t play music, has no internet, and my phone is on silent, face down, in another room. There is “fog” in my head when I sit down to write, and I sit there and stare at the screen for ten minutes. But the fog is me thinking about how to start and what I want to say in the section. I need those ten minutes of initial concentration to break through the resistance of the task. If I had a distraction, I would probably take it. What also helps is having a notebook that you keep in front of you when starting, so that you can write down what you want to do about the task first, like a small todo list. I find that after I start, I can stay in work mode until I’m done, even through small distractions.
- Have a deadline that feels a little too close. Aggressive deadlines only cause stress and burn you out because you have to spend extra energy to hit them, and for whose sake? The trick is to have a due date for the task that will make you feel like you have to start working on the task now. If a task at work is due tomorrow and takes a day to get through code review, I know I have to start working on it right now, or I will be late. When I began writing, I picked the deadline for the book a month and a half away. For a whole book, it’s ridiculously short (books take six months or more to write), but if I had a year, I would never finish it. If I had a week, I wouldn’t finish it too, it’s simply not enough time to write fifty thousand words. But a little more than a month? It’s a stretch, but doable. I’m not overexerting myself by writing for twelve hours every day (like I would have to if I had a week), but I know that with the amount of work I need to do, I don’t have time to procrastinate, only to work. So here I am, writing.
- Work towards a goal for the day. I learned this from the book “Make Time” by Jake Knapp and John Zeratsky. Pick what you want to accomplish in about two–three hours and feel that you’ve “done good work.” I often pick a task that can take the whole day, but you get the point. If you’ve done it, you feel like you’ve won the day, and everything else you do is a bonus. A large todo list can be discouraging, but being able to tick off a large, important task makes you feel incredibly productive, and you get a boost of energy that you can use to do more work. Writing this book is not the only thing I do, but if I’ve written what I’ve planned for the day, I feel in control and calm, because I’ve done the work that requires the most concentration.
Here we are at fifty thousand words, and I’ve been writing for more than a month every day, a sustained effort of unprecedented proportions for me when working on what is essentially a side project. If I didn’t have a table of contents that I could follow, dozens of people waiting for the result and a not-too-distant deadline, I would never have made progress so consistently and intentionally.
(end excerpt)
Timeline
Here’s a graph of the word count for the book with some milestones.
Every Wednesday I published an email update. You can read them all in the thread here.
(1) November 5. Table of contents ready. I realize I’m actually writing a book.
(2) November 8. I made the cover and published the preorder page.
November 9. Public announcement on Twitter that got me most of the preorders.
November 10. I was so worked up that I forgot about the Apple event.
November 17. Crossed 20,000 words and made a meme.
(3) November 18. Spent the day doing research instead of writing. Found three papers that confirmed my hunches.
November 19. Reflecting on my writing routine.
November 22. Crossed 25,000 words and finished part 2 (the most difficult).
November 24. I didn’t expect I would write so much. My initial estimate was that I would be able to write about 20,000 words, not more.
November 26. Crossed 30,000 words, which is supposed to be a roadblock.
November 29. Finished part 3.
(4) December 3. Extracted 3,000 words of random notes into their own doc because I prepared the text for editing.
December 5. Having a hard time starting to edit the text. I decided I would finish first and then start editing in earnest.
December 8. On elegant code.
December 9. Getting tired of daily writing and doing Advent of Code at the same time, I need a vacation from this sabbatical.
(5) December 10. The end! Draft zero is done.
December 13. Started editing. 5% done.
December 14. 11% editing done. Trying to do it quicker.
December 15. 24% editing done.
December 16. 50% editing done.
December 17. 100% editing done. The only thing left is to insert illustrations instead of placeholders.
(6) December 18. Illustrations done and put into the text. The only thing left is to generate the PDF and other files.
December 19. Having some trouble with LaTeX.
December 20. Uploaded the files to Gumroad. A sigh of relief: now I’m really done.
December 21. Added the book to Goodreads (I am now a Goodreads Author). Wrote a public announcement about the book release. I did it!
Looking back, I focused on doing (and celebrating) the work in the moment. Eat the elephant one bite at a time.
Tools
Conceptually, the process of producing the book is fairly simple. The book is a single Markdown document that lives in my notes directory among all my other notes, with images in the notes/files directory. I don’t care about previews because there’s no fancy formatting, so any text editor can be used to write the text.
When I’m happy with the text, I run a small Pandoc script to convert Markdown into a PDF and an EPUB. That’s basically it.
I’m platform-agnostic—I have a MacBook and both Windows and Linux machines—so I value cross-platform, (preferably) native tools that let me preserve my workflow on any platform.
I use the free tier of Figma to produce all graphics (banners, cover and other things). It makes working with shapes and exporting a breeze. If you install the “native” app, you can use local fonts installed on your system. For example, I whipped up the cover in a few minutes and exported it both as a PNG for the web and as a PDF with vector graphics to use it in the PDF version of the book. How cool is that?
I write in whatever I feel like at the moment. I did the bulk of writing on a small Linux nettop without internet in Vim. I often browse my notes in Zettlr so I did some of the writing in that, but being Electron, it stopped working after I crossed 250,000 characters. When I needed some visual mucking-about, I used Geany—compared to Zettlr, it was blazing-fast and had Markdown table of contents and preview.
It really doesn’t matter which editor you use, as long as it lets you write and navigate what you’ve written. For developers who want to write something long-form and don’t want much hassle, I’d recommend either LeanPub or novelWriter.
For me it’s important that I have full control over my notes and how exactly they are stored and handled, so I didn’t use any cloud tools for writing. Besides, anything browser-based has a lot of trouble working with large documents.
I’ve drawn my few illustrations by hand on printer paper with a permanent marker. Then I snapped them with my iPhone, imported and converted them to 1-bit PNGs—only two colors, black and white. I think they turned out pretty well. Here’s one of them:
When sharing my book for editing, I used Google Docs. It wasn’t an “export,” I just copied raw Markdown from my document and inserted headlines and images where necessary. It was really good for commenting and discussing portions of text. Just the other day I helped Kevon Cheung review his ebook “Building in Public,” also in Google Docs, so I can definitely recommend it for light editing, compared to some specialized tools that I’m sure exist out there.
For generating the PDF, I started with this code and modified it for my needs, while still using the Eisvogel template. I also used PDFtk to attach the cover after compiling the PDF. The generation script is as follows:
pandoc --pdf-engine=latexmk --template=./templates/eisvogel.latex \
--highlight-style tango --shift-heading-level-by=-1 \
--number-sections --top-level-division=chapter \
-o build/text.pdf src/title.txt src/01.md
pdftk cover.pdf build/text.pdf cat output build/junior-to-senior.pdf
LaTeX (required by Pandoc for the PDF conversion) was a little tricky to set up, but finally I went with MiKTeX and it went smoothly.
EPUB is similar:
pandoc --css templates/epub.css --highlight-style tango \
--shift-heading-level-by=-1 --number-sections \
--top-level-division=chapter --epub-cover-image="cover.png" \
-o build/junior-to-senior.epub src/title.txt src/01.md
After that, I generated the MOBI file with Kindle Previewer. The formatting is not stellar, maybe that’s the fault of the original EPUB CSS, but I can live with that for the moment.
What I learned
I’m not a writer, I’m a developer. Surprisingly, writing a book felt exactly the same as working on a piece of software. You have a “spec” (table of contents), you have “end users” (readers), you come to work every day and submit “code” (text) that implements a “feature” (chapter or section). After you’re done writing, you get “pull requests” from your editor that you need to (literally) merge into your text, so there is even a bit of collaboration involved.
Writing feels a lot like programming
The process of writing itself, at least for me, was also remarkably similar. When I sat down to write the next section, I needed to concentrate first and extract a plan of action, some vague sentences from the fog in my head first. When I had a good plan in my mind, I could start working, putting sentence after sentence with some light editing, until I got something that “worked.”
I had the same capacity for writing as for programming—four to six hours a day, give or take. Beyond that, I could only produce mush or got too distracted.
Expectations beget motivation
I have a long history working on and off on side projects, but this was the first one where several dozens of real people waited—and paid money—for what I was about to produce.
This made a dramatic difference to my motivation levels compared to working on something nobody knew about. My reputation was at stake, I didn’t want to let people down. The audience and the allotted time directly informed the shape and form of the project, I knew exactly what and when I needed to deliver.
I knew more than I expected
In the beginning, there was the question: “Do I have anything to say?” Can I write a whole book? It turned out, I can. And there is more left to say (it’s a threat).
I didn’t expect I would have this much to say. My book may be long-winded (and can be cut by half), but to me, it’s proof that the knowledge I have is real. A soothing balm for my impostor brain, and something I can improve and refer to for the years to come. All it took was to write it down.
Good things happen when you create
“Fortune favors the brave,” and the universe moves in interesting ways when you get out there and create something, even if you don’t think it’s too valuable. Your actions generate goodwill and inspire others to take action.
One person told me my book was the only one they read in 2020—and they liked it!
Jeroen asked me to talk with him for his podcast (which was a first for me—see the transcript here), and then got sufficiently inspired that he decided to write a book about being a lead developer.
A friend told me that I was the first person they knew who decided to write a book and wrote it. That’s worth something?
I like being pleasantly surprised, and making things creates the most serendipity.