Thinking about this some more, I do wonder if explore-expand-extract tracks as a specific application of Dave Snowden’s Cynefin framework.

What do you think? Does this theory make sense, or am I simply defending my biases?

As a side effect of this structured thinking process, you also generate automated tests that provide immediate feedback on your progress. And if you're following _all_ the steps (red, green, refactor), the code improves with every iteration.

It’s because that initial investment of self-discipline pays off. And the return on investment is huge. Problems are easier to solve if you are clear and specific about what the issue actually is.

And that’s not all.

Instead, TDD forces you to be very specific upfront about _what_ you want to achieve. And that feels like less fun and more effort than diving in and coding a solution. It takes mental effort.

Why, then, do some people love TDD so much?

What would you use these for? Well, if you have large arrays, they can (sometimes) be a more efficient alternative than `.filter()` if you know where the data you want is at the start (or the end) of the array. They also come in handy when writing parsers.

The second, dropWhile(), does the opposite. It traverses your array and ignores items until a predicate returns false. Then it will give you the rest of the array.

The first, takeWhile(), traverses your array and keeps adding items to a new array until a predicate returns false.

All we've really done with the third option, though, is re-implement the Set structure from scratch. So, we might as well use that. The most efficient option also happens to be the most concise.

To avoid traversing the array more than we need to, we can use a Map to keep track of the elements we've seen so far. This way we only traverse the array once. Once we've been through the list, we return the keys of the Map as an array.

A (slightly) more efficient approach is to use .indexOf() to check if the current element is the first occurrence of that element in the array. But it still traverses the array many more times than it needs to.

Our first approach uses a filter and `.includes()`. This is inefficient because it traverses the array multiple times, and creates lots of new intermediate arrays. It works, though.

Ousterhout argues that general purpose code tends to be simpler. It doesn't need to handle lots of special cases with copious if-statements and control structures. This kind of code handles those cases "ya ain't gonna need" _without any modification_.

In case you haven't come across it, YAGNI stands for "ya ain't gonna need it." The idea is that we want to avoid over-complicating things to solve for problems we may never encounter. Applied carelessly, you may end up with an over-specialized design.