Kaizen: continuous dissatisfaction?

Rewrites, rewrites, rewrites.

 

Kaizen: continuous dissatisfaction?

 

 

A few days ago, I decided that this blog really needed an end-to-end review with major surgery: many articles need a rewrite, and some should be scrapped altogether.

Coincidentally, the ever-interesting Nick Kolenda sent an e-mail to his subscribers titled “My most embarrassing article” in which he asked, “Do you ever look at your old writing and cringe?”

Yes, Nick. Yes, I do.

Growing up sometimes means disliking your old self…

At least, I hope that's the case. I don't write these because I've somehow found a trove of glittering best practices no product manager has yet been gifted.

(That said, my collaborative stack ranking exercise might just be a “Glenvention”. Plus, it's got a cute carousel!)

No, I write these as self-expression and in the hope that someone might find them useful. They also help me codify my thinking. The act of writing forces ideas to crystalize and justify themselves; sometimes, they reveal their shortcomings only when they're being readied for the big stage we call Internet.

Sometimes, the shortcomings show up only well after publication.

Does my personal and professional growth in the years since I started these occasional posts guarantee that a good bit of the earlier content will rust to embarrassment? I think so&emdash;but isn't that just the awkward-yet-inevitable side effect of continuous improvement? I believe that's the case, so in a very real sense…

Kaizen can be defined as a constant state of mild dissatisfaction.

Side story:

It really wasn't any different in the two earlier phases of my career: music, followed by programming, each have an inherent “throw the past away” aspect. As a student trombonist, I would review tapes of old recitals and cringe. “Wow, I know you tried your best back then, but boy was that rough.”

Same thing as a programmer… in one case (at Schlumberger) I designed and wrote an intranet program with a nice interface that solved a real pain point the entire office there had. The system had a level of configurability so easy and fit-for-purpose that you'd never need another programmer to touch it later (when you need to capture and report on different types of record, for instance).

And I hope to god that no programmer ever did actually touch it. My code hygiene was straight-up horrible. Working but nearly unreadable gick. *cringe*

Becoming a better programmer, trombonist, product manager, or writer means discarding old habits of thought and practice, and trying your damndest not to repeat mistakes of the past. Sure, you'll make some interesting new mistakes, but kaizen your way away from the others.

And that's why…

I'll be doing a lot of rewrites over the next few weeks or months. In the meantime, the posts I believe are among my best can be found in this Highlights collection. I hope you enjoy!