← Back to Library

The software engineer’s guidebook: A recap

Most engineers view book publishing as a linear path to credibility, but Gergely Orosz reveals a fractured landscape where the traditional gatekeepers often stifle the very expertise they claim to champion. This piece stands out not for its financial breakdown, but for its raw, unvarnished account of how an author must dismantle a publisher's rigid template to preserve the integrity of their technical advice. It is a masterclass in the hidden friction between creative control and commercial machinery.

The Publisher's Trap

Orosz begins by detailing his initial foray into the traditional publishing world while working as an engineering manager at Uber. He sought to codify the journey from a mid-level engineer to a senior leader, pitching his idea to the industry's most respected names: O'Reilly, The Pragmatic Bookshelf, and Manning. While Manning accepted the pitch, the relationship quickly soured. Orosz writes, "I felt the book would be dumbed down, and that following some of the guidance would weaken it." This sentiment strikes a chord with any professional who has watched their nuanced work flattened into a generic checklist.

The software engineer’s guidebook: A recap

The core of the argument here is that the traditional model, which often retains 85-90% of sales revenue, demands a level of creative surrender that may not be worth the cost. Orosz notes that he was "less comfortable with some of the conditions and feared my hands could be tied if I wanted to share draft material online," and critically, he "would not be able to choose the book title." These constraints highlight a fundamental misalignment: publishers often prioritize a standardized product over the author's unique voice. Critics might argue that publishers provide necessary polish and distribution networks that self-publishers cannot match, yet Orosz's experience suggests that for technical non-fiction, the "polish" can sometimes be a form of dilution.

"I felt the book would be dumbed down, and that following some of the guidance would weaken it."

The Mechanics of Self-Publishing

Once Orosz parted ways with the publisher, he faced the daunting reality of the "lack of deadline pressure." He outlines a grueling process that mirrors software development cycles, from a "weighted table of contents" to the final production layout. He draws a parallel between book planning and project management, noting that the exercise "resembled estimating the size of a piece of work during the planning for a software project." This framing is effective because it speaks directly to the engineer's mindset, translating abstract creative tasks into familiar technical workflows.

However, the path was not smooth. Orosz admits that starting a weekly newsletter to accelerate the book's completion "actually delayed it by another two years." He explains that "online newsletter issues can be a lot more in-depth than a chapter in a book can be, due to the issue of space constraints," and that the timely nature of newsletters clashed with the timeless goals of a book. This is a crucial insight for busy professionals: the tools we use to stay current can sometimes sabotage our long-term projects. The choice of tools was equally pragmatic; he utilized LaTeX for print layout, a decision that required hiring an expert to handle the complex indexing, a nod to the historical rigor of typesetting that has persisted since the days of early academic publishing.

The Economics of Impact

The financial transparency in this piece is rare and compelling. Orosz reveals that the book earned "$611,911 in two years from royalties on 40,000 copies sold." He argues that these numbers are not just a vanity metric but a signal to the industry: "We need more good books in tech, so I hope that sharing these numbers inspires other techies to write them." This reframing of success from pure profit to ecosystem contribution is powerful. It suggests that the barrier to entry for high-quality technical literature is not a lack of talent, but a lack of confidence in the distribution model.

The launch strategy further underscores the shift in power dynamics. Without a publisher's marketing machine, Orosz built a landing page to collect emails, a move he calls "one of the best things I did." He found that sharing work-in-progress drafts on social media generated nearly as much feedback as formal beta readers. This democratization of the feedback loop challenges the old guard's assumption that only established publishers can validate an author's work.

Beyond Borders: The Mongolia Connection

Perhaps the most unexpected chapter involves a trip to Mongolia to meet Nasha Tech, a startup that translated the book. Orosz was initially skeptical, noting that "Mongolia's population is 3.5 million; much smaller than other countries where professional publishers had offered to do a translation." Yet, the startup's initiative to translate the book for their own ecosystem defied standard unit economics. He describes the office vibe as a mix of "startup and digital agency," where the team builds the "Uber Eats of Mongolia." This anecdote serves as a poignant reminder that technical knowledge has no borders, echoing the global reach of open-source software and the historical spread of the ISBN system which standardized book identification across diverse markets.

"Awareness about the latest tools has no borders."

The story of Nasha Tech illustrates that the demand for high-quality technical mentorship exists even in markets that traditional publishers ignore. It validates Orosz's decision to self-publish: by retaining control, he enabled a translation that a profit-driven publisher would have deemed unviable.

Bottom Line

Gergely Orosz's account is a definitive argument for the modern technical author to reclaim ownership of their work, proving that the traditional publishing model often sacrifices depth for standardization. While the self-publishing route demands a steep learning curve in logistics and marketing, the financial rewards and creative freedom it offers are unmatched. The biggest vulnerability in this approach remains the sheer volume of non-writing tasks required, but for those willing to treat the book as a product launch, the payoff is a direct, unfiltered connection to a global audience.

Deep Dives

Explore these related deep dives:

  • Vanity press

    The article discusses the author's choice between traditional publishing and self-publishing, including the economics of each. Understanding the history and evolution of vanity/self-publishing provides valuable context for why the author's approach was viable and how the publishing industry has changed.

  • ISBN

    The author specifically mentions purchasing ISBN numbers for self-publishing and notes regional differences. Understanding how ISBNs work, their history, and the global system behind book identification adds depth to understanding the self-publishing logistics described.

  • LaTeX

    The author mentions hiring a LaTeX expert for print layout and using Overleaf. Understanding LaTeX's origins in academic typesetting and why it remains the gold standard for complex document formatting explains why technical books often require this specialized knowledge.

Sources

The software engineer’s guidebook: A recap

Before we start: I’ll be in San Francisco on 11 Feb, 2026. I’m working on something special for engineers and engineering leaders. I can’t wait to share more. 11 February – save the date!

Two years ago almost to the day, I published The Software Engineer’s Guidebook. Originally, it came out in paperback, then as an ebook and an audiobook. I’m happy to share that it is now available as a hardcover, and is also on the O’Reilly platform.

Today, I’d like to draw back the curtain on the process of writing a book as a techie:

Pitching to publishers. And why I ended up breaking up with a publisher.

Self-publishing. The tools I used for writing and the platforms I published on.

Traveling to Mongolia to meet the startup which translated the book. A 30-person startup called Nasha Tech translated the book for the benefit of their company and the Mongolian tech ecosystem.

How much did my book earn? $611,911 in two years from royalties on 40,000 copies sold, to date. We need more good books in tech, so I hope that sharing these numbers inspires other techies to write them.

Learnings from writing my book. It’s hard to judge a book’s impact, but good books stay valuable for longer – that’s why they’re hard to write.

1. Pitching to publishers.

In late 2019, I was an engineering manager at Uber, the ridesharing app. For the first time in my career, I was a manager of managers: suddenly, I had “skip level” software engineers, and it was here that the inspiration came to write a book that provides some advice and observations for these tech professionals.

During a 1:1 catchup with a new joiner skip-level engineer, they asked about getting up to speed in the workplace faster. They were at the Software Engineer 2 (L4), and wanted to figure out how to get to the Senior engineer level (L5A at Uber). I thought it would’ve been nice to give them a book with a bunch of pointers about what it takes to become an effective software engineer in this environment.

With that inspiration to write a book about professional growth at large tech companies and startups, I looked for publishers who could help make it a reality. I pitched my book to 3 publishers behind the highest quality tech books in the industry – O’Reilly, The Pragmatic Bookshelf, and ...