A lot of people will tell you writing a book is hard. I'm here to tell you it's not.
Solving the Hamiltonian path problem is hard, writing a book just takes some hard work and a bit of dedication. It's not hard when all it takes is plomping your arse down and refusing to get up until something happens. That's easy.
As Hemingway put it in a movie, "There's nothing to writing, you just sit down and bleed" Which is odd, since he liked to write standing up ... anyway.
After two months of plomping my arse down repeatedly I finally finished my d3.js book. Or rather, I finished the first drafts, which would be a done book if I was self-publishing. Because there's a publisher involved, I'm now looking at two to three months of revision and editing.
To be honest I'm getting slightly sick of that book. Being able to step away and ignore its existence has been one of the most amazing feelings in the world. I am enjoying my new found freedom to the full. At least until reviewers come back with their You idiot! That's not how you write that bit there!!
Life can get really frustrating when you try to squeeze at least an hour of focused writing into every single day.
The final tally for the book is 179 pages, 30 examples, 66 days, 171 hours.
That means I spent about an hour per page including research, writing and coding a working example, and an average of almost 3 hours writing per day. All the while doing enough freelancing that my business grew by about 30% in terms of monthly income. \o/
What surprised me is just how much work I had with examples. It is insanely difficult to come up with an example that will exercise what you're talking about in a particular chapter, without depending too much on stuff you haven't covered yet and being thin on the stuff you've already covered and is now boring.
Then you have to get the examples working.
I didn't really know much about d3.js when I started out and it would often take me a whole afternoon to get a single example working. Like, you'd sit down, read the API documentation and get to work. Error.
Fix error ... blank screen.
Get a line on screen ... wrong line.
And so on for hours.
It would always be something stupid in the end, or I'd misunderstand what the documentation is telling me. Often I'd resort to looking at other people's examples myself so I could even get something working.
But then the really fun part starts. When you do have an example, writing just flies. You sit down and start talking about the code, pasting code in the book, showing some pictures and before you know it, that simple example you spent three hours coding has turned into five pages of the book in just half an hour.
It really is quite amazing.
While there's always stuff you can fix in a book and the writing never seems polished enough, I hope there wont' be too much work with editing. My approach is very re-writing in itself and I often write the same sentence or paragraph several times before it sounds natural enough.
Yeah, who knew, making yourself sound natural takes deliberate practice. You can't just dump your brain on a page and think it sounds natural. It doesn't
Right, you've kept reading, now you want a The Point. If you really want to learn something, write a book about it. It doesn't take long.
Continue reading about It takes about two months to write a technical book
Semantically similar articles hand-picked by GPT-4
- First lessons learned about writing technical books
- Write sitting down, edit standing up
- What writing a book feels like
- I published a book with a publisher. Here's what the journey was like.
- Is writing the same as coding?
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️