The reason for leaving in the password.trim() would be one of the few things that I would ever document with a comment.

You might want to think about it a bit more before putting it to work. The comment with the streams example is far, far better.

It goes really well with YAGNI. Also DRY without YAGNI is a recipe for premature over-architecting.

This is also one of the main benefits of TDD. There was a really good video that I can’t find again of a demonstration of how TDD leads you to different solutions than you thought you use when you started. Because you code exclusively for one single requirement at a time, adding or changing just enough code to meet each new requirement without breaking the earlier tests. The design then evolves.

I’ve always heard of your “post-architecture” referred to as “evolutionary design”.

Many, many years ago I used to have two Wyse50 terminals, running split screens each with two parts. I did a lot of support on remote systems (via modem!) and I would have a session on a customer system, source code and running on our test system and internal stuff. I didn’t have space for a third terminal.

At another job I had an office with a “U” shaped desk. I would spread printouts across half the “U” and swivel around between the computer and the printouts.

So write it properly from the get-go. You can get 90% of the way by naming things properly and following the Single Responsibility Principle.

FORTRAN IV was the first language I learned to program in. Punch cards!!!

Kotlin is a very easy transition, and it sorts out a ton of issues that you find in Java. Certainly easier than moving to Rust.

I’m not sure that what developers really, really need is faster programming cycles. Most teams could benefit more by controlling the process - from idea to deployed. How much technical debt is incurred because users/customers can’t prioritize features or give accurate requirements, there’s way too much WIP, features are huge, releases are huge and infrequent and the feedback cycles are far too long.

So yeah, as programmers it’s always cool to look at ways to program faster, but what’s the point in programming stuff nobody needs faster? Or programming the wrong things faster?

I’d be willing to be that if you asked any team, “What are the biggest impediments to delivering value to your users faster?”, the answer would be that you can’t cut code fast enough.

I retired now, but I still write code for my blog. I totally prefer to write with Kotlin. Java just feels clunky to me now.

Well, thank you very much mr bot, but I posted this from Mastodon and the fact that it’s even here is testimony that I got it right.