🖊️Writing a technical book: from idea to manuscript
Writing The Art of Code has been an enriching journey. It wasn’t my first experience writing a book, but with this new one, I felt the need not only to share technical insights, but also to share the writing experience itself. That’s why I’ve decided to start a series of blog posts about the process — from idea to manuscript.
This series is for developers who feel the desire to write — whether to share hard-earned experience, explore ideas in depth, or eventually commit to a technical book — and who want a concrete, honest view of what that process actually involves.
The series will cover the following topics:
- Finding and cultivating the idea of a technical book (below)
- Calculating your writing metrics
- Organizing your writing sessions
- Overcoming writer’s block
It all starts with an idea
Everything begins with an idea. Sometimes it feels as if it appears out of nowhere — you wake up with it, or it appears while you’re walking and thinking about something entirely different. But in reality, ideas never emerge from nothing.
An idea is the visible result of invisible preparation.
In technical writing, that preparation is your ongoing technical watch: reading documentation, exploring new frameworks, experimenting with tools, challenging architectural decisions at work, debating design choices with colleagues. It is the slow accumulation of experience, passion and reflection.
Some book ideas require less incubation — for example, writing about a new framework or the latest features of a language. But the ideas behind books that are still discussed years later — like Design Patterns or Accelerate — are rarely spontaneous. They result from deep observation, synthesis, and long-term intellectual reflection.
Cultivating your mind, however, is not enough. You also need time to process. For some, that might mean long walks. For me, that is rarely sufficient. True processing happens at a desk — by giving shape to ideas through writing.
That writing does not need to be public. It does not need to be polished. It does not even need a defined objective. It can be a professional diary, as well as a story or a technical blog post.
The key is to deliberately book time — once or twice a week — to open a document and let your thoughts take form. Whether on paper or on screen, what matters is the act of shaping ideas into language. You don’t need to share it on LinkedIn or publish it on your blog. It can remain entirely private, so there is no pressure to be brilliant. But by consistently creating that space, you open the creative gate of your mind. And that discipline often leads to surprising results.
If you intend to write a book, this habit becomes even more essential. You are not only generating ideas — you are training your craft. You refine your style. You learn to structure arguments. You make sentences flow.
The seed behind The Art of Code
Let me share the story behind my book as an example.
One beautiful autumn day, I sat down intending to write a story. But before starting, I felt the need to vent. Once again, I had heard someone talk about programming as if developers were just “producing code” — as if we were machines outputting lines on demand.
But no two developers write the same code. We don’t model problems the same way. We don’t make the same trade-offs. We don’t express structure, clarity, or elegance in the same way. Code carries judgment, taste, and experience.
And this was even before AI entered the mainstream conversation as our supposed replacement. When that narrative gained momentum, it only amplified the idea that developers are interchangeable — that we merely generate output like a machine.
I wanted to push back against that idea. I wanted to express something I deeply felt: developers are artists, and code can be beautiful.
I wrote that text and later published it as a blog post. It never became a chapter of the book that emerged afterward — but it was the seed.
And then, I decided to challenge myself. If I was claiming that code could be beautiful — something I could clearly feel while programming — could I actually explain it? Could this intuition sustain an entire book?
So I decided to test the idea. As with most of my book projects, I never commit immediately. I write a few exploratory chapters — nothing more. It is like testing the water.
Some ideas survive that phase. Others do not. If, while writing, I feel the idea gaining structure, if I see that there is enough material for a coherent whole, and if — most importantly — the passion to continue is still there, then the project enters the next phase, which I will describe in a future post.
To sum up:
A strong book idea emerges from cultivating your passion for your craft, taking regular time to reflect, and then deliberately testing the concept with a few chapters before committing fully.
In the next posts, I’ll move from ideas to execution: how I measure writing progress, structure sessions around a full-time job, and deal with writer’s block.