Where My Writing Journey Began
“Why/how did you start writing technical books and articles?” It’s a question I hear often, and my answer might surprise you. My writing journey started long before computers, coding, or Information Technology, back in 1989.
Right from the beginning, my motivation was simple i.e. clarity and honesty. I wanted to communicate my ideas clearly, share insights, and help others understand the ‘world around them’.
I like to describe this journey as “From Sports Commentary to Technical Article Writing.”
Living in San Francisco East Bay, I wrote letters and commentaries for our local newspaper, Contra Costa Times, about our football team, San Francisco 49ers, and baseball team, Oakland A’s. I shared my opinions on games, coaching decisions, and team performance. Sometimes praising, sometimes criticizing, but always aiming to communicate clearly.
“Those early experiences in expressing my thoughts clearly laid the foundation for a career in technical (Requirement Specification) writing as a TPM.”
Technical Writing as Problem-Solving Communication
Technical writing has grown far beyond documenting requirement specifications. Today, it is a proactive, strategic, and problem-solving discipline.
Ideally, Knowledge Base (KB) technical writers no longer just record how a software product works, they act as end user advocates, bridging the gap between complex engineering, design, and user experience (UX). Their goal is simple i.e. help end users solve real problems, efficiently and independently.
From writing Software Specs to Articles and Books
Traditionally, tech specs writing in software development was a final step, assembling documentation after a product was built. Today, it is an integral part of software product lifecycle (SDLC), helping end users understand, adopt, and succeed with a software product.
Key aspects of modern technical specs writing:
- Documentation as a Product Modern guides explain why steps matter, empowering end users to solve problems on their own.
- Identifying Gaps Spotting where end users might struggle and proactively filling those gaps.
- Debugging Documentation Continuously refining content to reduce errors and confusion, just like debugging software code.
“Documentation is no longer an afterthought, rather it’s a tool that shapes user experience (UX).”
Technical Problem-Solving Process in Action
My approach mirrors structured problem-solving in engineering:
- Identifying their Issue: Understanding real problem end users face.
- Analyzing for a Solution: Determining a clearest way to communicate it.
- Implementing Clear Documentation: Writing guidance that is intuitive and actionable.
- Iterating for Improvement: Continuously refining content based on feedback.
Why This Approach Matters
- Empowers End Users: Well-written software product guides allow users to solve problems independently.
- Enhances Personal Growth: Clear writing improves knowledge, organization, and work-life balance.
- Creates Lasting Impact: Good documentation reduces support calls, improves adoption, and builds trust.
From Letters to Legacy
From writing sports commentary to authoring (IT) technical books, my journey has always been about helping others understand and succeed.
Every article, guide, and book I write is a step toward making knowledge accessible and actionable. Writing is no longer just a job or hobby, it’s a way to solve problems, connect with people, and leave a lasting (positive) impact.
“This is what keeps me motivated every single day.”
Explore my books (CTRL-ALT-Planning, CTRL-ALT-Execution & CTRL-ALT-Deliver)
Read my articles
