Stick to boring architecture for as long as possible, and spend the majority of your time, and resources, building something your customers are willing to pay for.
Comments
Log in with your Bluesky account to leave a comment
How do you approach suggesting sticking to boring, solid architectures to a team full of starry eyed developers and managers who want to try out the new shiny things?
Remind them who is going to be on the bridge line at 2am trying to get the site back up when their shiny new shit inevitably breaks. Skin in the game is a strong motivator.
This addresses an instinct I've sometimes fought to stifle in myself - the desire to build big beautiful orchestration frameworks for things that are very pretty but where the time-investment is way way premature (and often existing projects would be good enough so no need to code it anew).
Yes, but at the same time be prepared that you might need to change that. Because when it's no longer possible, it too late to *begin* thinking about it.
As kubernetes gets more boring, I am getting more work. If anything, kubernetes is facilitating cloud exit. The strangest discussion popped up in my Linux users group that I am confused by; how run Cobol on k8s.
Comments
I see so much wasted time picking a programming language and brings back tab vs space OR Emacs vs vim discussions of past era...
Rails/Django/Laravel (full stack framework)
Postgres
Tailwind
If you have to explain your architecture to me, hard pass.
Boring tech + critical use case = good company
Soaring: Litestream replicates it to s3 with a hot standby 🤯
If the team is not ready for such tool it will bring them down. It applies to any tool, but I am referring to experience.