Is it worth writing about?

I agree, and I'd add ".. and speak in public more, too."

I have a Substack post "Public Speaking for Engineers" about this, but unfortunately it lost out in the poll to the one about my experiences at Oracle in the 90s, so you'll have to wait for that one.

Anyhow, getting practice speaking, even if it's only to two people, is indispensable, and so is practicing writing. "Nobody reads what I write," you say? That's OK, you can wait a week and then read it yourself.

There's a YouTube video that advocates that you just speak to your computer for a few minutes a day, so you don't even really need an audience for that. Getting inured to watching and hearing yourself is really valuable. The shock wears off.

This is really fortuitous timing

For...years at this point... I've had it in my mind to write a short, high level guide on how to design systems that have to work while offline. My motivation being:

- there's no one size fits all solution

- a lot of database products heavily suggest they're one size fits all solution

- you can really get lost in the weeds delving into research papers which describe things that don't actually fit your specific problems

- you can really screw things up by just doing the simplest possible thing you can think of.

But I always held back by thoughts like "you're not a distributed systems researcher, stay in your lane", "some of these approaches you've only read case studies on, you've never put them in production", "almost no one cares about things that work offline, the niche is too small" etc etc.

But after a couple of people on HN got in contact with me about it these past few days, I decided to finally bite the bullet and start writing it. Because no one else has.

Very happy to see this meta-topic written about! Especially happy to see the "bad faith" argument called out:

"The internet is already full of crap. People who aren't experts are just making it worse."

I keep seeing this argument, particularly on Hacker News. As the article says, it's not the content creator's fault for creating something the reader doesn't like. It's the content aggregator's job to improve matching content to readers.

I agree wholeheartedly with this article and think it's worth writing more. I used to blog a ton and am considering restarting the habit.

A good companion article to this could be Simon Willison's "What to blog about" https://simonwillison.net/2022/Nov/6/what-to-blog-about/

Almost everything is worth writing about. The vast majority of us never write about anything at all and most of those who do write only about the things that they feel are approved of by those who surround us or by some imagined social standard.

Even if no one else reads it the mere act of committing to paper, or electronic document, helps to crystallize one's ideas.

I recently started writing a lot about depression trying to channel all this neurotic energy I have into some nice descriptive writing. Here's one where I describe the nice sauna experience I have every now and then in the town we're currently studying in: "One with Nature" -> https://sentience.lostbookofsales.com/one-with-nature/

It's some kind of a meditative process and I do it only when I truly feel like it. With a cup of tea and some nice background music. Definitely recommended!

I long have the impression that we are building software wrong. Wrong as in not ideal. We are like the personal electronics in the 90s. One gatget for one task, phone, radio, MP3, camera, watch, etc. They all make sense at the time, until the advent of iPhone/smartphone. Same for software development. IMO it is prime time for a smartphone for software dev. Seeing this post motivates me to distill my thinking, write about what I imagined the smartphone to be. Or maybe not.

Thank you Eatonphil for writing this.

I agree that I would love to see more of this kind and quality this kind of article of technical subjects.

https://blog.jcoglan.com/2017/02/12/the-myers-diff-algorithm... https://keleshev.com/abstract-syntax-tree-an-example-in-c/

I don't want to add more work to people who are already working more than everyone else. But when you write software or code that is truly good, I want people to write lots of examples and descriptions of their mental model and how to think of the software.

I'm still trying to understand what the difference between a poller and an awaiter in Rust async.

I use Flask because I find Flask easier to understand than Django. There's even a simple example on the Flask homepage. But Django has a very large tutorial which still doesn't really explain how each component fits together. I don't understand the mental model behind Django but I do with Flask.

For example, I'm still trying to understand C++ coroutines. And I have some code that kind of works and some code someone provided on Stackoverflow I cannot get to work with GCC. There's not large amounts of documentation on C++ coroutines.

I see people post fascinating awesome GitHub projects and have sparse README.md and no screenshots

The code doesnt speak for itself. You can write the perfect code at a company and that code never flourishes because nobody wrote about it. Or you can write the perfect code at home but it doesn't get used.

I would rather read your documentation of the inner workings of your software than your code itself. Code is harder to read and understand.

This article essentially explains how to write a extremely fast query engine for columnular data, row data and exact match search:

https://rockset.com/blog/converged-indexing-the-secret-sauce...

I prefer a whitepaper + code than just code or just whitepaper. I learned from whitepapers and Wikipedia descriptions of algorithms more than I read people's code. I find it easier to understand people's descriptions of things and mental model.

I hope people shall stop saying code IS the documentation and start documenting their software.

“Writing is thinking”

Unless you can do better than GPT-3, no.

(Not having read the article) the main purpose for me, to write publicly in something like a personal blog, would be to keep myself honest and place the writing under review / critique so I could learn from people who know more.