Gergely Orosz has an uncanny sense of what matters. He spots and researches emerging engineering trends, then reports on them months, sometimes years, before anyone else. He scoops journalism giants like The Wall Street Journal, The New York Times, and Bloomberg. And when his vision for The Software Engineer’s Guidebook didn’t fit neatly into publisher conventions, he published it himself – and ended up with a #1 Amazon bestseller.
That instinct has earned him over a million regular readers, making The Pragmatic Engineer the top newsletter in tech. His focus on long-form analysis, original research, and insider perspectives sets it far apart from all the LLM remixes and Hacker News pandering.
Gergely’s path (engineer> engineering manager> professional writer/publisher/podcaster/conference organizer) is unlike most. So we thought we’d ask him an expanded version of our usual writerly questions.
Over to Gergely…
I started a blog when I was still in university because a lot of devs I looked up to all had personal blogs. When I got my first job, I wrote down interesting learnings I came across. It did not have many readers - but it helped me reflect on some of my learnings.
After a while, I got annoyed that my blog was a mish-mash of all kinds of posts, and no clear topic. The blog post How To Achieve Ultimate Blog Success In One Easy Step by Jeff Atwood (cofounder of Stack Overflow) suggested that if you want a successful blog: write regularly, for an extended period of time. I took this inspiration, registered the domain “pragmaticengineer.com” and started to write one post per week. I managed to do it for two months, before throwing in the towel.
Note: Jeff also shared his writing experiences here.
What got me back to this blog is one of my early articles got submitted to Hacker News, and got so much traffic that crashed my shared hosting. I realized “huh, something I wrote 5 months ago resonates with people and starts conversations?”
From there on, when I thought I learned something interesting (or observed something interesting) I blogged about it on this blog.
A few things:
Meeting people who think similarly as I do and becoming friends – purely thanks to writing. Charity Majors is one such example. Unbeknown to me, a person sent me and Charity the same question, and we both blogged about it independently. Our views came out… very similar (here’s Charity’s take, and my take on measuring individual developer productivity.) And it’s how we started talking, and later met as well.
I learned more – whenever I wrote things down! I retain information better when I write about it. This was pretty surprising. I guess it makes sense: when writing about it, I think about it a lot more.
Two stand out:
Distributed architecture concepts I learned while building a large payments system. This was the first article where I spent months learning about a topic (I felt pretty lost with distributed systems when I started working at Uber), then another ~1-2 months writing up what I learned, hoping that it would be useful for others.
And it was the first time ever that it felt worth it putting in all this time writing it all up: the response was phenomenal, and developers translated in Japanese and Russian as well, further spreading it (it was also the first-ever article I wrote where I got requests to translate it.)
The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe. This one article helped hundreds of people get better jobs they were not aware of, and it was the catalyst to have at least a dozen companies I know of increase compensation bands by 10-25% a year after I published it.
The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe – This was the first time ever I did a post with a lot of research. I wasn’t sure that I did research the “right” way, or that people would take it seriously when it came out.
Turns out when there’s zero information on a topic (in this case, Big Tech salaries in the likes of the Netherlands), some information is always better than none!
It’s hard to publish the first few blog posts or articles: but it gets easier, over time. If and when you develop a habit, it happens a lot more automatically.
I have a simple system where I take notes when I get an idea about something I could write about. When I feel like writing, I go through these!
Counter-intuitive, but pay for a basic service where you write your blog on! Paying even $10/month reminds you that you should write something else that money you pay goes nowhere! Honestly, it’s hard to get into the habit of writing regularly, so some external “push” can help.
Also, consider that it feels like blogging is less popular these days: which is why it can be easier to stand out if you do start!
Note: Simon, Charity, and Sean also shared their writing experiences here.
With AI tools, I feel it should be easier to produce writing that looks good. You can also ask AI to edit your work, critique it, and so on.
I’m not sure I see that much more or better tech blogs though - which is strange!
One trend I notice is more longform writing is happening over newsletters (mostly Substack), and on social media (e.g. X articles.) I also see engineering leaders do more opinion pieces on some of these platforms than before.
Writing is still an underrated way to connect with people who either work on similar stuff as you are, or think similar to you do.
What’s different is I now have strict deadlines to publish: twice a week, for my paying subscribers! Nothing is as motivating to finish an article like a deadline that cannot be moved! My writing cadence is up thanks to this self-imposed constraint.
I now write much less about my own experience (which was the only thing I wrote when I blogged, before The Pragmatic Engineer) and most of my pieces are based on research, interviews or analyzing events.
Personally, I greatly appreciate blogs where someone shares hard-earned experience (something they did over months, sometimes longer.) My nature of writing is that I often get people to talk to me about these, then I write them down to share.
Personally, I stayed away from writing for my employer, because of how painful the process was. Also, every time I wrote on a company blog: within 3 years, it got removed/deleted.
I found it easier to write about my own learnings at the company, but omitting business-sensitive details. This is a much easier way to start.
Writing on the company eng blog can give good visibility to you externally, and doing it once can be educational. I would suggest you copy the blog and publish it on your own domain – expect that corporate can and will delete it in a few years’ time!
The best aspect is talking to far more people than I had access to when I worked fulltime as an engineer. Both in terms of time, but also getting responses from a lot more people.
An aspect that is surprisingly challenging is the pressure to publish both things that are timely, but also well-researched. Good research takes time: but by the time it is done, it can get out-of-date. What is timely – a trend, a technology or framework getting popular etc – on the other hand is hard to go into meaningful details without putting in the time and work to research.
Having too many drafts in progress (researching) can get overwhelming as I feel some of them could get out-of-date by the time research is done. Working only on one timely topic at the same time can make me worry I won’t have any other topic researched in, say a week or two’s time.
Finally, “scaling” The Pragmatic Engineer is surprisingly difficult - and maybe this is why it is as popular as it is? People are surprised to learn that it’s just me working fulltime on it, and Elin part-time. That’s all we are! After four years, I’m now hiring one more tech industry analyst to help with research.
***
Note: Gergely’s work is featured throughout Writing for Developers.
