In the previous posts, I talked about writing metrics and how to schedule writing sessions realistically. In this final article, I want to look at what actually happens inside a writing session — and at what is usually called writer’s block.

I don’t really believe in writer’s block when it comes to technical books. Let me explain why.

A writing session is not just about writing

A working session on a technical book is not limited to producing text. It also includes:

• reading documentation,
• researching,
• writing and testing code,
• preparing figures,
• proofreading and integrating feedback.

So even on days when inspiration is low, there is almost always something useful you can — and should — do. When the preparatory work is done, writing becomes much easier. It’s like building a house: once you have a solid blueprint, construction flows.

Remove the pressure to be brilliant

Another major source of blockage is self-judgment. First drafts are not supposed to be good. In her book Bird by Bird, Anne Lamott famously describes them as “shitty first drafts.” She writes:

Almost all good writing begins with terrible first efforts. You need to start somewhere. Start by getting something—anything—down on paper. A friend of mine says that the first draft is the down draft—you just get it down. The second draft is the up draft—you fix it up. You try to say what you have to say more accurately.

Personally, I didn’t hesitate to add jokes just to make myself laugh — sometimes late at night. Some of them even survived the editing process.

How I structure a writing session

I usually start a writing session by rereading and lightly fixing the previous work. This acts as a warm-up.

It helps me get back into the subject and re-establish tone and continuity.

I’ve read authors who explicitly avoid doing this, because they fear spending the entire session rewriting. That’s a valid approach. Each author has to find what works for them.

How to write a technical text

A technical book is not a novel. The rules are different. Readers will not necessarily read a chapter from start to finish. They may skim, jump sections, or come back later looking for a specific idea. That means you have to give them a reason to stay.

First, the opening paragraphs matter a lot. Early on, you should make it clear what the reader will gain by reading the chapter, with explicit statements such as “By the end of this chapter, you will…”.

Second, each meaningful section — and the chapter as a whole — should end with a short summary. This can take the form of a bullet-point list or a table with the key ideas. These summaries serve two purposes:

• they reinforce what the reader has just learned,

• and they provide a quick way to refresh one’s memory later, without rereading the entire chapter.

Next, you should avoid dumping huge code listings. Sometimes a short snippet does a much better job. If you do include larger listings, make sure they are properly commented and clearly explained.

In general, allow the reader to breathe.

That means avoiding long, dense pages of text and making sure there are pauses — both visually and mentally. Visually, this can be done with snippets, figures, or short definitions in callout boxes. Mentally, it can be a short, true story drawn from your professional experience and directly linked to what you are explaining. Be careful, though: those stories should remain short. A long anecdote quickly becomes an annoying digression.

Knowing when a text is done

How do you know when a section is finished? For me, it happens in two ways.

First, during rereads, the amount of change decreases. At the beginning, I rewrite entire paragraphs. Then only sentences. Then just words. Eventually, I’m mostly moving commas. When the text stops changing structurally, it feels solidified, and I know it’s done.

Second, it needs to feel right. Sometimes a passage technically makes sense, but something doesn’t flow. As long as that discomfort remains, I keep working — even if I can’t immediately explain why.

That said, there is a danger on the other side. If you rewrite a passage too much, its meaning can start to blur in your mind, like soup. At that point, pausing work on that section is often the right decision.

Let the text rest

Once a chapter is done, I let it rest for a few days. I try to forget about it. When I come back, I do a proofreading session — often on paper. Distance resets perception. Problems that were invisible on screen suddenly stand out.

It’s like bread fermentation: letting the dough rest allows the structure to develop, and imperfections become easier to spot.

Conclusion

You can find additional writing advice in the book Writing for Developers: Blogs that get read by Piotr Sarna and Cynthia Dunlop.

If these articles gave you a few practical tools, then it has done its job.

Enough reading. Now it’s time for you to write.

In the previous article, I discussed how to calculate writing metrics: writing speed, creative capacity, and writing ratio. Now it’s time to use them to organize actual writing sessions.

But before talking about schedules, one point needs to be absolutely clear: writing sessions must be treated as a priority.

---

Writing sessions are non-negotiable

Once you decide when and how long you will write, that decision must be respected.

Not after the dishes are done. Not once all pending calls have been handled. Not when everything else is finally quiet. If you wait until all chores are finished, your mind may indeed be at peace — but that moment will rarely arrive.

Writing sessions must come first. When the time comes, you turn your attention fully to the work and deliberately ignore the unfinished tasks waiting for you. This is uncomfortable, but necessary.

---

