The goal of the software game is to learn faster than you code

Workshop: Implementing Domain-Driven Design 4 days: $400 total - DDD Strategic and Tactical Design - EventStorming, Impact Mapping - Ports & Adapters / Hexagonal Architecture - Event-Driven Architecture - Live, virtual, online - Limited registration--same seat limit as full price. kalele.io/iddd-workshop #DDDesign #DDD #DomainDrivenDesign

Workshop: Implementing Domain-Driven Design 4 days: ̶$̶1̶6̶0̶0̶ $400 - DDD Strategic and Tactical Design - EventStorming, Impact Mapping - Ports & Adapters / Hexagonal Architecture - Event-Driven Architecture Limited registration--same seat limit as full price. kalele.io/iddd-workshop #DDDesign #DDD #DomainDrivenDesign

I don’t agree with it either. I hope that’s not a quote from something I wrote. I don’t remember writing that. But if I did write that, I have since changed my mind. Two years ago, I did not think the AI’s would be as capable and potent as they are. I also did not think that there would be a way to wrangle them to producing good code.

Hack of the days: taking Opus 4.7, ask him to look at a prompt, and tell you what he find ambiguous in it, and propose to improve it. Then A/B test results! (this should be a skill by the way... nobody saw a skill like this somewhere?)

Right now, I’m using Opus 4.6 with 4.7 as an advisor. Seems to work well! I guess 4.6 knows how to prompt 4.7 better than me…

If you are using gherkin for acceptance testing, you may find a gherkin mutation tester helpful. It makes changes to the gerkin tests and expects them to fail. If they don't that's worth investigating.

You don’t have a lead gen problem. You have a tool addiction problem. Apollo. Lemlist. Hunter. Sheets. $300/month. 10 tabs. Still no results. Saw this on Product Hunt 👇 One tool to replace your entire stack. Find leads. Outreach. Book meetings. ~$29/month. If this works… most stacks are dead. Try: launch.xp-one.io/

Unpopular option: most change that AI tools will bring for software engineers are likely to be making the practices that the best eng teams did until now, the baseline for those that want to stay competitive move fast Things like product-minded engineers, testing, o11y, CD etc

The "core four" resources.scrumalliance.org/…

And here I thought Haskell was challenging to learn… How naive!

How to coach a team that has been burnt by bad TDD philippe.bourgau.net/how-to-…

i was shocked to discover just now that my 2001 Agile Sw Dev book contains a discussion of the agile manifesto! knock me over with a feather duster, as they used to say. Take a look!

of course, for a particular UI it can always be argued that an optimized JSON payload for that UI would be more efficient, but then your JSON API is specialized for your user interface, thereby loosing its generality separate and thrive! htmx.org/essays/splitting-yo…

You can't bring a solution to somebody not aware of having a problem...

Fact: FP precedes OOP. Make your conclusion...

Python is probably the best procedural langage out there IMHO

My new dream stack for 2025: . Scala (for fun) . Kotlin (for profit)

Maybe. I think what you aren't exactly capturing is what an invariant is and why a root-based access is so important. Heres an oversimplified example: // invariant rule c = a b a = 3 b = 2 c = a b You can't trust clients to get this right. It's not the client's responsibility. The fact that a transaction is possible only ensures that a, b, and c are persisted atomically as one. The transaction doesn't guarantee the invariant. The business logic does, and that's the point of the encapsulating root, whether the behavior is on the root or on one or more other composed types. These values could be held by any means, such as attributes on an object or set as keys that reference values in a map ("a" -> a). Here's a more complex example that has a similar invariant rule: // tork is a calculation using // the current lever and stress class Tool { int lever int stress int tork calibrateUsing(gauge) { lever = gauge.increase(lever) stress = gauge.lower(stress) tork = gauge.tork(lever, stress) } } // client tool = Tool(settings) tool.calibrateUsing(gauge) repository.write(tool) The point of the encapsulation by some kind of behavioral component (even a code modual of related functions) is that the invariants can only be enforced and protected by strict control. Here's another example of the same rule using different containment: calibrateUsing(tool, gauge) { lever = tool("lever") lever = gauge.increase(lever) stress = tool("stress") stress = gauge.lower(stress) tork = gauge.tork(lever, stress) return ("lever" -> lever, "stress" -> stress, "tork" -> tork) } // client map tool = Tool(settings) ... tool = calibrateUsing(tool, gauge) repository.write(tool) This example may or may not be considered an Aggregate, and who cares? The principles are the same. In both examples, there is explicit business logic that protects the invariants. The database transaction only ensures that the values persistent atomically as one unit.

be on your guard hypermedia enthusiast: the temptations of employment loom increasingly large! deny them your essence!