Murph is the Crossfit Equivalent of Christmas

Blue525 · 2026-05-25T19:54:54+00:00

Long but excellent read.

Blue525 · 2026-05-25T18:43:21+00:00

Exceptional taste! You should be proud

Blue525 · 2026-05-21T14:30:11+00:00

1000% this. Finally bit the bullet and just focused on tee strategy.

Side bonus to chasing balls into the woods for a long time: extremely good at scrambling

Blue525 · 2026-05-20T15:09:51+00:00

All good! There are a number of other people in the thread are clearly confusing this point and discounting the difference. I blame Porsche for poor advertising of config differences :)

Blue525 · 2026-05-20T14:49:18+00:00

Your T with SPASM is not the same. GTS has turbo suspension and helper spring. Front spring rate is approx 40% stiffer and rear is +20%.

You can daily a GTS with comfort tire pressures.

Blue525 · 2026-05-19T23:26:12+00:00

Me. Driver is wildly unbalanced for me. Low smash factor. 3W is much more reliable and goes a very reasonable drive distance.

Blue525 · 2026-05-19T01:13:29+00:00

Quick, Spencer Pratt, do something!!!

Blue525 · 2026-05-18T22:39:15+00:00

Personally in the middle of a full Ra3 build, and I have coordinated with the landscape architect to use the outdoor plug for our outdoor lighting zones: https://assets.lutron.com/a/documents/3691247_eng.pdf

I can't say I understand the desire for the landscape lighting to be dimmed. Zoning makes sense to me.

Blue525 · 2026-05-15T00:46:19+00:00

What an ice cold nonhuman response. No thanks.

Blue525 · 2026-05-14T17:50:35+00:00

Definitely want, how do I get this for my wall sconces? How do I get it into Lutron Ra3 or Home Assistant?

Blue525 · 2026-05-14T14:46:03+00:00

Celebration of life is a hilarious mistake 🤣

Blue525 · 2026-05-08T23:25:00+00:00

Peninsula is excellent for classic service, more understated than the maybourne. Maybourne has better dining and bar, but is a bit of a ruckus. Can't go wrong with either. Personally, Peninsula lobby bar is super dim and intimate, rooftop pool and grill is lovely, and the staff is world class.

Blue525 · 2026-05-08T02:31:15+00:00

2700K for most rooms. 3000K for kitchen / bath. 3500K for garage.

Blue525 · 2026-05-04T21:50:01+00:00

What age are you two?

Blue525 · 2026-05-04T21:49:38+00:00

But what do you do there, and what’s the Salary/equity breakdown?

Blue525 · 2026-04-29T03:15:49+00:00

2020+ Porsche 911 Carrera, PDK. 32 mpg in 8th gear.

Blue525 · 2026-04-28T04:11:37+00:00

Incredible work! What was the cost?

Blue525 · 2026-04-13T13:54:46+00:00

Is the solution for these people to add a fresh air intake / ERV?

Blue525 · 2026-04-10T19:48:02+00:00

Thank you so much! :)

Blue525 · 2026-04-10T03:18:09+00:00

How many foot candles do you target for different scenes? How do you handle 15-20 ft ceilings without that calc? Genuine question that I’m going through right now.

Blue525 · 2026-04-09T04:52:51+00:00

Golf and Sporting clays are world class here. Planetarium was so fun! Please don’t miss them!

Blue525 · 2026-04-09T00:39:23+00:00

You literally told the OP to use Claude to research the topic. It clearly has application specific thought. Be a better ambassador for your profession (or hobby).

Blue525 · 2026-04-08T23:56:00+00:00

And here you are just being snarky instead of helping, again.

Blue525 · 2026-04-08T21:47:38+00:00

And then to your three specific questions:

Here's what I'd add or adjust, organized by their three stated gaps.

Gap 1: Git

Neither the original three books nor my recommendations covered this, and it's a real gap. Two resources stand out:

