What I’ve Learned From Publishing My First Book

Source: https://pbs.twimg.com/profile_images/603762570890117120/L5AKX-6w.jpg
Source: https://pbs.twimg.com/profile_images/603762570890117120/L5AKX-6w.jpg

I had a wish starting from 5th grade: to publish a book. A wish finally fulfilled this year when my first book, “Usable Software Design” became available on leanpub.

But this is not a blog post about the book per se. It’s not even meant to convince you to buy it (although you should). It’s more about convincing you that you have to publish your own book. It’s fun, it helps you discover yourself, and you might make some money from it. Seriously, start today. And if you think that you can’t, or that you have nothing to say, or that it won’t make money, etc. then read on, because I’ve been there too.

Adapt to Your Constraints and Preferences

Creating anything is hard. But it’s not hard where you expect.

Contrary to what most people think, ideas are easy. Ideas are everywhere. Inspiration is everywhere. Ideas pass from mind to mind and adapt to the recipient’s personal experience all the time. More ideas combine into a new idea. Ideas are easy and cheap and don’t account for much. Execution is what makes ideas valuable.

The idea of “Usable software design” came from a few happy accidents: curiosity (reading about general design practices), something someone said (the SoCraTes UK community and many people) and applying UX ideas in software design. (Incidentally, applying ideas from a domain a seemingly completely different domain is an innovation pattern applied over and over throughout the history of innovation).

It is much more difficult to execute on an idea than to get an idea. Maybe you don’t have time (and I don’t), maybe you doubt anyone would read it (and I did), maybe you want success so much that you can’t even start doing it (and I avoided this thought by lowering my standards for success).

Getting your idea into a book and in the world requires a favourable context. This favourable context rarely appears by itself; instead, you have to intentionally set it up. Sometimes, figuring out your favourable context requires trial and error. This is just another way of saying that you need to understand your constraints and preferences and adapt to them. A common mistake is to use willpower instead of adjusting; unfortunately willpower is a limited resource and it will not work in the long run.

This is how I adapted to my constraints and preferences:

  • No deadline. Not even an estimation. It was an important side project, but unpredictable with the data I had at that time, so no reason to add artificial time constraints.
  • Write when I felt like it, and I had nothing else to do. In my case, this meant week-ends, usually Sunday morning.
  • Intrinsic motivation. I wanted to publish the book. I wanted to write about an innovative topic. I love the “Usable Software Design” idea.
  • Clear quality constraints. I wanted the book to be short, clear, expressed as simple as possible and easy to read while commuting. In a word, I wanted the book to be usable.
  • Clear definition of audience. This was the hardest part. The book is innovative, thus its audience will hopefully grow in time. Software craftsmanship communities and conferences were a start, but I knew the conversion rate would be low
  • No expectations of profit. A few books make authors rich. Others make them a living. Most of them make little money. I know that, and it’s OK; my goal is not to get rich from this book. Hopefully, after writing more books I can generate a nice extra income while getting better known in development communities.
  • Keep full ownership. I decided I wanted to keep full ownership on the book. This is not definitive; in fact I’m considering publishing it under creative commons or an open source license in a few years. This is very difficult once you sell your rights to a third-party. Preserving full ownership allows me to keep my options open.
  • Tools. I used markdown, pandoc, vim and a bash script to build the book. The bash script takes the markdown file and generates all formats (pdf, printable pdf, epub, mobi) on my computer. I use dropbox to back up everything. (I didn’t know I would publish the book on leanpub when starting. Even now I prefer my way because the feedback cycle is shorter than on leanpub.)

You don’t have to do the same as me. I hope however these ideas will get you inspired and you’ll create your own favourable context.

Embrace Your Flaws

I read a lot about writing, and I discussed with authors I know. Stephen King writes each day for many hours. JB Rainsberger told me how he started writing a small book and ended up with a huge manuscript he then had to edit and index manually, the latter being the most boring operation he ever did in his life. Jurgen Appelo keeps talking about how he planned his first book in detail and finished just in time before the deadline to pour himself a cup of coffee.

I’m a flawed human being. I’m not disciplined when it comes to writing. I hate planning in general. I understand why and when planning is useful and I do it, but it’s against my nature. I definitely didn’t want to plan a side project. I get easily bored. I knew there was a risk that I’d get bored while editing and just stop.

I could do one of two things: either wish that I could magically transform into my ideal image of a writer, or embrace my flaws and just do it. I chose the latter.

I forgot every writer story I knew. I didn’t plan anything. No outline, no time slots set aside for writing, no set structure. One Sunday morning, I started writing. When I stopped, lots of hours later, I had all the important parts written. Not perfectly written, not even in correct English. That structure makes up to 80% of the finished book.

I learned an important lesson then. It works for me to just start writing. If I have a clear idea, the draft will have a good structure I can work with. If my ideas aren’t clear, things will get confusing and I will need to stop. And that’s OK – it’s my process. It’s the process of a flawed human being, and it’s by definition imperfect. But you know what, it has a huge advantage over all the perfect processes of the perfect writers: it works for me.

It is not your process, because your flaws are different than mine. So build your own process. Forget what you know about authors, writing, and advice for new writers. If you need structure, visualize it; mind maps or visual storyboards are extremely useful. If you don’t need structure, or if you don’t have enough patience or time to build it, start writing. When you get stuck, stop and let the ideas sink and grow for a while. Trust that time will bring a resolution. That’s the most stripped down process and planning to start writing.