Turning metrics into a plan

Once you know your metrics, you can translate them into a concrete plan.

Let’s assume:

• a creative capacity of two hours on weekdays and four hours on weekends,
• a writing speed of one page per hour,
• a writing ratio of 70%
• a target book length of 350 pages.

You plan to use your full creative capacity of eight hours over the weekend. At one page per hour, that gives:

350 pages ÷ 8 ≈ 44 weeks, or roughly 11 months.

However, once you account for a writing ratio of 70%, the effective output drops:

350 pages ÷ (8 × 0.7) ≈ 62 weeks, or roughly 16 months.

If you want to compensate for the writing ratio, you need to increase the total time spent on the project. By extending each weekend writing session from 4 hours to 5, you reach 10 hours. With a 70% writing ratio, that yields:

350 pages ÷ (10 × 0.7) ≈ 50 weeks, or roughly 12 months.

However, extending sessions beyond does not automatically increase output. At that point, you have already exhausted your creative capacity and almost fully accounted for the writing ratio. Additional hours mostly translate into diminishing returns or lower-quality work, not more pages.

In my case, my writing speed was closer to half a page per hour. Writing only on weekends would have pushed the project to more than 2 years — far too long for a technical book.

The metrics forced a decision: I had to write during the week as well.

---

Adding weekdays to the schedule

By planning 2 hours each weekday and 4 hours on Saturday and Sunday, I reached 18 hours of writing per week, which translated into roughly 9 pages per week (6 to 7 pages once the writing ratio is applied). That brought the timeline to approximatly a year.

Writing on weekends was easy. Writing on weekdays was not — especially with a family. Some writers wake up early and write before work. I’m not a morning person, so that was never an option. Instead, I planned to write in the evening.

From the moment I got home to bedtime, I had about five and a half hours. Daily chores usually take around two hours, but by concentrating most of them on the weekend, I reduced weekday chores to one and a half hours.

That left:

• 2 hours to write,
• 2 hours to rest.

On paper, it looked perfectly balanced. I maintained that rhythm for two months. My writing sessions were immovable. I kept my promise. But slowly, everything else started to deteriorate.

The plan seemed sound. In reality, it exposed a problem metrics alone cannot reveal.

---

The warning signs

First, daily chores became harder and harder to complete. I reduced them to the bare minimum. Then I started going to sleep later and later. I blamed everything on procrastination. But when the most disturbing change happened, I could no longer ignore the problem.

For over twenty years, my free time had been stable — reading books, watching series or documentaries. Slowly, those activities felt like too much effort. Picking up a book became exhausting. I replaced them with shorter, easier forms of distraction such as brief audio stories. I felt like a different person. That was unsettling. At that point, I had to face the truth: I had pushed myself too far.

I had added 18 hours of work per week — two extra workdays — and I reduced my resting time.

I needed more rest, not less.

---

Accounting for the human in the process

Most advice about writing a book is about scheduling writing sessions and keeping those appointments. This advice is often written for students working on a thesis, or by people who are their own bosses and can write during working hours. When writing sessions are reducing your rest time, the impact can be significant. To mitigate this, here are my recommendations:

• Be transparent with your family
  Explain what you are doing, why you may be less available for chores for a while, why you should not be disturbed during writing sessions, and why you may need additional rest during that period.
• Reduce chores as much as possible
  Avoid writing a book during heavy chore periods such as planning a wedding, moving, or welcoming a newborn. Use every possible shortcut — grocery delivery, teaching your teenagers to clean their rooms (and maybe load the dishwasher), and postponing non-essential tasks for a few months.
• Plan breaks when working with a publisher
  If you are self-publishing, it is relatively easy to slow down or stop when things become too intense. This is not the case with a publisher. When defining your schedule, explicitly account for breaks and holidays.
• Take care of yourself
  Make sure you sleep enough, eat properly — especially food that supports sustained cognitive effort — and do some light physical exercise.

One interesting thing to point out is that I did not experience the same kind of exhaustion when I wrote a self-published book in my native language. Quite the opposite, actually. Writing was not depleting my energy; it was recharging my batteries. It didn’t feel like work, but like leisure.

The stress of having a contract, writing in a non-native language, and meeting the higher expectations of a well-known publisher turned what was once leisure into work. Work that I still enjoyed, but that no longer served as a restorative activity.

Just remember that metrics and discipline are necessary, but they are not sufficient. Writing a book is not just a scheduling problem — it’s a human one.

---

What’s next

In the last post, I’ll talk about writer’s block and what actually happens inside a writing session.

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.