(Disclaimer: I teach this stuff) Good article. It's a keeper. Touches on a lot of things I've been telling clients for years. My takeaways: - Pure functions i

(Disclaimer: I teach this stuff) Good article. It's a keeper. Touches on a lot of things I've been telling clients for years. My takeaways: - Pure functions in little composable pieces. Screw the fact you can't find programmers. With 1/20th the staff, it's not important - Zero to few meetings. Keep focused on one thing. No playing around with WhizzBang Platform 7.0 because all the cool kids are using it. Mind your knitting. - Keep It Simple, Stupid. Engineers are our own worst enemy. Solve the most simple problem possible. Then add complexity a little bit at a time, only as a last resort. For those of you saying "But messaging is solved", "Erlang was written for messaging", and so forth, this is where you missed. Any complex system (with a few notable exceptions) will look very simple when solved in this manner. In fact, that's the entire point. - Running and deploying are the same thing. CI/CD. There is no Big Red Button to push because we're always working on the airplane engines while the plane is flying Coming from a traditional OOA/D/P background, this mentality was extremely foreign to me. Even though I was using and talking about TDD, it was still in terms of composing and re-arranging object graphs. It wasn't until I got into F# several years ago that the pieces started coming together. This is a very difficult conceptual leap to make, because a lot of the ways you work looks completely ass-backwards to folks who are used to doing it the other way.