View this email in your browser
Code better

Introducing Mirdin, The Code Quality Company

It's been months since the announcement, but now the name-change is official: We are Mirdin1, the Code Quality Company.

I started training software engineers six and a half years ago, just me having a call every week with one person. Now we're two full-time employees, around half a dozen instructional staff, and we've trained over 250 people.  Our new name reflects our commitment to help orders of magnitude more people, and the breadth of our mission, which reads as follows:

To permanently make the world’s software less buggy and easier to change by raising the average skill level of programmers by creating common-knowledge of scientific principles for better code.


Towards that end, we're producing new material on software design faster than ever. You can find two pieces in the rest of this newletter, and more over at .

But right now, there's still a lot of people who can be helped by our traditional offering, the Advanced Software Design Course. And so we continue to polish and run it.


1: Pending some DNS issues at least. We are resending this E-mail from another domain, as the first send went to everyone's spam folder. Apologies to those who saw it twice.

Advanced Software Design Course starting Oct 6

With an alumni list that includes top engineers at Google and Facebook, around a dozen founders and entrepreneurs including the CEO of an almost-unicorn, and residents of every continent except Antarctica, our Advanced Software Design Course remains the premier way for skilled software engineers to accelerate their path to becoming great in broad technical skills. As our new alum Ben says:

Join the next cohort, starting October 6th.

Register Interest

Linguistic Antipatterns

Every programmer past a certain point has had the experience of spending days fixing a bug that turned out to be stupid. When it happens, you can't help but wonder what would have prevented it. One of my stories came from switching two integer arguments, and now I get nervous when I see two arguments of the same type in a row. Sometimes, the stories come from naming: when a function just doesn't do the thing you thought it did. If bad naming is such a problem, how can we practice avoiding it?

But first, what exactly makes a bad name?

Nearly a decade ago, researchers led by Venera Arnaoudova took on this challenge by studying open-source code and creating a bank of "linguistic antipatterns," specific ways in which a function or field name could be deleterious. I immediately felt a will to help more people learn about linguistic antipatetrns.

Turns out Arnaodouva's original catalog was more suited for tools than for people, consisting of 18 hyper-specific points We've cut her list down to an easily-memorizable 6, and broadened them to describe problems in any sitting.

Next time you see a name you think is bad, don't start arguing with the author that it's bad. or play "Yes it can, no it can't" with whether the name could cause confusion.  Just find which linguistic antipattern applies,  point them to this website, and let it do the talking.

And if a name is bad but not for a reason on this list, come contribute!

And if you have a story of a bad debugging experience caused by a naming problem, come contribute that too – we want to hear from you!

TypeScript Type-Level Tic-Tac-Toe

Types are not just there to make you type. They are a way to have a conversation with your compiler, and to express thoughts about how a program should work, enforcing deep invariants about your program. Back when the dynamic typing debate was raging, opponents were told they had an invalid opinion of static typing until they could do this. Static typing has emerged dominant, and this skill is as important as ever.

As practice, we give students an exercise to design an API for Tic-Tac-Toe in which it is a compile error to play out of bounds or to make a move on a board where someone has already won, among other things. Years ago as a student, Nils Eriksson decided to take this to the next level by encoding not just a safe API, but the entire game, into the type system. Now as an instructor, he's polished his work and written an explainer. I started off skeptical of his exercise, thinking it would be as interesting as someone trying to get 3D graphics running on a 1985 Commodore Amiga – something which has produced some spectacular demos to be sure, but still not a great source of lessons for the rest of us. I ended with my mind blown. And just reading it gave me the ability to do similar typelevel programming of my own.

For anyone interested in seeing just how far modern type systems can go, or indeed any TypeScript programmer, I highly recommend reading


TypeScript Type-Level Tic-Tac-Toe: Overkill Edition!

Copyright © 2022 James Koppel Coaching, All rights reserved.