What things you should consider when planning to self-publish a tech book? How to validate is there enough interest for the topic? Very inspiring discussion with Tero Parviainen author of Build Your Own AngularJS.
Brief introduction to Tero:
Tero Parviainen is an independent software developer who has been active in Angular and Clojure communities. He has written two books (Build Your Own AngularJS and Real-time Web Application Development using Vert.x 2.0), organizes Clojure Cup and also has given some great talks on various conferences.
Question: What were the reasons for writing your latest book "Build Your Own AngularJS"?
I was getting into Angular and wanted to learn it on a deeper level than what most tutorials give you. The main reason for this was that I’ve had issues with some technologies I’ve used during my career, like Rails and Hibernate, that were caused by never really understanding how they work. There’s often too much magic involved, and I find it uncomfortable to use a framework that feels magical. I didn’t want that to happen with Angular, and based on what I was reading it looked like it might. I decided to actually dig into the source code.
So I started a process of reverse engineering Angular, to try to figure out what it does and why it does it. Then it occurred to me that I could write about what I’m learning, since I was going through all that trouble and other people might find that stuff useful. So I wrote an article about Angular’s change detection. It was received really well, and people started asking for more.
At the same time I’d just become an independent consultant and was interested in exploring alternative sources of income. I had written a short book earlier, and thought that it might be something I was both willing and capable of doing. So I decided to extend the Angular articles into a book project.
Question: Did you start writing the book before Angular 2.0 announcement and following "community shitstorm"? If yes, how did it affect writing process of the book?
Yes, I started writing the book before Angular 2 was announced. I released the first chapters in January 2014. I think the very first ideas regarding Angular 2 were publicised in ng-conf in that same month, but the more concrete announcements were only made last autumn.
It hasn’t really affected the writing process much, as the book doesn’t cover Angular 2. Angular 2 is a completely new implementation of the Angular concepts (which is also the reason some people got upset about the announcement), so to cover its implementation you need another book.
Angular 2 has only recently become pre-alpha, and it’s still very much in the experimental stages. This kind of book can only be written about a relatively stable technology, whose codebase isn’t undergoing major changes all the time. Also, to get the most out of this kind of book, you need to have some prior experience with the technology. It’ll take one or two years before Angular 2 is in that kind of place. In the meantime, Angular 1.x isn’t going anywhere.
Question: How has the book and the publicity you have received affected your freelancing career?
The book - as well as the articles and conference talks around it - have certainly increased my online presence a bit, especially within the Angular community.
In terms of direct effects to my consulting work, there hasn’t been many yet, but that’s mostly because I’ve been working the same full time contract for this whole period, and haven’t been actively looking for work.
In the long term, I guess the effects will be positive. Someone may think of me when they have front-end work that needs doing. That’s actually something I’ve seen happen already. Also, when a potential client googles me, they’ll see stuff I can be proud of.
Question: Any advises for those who are thinking about writing a self-published tech book? Anything you would do differently?
Most importantly, Hofstadter’s law applies. It’s a big undertaking - probably bigger than you expect. My biggest problems have been about not understanding the full scope of the project, and the deadline slips that have occurred because of that.
I think you need to validate that there’s interest in the topic you’re planning to write about. Write articles and see what kind of response you get. If there isn’t a strong one, it may not be something people would be willing to pay for.
You need to write a lot more than just the book. Write articles around the topic. I have a couple of relatively popular Angular articles out there, and they’ve probably been my biggest driver for book purchases. Also, if you, like me, aren’t already well known in the community you’re writing for, having good content online helps people see whether your work is something they’d be willing to pay for.
As to the writing itself, all I can say is work on it a little bit every day. Even if it doesn’t feel like you’re making much progress, it adds up. Also, doing one hour every day for five days is better than doing five hours in one sitting, since it lets your brain process the content in the meantime. Then, once you do sit down and write, you will write better.
Finally, what they say is true: The first draft is always shit. Get it out without thinking too much about how good it is and how well it reads. Once that’s done, start revising. It’s just easier that way.
Question: Can you give short overview what Clojure Cup is?
Clojure Cup is an online hackathon where Clojure and ClojureScript programmers from all around the world can team up and build something from scratch in 48 hours and put it up on the web for the world to see. It’s like Rails Rumble or Node Knockout, but for Clojure and ClojureScript.
Question: You have organized Clojure Cup two times. How did it get started and what is the future of the cup?
I’d had this vague idea of doing “Rails Rumble for Clojure” for a long time, and a couple of years ago I had some time on my hands and thought I’d test the waters. I contacted a few Clojure open source luminaries, and asked them whether they’d be interested in judging a contest like that.
Maybe half of the people I contacted said yes, so next I set up a teaser website announcing the idea and the dates, as well as the names of the people who’d agreed to judge. It got on the front page of Hacker News, which meant it was seen by tens of thousands of people that day. At that point I felt like it was something I actually had to do. It all basically just went from there.
I’ve organised the Cup twice now, and it’s been fun. I would very much like to see a third one this fall. I’ll probably hand over the head organizer responsibilities to someone else this time. Finding a successor and working with them to make sure everything goes smoothly is something I’ll start doing very soon.
Question: Have you used Clojure or ClojureScript in a production software?
What kind of things you consider when selecting development stack for the greenfield project?
I don’t have a repeatable process for that, but it’s always some combination of technical suitability, maturity, and, to be honest, just gut feeling. The customer’s existing software stacks matter a lot too. If not directly in terms of technical interoperability, then indirectly in terms of how well they’ll be able to maintain and develop the new stuff.
I’m actually fairly conservative when selecting technologies for customer work. I think it’s important to realise I’m making decisions and recommendations that will have impact for years to come. I don’t want to use some new thing just because I think it’s cool, if there’s a big risk the customer will end up with something that’s difficult to work with because it doesn’t have a strong community behind it or they can’t find the people they need to maintain it. I sometimes find that I’m really more conservative about tech choices than the customer actually wants me to be, but when that happens I’m usually happy to concede. :)
Any links, blog posts, products, services etc. (yours or someone else's) you want readers to check?
For anyone interested in front-end development, I’d recommend checking out David Nolen’s presentations about ClojureScript and Om. The combination of ClojureScript and React seems to be an explosive one, and to most front-end developers it’s a bit of a paradigm shift. It's always healthy to expose yourself to new paradigms.
I’ve been betting into Gitchat lately, as there’s a chatroom for HelsinkiJS and another one for Clojure Finland. It has the potential to be a really nice new communication channel, especially for people like me who could never really be bothered about IRC. I used Gitchat for Clojure Cup 2014 too, and it worked out great.
Wow, there's plenty of ideas for the mind to process. I'm definitely going to check those resources Tero mentioned.
Thank you Tero for your time! If any of you readers have questions I am pretty sure Tero would like to continue the conversation in the discussion section below or in the hacker news.
Remember to check also other interviews!