dondraper36

I am not suicidal and I am lucky to have loving people who I also love around. That said, with all the rapid changes in the software engineering industry and in life in general, I sometimes wonder what I am doing with my life and why.

It's like plenty of things are happening by inertia, but none of them bring any joy or make lots of sense. In such moments, I really envy people who have the courage to work on something they truly believe in. I have quite a few people to take care of, which requires financial resources, so I am not there yet.

The idea sounds related to the distinction between essential and accidental complexity.

https://ferd.ca/complexity-has-to-live-somewhere.html

I really like the article above in that complexity does have to live somewhere. If you have a hard problem to solve, there is a minimum level of complexity (essential complexity) that can't be further reduced, only moved from one place to another.

And yet we often add accidental complexity by making bad choices (thinking of you, microservices). If your choice is bad enough, you get all the disadvantages (challenges with distributed systems, complicated debugging), but without any of its advantages (a distributed monolith doesn't get you any deployment or team independence).

Telling one from the other, well, is something I'd like to learn and that seems to require both experience and some sort of intuition.

If I understood correctly, the queue implementation in the blog post holds a transaction while an operation is progress.

I see the advice to make it as short as possible, but why can’t we update the status column to, say, “processing” and avoid potentially long transactions at all?

Not a novel idea, but it always resonates with me when I hear that the goal of every software engineer is to manage complexity.

That said, I still find it hard to formulate for myself how to tell the difference between accidental and essential complexity.

It’s a fantastic performance booster for a lot of mundane tasks like writing and revising design docs, tests, debugging (using it like a super smart and active rubber duck), and system design discussions.

I also use it as a final check on all my manually written code before sending it for code review.

With all that said, I have this weird feeling that my ability to quickly understand and write code is no longer noticeable, nor necessary.

Everyone now ships tons of code and even if I do the same without any LLM, the default perception will be that it has been generated.

I am not depressed about it yet, but it will surely take a while to embrace the new reality in its entirety

As a person with ADHD, I feel personally attacked.

As Martin recently posted, now the production should take about 4 more months until we can buy the paperback version.

That said, if you have an O'Reilly subscription, you can already enjoy the new edition.

+1

I'd also like to understand whether there are still any cases when MongoDB is the right choice

Also, take a look at windmill.dev. It’s a beast

12 out of 13 chapters are already available on the O'Reilly website in the "raw and unedited" format.

The book is scheduled for publication in February 2026, but if you have an O'Reilly subscription, you can already access the new content.

That's exactly the "simple vs easy" difference that Rich Hickey emphasized in his famous talk.

Even in this thread, there was a comment (now deleted) saying that a staff engineer at GitHub is unlikely to know what real scale is.

Not directly related to the article we're discussing here, but, based on your experience, you might be the ideal kind of person to answer this.

At the scale you are mentioning, even "simple" solutions must be very sophisticated and nuanced. How does this transformation happen naturally from an engineer at a startup where any mainstream language + Postgres covers all your needs, to someone who can build something at Google scale?

Let's disregard the grokking of system design interview books and assume that system design interviews do look at real skills instead of learning common buzzwords.

That's where the familiarity factor steps in.

Until you get enough experience for your own good judgment, you need some rules of thumb and guidelines from more experienced peers.

As long as you understand that everything is a trade-off and, unfortunately, that the modern field is based on subjective opinions of popular and not necessarily competent people, you will be fine.