I just found out about Lagom from this blog post and it's exactly what I have been looking for.

All other Python options I've seen feel too involved or leak too much into your code. Lagom seems to balance everything just right.

Thank you!

Haha, I can imagine Steve is quite pleased with this comment. You should look up the meaning of the (Swedish) word lagom.

Thanks 4140tm and thanks cinntaile. I was very pleased. That was very much the intention of the name

How do you know what testing/designing practices all "important" software projects use?

Do you expect it to be advertised?

It's been twenty years. People would have moved on to new jobs, and spread the word with them. Some would have applied for jobs there. After all, non-googlers know a thing or two about their infrastructure, despite being mostly a trade secret.

If nothing else, apparently there are enough of disciples out there that it would be a great way of hiring the right people.

You'd have to believe there is some sort of cabal, completely bent on keeping this enormous advantage to themselves in absolute secrecy, to argue that it is a software development success story.

A few years back I saw something similar where subreddits were presented like a tree, based on topics (and popularity, I think). Made it easy to drill down to interesting niche subreddits.

Haven't been able to find it since.

You are skipping a step there - it's red -> green -> refactor

As for "tactical programming instead of strategic design" - that's entirely up to the developer and how they approach the problem. if you are prone to neglecting the design you'll do it any way. If anything, (actually) practicing TDD would force you to come up with better design.

How does TDD force you to a better design ?

By forcing you to think about your code's interface before thinking about its implementation. That means you get larger components that fit together based on the problem requirements, rather than components with interfaces that are only locally optimal.

You can see this same thing in action when watching functional programming live coding sessions: most live coding is bottom-up, but they still write the function signatures before writing any code.

This strikes me as tautological. If you're using anything statically typed you have to write the function signature before it's body.

Static typing is not synonymous with manifest typing (always require an explicit type declaration). Many functional languages can infer the type of an expression from its definition, so explicit type signatures are optional. These languages are still statically typed though.

It doesn't. It signals a particular point in time to improve the design.

Good design is a creative activity and cannot really be forced, only given space to grow.

People in general are bad in dealing with nuance. And there is enough of it in these type of books for some to overheat.

Nuance may leave a good feeling with the one reader. Black and white however will make your post go so much further as it either enrages or wins accolades and really who cares if it just gets forwarded and promoted and with it your name.

It's not a huge investment to learn. At the same time it's very valuable. I would prepare for CKAD first and do CKA only if relevant.

The main reason for not working NGINX examples is because there are two NGINX ingress controllers - one by NGINX and one maintained by k8s. Real fun if one does not know this upfront. Ingress api version changes don't help much, of course

You don't need precise specs to practice TDD. If you have idea of the code you need to write, you can write the test for it beforehand - no matter how often someone might change their mind about the app.

Doing so would actually make your life a lot easier when it's time to alter functionality, because now you have well tested and testable code. Code that is written to be tested is usually a lot easier to reason about, to change and extend.

If you do it in concise manner and test behavior rather than implementation, what you previously thought of overhead will actually speed you up.

Tests are also meant to be continously refactored, though.

If no one knows whether the code is correct a generated test could easily do more harm than good.

If no one is able/willing to refactor the code into understandable and testable bits, there's not much left to guarantee the correctness of it.

> The domain is fintech

What you describe is the opposite of what I expect from (modern) fintech.

* no tests

* god method with no proper documentation/requirements

* no one actually understanding the function deciding how much money to send! Isn't this one of the core functionalities of fintech products?

Just plain scary especially with money if they can't at the very least test the extremes and some in the middle values. Good gravy! What is the name of this company so I can avoid it...