29-05

2026-05-29 08:41:15 +01:00
parent 5d30c8f19e
commit a7285933c3
37 changed files with 1210 additions and 137 deletions
--- a/Articles/20260501153346-substack_articles.org
+++ b/Articles/20260501153346-substack_articles.org
@@ -4,4 +4,6 @@
 #+title: Substack Articles
 #+filetags: :notes:articles:

-[[id:973f2e9c-f161-45ad-8f19-2e4d563f56ac][The 20 Software Engineering Laws]]
+- [[id:973f2e9c-f161-45ad-8f19-2e4d563f56ac][The 20 Software Engineering Laws]]
+
+- [[https://medium.com/data-science-collective/microsoft-banned-ai-because-it-cost-too-much-135bcbf15a18][Microsoft banned AI because it cost too much.]]
--- a/Articles/20260522112659-i_thought_i_knew_system_design_article.org
+++ b/Articles/20260522112659-i_thought_i_knew_system_design_article.org
@@ -0,0 +1,45 @@
+:PROPERTIES:
+:ID:       9f220a90-635a-4744-9664-be89d8b2a64b
+:END:
+#+title: I Thought I Knew System Design Until I Met a Google L7 Interviewer
+#+filetags: :articles:notes:
+
+* AI summary:
+- System design is not about memorising architecture patterns; it is about knowing why each component is needed.
+- Start with real numbers first, such as traffic, read/write ratio, latency, and throughput, before drawing the design.
+- Every component, like caching, sharding, or replication, only helps under certain conditions.
+- Good designers think through failure cases, such as database crashes, cache delays, or datacentre splits.
+- The best approach is to start simple, measure the system, and only add complexity when a clear metric proves it is needed.
+
+* Article Notes
+   :PROPERTIES:
+   :NOTER_DOCUMENT: ../../../pdfs/_articles/I Thought I Knew System Design Until I Met a Google L7 Interviewer.pdf 
+   :NOTER_AUTO_SAVE_LAST_LOCATION: t
+   :NOTER_PAGE: 4
+   :END:
+** sharding or replication.
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.2849462365591398 0.7887537993920972 0.43870967741935485 0.7993920972644377)))
+:END:
+Sharding is the process of splitting a database into smaller, more manageable pieces called shards. Each shard is a separate database that contains a subset of the data. Replication, on the other hand, is the process of copying data from one database to another. This can be done for backup purposes or to improve performance by distributing read requests across multiple replicas.
+** Notes for page 3
+:PROPERTIES:
+:NOTER_PAGE: 3
+:HIGHLIGHT: #s(pdf-highlight 3 (3 (0.07204301075268817 0.8882978723404256 0.6440860215053763 0.9224924012158054)))
+:END:
+#+BEGIN_QUOTE
+This is the part that changes everything. Every component has this envelope of conditions where it actually helps. Caching works
+when reads dominate and access patterns cluster together. Sharding makes sense when write throughput matters way more than
+transactional guarantees. Replication helps when read availability beats consistency.
+#+END_QUOTE
+** Notes for page 4
+:PROPERTIES:
+:NOTER_PAGE: 4
+:HIGHLIGHT: #s(pdf-highlight 4 (4 (0.06774193548387097 0.29635258358662614 0.12365591397849462 0.3366261398176292)))
+:END:
+#+BEGIN_QUOTE
+Start with one database, one server, no cache. Only scale when some specific metric like latency or throughput or cost crosses a
+threshold you can actually name. When you add a component, explain what new failure mode it introduces and how you’d even
+detect it.
+#+END_QUOTE
--- a/Articles/20260522115235-every_senior_engineer_has_read_these_books_article.org
+++ b/Articles/20260522115235-every_senior_engineer_has_read_these_books_article.org
@@ -0,0 +1,124 @@
+:PROPERTIES:
+:ID:       c3b075bc-44c9-43eb-9c44-a58cb532fc35
+:END:
+#+title: Every Senior Engineer I Respect Has Read These Books (Have You?)
+#+filetags: :articles:notes:
+
+* Article Notes:
+   :PROPERTIES:
+   :NOTER_DOCUMENT: ../../../pdfs/_articles/Every Senior Engineer I Respect Has Read These Books (Have You_) _ by The Latency Gambler _ Mar, 2026 _ Medium.pdf
+   :NOTER_AUTO_SAVE_LAST_LOCATION: t
+   :NOTER_PAGE: 3
+   :END:
+** Notes for page 1
+:PROPERTIES:
+:NOTER_PAGE: 1
+:HIGHLIGHT: #s(pdf-highlight 1 (1 (0.21505376344086022 0.39893617021276595 0.2591397849462366 0.4217325227963526)))
+:END:
+#+BEGIN_QUOTE
+But they also read specifically, they read books that challenge assumptions about how
+software should be built.
+#+END_QUOTE
+[[../assets/_books/2026-05-22-senior-books.png]]
+** 1. The Pragmatic Programmer Hunt & Thomas
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.07119741100323623 0.06554878048780488 0.38187702265372164 0.0663109756097561)))
+:END:
+** The DRY principle originated here.
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.07119741100323623 0.13795731707317074 0.32362459546925565 0.1326219512195122)))
+:END:
+** Notes for page 2
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.10463861920172599 0.21417682926829268 0.4530744336569579 0.3307926829268293)))
+:END:
+#+BEGIN_QUOTE
+Tracer bullet approach:
+Instead of:
+[Full DB layer] → [Full business logic] → [Full API] → [Full UI]
+(nothing works until everything is done)
+Do this:
+[Minimal DB] → [Minimal logic] → [Minimal API] → [Minimal UI]
+(thin slice works end-to-end, then iterate)
+#+END_QUOTE
+** 2. Designing Data-Intensive Applications Martin Kleppmann
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.07551240560949299 0.4214939024390244 0.47788565264293414 0.42225609756097565)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium.png]]
+** Author’s website
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.2118279569892473 0.8199088145896657 0.05161290322580645 0.8237082066869301)))
+:END:
+https://dataintensive.net/
+** 3. The Mythical Man-Month Fred Brooks
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.07526881720430108 0.8427051671732523 0.3419354838709677 0.8381458966565349)))
+:END:
+** Nine women cannot deliver a baby in one month.
+:PROPERTIES:
+:NOTER_PAGE: 2
+:HIGHLIGHT: #s(pdf-highlight 2 (2 (0.3043010752688172 0.9156534954407295 0.6741935483870968 0.912613981762918)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-01.png]]
+** 4. Refactoring Martin Fowler
+:PROPERTIES:
+:NOTER_PAGE: 3
+:HIGHLIGHT: #s(pdf-highlight 3 (3 (0.07204301075268817 0.25835866261398177 0.26881720430107525 0.2613981762917933)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-02.png]]
+** 5. Software Architecture: The Hard Parts Richards & Ford
+:PROPERTIES:
+:NOTER_PAGE: 3
+:HIGHLIGHT: #s(pdf-highlight 3 (3 (0.07634408602150537 0.7241641337386018 0.4698924731182796 0.7165653495440729)))
+:END:
+** 6. Working Effectively with Legacy Code Michael Feathers
+:PROPERTIES:
+:NOTER_PAGE: 4
+:HIGHLIGHT: #s(pdf-highlight 4 (4 (0.06881720430107527 0.1899696048632219 0.46021505376344085 0.1884498480243161)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-03.png]]
+** 7. Database Internals Alex Petrov
+:PROPERTIES:
+:NOTER_PAGE: 4
+:HIGHLIGHT: #s(pdf-highlight 4 (4 (0.06989247311827956 0.5075987841945289 0.310752688172043 0.5144376899696048)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-04.png]]
+** 8. A Philosophy of Software Design John Ousterhout
+:PROPERTIES:
+:NOTER_PAGE: 4
+:HIGHLIGHT: #s(pdf-highlight 4 (4 (0.07311827956989247 0.8586626139817629 0.4376344086021505 0.8594224924012158)))
+:END:
+** Notes for page 4
+:PROPERTIES:
+:NOTER_PAGE: 4
+:HIGHLIGHT: #s(pdf-highlight 4 (4 (0.3720430107526882 0.8806990881458967 0.17956989247311828 0.9247720364741642)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-05.png]]
+#+BEGIN_QUOTE
+Ousterhout’s core argument: the primary enemy of software quality is
+complexity, and complexity accumulates through shallow modules, information leakage, and temporal
+decomposition.
+#+END_QUOTE
+** 9. Clean Code Robert C. Martin
+:PROPERTIES:
+:NOTER_PAGE: 5
+:HIGHLIGHT: #s(pdf-highlight 5 (5 (0.07204301075268817 0.32598784194528874 0.2924731182795699 0.32370820668693007)))
+:END:
+** The Reading Order That Makes Sense
+:PROPERTIES:
+:NOTER_PAGE: 5
+:HIGHLIGHT: #s(pdf-highlight 5 (5 (0.4021505376344086 0.7188449848024316 0.08064516129032258 0.7188449848024316)))
+:END:
+[[../assets/_books/2026-05-22-every-senior-engineer-i-respect-has-read-these-books-have-you-by-the-latency-gambler-mar-2026-medium-06.png]]
+** Nine books. Maybe 4,000 pages total.
+:PROPERTIES:
+:NOTER_PAGE: 6
+:HIGHLIGHT: #s(pdf-highlight 6 (6 (0.07096774193548387 0.14817629179331307 0.34623655913978496 0.15273556231003038)))
+:END:
--- a/Articles/20260522161728-software_quality_article.org
+++ b/Articles/20260522161728-software_quality_article.org
@@ -0,0 +1,34 @@
+:PROPERTIES:
+:ID:       453e252a-34f4-4d84-adab-35fe69ceed55
+:END:
+#+title: Software Quality Article
+#+filetags: :articles:notes:software:
+
+* Article Notes:
+   :PROPERTIES:
+   :NOTER_DOCUMENT: ../../../pdfs/_articles/software-quality.pdf
+   :NOTER_AUTO_SAVE_LAST_LOCATION: t
+   :NOTER_PAGE: 11
+   :END:
+
+** Notes for page 1
+:PROPERTIES:
+:NOTER_PAGE: 1
+:HIGHLIGHT: #s(pdf-highlight 1 (1 (0.07096774193548387 0.40197568389057753 0.5849462365591398 0.44680851063829785)))
+:END:
+#+BEGIN_QUOTE
+We've normalized software catastrophes to the point where a Calculator
+leaking 32GB of RAM barely makes the news.
+#+END_QUOTE
+[[../assets/_books/2026-05-22-software-quality.png]]
+
+** Notes for page 10
+:PROPERTIES:
+:NOTER_PAGE: 10
+:HIGHLIGHT: #s(pdf-highlight 10 (10 (0.07419354838709677 0.6565349544072948 0.7365591397849462 0.743161094224924)))
+:END:
+#+BEGIN_QUOTE
+Teach fundamental engineering principles again. Array bounds
+checking. Memory management. Algorithm complexity. These aren't
+outdated concepts—they're engineering fundamentals.
+#+END_QUOTE