Featured

I’m writing the book I wished I’d read

Dear new developers,

Update July 5, 2020: I now have a launch date and a cover.

You may have noticed the pace of new letters has slowed down a bit. There have been some fantastic guest posts, but there’s only been one new letter per week for a while. There’s a reason for that.

I’m excited to announce that I’m writing a book. It’s the book I wished I’d had when I was beginning my development career.

It’s based on this blog, with ideas, text and guest posts drawn from it. The format is similar: letters covering a variety of topics. However, all the content has been thoroughly reviewed, organized and revised. You’ll also see new letters covering topics left untouched by this blog.

I just shipped off the first half of the book to the publisher. If you want to be in the loop, contact me to be put on the book announcement list.

– Dan

Read great books about software development

Dear new developer,

Read books about software development.

Seriously.

Now, you won’t learn the latest techniques from books. Those will live online in blogs or videos (or in papers, if you work in an area like machine learning influenced by academia).

Nor will you learn a lot that you can put to immediate use to solve the problem right in front of you (that will probably be found in online docs, github issues, or stackoverflow).

What you’ll learn from the great books of software engineering are timeless practices. You’ll also learn how to dig in to a topic deeply, and how to take what is in the book and discern what can be applied to your work (and what should be ignored). I’ve had discussion groups about software books, which can be a fun way for people to bring their own experience (and be accountable; sometimes great books can be hard to get through).

There are a number of great books out there, but here are three:

  • The Mythical Man Month
    • Covers a major software project from the 1960s, including how hard it is to build good software and the fact that when a project is late, adding more developers will increase communication needs, which will delay it further.
  • The Pragmatic Programmer
    • Discusses software best practices and ways to level up your software development. Has a great set of checklists.
  • Refactoring
    • Talks about the practice of refactoring, which can be thought of as software maintenance (in the same way that you need to take care of your car, you need to take care of software). How to do it, when to do it, how to talk about it–these are all covered.

As a bonus, here’s a great software essay on the essential complexity of building software, There’s No Silver Bullet.

I suggest asking engineers you respect what books they’d recommend you read to deepen your understanding of your craft.

Sincerely,

Dan

Write a technical ebook

Dear new developer,

I suggest you take some of your ample free time (if you have it) and write a technical book. I’ve written one book and doing so gives you a deep understanding both of the technology you choose to write about and of the difficulties of doing so. It will give you instant credibility should you choose to pursue a job related to the technology. You can use it to make connections and give speeches at meetups.It may even make you some money, but don’t count on that.

Pick a technology that you use at work or on a side project. Characteristics you are looking for:

  • few books have been written about the topic
  • you are really really interested in the topic and want to master it
  • it is something you use regularly
  • the technology is either really new (and you think you might be able to do multiple revisions) like React, or is really old and slow moving (like bash)
  • it’s something relatively popular or new

I made a number of mistakes when I wrote a book about command line hooks in cordova (which is a framework for writing mobile applications). The mistakes I made included:

  • the market for cordova books was small, and the subset of people interested in automation of cordova actions was even smaller (even so, I found about 70 people willing to pay for the book)
  • I picked the technology because we were using it at the time, but after one project we stopped. I wasn’t really interested in mobile development, and so never updated the book.

Topics that aren’t technical are more evergreen (how to manage a software team has changed in the last 20 years, but how to build a javascript application how changed in the last 12 months), but there are more books out there about them as a result. Technical books have a shorter shelf life but also have less competition.

However, if you can find a topic you want to write about, don’t start writing the book from scratch. Instead, outline it and write a number of pieces of the book. An easy way to do this is to create a category on your blog (you have a blog, right?) and start writing regularly about the topic. Write an outline and add blog posts based on the outline.

After four or five blog posts, you’ll know if this is a technology you want to dig into and publish a book about. Keep writing the posts, but start looking for communities where the technology is published. Start answering questions about it on the forum and/or your blog. Set up an email list to capture people who are interested in your topic and visit your blog.

The risk is low. If, on the other hand, you write two articles about technology X and you are bored out of your mind, then just stop and don’t create the ebook.

Once you have about 20 posts, you can start thinking about pulling them together to form an ebook (the exact number depends on the size of your topic). I used leanpub and had a great experience. Note that you’ll be entirely responsible for not only writing the book, but marketing it. However, you get to keep something like 90% of the price of the book. Leanpub can pull an RSS feed into the leanpub format and you can use it to suck down the posts you’ve been writing.

After you do that, it’s really about continuing to fill out the outline, updating your forum posts to include a link to your book site, and marketing the book. I’m no expert there, but made about $700 bucks from my ebook. I don’t think I ever calculated the exact hourly rate, but I can say with confidence that it was far lower than I could have made contracting.

So, in the end, why is it valuable? I think writing a book, even a 40 page ebook like I did, challenges you to think deeply (to understand the technology and convey it in a way that other people can understand) and broadly (similar to holding a really large software system in your mind). These are both really good skills to acquire.

Sincerely,

Dan