>>108818475
Plan first. Build second.
>t. Contractor

>>108818475
Design everything like it's going to be an enterprise project with thousands of clients just in case.
Use strings for all vars because anything can be a string and you can't fit words into numbers.

>>108818475
build one or two quickly and throw them away
and don't use k8s

>>108818571
I don't understand why would anyone use k8s ever, it's complete hotseshit. You're better off with a simple bash script for deployment and once you have something more complex, just write your own deployment program that fits your goals in any language you prefer and just avoid doing yaml file deployments.

>>108818475
>What's your best software architecture advice?
Just yolo it. Write a quick and dirty version of your software to prove the concept, and then just rewrite it a second time. It's probably not the most efficient way (so you wouldn't do this for work), but every single successful software project I've done has been the result of a FULL rewrite of a quick-and-dirty prototype.
I find that if I try to plan and be careful from the beginning, I don't know all the details, and the plan ends up being incomplete and I have to deviate from the plan and then everything goes to shit and I have to rewrite everything anyway. I never know what kinds of unforeseen problems I'm going to have until I just yolo it.

File: 649034013_133650385517062(...).jpg (42 KB, 612x408)

42 KB JPG

>>108818475
First make it work, then make it right,
finally, make it fast

>>108818597
This is called rapid prototyping, and is sometimes used professionally. Having an early prototype to mess around with isn't useful just for the programmer, but you can also show it to cow-orkers, or even potential customers, and gather their input before you start writing the real thing.
You can make the prototype in something like Python or JS to get it done as fast as possible, and then use C++ or whatever for the real program.

>>108818475
Reject software "architecture". Embrace software evolution.

you probably don't need docker
getting it mostly right is better than taking forever to perfect it from a job security pov
if you end up in a situation where you can't implement A because B is broken because C is broken because D is broken then put in a shitty hotfix for B so you can implement A. This happens all the time in real codebases but nobody wants to hear you couldn't do your job because the code is a house of cards. They just want results.
things that are good for your job security and career aren't necessarily things that are good for the product.
you can get fired anytime so have a ton of savings

this is more career advice for software people than software architecture now that I read it back

>>108818475
It's not """impossible""", you just aren't being smart enough.

>>108818539
Try first
Go do something else if it doesn't work second
>t. paid by the hour

>>108818543
this is what I am doing for every project I am starting, doesn't matter how big it is, I open Penpot and design the shit and when everything looks good and makes sense I am starting with the code.

>>108821936
This. Use genetic algorithms in Lisp for every problem.

File: GAoiwxDaoAAIE84.jpg (107 KB, 1079x1075)

107 KB JPG

Know what your inputs are and know what your outputs are.
A bad algorithm can always be replaced with a good one. A bad input requires rethinking the entire solution.

>>108818475
Collateral damage of total failure determines planning effort.