Excellence is a Habit

Hello, loves!

We talked about some code, and excellence, last night.

At FGNO¹ last night, we looked at a little program/script by an author who shall rename nameless <cough>Chet</cough>. The program was in Python, a new language for our unnamed author, who hadn’t written an actual program for years, though he does have decades of experience and knows what good code is. The program needed to use MySql, and SMTP, and to do a lot of grubby text formatting.

The program worked exactly as intended. We did spot a few issues with the code. It included no real abstractions or classes, other than one class that held everything, pretty much just three functions in a class trench coat. There was one particular method too long to fit on a page of PyCharm. The method included two or three loops, some nested, eight or ten lines long. There was lots of string construction by appending fields to standard text. There were no automated tests.

Recall that this was [REDACTED]’s first Python program, and first use of PyCharm. Recall also that it unquestionably worked.

I’ll only say one more thing about it: it looked almost exactly like real production code that I have seen in my consulting work, no tests, no abstractions, long methods, nested loops, string stringing.

No. Two more things: it was not excellent code. Typical, perhaps, but not even good by our standards. But it did work.

We had one of our best sessions in weeks, perhaps months. Since [REDACTED] had been writing his first Python program ever, I can imagine him struggling with syntax and with the weird way you work MySql and such. We knew that he knows all the things we know, and that the program just got that way as he went along. So we were mostly as gentle as we would be with the most delicate beginner we might encounter, with a few exceptions, because, as Hill put it, if you can’t $%!#-talk your friends, who can you $%!#-talk?

We mostly focused on a quick observation about the code and then coached [REDACTED] in the PyCharm incantation that extracted a method, or renamed something, or moved a line up and down, teaching the keys one needs to type, because he already knew and understood the need.

We had a very pleasant time. Along the way, Hill mentioned “Excellence is a habit”² and spoke briefly about it, as it was a phrase that had popped up for him in the past day or so. The main point Hill wanted to make was this:

If we aspire to do excellent work, we must always practice doing excellent work day in and day out, so that when the pressure is on, we’ll automatically still do excellent work.

I of course agree with that notion, and it is a big part of what I do here every day. I practice making the code more excellent, demonstrating along the way that good code isn’t the result of some large massive effort, it is, instead, the result of many small efforts that can be done one at a time.

Hill speaks with purpose: to bring about changes he desires in what he sees and hears. So he surely brought that notion up to bring about some change. I think I know what it might be. So do you, I imagine.

The changes that I hope it makes in me include but are not limited to:

• I’d like to become more alert to when things are going awry, so as to stay closer to the best I can do;
• I’d like to use and build energy from the joy of making things better;
• I’d like to better see the value of automated tests to overall excellent work, and do better with them.

Homily ends. Let me bring you up to speed on the code I’ve been writing, in the next article.