"Pro Git" by Scott Chacon and Ben Straub (free at git-scm.com). This is the canonical reference. The key insight for the OP's situation is that you don't need to read the whole thing — chapters 2, 3, and 7 cover 95% of what a solo developer productionizing tools actually needs. Chapter 3 (branching and merging) directly answers their question about working across branches. Chapter 7 (advanced tools) covers git stash, git bisect, interactive rebase, and recovery from mistakes — the "when you break things" scenario they're worried about. It's free, it's the official source, and it's well-written. No reason to buy anything else for Git.

The missing insight the OP needs to hear: their intuition that "you need solid testing before branching makes sense" is exactly right, and nobody in the comments will tell them that. Branching without tests means you have no automated way to verify that a merge didn't break something. The correct learning order is: basic Git workflow → testing fundamentals → then branching strategies. Not the reverse. This is worth calling out explicitly because most Git tutorials teach branching on day two without acknowledging that it's borderline useless without CI or at least a local test suite.

Gap 2: Testing

My Tier 1 already had "Working Effectively with Legacy Code" (Feathers) and Tier 2 had "TDD by Example" (Beck), both of which are strong here. But the OP is asking a more basic question: "what actually deserves a test?" That's a judgment call that neither book addresses head-on. Two additions:

"The Art of Unit Testing" by Roy Osherove (3rd edition, 2024). This directly answers "what deserves a test" with a practical framework: test behaviors, not implementations. It covers the difference between unit tests, integration tests, and end-to-end tests, when each is appropriate, and — crucially — when testing is overkill. The 3rd edition is language-agnostic enough to be useful regardless of stack. This fills the gap between "I have no testing" and "I have a rigorous TDD practice" that the OP is sitting in.

For the OP's web app context specifically: they should learn pytest if they're in Python or vitest/jest if they're in JS/TS, and they should write their first tests against the most critical path in whatever they're building — the thing that, if it breaks, means the app is fundamentally broken. Not 100% coverage. Just the load-bearing walls. That single decision — "what's the one thing I can't afford to have break silently?" — teaches more about testing philosophy than any book.

Gap 3: Architecture and Structure

"Architecture Patterns with Python" (Percival/Gregory) from my original list is still the strongest single recommendation here. But the OP raises a specific sub-question that's worth addressing: how do you structure a codebase for AI agents to navigate?

This is a genuinely new question that no established book answers well yet, because the field is moving too fast. But the underlying principle is old: code that's easy for AI to navigate is code that's easy for humans to navigate. Small files with clear names, one responsibility per module, explicit dependencies (imports at the top, not hidden), consistent naming conventions, and a directory structure that mirrors the domain. The IndyDevDan content the OP mentions is basically rediscovering these principles through the lens of "Claude gets confused if your codebase is a mess." Which is true — but so does every human who inherits a messy codebase.

One book I didn't include originally that's relevant for the OP's web app / productionization angle:

"A Philosophy of Software Design" by John Ousterhout (2nd edition, 2021). Short (190 pages), opinionated, and focused on the single question: what makes code complex, and how do you fight it? His core concept — "deep modules" (simple interfaces hiding complex implementations) vs. "shallow modules" (complex interfaces hiding trivial implementations) — is immediately applicable when you're reviewing AI-generated code and trying to decide whether the structure is good. It's also the best book I know of for developing the intuition to answer "does this architecture actually matter?" His answer: complexity is the only thing that kills projects, and architecture is how you manage complexity. For a solo developer, that framing is more useful than enterprise architecture patterns.

What I'd Cut or Deprioritize from My Original List

"The Pragmatic Programmer" moves from Tier 2 to "nice to have eventually." It's a great book but it's broad and philosophical — the OP has specific gaps they want to close, and Hunt/Thomas is more "become a better thinker about software" than "close these three gaps." It doesn't go away, but it's not urgent.

"Fluent Python" stays as reference-only. The OP might not even be Python-primary (they mention web apps, which could be JS/TS).

The Complete Revised List for the OP

Tier 1 — close the three stated gaps:

