dondraper36

6 ms·

31.
by dondraper36 1y ago
Isn't reading the article before posting comments considered cool anymore?
32.
by dondraper36 1y ago
... and nevertheless at the end of the article, the author does offer their understanding of the terms
33.
by dondraper36 1y ago
Such a familiar feeling. Articles similar to this one make lots of sense to and I do try to embrace simplicity and not optimize prematurely, but very often I have no idea whether it's the praised simplicity and pragmatism or just a lac
34.
by dondraper36 1y ago
I don't think the author (or anyone else) could come up with term definitions that would satisfy everyone.
35.
Do the simplest thing that could possibly work(seangoedecke.com)
1111 points by dondraper36 1y ago|387 comments
36.
How I know I'm working with a strong engineer(seangoedecke.com)
4 points by dondraper36 1y ago|0 comments
37.
by dondraper36 1y ago
Absolutely. To put it differently, unfortunately not everyone has a chance to be part of a product's organic evolution from "all we need is Postgres" to "holy crap, we're a success, what is Cassandra by the way?&quo
38.
by dondraper36 1y ago
I believe even at FAANG-like companies, only a lucky minority is involved at that level of scale. Most developers just use the available infrastructure and tools without working on the creation of S3 or BigTable.
39.
by dondraper36 1y ago
Yes, I would probably phrase it like this. "Under the current load, I would go super simple and use X, which can work fine long enough until it doesn't. And then we can think about horizontal scaling and use Y and Z". Then pr
40.
by dondraper36 1y ago
Unless it's encouraged by the modern technical interviewing culture, which it partly is.
41.
by dondraper36 1y ago
There's another reason for that. Deep in my heart, I would love to be part of a team that works on truly data-intensive applications (as Martin Kleppmann would call them) where all the complexity is justified. For example, I am more of
42.
by dondraper36 1y ago
This also happens because plenty of candidates learn the buzzwords and patterns without understanding the trade-offs and nuances. With a competent enough interviewer, the shallowness of knowledge can be revealed immediately.
43.
by dondraper36 1y ago
I enjoyed reading this book (it's a short one), even though the prose is very, well, special :)
44.
by dondraper36 1y ago
Yes, and this is exactly why LinkedIn-driven development exists in the first place. Listing a million technologies looks much more impressive on paper to recruiters than describing how you managed to only use a modular monolith and a single
45.
by dondraper36 1y ago
Not really disagreeing with you here, but that "later" never comes for most companies.
46.
by dondraper36 1y ago
Especially given that generating documentation and tests (of course, with manual revision) is so much faster with, say, Claude Code.
47.
by dondraper36 1y ago
That also depends on what you would consider "business logic in the database". What would you say about CHECK constraints, though? I don't think it's something few developers expect to see, and having these checks is ver
48.
by dondraper36 1y ago
What I particularly like about the comments in this thread is how it proves that everything is a trade-off :)
49.
by dondraper36 1y ago
Vertical scaling is criminally underrated, unfortunately. Maybe, it's because horizontal scaling looks so much better on Linkedin.
50.
by dondraper36 1y ago
In Go, for example, there is a mixed approach of pgx + sqlc, which is basically a combo of the best Postgres driver + type-safe code generator (based on raw SQL). https://brandur.org/sqlc Even though I often use pgx only, f
51.
by dondraper36 1y ago
But isn't that type of advice the best we can have? Having read Designing Data Intensive Applications (DDIA) and some system design interview-focused books (like those from Alex Xu), I have noticed two types of resources: * Fundamental
52.
by dondraper36 1y ago
There's a great book SQL Antipatterns, by Bill Karwin where this specific antipattern is discussed and criticized. That said, sometimes when I realize there's no way for me to come up even with a rough schema (say, some settings o
53.
by dondraper36 1y ago
Yeah, absolutely. But the author's idea of logging all major business logic decisions (that users might question later) sounds reasonable.
54.
by dondraper36 1y ago
Well, as sad as it is, such advice is often applicable to new projects when you still have runway for your own decisions. For mostly political reasons, if you are onboarded to a team with a billion microservices and a lot of fanciness, it&#
55.
by dondraper36 1y ago
The logging part is spot on. It has happened so many times when I thought, "Oh, I wish I had logged this.", and then you face an issue or even an incident and introduce these logs anyways.
56.
Good system design(seangoedecke.com)
957 points by dondraper36 1y ago|390 comments
57.
Ask HN: Would you still recommend SICP in 2025?
3 points by dondraper36 1y ago|1 comments
58.
by dondraper36 1y ago
That's why I often use eg, egCtx :)
59.
by dondraper36 1y ago
The question is, however, whether this is a good proxy for one's future colleague and employee. I have no idea what could be a better option (well, maybe preparing some small feature to work on together), but it often turns out that go
60.
by dondraper36 1y ago
Speaking of ADHD, sometimes I wonder whether that might be a false positive self-diagnosis in my case. About 10 years ago, when I consumed much less media content like Instagram or YouTube, everything was different in that I used to be an a

More ›