Announcing CodeLiftSleep's Architecture Lab, a YouTube Channel dedicated to helping developers leveling up their architecture and fitness. The body doesn't operate in a vacuum, and I am a firm believer that to be your best mentally, you need to be at your best physically as well. Every episode will contain Software Architecture topics as well as an evidence-based Fitness tip to support you physically on your journey as well. The first episode in The Modern Architect's Career Playbook Series is "You're Already an Architect". Check it out and let me know what you think: youtu.be/SCCA-9dXB0U @ManningBooks @ManningMEAP #SoftwareArchitecture #SystemDesign #Fitness

This was such a great discussion about a very important topic! How you work with AI Agents determines your results with them and if you have no process or you are just "shotgunning" it, your results will be highly variable. The engineering process you normally use needs to be adapted for AI. At the end of the day, you are responsible for what goes into production, not the AI agent. @ManningBooks @ManningMEAP

Understanding tradeoffs are one of the key aspects of software engineering/architecture and you are faced with them constantly. Before making decisions, you MUST properly understand the tradeoffs to be able to make good ones. Grokking Software Architecture helps you do exactly this.

Interested in making your codebsse better one fix at a time? Follow this RED/GREEN regression test method for bug fixes. You can thank me in 6 months. And if you want to learn how to build systems that last, check out my book, Grokking Software Architecture from @ManningBooks found here: hubs.la/Q04dH6BX0

If you still think "writing code" means software engineering is over, I suggest you don't actually understand what software engineering actually is.

Thr bad news? Grokking Software Architecture is no longer the Deal of the Day at Manning. The great news? It's still 50% off during Manning's Labor Day sale! Check it out below: hubs.la/Q04dH6BX0

Clean-CTX started from me asking something nobody else seemed to be: "Why are we sending source code to an LLM at all?" It turned into something far greater than that. How deep will this rabbit hole go? I have no idea, but trust that I will be exploring it fully. Check out my latest LinkedIn article: linkedin.com/pulse/i-started…

Deal of the Day for September 2nd: Modern Software Architecture! Get half off my book, Grokking Software Architecture and other selected titles from @ManningBooks @ManningMEAP : hubs.la/Q03-d27Y0

A "contract" in software is often syntactically defined via keywords like Interface or Abstract Class. But it doesn't HAVE TO BE. A contract merely defines the "promise" your code makes about it's behavior and a behavioral contract is JUST AS VALID, as a syntax based one. So for instance, when people state that JavaScript doesn't have "contracts", they are partially right. It doesn't have contracts defined through Syntax, but it DOES have contracts that can be defined through behavior, which are JUST AS VALID. Key takeaway: whether you define a contract via interface, inherit from a base class or simply a throw inside a class that enforces a method being present in a subclass, to explicitly create the contract yourself, it does not matter. All that matters is a promise is being made and whether it gets caught at compile time or run time, it will be the same result. An error. Now, obviously it's more helpful at compile time, and very few people are using plain JS anymore where they would have to manually enforce this. But the bigger point that many developers miss, is th underlying notion of what actually defines a contract, and it isn't a keyword. Understanding this will make you a better architect in ANY language, and is what my book Grokking Software Architecture aims to teach. Check it out here! hubs.la/Q04dH6BX0 @ManningBooks @ManningMEAP

Great architecture that stands the test of time doesn't "just happen". It's an intentional process that is followed day-to-day that produces it! The same processes I use with AI are the same processes I use in my normal engineering. Why? Because they are the SAME! The application of the process changes, the actual process does not.

In 95% of cases, you don't need a better model. You need better architectural and engineering gates around the model that you are using. I almost never use anything other than DeepSeek Flash 4 in my personal work or Claude Sonnet in my professional work. Why? Because I have tremendous architectural and engineering gates and processes around it so that the constraints make better models nearly irrelevant. I don't need more expensive models that make better "guesses" because I removed almost all the guesswork to begin with. These are the type of thinking and architectural processes I teach in Grokking Software Architecture. If you still haven't picked up your copy, what are you asking for? Still in MEAP with 10 full chapters out and a significant online code repo supporting the chapters in 4 languages (C#, Java, JavaScript, Python). Check it out here hubs.la/Q04dH6BX0 @ManningBooks @ManningMEAP

Always remember, saying "I don't know, AI told me that was correct" still doesn't work in a code review when you get asked "Why did you do that?" Own your decisions and be accountable!