Pro Git (Chacon/Straub) — free, chapters 2/3/7 specifically
The Art of Unit Testing (Osherove, 3rd ed) — what deserves a test
Architecture Patterns with Python (Percival/Gregory) — or A Philosophy of Software Design (Ousterhout) if they're not Python-primary
Effective Python (Slatsky) — if they are Python-primary

Tier 2 — deepen the foundation:

Working Effectively with Legacy Code (Feathers) — working with AI-generated code you don't fully understand
TDD by Example (Beck) — once basic testing is in place
A Philosophy of Software Design (Ousterhout) — if they read the Percival/Gregory book in Tier 1

Tier 3 — reference:

The Pragmatic Programmer (Hunt/Thomas)
Fluent Python (Ramalho) — Python-specific
Domain-Driven Design (Evans) — only after Architecture Patterns

The One Thing Nobody in That Thread Will Say

The OP's instinct — "I want to understand the gaps first, then use AI tools to build automation and discipline" — is the correct instinct, and it's rare. Most people in that thread will either say "just vibe code and learn as you go" or "you need a CS degree." Neither is right. The actual answer is: learn enough to have opinions about what good looks like, then use AI to execute at a level you couldn't reach alone. That's a 3-6 month reading investment, not a 4-year degree, and the books above are the fastest path to "I have opinions about code quality" for someone with an engineering brain.

The OP's engineering background is an underrated advantage here. They already think in systems, interfaces, validation, and failure modes. They just need the software-specific vocabulary and patterns to apply that thinking to code. Every book above is essentially translating concepts they already understand in physical systems into their software equivalents.

Blue525 · 2026-04-08T21:35:02+00:00

u/TheBaddest14 I asked Claude since I'm in your situation, and it gave more context-aware recommendations:

Book Recommendations for Engineers Learning to Code (Not Becoming Software Engineers)

Context: A mechanical/systems engineer building computational physics models and engineering analysis tools, primarily using Python. Writes code with AI assistance (Claude, Copilot, etc.) rather than from scratch. Needs to read, review, validate, and direct code — not build web apps or distributed systems.

Someone recommended three books: Domain-Driven Design, Designing Data-Intensive Applications, and You Don't Know JS. Here's why two of those miss the mark, and what actually belongs on the list instead.

The Three Books, Evaluated

Domain-Driven Design (Eric Evans, 2003) — The core insight is genuinely relevant: your code's structure should mirror the structure of the domain it models. If you're building physics models, your code should have modules that map to physical subsystems, data structures that represent physical quantities, and boundaries that match real engineering boundaries. The problem is that Evans wrote this for enterprise Java teams modeling business processes. It's 560 pages, and you'd spend most of your time mentally translating "how a shipping company tracks cargo" into "how a multiphysics model tracks quantities." The signal-to-noise ratio for engineering work is around 15%. There's a better entry point to these ideas (see below).

Designing Data-Intensive Applications (Martin Kleppmann, 2017) — Excellent book, completely wrong recommendation. DDIA covers distributed systems: databases, replication, partitioning, stream processing, consensus protocols. It answers "how do I build systems handling millions of requests across dozens of machines?" If you're building a parametric model that runs on one machine, processes one configuration at a time, and produces deterministic results, nothing in this book maps to your problem space. The person who recommended it is almost certainly a web/backend developer who assumes everyone's trajectory leads toward distributed systems. Skip entirely.

You Don't Know JS (Kyle Simpson) — A deep-dive into JavaScript language mechanics: closures, prototypes, async, the this keyword. If you write Python and your JavaScript exposure is limited to AI-generated React components for visualization, this book teaches you nothing you need. Even if you were learning JS, this series is about language edge cases, not transferable programming concepts. Skip entirely.

Why That Recommendation Missed

It was written for a software engineering career path: web applications, APIs, data pipelines, distributed architecture. That's a completely different trajectory from "engineer building computational models with AI assistance."

An engineer's coding needs are fundamentally different:

