yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards.

It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it'

the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.

> Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress.

Good advice which applies not only to software development. I've found that focusing on what's currently known and on what I can change removes anxiety, allows me to move forward and then usually the unknowns resolve themselves along the way.

It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".

Even when that does happen... and I'd argue that it often does not, if you've done the work to make your interface pretty, and write a precise, accurate test suite, you've usually done the work to make the actual functions neat and orderly...

Even when you end up with a black box full of entropy, it's segregated from the rest of the system. You can feel free to change the rest of the system around it and know that the black box will keep doing it's job, as long as you keep using the well-written API within spec.

But, that's not all you get... because you took the time to write the tests, you can refactor this entropy box to your heart's content... until it starts looking more approachable. You've got your tests around the API, right? Then you don't even really need to change them to do the refactor work. The only reason to change the tests would be if you want the function to do something else (or you missed something, of course).

Take small steps... refactor out a couple lines at a time... run the tests with each iteration. Based on previous experience, you're going to end up with a fairly clear and concise implementation... not to mention performant.

Absolutely! Get something working and then keep it working while making small steps.

On the other hand, the example that comes to mind is Ron Jeffries' TDD sudoku solver.

I've seen several systems where the magic black box is doing things hilariously wrong---as long as it works on the test cases and the production results are sufficiently difficult to verify, it'll be accepted as gospel.

I agree. They all seem quite familiar, though more abstractly defined than I would define them. Perhaps that is why I am now a bit tired of development - too many new specific details to learn about the 'latest and greatest', but fundamentally it is all the same stuff anymore. Maybe I'll pick up Haskell, just to think in Lisp-ish terms again... But statistics and ML in general are now drawing me in - and I hated stats in college. Brand new concepts.

Like LoSboccacc said, all this stuff is in 'Code Complete' and the related series of books. Another I'd recommend is 'The Practical Guide to Structured System Design' and 'The Psychology of Computer Programming' (about egoless programming). Old books, but well written and perhaps seemingly basic considering how complex React/Node/javascript... seem to be, but the fundamentals never go out of fashion.