7/17/17: Ooh, a palindrome!

I’d had the impression, for a while, that I wasn’t getting any better at…well…not my job, but my profession. I’m certainly getting better at my job in that I’m acclimating to the office environment and am more and more able to deliver software that brings civilization to the wild wild west of our business.

But I’d largely plateaued as a programmer.

It got me to asking myself: What was it that helped me make the largest leaps in skill that I THINK I used to make fairly regularly.

The right answer is something like “I improved dramatically when I tried something beyond my current skill level and forced myself to step up and figure it out.” But that shit ain’t the truth. The TRUTH is: “I make quantum leaps in skill when I read something that gives me another set of gears for my ‘ways of thinking’ machine.”

Yeah, it takes some practice to get new cogs and sprockets fitted right. But that’s really just that.

So, in my furious out of control rush to rebuild my library (which I’m doing at a positively ALARMING rate) I then refined my thinking…Which books then?

Well, there were a couple things:

– Technology cookbooks that have concrete plug and play solutions to very specific low level problems. (“Java Examples In A Nutshell”, any of the old O’Reilly “Cookbook” books.)
– The Design Patterns books.

Ah yes, that blast from the 90s and early 2000s: Design Patterns, Pattern Languages, and all the various associated conference proceedings books. Design Pattern thinking (the specifics of which I won’t really get in to too deeply here. Far better people have done a far better job) exploded on the scene with the Gang of Four book in 95.

The Pattern Movement produced a way of describing complex component interrelationships without being either bogged down in technology specifics or staying too lofty to be useful.

You couldn’t copy a design pattern out of a book into a code editor. Not really. But IF you had basic fluency with the language you could implement a solution that encoded the pattern itself, but that would be tightly bound to your specific application.

If you didn’t have fluency with the language to implement the pattern, the gap in your knowledge was pretty easy to track down and remedy. So, if you knew a pattern fit, but couldn’t figure out how to make it work, there were (I just realized I’m talking about patterns in the past tense. There’s nothing past tense about them except their overwhelming popularity.) ways to figure it out. That way you’d increase your language/toolkit knowledge as well.

But going back over 40 years of programming in my head, aside from the Stephens book (Advanced Programming In The Unix Environment) I don’t think any other book, series of books, lecture, project, job, or person has had quite the cumulative effect on me as the Patterns literature.

So I’ve ordered (and am starting to re-accumulate) the PLoPD (Pattern Languages of Program Design) and POSA (Patterns of Software Architecture) books. There are about five of each and I think I’m back up to half of them.

Even just browsing these things feels like I’ve reacquired ancient keys to knowledge. It’s so much fun, browsing back and forth through these, picking them apart and looking through my brain for problems/solution matches.

Time to figure out what the next frontier is though. I think re-familiarizing myself with this stuff gets my head back in “actual thinking” mode. But I’m not sure if it’s going to help me advance.

I dunno…AI? Too much fake mysticism around it.

We’ll see. I have to think it a good thunk.