Software engineers don’t like writing. We love writing code—sure. But writing a technical documents? Not for me!

However, the more senior you become, the less code you actually write. No, you don’t work fewer hours. You just write more technical documents: design reviews, runbooks, general technical documents.

If I have to look back at my career—and identify one skill, other than coding, that helped me in my journey of becoming a better software engineer—it would be writing. Technical writing, to be specific. Through technical writing, you can:

1. Demonstrate your knowledge and expertise
2. Improve your communication skills
3. Leave a legacy inside your company
4. Open yourself to cross-team collaboration

This handbook is my attempt to share my knowledge and tools with other software engineers who are willing to take their career to the next level.

Why trust me?

I started writing code professionally 14 years ago. Throughout my career I worked in very different companies: small family owned, small startups, big startups, and an American corporate.

I had great mentors along the way, who helped me perfect not only my coding skills, but my career. One of the tools that helped me—was technical writing. From a newbie who hated writing anything non code—I perfected my writing skills and became one of the best technical writers in my team.

I wrote design reviews; runbooks for the entire team; technical documents to promote my personal agendas and move the organization forward. One of my design reviews was named as the gold standard design review, and became an example to all other design reviews.

I like writing in general. I’ve been writing for at least 20 years. Many of my writings were thrown away, but those that survived live in the two blogs I write, one of them is this technical blog. This blog grows organically, and my readers praise my writing to be concise and actionable.

Who is this for?

If you are a software engineer, who want to take his/her career to the next level, and struggling with technical writing—this handbook might help you become a better technical writer.

This handbook is less suited for engineers who are experienced in technical writing. However, I believe that we, as humans, are constant learners—and reading the techniques and tools of other people, might help you perfect your craft, even if you feel they are already perfect. So consider getting this handbook anyway.

Disclaimer:

This handbook is not a magic pill. It won’t turn you into a writing machine overnight. It’s filled with examples and guidelines, but these are only tools and knowledge. You still need to put in the hard work of actually writing, editing, throwing away, and writing again—in order to become a great writer.

Lastly, this handbook is mainly textual. Please understand that different people—learn differently. If you are a visual learner, or never read a book in your life—this might not be the product for you.

What you will learn?

This handbook is short and covers three main types of technical documents:

1. Design reviews
2. Runbooks or protocols
3. General technical documents

Together, they make the majority of all the technical writing you will have to do in your career. Each chapter covers the unique traits of each document, analyzes bad examples of writing, and gives tips and guidelines on how to improve it.

F.A.Q.

I hate writing. Will this handbook help me?

If you hate writing, this book won’t help you fall in love with writing. You need to understand that writing is an important part of a career of a software engineer. If you refuse to write, or avoid it—you will be, most likely, stuck in your career.

Is there a refund policy?

Yes. You have 7 days to return the book for a full refund. But I’m sure you will gain value from it, and won’t have to return it.

Is this handbook suitable for non-tech people?

This handbook is targeting mainly software engineers. Other tech people, such as DevOps, who encounter the need to write technical documents—might also benefit from it.

If you are a product manager, project manager, sales, or don’t write technical documents—this handbook won’t be of much help to you.

I can’t afford to buy this handbook.

This handbook is not a must-have in order to advance in your career. However, it contains the knowledge, and mistakes I’ve made—and explains how you can avoid them. I believe that such knowledge is valuable, and deserves to be paid for.

However, if you are a student or really can’t afford the book—please reach out to me via my website, and I’ll try my best to help you.

Book page on my blog.