I think that's where people swing back to DAMP, or at least the rule of 3.

I'm not trying to fractally compress my code. I'm trying to make it succinct. Those two things are very different. Now if I could only convince a particular coworker of that...

I think every good programmer has these rules of thumb, from most important to less important:

1. Make it so you'll understand it in 2 minutes after being away for a year. Positive side effect: it's very readable for your colleagues.

2. Make it brief.

3. Make it fast.

4. Make it pretty (although often times readable + brief code is pretty but obviously it's subjective).

I've gotten to a place where I start with a sketch of how I think my code ought to be used and then work backward into the implementation.

So far I've gotten a lot of pushback from others on my team. And, what starts as "oh, you should just have to ____" gets really messy as the implementation takes shape.

So test-driven development (where you write the user -- the test -- first, and then the implementation)?

I think so, yes. But I start "before" the test? I write a use-case. Almost a user story, but in code. Sometimes I add comments inline with the code to try and sort out what abstractions are useful.

Still TDD, this could fall under the use of Cucumber where the integration test DSL reads almost like English.

So kudos to you for using good practices.

Those two are not exclusive.