Continuous Improvement for the Self

Yesterday, in discussing the "Close the Loop" principle, TheHackerCIO touched on how one is worse off for not addressing deficiencies. It's simple, really. Not only do you now have a known deficiency, but you also know that  you are the kind of person who doesn't fix problems. (At least with respect to this problem.) And that is setting you down a course of habitual non-fixing problems, which is nothing but a downward spiral.

Don't go there.

There are many applications. For instance, how many times, O fellow Hackers, are you compelled by deadline-pressure and/or management to employ what we might humorously call a "sub-obtimal" solution or approach. In other words, we put in a hack, or a "work-around," or take on "technical debt."

Now, the reality of life is that this is always going to be there. But it should be tracked and a solution found for the future. This is they way to move yourself toward the elimination of such issues.

I keep a page in my client-journal where I track everything I've done that I'm unsatisfied with. I just label it my "Technical Debt" page, and make sure I log it. And, naturally, from time to time, when time permits, I come up with remediation approaches and solutions. Even if I can't get them into production, I've at least "closed the loop" on the issue. And so, on a personal level, I have improved myself. Which, by the way, is a very selfish thing -- in the best possible sense.

I hope you too choose to improve yourself. You'll find yourself a much better technologist for it.

I Remain,

TheHackerCIO

Closing the Loop

Recently a junior developer asked me one of those rarest of questions: the questions about how to improve. He's a very talented developer; and in a few years he's going to be awesome. But there was one chink in his armor I thought he should address.

And there are plenty of others who would benefit from this advice.

As a matter of fact, I could produce a major list of ex-clients and the vast majority had never grasped it. 

The principle is very simple. But the benefit comes only from the rigorous, regular, -- even habitual --  application of it.

The principle is: always close the loop. 

Here are a few examples.

If you go for an interview, afterwards you must sit down an and write up every missed question and failure. You must assess the gaps in your knowledge, or presentation and close the loop. Closing that loop might involve learning the answer to a question you missed. It might involve developing a small sample program to recursively traverse b-tree, because that's what you messed up on.  It might be a matter of reflecting on all your past experiences and determining what the nastiest bug you ever encountered was -- because you drew a blank when hit with that question. The point is, that you must always close the loop. Address deficiencies so that they are never repeated.  By following this policy, you will root out deficiencies and remediate them. 

If you fail to close the loop, you will undercut your self-confidence. Your own mind will know, implicitly, that you didn't take care of business, and that you have a deficiency of which you have not undertaken remediation. That means, without closing the loop, you are worse off for your bad performance. Not only do you have a flaw, but you know it, and you didn't care enough to fix it, or start fixing it.

The violation of the closed-loop principle seems institutionalized in many companies. "Let's move on, " they say. "There's no point in doing a full-blown investigation of why this happened." No?  Seems like the point would be identification of the problems that led to the debacle, followed by instituting a plan to avoid it in the future. Without closing the loop -- doing a post-mortem examination of failure -- assigning blame, where blame is due -- every future action is subject to the same causes. And, naturally, the same effects. 

So alway, always close the loop. And of course, you can use your techno-journal to help.

I Remain,

TheHackerCIO