One of the benefits, perhaps the main benefit, of TDD that's not mentioned here is that TDD leads to different solutions than "test later". You could probably make an argument that it often leads to cleaner, "better" solutions. The idea is that since you are forced to always adopt the simplest approach to implement the functionality required for the next incremental test, it allows patterns in the code to emerge that you might not have anticipated had you taken a "big bang" approach to your design - leading to a cleaner solution. Can you do it without formal TDD? Sure. I'd bet that many programmers with decades of experience do a certain amount of that naturally. Tackle the easiest part first, don't worry about the stuff that's not part of that, then let the design evolve, refactor as necessary as you go. But the industry is full of programmers with just a few years of experience, and they don't do that. Instead, they write baroque nightmares of complexity and unused functionality that they quickly get lost and confused in. It's incredibly rare to see a newish programmer write something that's too simple and clean :). Generally, I'd be surprised if I couldn't take a junior programmer's code and strip about 30-60% of it out in a few hours of refactoring. Why? Because they make all kinds of assumptions about the solution before they even start, and get committed to a sub-optimal approach right at the beginning that they can't back out of later on. I think those kinds of programmers (who are the majority) could benefit greatly from TDD.

I totally agree about dropping Java. I think you missed out on some of the terseness of Kotlin in your Fibonacci routine. You can use two techniques to get there: fun fib (n: Int ) : Int = if (n < 3 ) 1 else fib(n - 1 ) + fib(n - 2 ) fun main () { IntRange( 1 , 30 ).forEach { println(fib(it)) } fibonacci().take( 30 ).forEach { println(it) } } fun fibonacci () : Sequence< Int > { return generateSequence(Pair( 0 , 1 )) { Pair(it.second, it.first + it.second) }.map { it.first } } In the first, I've just cleaned up the fib() routine so that it looks how you'd actually write it in Kotlin. It really does look like a function now. To invoke it, I replaced the for loop with an IntRange and the used the forEach() method. That's a bit more Kotlin-like, IMHO. The second I just lifted right from the Docs for generateSequence() which use Fibonacci as an example. It feels like the most Kotlin-like approach to the problem, treating the Fibonacci sequence like a sequence and then relying on the lazy loading to calculate each new value as/when/if required.