2019 was an eventful year. At work, I had another good run with promotions with my team and I became a first-time manager of a first-time manager. This means that I now have skip-levels: people I don't directly manage. I also had a few dozen coffees with developers in Amsterdam that I did not know before, which mostly turned into career discussion sessions.
Increasingly, I started to feel that I though I have a lot of experience and advice to share on career growth for software engineers, I'm having less time to do this in-person. For every coffee I grabbed with people outside Uber, I had to say no to more of them. And while there are many great books on engineering and leadership, I found few good resources specifically on career growth. So I decided to scale myself better and set the ambitious goal of writing a book on professional growth for software engineers at tech companies.
This post is about the validation I've done so far and how you can help shape the content of the book, and how you can sign up for updates.
Validating the book topic with senior/staff engineers
Writing a book is a substantial time commitment. Before going all-in, I decided to validate my ideas with my network. I reached out to 70 engineers whom I worked together with at some point in the past decade and who have gone on to have successful careers. Most of them are now senior/principal/staff engineers or engineering managers.
I asked these questions about what they found the hardest things about software engineering, the best feedback they've gotten to grow, and things they wish they'd have learned earlier. I also asked the most important traits they see in people they consider great software developers. Finally, I asked what content they would expect to see on a book on growing as a software engineer.
The responses were interesting. From the feedback, the hardest things about engineering - according to these engineers - are dealing with change and with people. Something they wish they'd learned earlier was to test more, to lean on others more, and to keep learning even when feeling like an expert. They saw great software engineers as humble, empathetic, competent, good communicators, and servant leaders. Most of their expectations from the content were covered as part of my draft table of contents.
Validating the book content via blog posts
I started to publish blog posts on a few topics I would eventually write about in the book: code reviews, writing well, operating large & reliable systems. In August, I did a month-long sprint of writing 50,000 words on the topic and started to publish "blogified" versions of my writing. Almost all of the posts I originally wrote for the book were picked up and discussed on places like Hacker News and Reddit. I saw more traffic to my blog the past three months than the previous three years:
Numbers-wise, my blog traffic for the past three months has been 70,000-90,000 unique visitors per month. This year, I've had 11 articles with more than 10,000 unique page views. The most popular articles this time have been Software architecture is overrated, The product-minded engineer and Developers mentoring other developers. I've also gotten - and said yes to - translation requests to Russian and Chinese. Curiously, the Russian translation of Software architecture is overrated has seen half the traffic - 35K views - as the English version.
The source of traffic is quite diverse and seems in-line with technology hubs across the world. The top 7 cities I got traffic from, in order, were San Francisco, New York, London (UK), Bengaluru (India), Seattle, Berlin (Germany), Amsterdam (Netherlands). The top 20 include Toronto, Sydney & Melbourne (Australia), Paris (France), Warsaw (Poland), Stockholm (Sweden), and Moscow (Russia). If Google Analytics is to be trusted, there are 95 cities where this blog has seen 500 or more unique visitors the past quarter.
If I was looking for validation of people being interested in the content I'm writing, I've gotten it. Both in a quantitative way - number of visitors - as well as in a qualitative way. I'm having more people add me on Linkedin, saying thanks for the blog posts. Some people are also asking for career advice, which is an inspiration for my book content and future blog posts. And my monthly newsletter has grown to over 3000 subscribers in 3 months.
Validating the idea with publishers
Publishing a book can be done two ways: self-publishing or going through a publisher. The main pros of self-publishing are a larger share of royalties. The main pros of going through a publisher are more thorough vetting, better editing, and a larger reach, with more channels, like being included in Safari Online. Going with a publisher also involves a contract that can provide additional motivation to finish the book on time.
I was lucky enough to work with a professional editing team at Stack Overflow and saw the difference great editing makes. Read my original blog post on code reviews and the re-edited one on code reviews on the SO blog. The content is the same, but the result is different - and for the better. For this book, quality and reach is a more important consideration than a large cut of royalties, so I'm currently in the phase of looking for a publisher.
Going through a publisher is a more time-consuming process. It involves getting through to an acquisitions editor, putting a formal proposal together, that the publisher then vets through their proposal process. Publishers are in the business of making a living through publishing profitable books, and they approach book ideas like an investment. Is it a good investment to make for money and their resources (editors, marketers, prints)? They look at potential sales numbers, based on their experience, and the likely profitability of the book. They compare the content with other books in their pipeline. If it is a lucrative enough proposal, they will say yes. Else, they will likely pass.
I'm talking with publishers and the feedback I've gotten was the idea is interesting, and the topic not very conventional. Most publishers I'm talking with publish the majority of their books on specific technologies, and take on few projects that are outside of this format. I've put together a few proposals, which also helped narrow what I'm planning the book to be about.
I'm hoping to lock down a publisher/editor in a reasonable timeframe and have an estimated publish date beyond just "sometime in 2020".
Sounds interesting? Sign up for updates & help shape the content.
You can read details on the book and the table of contents and sign up for updates on the release date and other relevant information.
You can also help shape the content of the book, in two ways:
- Fill out this survey on your experience as a developer. Feel free to provide as little or as much detail as you see fit.
- Email me questions you have on growing, as a software engineer, or topics you'd like to see in the book.
In the meantime, expect more posts on software engineering growth on this blog.