I read an interesting post this evening by Michael DeHaan, titled The Archaeology of Software. In it, he makes the case that there is a great deal of value in endeavoring to understand why things exist as they do in, specifically, the field of software development. He says (I’m paraphrasing) that’s way more productive than dismissing something out of hand as being subpar, dumb, brain dead, or whatever – and a learning opportunity is missed. He makes a lot of insightful points, and I highly recommend you spend a few minutes reading it.
I know he was making a larger point about how some people behave towards others’ solutions and ways we might strive to rise above pettiness and vitriol to be more constructive, but he touches on so many facets of engineering. What struck me as I read his post was how much engineering wisdom there was implicit in his words. I don’t know Michael, and can’t say how deliberate his wording was, but he at least casually touched on the essence of engineering a lot in the post. He spent a great deal of time enumerating a long list of heuristics he has developed over time (see my last post). These heuristics are very obviously hard earned from experience, and are all very consistent with the essence of engineering.
In my last post, I spent a long time describing some recent successes at work. At the end, I had the nerve to close the post on a very unsatisfying allusion to a ‘discussion for another post about “the process”‘. Let this post be the first installment in a recurring series discussing “the process”, by which I mean “Engineering process”.
I want to start by addressing something that wasn’t acknowledged in my previous post, and is really only obvious in retrospect: While the successes were pretty spectacular, they were made possible by a situation of extremely pent-up need. That string of rapid, extreme successes was the dam breaking more than anything. We were just there to ride the wave. We made it look easy and sound amazing, but the truth is the situation made that easy for us. Since that initial burst of productivity, things have settled down to a steady plod as we continue to iterate on improving things.
My employer has been in the process of reorganizing for several months, now. A couple of weeks ago, as part of this reorganization, I was moved to a “new” team. In actuality, this team is simply a small subset of the people I already worked with. It was an All-Star team of three. Our mission was … whatever we saw fit, related to everything in our domain of skill, interest, and concern. Mostly we would direct our efforts at release engineering, build engineering, systems architecture, and deep-investigation type troubleshooting. Stuff we already did anyway, albeit much less formally.
When I first learned of the new team (and the team reorg plan in general), I was in a bad state of burnout. So bad, in fact, I just couldn’t even get excited about the new team. I just didn’t care. However, when the three of us got into a room with our PO for the first time, the energy was palpable. We are like-minded engineering types, and I have the utmost admiration for my teammates’ skill, professionalism, and opinions. I felt much more positive after that first meeting.
Lately, I’ve been studying Engineering Method by reading the textbook “Discussion of the Method“, by Billy Vaughn Koen. It has been a very enriching exercise. From reading this book, I have acquired a formal language to express many thoughts and observations I’ve had for years; but, it has also been great because I have learned new ideas and made connections I hadn’t noticed before.
My grand vision is to acquaint myself with the material in this book through a study group with one other person. From this study group, we are developing a set of talking points with the intention to (a) begin spreading a cogent, coordinated message about engineering practices and (b) lead a small reading group of 5 or 6 people to train another generation of budding engineers within the organization who can go forth and reinforce the message. Eventually, I’d like to condense the material down to a meaningful set of highlights we could use to develop a recurring, short training course on the topic; perhaps make it an annual session we subject everyone to. You might recognize some of these patterns if you’ve ever read the book “Fearless Change“, by Mary Lynn Manns, Ph.D. and Linda Rising, Ph.D.