👑 Context is King 💻 Software Architecture & Design 📺 https://teapawt.org/t.co/zMGP2Ktbn4
Canada
Joined November 2008
- Tweets12K
- Following214
- Followers12.1K
- Likes6.9K
Pinned Tweet
Random reminder that I have a YouTube channel where I post videos about software architecture and design. Usually in the 10 min range trying be concise as possible. If you enjoy please share. Have suggestions? Please let me know.
youtube.com/@codeopinion
Why is your database generating your IDs?
It seems like a simple implementation detail, but it can have a pretty big impact on your system design.
Good luck if you don't think coupling matters anymore. Or maybe you aren't or ever have been thinking about it.
No me canso de decirlo:
A los programadores nos han arrancado de cuajo nuestra identidad de la noche a la mañana.
Que sí, que soy el primero en usar Codex o Claude Code.
Que sí, que shippear features a toda hostia, con las que antes ni soñabas, es dopamina por un tubo.
El problema no es el avance en sí, toda profesión evoluciona con el tiempo.
Pero es que en cuestión de 18 meses, todo lo que habías aprendido durante años, miles de horas de práctica, cientos de horas de estudio dentro y fuera del trabajo, se han esfumado.
Ya dan igual las discusiones sobre patrones de diseño.
Ya dan igual los libros de Uncle Bob.
Ya dan igual las noticias con las novedades en Swift.
Ya dan igual las horas debuggeando o resolviendo un problema que acababan en ese aha moment.
Hasta nos divertíamos cambiando el tema de colores del código.
Ya hace muchos meses que no toco una sola línea a mano, así que ya ni eso nos queda.
Nos hemos quedado sin identidad.
Como decimos en Galicia: A chorar a Cangas (supongo)
This PHP situation exemplifies when your in the fire to find a solution and look forward and not get into the "why didn't we do X". You can do that later. This comes to mind because I'm seeing "well you should have done..." replies which is absolutely useless to people looking for guidance and help.
"We switched to Event Driven Architecture. Now we cant debug anything."
A lot of the pain is from lack of tooling, visibility, and a misunderstanding of when to use events versus commands, or when something should even be asynchronous in the first place!
Event Driven Architecture isn't your architecture. Its just part of it.
codeopinion.com/event-driven…
I find it comical all the "domain knowledge matter more now".
No.. it mattered just as much before. Still the same. Nothing changed.
Derek Comartin retweeted
It's such a strange time to be a programmer. In a two-minute span it's "DDD and domain modeling generally are more important than ever" then "reading code is a waste of time, just let the agents manage it" then "classical software design principles are what matter." Please help.
Derek Comartin retweeted
So…are you updating data or performing an action? codeopinion.com/crud-vs-task…
Derek Comartin retweeted
CRUD vs Task Driven - codeopinion.com/crud-vs-task…
Stop Modeling Everything as CRUD. Task-Driven isn't always the answer either. Ask: What is the user trying to accomplish?
"design patterns don't matter because AI writes code" is like saying "architectural blueprints don't matter because power tools cut wood faster."
Ex: architectural (distributed, messaging) patterns like say a claim check or cache aside, do you need them? Depends on the context. But you can't say you do or don't unless you know what they are and the trade-offs. Otherwise you're just offloading decisions.
A recent example of this was pulling some metrics for a dashboard. The query made sense but was it efficient? Depends on the DB, amount of data, indexes, etc. Cache aside could be useful for partial values of the data set for historical data with a short expiry. But a cache would be more moving parts and complexity. Did the agent just magically decide it should use a partial cache or not? Are we deferring that answer to it without even any of that understanding? The answer can be yes, but it sure better have all the context to make that decision. But who is accountable?
Derek Comartin retweeted
Multi-Tenant Best Practices can Backfire - codeopinion.com/multi-tenant… @codeopinion
Derek Comartin retweeted
Ask a model to build out a public http API. It will be horrific to you. Why? Because is doing what it's told. You need to tell it how to handle your resource model, conventions, consistency, rate limiting, etc. None of this is "best practice" or a default, it's specific to your context that you need to define. And if you don't to ask you're left with, for example, a resource model that leaks your data model, that you can't change.
Derek Comartin retweeted
Alan K. said what was important: the messages in between the objects; that always been the tricky part ...
The older I get, the less I care about algorithms, data structures, and programming languages. Ai accelerated that.
Most algorithms, data structures, and programming languages are render trivial given that you understand the data, information and messaging between your components.
That is also why, sometimes, it is better to hire somebody with the domain knowledge than somebody that is purely very good at programming.
One of them is too expensive to get it wrong, and I testify this by the only failure in my entire career that I attribute to myself alone, and, it was not a problem of hard programming skills, but the fact I was not fast enough to discover all edge cases around the data.
The wisdom to avoid dead ends, and what NOT to do, comes from the understanding of the data in most contexts.
Multi-Tenant "Best Practices" often hide trade-offs. Where complexity really goes when using tenant context, shared databases, filtering, and feature flags.
Derek Comartin retweeted
Avoid API Breaking Changes - codeopinion.com/avoid-api-br… @codeopinion
A lot of software architecture and design is really just about where you want the coupling to live and the trade-offs around it. Yet I seemingly almost never hear people explicitly saying that's what's going on. I genuinely think that if people acknowledged that, the decisions would be much easier to make.
Derek Comartin retweeted
Good integration events don't just announce that data changed. They communicate a meaningful business event to other systems. Integration events are part of your public API. Design them deliberately. codeopinion.com/domain-event…
