My new book, Learning TypeScript 2.x, has just been released!
I'm not going to talk about the book contents in this post because you can learn everything about it at www.learningtypescript.com. However, I would like to talk about the behind the scenes process of how this book became a reality.
In this article I'm going to answer the following questions:
How did I end up writing a technical book?
What is involved in writing a technical book?
Is the effort of writing a technical book worth?
How can you write a technical book?
I decided to write this post because I think it could be useful for some aspiring authors. Let's get started!
How did I end up writing a technical book?
In this section, I will try to provide you with some background information that explains how I ended up being highly involved with TypeScript and receiving an offer to write a technical book about it.
My first JavaScript steps
I consider myself very lucky because early in my career I got a job at a company that had an extensive holiday booking system powered by JavaScript. I had spent the first couple years of my career working on PHP, Java, and C# web applications and this application was entirely different from anything that I had seen at the time. The application loaded "widgets" (a combination of HTML, CSS, and JSON) on demand using AJAX calls. It was basically a single-page web application (SPA) with "web components" however it was a couple of years before SPAs became mainstream.
The application worked very well. However, we regularly experienced some common JavaScript issues like:
Problems caused by the "this" operator pointing to the wrong thing
Type coercion issues like adding to numbers that were actually strings
Scope issues caused by the lack of block scope
This application gave me an early exposure to large JavaScript applications with client-side rendering. I found this "new" way of building web applications fascinating and I enjoyed working with JavaScript a lot, so I decided to focus on learning more about SPAs and JavaScript.
After some time, I got a new job, and this time I was going to work on a greenfield project. I had more room for choices, and I wanted to try to solve some of the problems that I had experienced in my previous project. I decided to build an SPA with "widgets" just like before but with two significant changes:
I decided to use a JavaScript module loader for the very first time (Require.js).
I also decided to use CoffeeScript because I liked the idea of not having to worry about lexically bind the value of "this" by hand thanks to the usage of arrow functions.
CoffeeScript didn't work for me
Af first, CoffeeScript did help to a certain extent but it never fully solved all my problems. However, after a few months CoffeeScript became a problem. I found that debugging some issues was becoming more and more complicated as our code base got bigger. It was also quite hard to find developers with previous experience with CoffeeScript. So I ended up removing CoffeeScript and going back to vanilla JavaScript with Require.js and AMD modules.
TypeScript came to the rescue
It was only a couple of months later when Microsoft showed TypeScript for the very first time. TypeScript didn't manage to get a lot of interest from the web community initially. I think this was because Microsoft had a bad reputation within the web development community. Many saw TypeScript as something completely different from JavaScript because when TypeScript was announced most people were unaware of the details of the ES6 specification. When they saw a code sample with classes in TypeScript, they thought that it was TypeScript while, in reality, it was ES6. As a result, they felt that Microsoft was not trying to improve the ecosystem but to replace it with a new ecosystem while the reality is that Microsoft was quite visionary!
I was aware of the mistakes of Microsoft in the past, but I was also familiar with the good side of Microsoft. I had some experience with C#, and Visual Studio and the developer experience od these tools was simply amazing. On top of this, I was already a fan of Anders Helsberg (the father of C# and TypeScript), and while JavaScript and frontend development are my passions, my adventures in the backend with C# made me miss and envy the type safety of C#. Finally, TypeScript was announced as an Open Source project able to run on Windows, Mac, and Linux, which might seem like something obvious today, but back on the day, it was pretty unusual for Microsoft.
I started to use TypeScript as soon as the first preview was released and it was a pretty exciting announcement for me. It was able to solve some of the problems that I experienced in the past, it was open source, and it improved the existing ecosystem as opposed to trying to replace it. It just ticked all my boxes.
Being an early adopter paid off
I started to learn more about TypeScript, I wrote a few of blog post about it, and I highlighted it as one of my skills on Linkedin.com. Then, one day I got an email from Packt Publishing. They told me that they were looking for technical reviewers for an upcoming TypeScript book.
Packt Publishing found me because I highlighted TypeScript as one of my skills on Linkedin.com. Today thousands of people have TypeScript as one of their skills on Linkedin.com, but a few years ago there was only a small number of early adopters. I'm sure that this significantly increased my chances of being contacted by a book publisher. Before this event, I didn't care too much about Linkedin.com, but ever since then I learned a valuable lesson:
If you want to increase the chances of great things happening to you, you will need to work hard, but you will also need to let the world know what are you working on.
I thought that being a technical reviewer was a fantastic opportunity. I always wanted to write a technical book. It was one of my lifetime goals, but I thought that it was completely out of my reach and many years ahead of me so I saw becoming a technical reviewer as something that could help me to get there faster.
I was not expecting it, but I ended up being offered the opportunity to be an author straight after my first job as a technical reviewer.
TypeScript becames mainstream
The first edition of Learning TypeScript was published just a couple of months before TypeScript became mainstream.
Over time the web development community became aware of the new ES6 features, the size of the average JavaScript application grew exponentially, and Microsoft started to embrace open source. However, it was only when the Angular team at Google announced that they were going to adopt TypeScript that it became mainstream.
I think the fact that Google adopted it helped the community to trust TypeScript and start to see it as what it really is: a truly open source technology that adheres to open standards.
What is involved in writing a technical book?
In this section, I'm going to try to describe the process of writing a book and the amount of work that is involved in it.
There is a rocky road ahead of you
Everyone can write a book; you don't need to be a genius. However, you are going to need time, patience and perseverance. For example, the Manning Publications website says that you are going to need:
Time and writing skills, or at least the time and will to acquire them.
While the Wrox website says the following:
If you're a programmer and you're interested in writing for Wrox — even if you've never written anything before — feel free to contact us. We'll be more than happy to take you on as an author if you know the technology inside out. Wrox authors aren't writers by trade — they're programmers, and our unique editorial process will get the best out of you.
I believe that time is and perseverance or will are the essential skills. I would also like to point out that I think that you are not going to be able to do it alone.
The book sales will generate some direct additional income for you. I cannot say the exact figures here because they are under an NDA. However, I can say that you can make enough money to go on an exotic holiday but not enough money to buy a car or pay your mortgage.
You are most likely going to need to keep your fulltime job to be able to pay your bills, which means that you are only going to have time to write in the evening after work and during the weekends. You probably also have other responsibilities outside of work which will take even more of your time. I don't know how others deal with this lack of time, but in my case, I went to bed very late and didn't sleep very well for months.
You will feel tired, and you are not going to spend as much time as you would like with your family and friends.
As you can imagine this is hard and this is why I think that you are not going to be able to do it alone. In my case, it only worked out because I had the support of my family and friends.
My advice about this is to be prepared. Expect a long, exhausting road ahead of you. It is going to be a big sacrifice for you and for the people that care about you. Troy Hunt has some good advice about this kind of sacrifice:
So many times I hear people who want to get more involved in the sorts of things I’ve been doing say “I can’t, my wife / husband / kids would go nuts”. That’s a perfectly fine position for the significant other to take and by no means is that a bad thing when that’s your shared vision. It’s when one party continually wants to head in a direction that the other doesn’t support that things get tricky.
I had many years of working my arse off at all hours in order to reach this point and that put a lot of pressure on my wife. We have two small kids and she was working in a pretty high-level job until recently too; my drive and ambition became her responsibility as well. And she supported me – almost unquestioningly – because ultimately, we share the same vision of how we want to live. It took many years for that effort to bear any fruit beyond my own personal sense of satisfaction which whilst important, doesn’t do a lot for the family as a whole. It’s only been over the last 18 months that she (and the kids, for that matter) have seen a return in a way in which we all benefit. Obviously, an important part of that is financial, but it also translates into flexibility which means more time with the kids, more holidays and more generally just doing what we want, when we went. It’s been her sacrifice as much as it has been mine.
And now I’m helping her to do the same, at least insofar as focusing on her public profile and building independence from corporate life in the way we’ve both previously known it. If you appreciate what I’ve been able to do over the years, tweet her a quick thanks because boy does she deserve it!
Tip: Talk to your significant other about where you want to invest your time and how that benefits you collectively. Don’t do this and don’t let it come between you; agree on where you’re heading together.
The writing process
The process of writing a book is intense and long, but it is not complicated.
Create an outline: In my case, the process started by ordering all the existing TypeScript books in the market (at the time there was only a couple of them). I created a list of the content covered by each of the books, the parts that I enjoyed, the parts that I did not enjoy and the missing parts. Then I used all this information to put together the initial outline. Creating an outline that progressively introduces the contents is crucial. The outline must be approved by the editor before you can move to the next phase.
Planning phase: In this phase, you need to come up with estimates for each chapter and create a calendar with the delivery date for each chapter. In my case, writing the initial draft of a chapter took between two and three weeks.
Initial draft phase: Once you have the outline, you can start writing the chapters. Each chapter must go through an initial QA check from the book editor. The chapter then enters the technical review phase.
Technical review phase: While you write the next chapter, a group of technical reviewers with different levels of expertise and different backgrounds will read the chapter and let you know how they feel about it.
Pre-final phase: Once you finish all the chapters, you will have to incorporate the feedback from the technical reviewers to the chapter, and it will enter the pre-final phase. At this point, you have your last chance to upgrade the outdated content and fix any remaining issues.
Final phase: You will then get the final version, and if you are happy with it, it will be sent to print.
Unfortunately, the review process needs to be quite fast because some technologies evolve at a very fast pace. For example, TypeScript is released every two months. If it takes you two months to review all the chapters, your book will be outdated before it is released.
This whole process (from outline to release) took me eleven months for the first edition and another extra eleven months for the second edition.
I found the reviews and content upgrades to be harder than writing the initial drafts. My advice about this is to try to don't panic. Your book is never going to be fully updated and entirely perfect. Work hard, try your best and enjoy the journey.
Is the effort of writing a technical book worth?
In this section, I'm going to try to explain all the benefits that I have experienced as a result of becoming an author.
The direct financial benefits are not great
As I said earlier, from the economic point of view it is not really worth it. If you divide the income generate directly from the book sales by the number of hours that you are going to put into the book you will find out that the pay per hour is not great. However, the book will provide you with some significant indirect benefits (including indirect financial benefits).
You will learn a lot
There are things that you understand and use every day. However, if you write about them and try to come up with an easy explanation, you will realize that you don't understand some of these things as good as you though and as a result, you will end up doing some more reading and having a better understanding.
You will also have to go deeper into detail because a technical book is a more formal medium than our emails, slack chats and blogs posts. This will lead you to learn some low-level details that you could afford to ignore before. As a result, you will learn a lot, and this knowledge will also help you to get a better job.
It will help you to get involved in OSS
While I was working on both of the editions of my book something unexpected happened. Besides writing a book, another thing that I always wanted to do was to contribute to an open source. I knew how to contribute (using Git, GitHub...) but I never felt that I had an idea worthy of being released as open source. However, I had an idea while I was writing the first edition (InversifyJS) and another idea while I was working on the second edition (TsUML).
I believe that this happened because when you write a book, you have to think about the future. You need to keep an eye on the product roadmap and ensure that your book will be up to date when it is released.
For example, I started to write a chapter about decorators before this feature was added to TypeScript. I wrote the chapter using some public design notes that were available online at the time. It was then when I had the idea of creating and IoC container powered by decorators and for the very first time I wasn't too late. I searched online for it, and Angular was planning something similar, but nothing was available at the time, so I started working on what became InversifyJS. Today InversifyJS has over two million downloads on npm.
It will help you to be more confident
Another thing that happened to me was that the book somehow helped me to overcome my impostor syndrome. I was not afraid anymore about doing things like sharing my thoughts with the community at blog posts, local user groups or conferences and I decided to start the Dublin TypeScript meetup.
Overcoming my impostor syndrome was for me the best benefit provided by the book and eventually led me to become a Microsoft MVP.
The indirect financial benefits are great
The income generated directly by the book sales will most likely not be great. However, the indirect benefits such us learning or getting involved in OSS and the community will help you to become a better professional.
Having a book, some OSS projects and conference talks in your CV will help you to stand out and get a better job. This means that the book will lead you to some great financial benefits not directly related to the book sales.
How can you write a technical book?
I was not expecting to be offered to publish a book so soon. I thought that it was a privilege reserved only for very well-known engineers like John Resig, Camille Fournier, Jon Skeet or Martin Fowler but I was wrong.
The reality is that a lot of times these very well-known engineers are too busy to write a book, or they don't want to do it because writing a book is a very exhausting activity.
In fact, there is a high demand for technical authors and not many authors available.
I believe that the lack of authors is not caused by a lack of skills it is more a lack of confidence. Just like me, I'm sure that many other engineers would like to write a book and would do a fantastic job if they had an opportunity but they don't feel ready. This is just another instance of the infamous impostor syndrome.
Being an early adopter of technologies
Becoming an early adopter is not always an option. Some critical solutions cannot rely on immature technologies. However, nothing is stopping you from trying something new on your next hobby project.
Being an early adopter of open source technologies will help you to identify potential ways to improve the technology and fix issues, which will give you clear opportunities to contribute to the project.
Sharing your experiences
Being an early adopter is only the first step. Do you need to let the world know how is it going for you? How can we get started with this technology? What are the benefits of this technology? Which patterns have you noticed to be effective? When you are an early adopter, this kind of things are not available online, but you will create them.
If a publisher wants to release a book a few years later, your name will most likely come up on his google searches. You need to let the world know what are you working on and what interest you. That is the only way that they will be able to find you and contact you if they have an opportunity for you.
Becoming a technical reviewer
You can become a technical reviewer right now. Trust me; you can contribute to a book right now.
If you don't feel you're ready to become a Wrox author, or you'd like to be involved but just don't have the time to dedicate to writing a book, you have some alternatives. You can become a technical editor, using your programming knowledge to review and validate a book's technical material. Your feedback would play a very important role in the quality of the final book.
Even if you are a junior developer, you can be a technical reviewer. The book will most likely be read by other junior developers so having your input will help the author to ensure that the book is suitable for the less experienced sector of the public.
You can become a technical reviewer by contacting the publishing companies. Here are some examples:
Becoming an author
I highly recommend working as a technical reviewer first because it will help you to get familiar with the process. As I said earlier you don't need to be a genius or to have amazing writing skills. All you need is:
Time and will to acquire them (writing skills).
If you're a programmer and you're interested in writing for Wrox — even if you've never written anything before — feel free to contact us. We'll be more than happy to take you on as an author if you know the technology inside out. Wrox authors aren't writers by trade — they're programmers, and our unique editorial process will get the best out of you.
The recipe for success is time + will + support from your family and friends.
Trust me; you have way more chances than you think. The publishing companies are having a hard time finding authors:
You can become an author by contacting the publishing companies. Here are some examples:
Maybe you are wondering which publishing company you should approach first. I cannot provide you with much advice because I have only worked with Packt Publishing but my experience with them has been enjoyable and I would happily work with then again in the future.
Summary
Writing a book takes a lot of time and effort. It is a big commitment but overall it also a very positive experience. If you have ever dreamed about publishing your own technical book, don't be afraid, contact the publishing companies and give it a go. You can do it!
Did you enjoy this article? Do you have any questions? Please let me know using the comments below or at @RemoHJansen.
Thanks for reading!
Top comments (11)
Hi Remo, first of all: Congratulations on your achievement!
I'm curious, could you provide a ballpark number on the total hours you put in over the course of your eleven month writing and editing process?
Hard to say but it was very usual for me to spend a minimum of 1-2 hours per day (Monday to Friday) and 3-4 hours on Saturday and Sunday mornings.
That gives me a minimum of 484 hours:
(((1 * 5) + (3 * 2)) * 4) * 11 = 484
A maximun of 792 hours:
(((2 * 5) + (4 * 2)) * 4) * 11 = 792
It is also true that some weeks I took a break (e.g. Xmas) so maybe the number is a bit smaller. Let's say something between 400 and 700 hours per edition.
Awesome write-up Remo, bookmarked!
For a technical book that I wrote recently I ended up using a weird combination: { HAML + STYLUS + javascript }. The results were surprisingly excellent, especially over markdown, where many a times I'd have to insert full HTML tags to get the content right.
HAML is way more expressive than markdown and I can only imagine the possibilities with it!
Interesting to hear your experiences and the process you went through for writing the book. I was involved as a technical reviewer for a Packt book a few years ago and have often wondered what it was like for others.
As a reviewer I found it hard work, particularly the unrealistic turn around of 24 hours expected for me to review a whole chapter, including checking that the code worked which often it didn't - it was littered with bugs.
While it was great to get a mention in the front of the book as one of the reviewers, sad to say that the experience put me off working with Packt again.
As you mention they found me through Linkedin because I was an early user of the technology involved. I suppose it was great to help others learn it by contributing to the book.
Congrats on the launch of your new book and I hope it does well.
Thanks! I think the short deadlines for the reviews is due to the pace of movement of some software these days. As I said I found the review phase harder than the writing phase because the deadlines are much more relaxed during the writing phase.
Congratulations on becoming a published author! Also, thank you for such an in-depth article about your journey becoming a writer and posting the resources for those who are interested in taking that path. Having read that it got rid of your own Impostor Syndrome plague gives others another coping tool when the feeling flares up.
Thanks! Happy to help others :)
Congratulations on hitting that milestone Remo! Thanks for sharing your journey with us. Was not aware this form of Technical Review was a thing.
Congratulations and thanks for this great and helpful article Remo!
That was really inspirational. I will make sure I will read it, before I start writing mine :)
Big congrats on this achievement and thanks for sharing your lessons learned with us.