How I Wrote a Technical AWS Book in Just 6 Months While Working Full-Time
When I look at the copy of my book, Mastering Event-Driven Microservices in AWS, sitting on my desk, it's hard to believe that just over 6 months ago it was nothing but a vague idea in my mind. Writing a technical book while maintaining a full-time job was one of the most challenging yet rewarding experiences of my career. In this article, I want to share my journey; the struggles, strategies, and small victories that helped me complete this project in half a year.
The Truth About "6 Months"
In a recent LinkedIn post, I wrote the following:
It took me 6 months to write my book.
And 15 years to gain the experience for it.
This perspective is important. While the actual writing process took half a year, the knowledge distilled into those pages represented a decade and a half of working with cloud technologies, making mistakes, solving problems, and developing expertise. Without that foundation, the book simply wouldn't exist.
The Decision to Write
The idea emerged when my publisher reached out to me about writing a practical book on Event-Driven architectures on AWS. I realized there was a gap between theoretical cloud knowledge and practical implementation skills. Existing resources either skimmed the surface or failed to explore specialized areas in sufficient depth.
I spent two weeks researching the market and outlining what my ideal AWS book would contain before pitching the agenda to the publisher. When they responded with enthusiasm and a tight deadline, I knew it was time to turn this idea into reality.
Planning the Marathon
With a full-time role as an AWS Solutions Architect, I needed a realistic writing schedule. I allocated:
Weekday mornings: 7:00 AM - 9:00 AM (before work)
Weekday nights: 9 PM - 10 PM
Weekends: 1-2 hours each day
This gave me roughly 30-35 hours per week for writing and reviewing. The math was simple but daunting: with 400 planned pages and 26 weeks, I needed to produce about 15 polished pages weekly, including the code examples, architectural diagrams, and images.
My Writing Process
Before starting, I had already prepared the table of contents, giving me a clear roadmap for what each chapter would cover. This upfront planning was crucial; I never had to wonder what to write next or how pieces would fit together.
I maintained a consistent writing routine, aiming to produce 1-2 pages every morning before work. This consistency was achievable because I knew exactly what I needed to write about. The early morning hours became sacred; no emails, no social media, just writing.
I developed a system that worked surprisingly well:
Visual Elements First: I created the architectural diagrams, code examples, and other visual aids first, allowing me to focus on crafting the written content around these. This approach ensured technical accuracy and gave structure to each section.
The "Two Passes" Method: My first pass focused on getting ideas down without worrying about perfection. The second pass, usually a few days later, refined the language and technical accuracy.
Daily Review: Each night, I would review the day's writing on my iPad, seeing it from a reader's perspective and making notes for refinements the next day. This ritual helped me maintain quality and continuity.
Chunking: I broke each chapter into 1-3 page sections I could complete in a single sitting. This made progress measurable and kept momentum going.
Version Control: I used Git not just for code samples but for the manuscript itself, which saved me more than once when I needed to revert changes.
Chapter Completion Process
After completing each chapter, I was spending 2-3 days to review and edit it, ensuring it had a good flow. This might seem like a lot of time, but this careful checking stopped mistakes from piling up and kept the whole book consistent.
By improving each chapter right after writing it, I had the early parts of the book almost ready for technical review while I was still writing later parts. This made the final editing job much less overwhelming.
The Technical Challenges
Writing about cloud technology presents unique challenges. AWS services change rapidly, and documentation gets outdated quickly. To address this:
I built a dedicated AWS environment for testing every example in the book
Created automation scripts to verify code examples still worked weekly
Maintained a "living document" of service changes during the writing process
Focused on fundamental concepts while acknowledging when features might evolve
The Final Push
The last month was a blur of late nights as I finalized diagrams, validated code examples one last time, and wrote the acknowledgments (surprisingly emotional!). The publisher sent me the entire manuscript and I read it cover-to-cover over a long weekend, making final notes by hand.
Hitting "send" on the final manuscript was both terrifying and exhilarating.
What I'd Do Differently
Looking back, I would:
Allow more buffer time for unexpected life events
Start the technical review process even earlier
Be more selective about code examples (some took days to perfect)
Schedule proper breaks; during the 6 months, I took only a one-week break
Was It Worth It?
Absolutely. The entire journey of writing my book was demanding yet incredibly exciting and rewarding. Beyond the professional satisfaction, writing a technical book improved my own understanding of AWS services in ways I hadn't anticipated. Explaining complex concepts forced me to understand them more deeply than I thought I did.
The feedback from readers has been the most rewarding part; especially hearing how the book has helped them prepare for certification exams or implement better cloud architecture.
For anyone considering writing a technical book: it's entirely possible with disciplined time management and consistent effort. The key is breaking an overwhelming project into manageable daily tasks and never losing sight of why you started in the first place.
Now, six months after publishing my book, I can say it was one of the most challenging and rewarding experiences of my professional life.