Crappy First Draft

As I mentioned, the first result was far from being publishing material. I learned it has a name from a publication coach named Daphne Gray-Grant: crappy first draft. (If you feel you have to learn more about writing, read her blog, subscribe to her newsletter and stop reading anything else about writing. I’m serious).

The word that best characterizes the crappy first draft is “raw”. It is basically a flux of conscience written down. It has many flaws, and that’s OK. It’s grammatically incorrect, and that’s OK. It has typos, and that’s OK.

Despite all its flaws, it was awesome. Writing the crappy first draft felt liberating. I had something to work with. I was on my way to become an author.

The key to write the crappy first draft is suppressing your instinct to edit while you write. Instead, write first and edit later. Editing while you write will slow you down. Editing is easier than writing, so you can do it after a writing session.

Don’t search the perfect word. Don’t reread the previous paragraph. Don’t search for photos or links. If you feel you must improve it, write to do notes in the text [TODO: MUST IMPROVE THIS], [TODO: add story], [TODO: add link], [TODO: check this fact] and move on. Write for as long as possible (with or without breaks, depending on your needs). And when you’re tired, stop. Take a break. Start editing or leave the text to sit for a while.

The publication coach recommends that only the author should see the crappy first draft. She recommends editing it until it becomes a sharable first draft. I didn’t follow this particular advice. I did a quick review and edit before asking for feedback, but many typos and errors were still there. I felt it’s more important to get early feedback than to have a “perfect” first draft. It’s up to you to make your choice.

Get Help

Once I wrote the first draft, I asked for feedback.

I hand-picked my reviewers, from people I know and with whom I collaborate very well. In this phase, it’s easy for reviewers to find errors. Actually, I could have destroyed the first draft if I had my critic hat on.

It’s too early for that. You need your first reviewers to give constructive feedback and ignore obvious mistakes.

Following advice from JB Rainsberger, I made my feedback needs clear. I specifically asked reviewers for content-related feedback and to ignore English mistakes. I asked 3 questions:

  • Is the content clear?
  • Is there anything missing?
  • Is there anything that doesn’t make sense?

The feedback was generally good, although it clearly needed more work. I am very grateful to everyone involved, and I couldn’t have published the book without them.

I was on to a good start, and the rest was just polishing work. Simplifying things here and there, fixing typos and language errors, moving paragraphs, rewriting some portions, adding more examples, stories and a few complete sections. It was not difficult, and I was really motivated to do it.


After a few months, the time had come to publish the book. I looked for a cover design concept.  One of my colleagues with a taste for graphical design helped me. I ran the bash script one last time, uploaded the results to leanpub, sent the book to print. I was ready to launch it and give away printed copies at I TAKE Unconference 2016. Needless to say, I was happy.

The total work time was around 30 hours. The first writing stretch took about 40% of the time and 80% of the result. This time included in addition to writing and editing: learning leanpub, improving my bash script and learning about self-publishing in general.

The aftermath

The good news is that the book is selling. It didn’t make me rich, and that’s OK. I expected that – it’s only my first book, and on a topic that needs time to grow into the consciousness of the industry. I believe it’s a very important topic, a possible revolution in software development just like UX was a revolution in general design. But I can’t control the timing, only hope it will come soon enough.

The most important thing that happened is that now I have confidence. I know I can publish a book. It may not have been perfect, or a big money bank, but I did it. Knowing I can do it makes it easy to publish more books. In fact, in a couple of weeks me and my brother Adi will publish a book on facilitating coderetreats, just in time for Global Day of Coderetreat 2016. And I have more books planned.


I hope this blog post will convince you to write your own book. It’s fun, it’s rewarding and you might make a few extra bucks. Forget all you know, forget all your worries. Start writing, find a group that can help you and publish. (If you want to include me, I’d be honored.) Once you publish your first book, opportunities will open. Trust me on that.


I’ve been very motivated by an excellent story told by Kevin Smith in one of his Q&A sessions and captured on a video embedded in this blog post. A warning however: don’t watch it if you’re easily offended, because he’s well-known for his foul mouth and candid references to drugs and sex. He knows his stories though, and this one is very inspirational.

For those of you who can’t or don’t want to watch the video, here’s the non-offending brief version:

  • There are two types of people in this world: “why” people and “why not” people
  • Whenever you want to create something, the “why” people will ask you things like: “Why? Why do you think you can do that?”. The “why not” people will ask you “OK, why not?”
  • There are a lot of “why?” people and very few “why not?” people in the world
  • To create something, surround yourself with “why not?” people. In turn, encourage other people who want to create things – don’t ask them “why?” but “why not?”
  • Take your shot at creating something that you like, even if it’s whimsical or doesn’t seem to have a future. Opportunities you could never have predicted before will appear. The shot is worth taken.


alexbolboaca.ro Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: https://codedesigner.eu. My plan is to add more blog posts there, and to involve other people doing work in this area.

Read My Book “Usable Software Design”

How UX techniques can be applied to software design to develop software better (given that the developer is the user of software design).

Read My Book “Coderetreat Hosting And Facilitating”

Learn how to facilitate and host a coderetreat from two of the most experienced coderetreat facilitators.