Learner100

In those situations, the more productive option to course-correct is to talk to the change author in a meeting/chat instead of just volleying off a tsunami of comments about various minutiae in the change IMO.

> When you receive a review with a hundred comments, it’s very hard to engage with that review on anything other than a trivial level.

Wow, that seems crazy. I can only hope I never have to work with somebody who thinks it is productive to leave that many comments on a change -- I genuinely cannot imagine any change that could ever require that.

Great article, fully agree with all the points.

For most self help / productivity books, I agree pretty strongly with this take. A lot of those types of books (Atomic Habits, Getting Things Done, Measure What Matters as some examples) often feel like they could have been reduced to a blog post, or series of blog posts at most. They were good books, but I did feel like there there was some padding to slog through in each chapter.

Usually, the point is communicated fairly quickly a few paragraphs into the chapter and then belaboured for pages with one or two anecdotes that don’t lend much more weight to the strength/validity of the point for me.

Ah, thanks!

- The SMTP client they implemented could insert a newline such that a line was comprised of only a single period.

- The SMTP client spec says that an additional period would be added here.

- The SMTP server spec says that it would remove this additional period, bringing us back to one period.

I don’t get how this led to there being no period at all. Am I missing something?

> While not traditional TDD or likely not a new concept, I’ve done something I’ve dubbed TLD (Test Led Development). Rather than writing a whole smattering of tests and then coding until they all pass, TLD focuses on ping-ponging between test and code.

TDD commonly gets mischaracterized as a two-step process of writing a suite of tests upfront, then writing some implementation to make them all pass. It's actually much closer to what is described as TLD in the post. You write a failing test, do the bare minimum to make it pass, refactor if appropriate and start the cycle again. It's a development process that will (in theory) produce a high quality implementation and suite of tests at the end.