The Code Whisperer

A Tale of map and parseInt in Three Acts Act 1: What?!

Do you know the Rule of Three in refactoring?

Today I read Jason Gorman’s “TDD Under the Microscope: One Outcome Per Test”.

Before You Begin What is the Saff Squeeze?

This comment arose recently at The jbrains Experience in a discussion about whether all software design choices are “like, just my opinion, man”.

I’d like to share a few little points to help you or someone you care about through their day.

I’ve been reading Kent Beck’s writing on Substack and on the occasion of the death of Niklaus Wirth, he shared part of a conversation he’d had with the professor when Kent had arranged to sit next to him on the flight home from a conference they’d both sp…

Overture You’ve probably seen code like this: if (condition) ...more code...

I see so many programmers tying themselves up in knots, trying to find “the right” testing strategy.

By now you’ve probably heard of Four Elements of Simple Design, among which you’ll find this suggestion: reveal intent.

I considered calling this article “Stubs Aren’t Parsers”, in the grand tradition of “Mocks Aren’t Stubs” and even “Stubs Aren’t Mocks” (which I never wrote, but wanted to).

A member of The jbrains Experience posted about a name they had just encountered in their day-job code base: compareReportedProfileToTargetProfileAndReportResultToSupervisor() They reported that they’d already renamed the method, but I immediately saw it…

I have witnessed programmers express annoyance about how tests seem to interfere with changing production code.

A member of my mentoring group started a discussion regarding this article: Victor Rentea’s “Overengineering in Onion/Hexagonal Architectures”.

In the middle of a discussion about test doubles/mock objects and their role in design, someone posted this: Reminder: arguing against a toot does not imply critiquing the tooter.

Code Reviews have a bad reputation.

A mentoring client of mine said this recently: I took ownership of some strategically pivotal code and did precisely that, typically refactoring twice a week for about 18 months (my delivery was unaffected).

What is refactoring?

Someone is circulating a talk—a concise one, which I appreciate—entitled “Refactoring is a code-smell” (sic).

I think a lot of people fall off the TDD wagon because of this exact thing—they learn TDD by working on new code and then can’t seem to apply it to their existing work projects.

Too many people are writing too many articles trying to direct others’ thinking on their own testing strategies.

I like it when programming feels boring.

I noticed that Ron Jeffries had written about a kata I hadn’t tried before, so I decided to try it.

When I teach evolutionary design with TDD, I often encounter programmers who don’t like all these little classes and all these extra interfaces.

This is not a step-by-step guide, but more of an overview that can help you stitch together the detailed step-by-step guides out there.

I couldn’t figure this out myself, nor even find the appropriate Stack Overflow article on my own, so I’m writing this.

Change the code as usual 2.

I used to waste significant energy trying to edit shell commands at the shell command prompt.

Today I ran into an example of where I’d really have liked to have some way to write a unit test.

A Reader Question Recently I came across attempts to verify framework-based behavior.

While writing something else entirely, I stumbled upon one of my earliest contributions to the evolutionary design/TDD community.

Over at The 260 Bowler I’ve added a handful of diary entries (just blog posts), so now I want a diary page (think recent posts).

In my evolutionary design practice, I consider removing duplication one of the three fundamental moves.1 Accordingly, I practise this move daily and trust it as a primary tactic for understanding the needs of the design.

I recently started a new project and used this as an opportunity to learn and practise a few things, among which we find 11ty, a static site generator.

Complicated code only creates problems when humans try to change it.

Limiting beliefs and unstated assumptions interfere with our performance.

A reader asked me this question: I’ve always wondered how does the basic flow of red, green, refactor reconcile with the concept of “make the change easy, then make the easy change”?

Refactoring, the activity, involves the following things. improving the design of existing code … in a sequence of small transformations … that preserve the important behavior of the system … which you can complete relatively quickly … and which gives you…

You don’t hate mocks; you hate side-effects.1 When a mock annoys you, it realizes its purpose, showing you where a side-effect is getting in your way.

When I teach evolutionary design, participants still often ask me which tools they ought to use to introduce test doubles into their projects.

If you add a port in Elm code, then you need to use that port in your Elm code, otherwise the generated Javascript might not even know that your Elm code uses ports at all.

How do object hierarchies evolve?

A recent tweet caught my attention.

I recently had this problem: I was writing some tests with Spock, but IntelliJ IDEA wouldn’t run them.

Doing (test && commit) || revert amounts to doing TDD very carefully, as an étude.

I have a new Linux laptop and I wanted to run C# code.

I made a silly mistake installing rvm on my new Linux laptop.

I write contract tests in order to help with the drifting test doubles problem: how do I know that my stubs and expectations and spies and mocks behave “like the real thing”?

In 2022 I learned about sd, a modern replacement for many of the simplest ways to use sed.

I taught evolutionary design in person to about 200 programmers this year.1 In the 15 years that I’ve been doing this, I’ve spoken with confused programmers who felt unsure how to use dependency injection to improve their design.