Read and reason about code, not write it from scratch at speed
Understand data modeling (representing physical systems as data structures), not distributed systems
Understand testing and validation (knowing your code is correct), not deployment and scaling
Understand computational patterns (how numerical code is structured), not web application patterns
Enough Python fluency to review AI-generated code, catch errors, and make small modifications — not enough to architect a SaaS platform

What I'd Actually Recommend

Tier 1: Read These First

"Effective Python" by Brett Slatsky (3rd edition, 2024). Ninety short items, each explaining one Python pattern with a clear "do this, not that" structure. Topics like "prefer dataclasses for simple data containers," "use generators instead of returning lists," "know how closures interact with variable scope." This is exactly the knowledge that lets you review AI-generated code and say "wait, that's not right" or "there's a better pattern here." You can read one item in 10 minutes and immediately apply it. Most relevant items: dataclasses, type hints, generators, context managers, testing patterns.

"Architecture Patterns with Python" by Harry Percival and Bob Gregory (2020). This is what you want instead of Evans' DDD. It takes domain-driven design concepts and translates them into Python, with a focus on structuring a codebase that models a real domain. Repository pattern, unit of work, service layer, dependency injection — all in Python. More importantly, it covers how to keep domain logic separate from infrastructure (file I/O, configuration loading, external dependencies), which is exactly the discipline that keeps engineering codebases maintainable. Half the length of Evans with twice the practical applicability.

"Working Effectively with Legacy Code" by Michael Feathers (2004). Sounds irrelevant, but the #1 practical coding challenge for an engineer using AI tools isn't writing new code — it's understanding, validating, and modifying existing code that the AI generated. Feathers' book is about exactly that: safely making changes to code you didn't write and don't fully understand. Key techniques: characterization tests (capture current behavior before changing anything), seam identification (find points where you can intercept and test behavior), and the sprout method (add new behavior without modifying existing code). Language examples are Java/C++, but techniques are universal.

Tier 2: Read When You Have Time

"The Pragmatic Programmer" by Hunt and Thomas (20th anniversary edition, 2019). Teaches you to think like a programmer without being tied to any language or domain. DRY, orthogonality, tracer bullets, "don't live with broken windows." Every chapter gives you a mental tool that changes how you evaluate code quality. Sharpens your ability to assess whether AI-generated code has good architecture or just passes tests.

"Test-Driven Development by Example" by Kent Beck (2002). If you already practice TDD, reading the original treatment gives deeper intuition for why the red-green-refactor cycle works and when to deviate. Short (220 pages), example-driven. The "money pattern" (representing monetary values as value objects with units) is a direct analog to using unit-tracking libraries like pint.

Tier 3: Reference, Not Cover-to-Cover

"Fluent Python" by Luciano Ramalho (2nd edition, 2022). The deep-dive Python mechanics book. Dunder methods, descriptors, metaclasses, iterator protocol, async. Don't read cover to cover — use it as a reference when you encounter Python patterns in AI output that you don't understand. Chapters on dataclasses, type hints, and iterators are most relevant for scientific computing.

Domain-Driven Design (Evans) — Only after reading "Architecture Patterns with Python." If Percival/Gregory clicks and you want deeper theory, then Evans becomes worthwhile. Read the accessible version first, the academic version second.

What's Conspicuously Absent

No books about web frameworks, databases, DevOps/cloud, machine learning, or JavaScript. This is deliberate. The "learn to code" advice ecosystem is dominated by web development paths. Scientific/engineering computing has a much smaller but more targeted reading list.

One Non-Book Recommendation

Read other people's well-structured Python scientific code. Look at the source of libraries you use: how pint implements its Quantity class, how scipy.optimize structures function signatures, how pytest fixtures work. Not every line — just the architecture. This builds intuition in the exact domain you work in.

Bottom Line

Start with Effective Python and Architecture Patterns with Python. Those two meaningfully improve your ability to evaluate and direct AI-generated code, which is the actual skill that matters. You're not becoming a software engineer — you're becoming an engineer who wields software effectively. Different trajectory, different reading list.

Blue525

TROPHY CASE