It definitely can be. I'm constantly trying to push our stack away from anti-patterns and towards patterns that work well, are robust, and reduce cognitive load.
It starts by watching Simple Made Easy by Rich Hickey. And then making every member of your team watch it. Seriously, it is the most important talk in software engineering.
- objects/functions which mix IO/state with complex logic
- code than needs creds/secrets/config/state/AWS just to run tests
- CI/CD deploy systems that don't actually tell you if they successfully deployed or not. I've had AWS task deploys that time out but actually worked, and ones that seemingly take, but destabilize the system.
Only read the transcript but I'm not getting most of it. I mean it starts with a bunch of aphorisms we all agree with but when it should be getting more concrete it goes on with statements that are kind of vague.
E.g. what exactly does it mean to:
>> Don’t use an object to handle information. That’s not what objects were meant for. We need to create generic constructs that manipulate information. You build them once and reuse them. Objects raise complexity in that area.
Most of that I agree with, I'm curious why you'd recommend unit tests over integration tests? It seems at odds with the direction of overall software engineering best practices.
It starts by watching Simple Made Easy by Rich Hickey. And then making every member of your team watch it. Seriously, it is the most important talk in software engineering.
https://www.infoq.com/presentations/Simple-Made-Easy/
Exhausting patterns:
- Mutable shared state
- distributed state
- distributed, mutable, shared state ;)
- opaque state
- nebulosity, soft boundaries
- dynamicism
- deep inheritance, big objects, wide interfaces
- objects/functions which mix IO/state with complex logic
- code than needs creds/secrets/config/state/AWS just to run tests
- CI/CD deploy systems that don't actually tell you if they successfully deployed or not. I've had AWS task deploys that time out but actually worked, and ones that seemingly take, but destabilize the system.
---
Things that help me stay sane(r):
- pure functions
- declarative APIs/datatypes
- "hexagonal architecture" - stateful shell, functional core
- type systems, linting, autoformatting, autocomplete, a good IDE
- code does primarily either IO, state management, or logic, but minimal of the other ops
- push for unit tests over integration/system tests wherever possible
- dependency injection
- ability to run as much of the stack locally (in docker-compose) as possible
- infrastructure-as-code (terraform as much as possible)
- observability, telemetry, tracing, metrics, structured logs
- immutable event streams and reducers (vs mutable tables)
- make sure your team takes time periodically to refactor, design deliberately, and pay down tech debt.