Archive
The What Before The How
While paging through my portfolio of dorky sketches and e-doodles, I stumbled upon one that I whipped up a long time ago when I was learning about Linux shells:
Unless I’m forced to rush, I always bootstrap my learning experience for new subjects by drawing simplistic, abstract pictures like the above as I study the subject matter. Sometimes I’ll spend several hours drawing contextual pix from the lightweight intro chapter(s) of a skill-acquisition book before diving into the nitty gritty details. It works for me because I’m not smart enough to learn by skimming over the “what” and immediately diving into the “how“.
Whenever I feel forced to bypass the “what” and bellyflop into the “how” (via pressure to produce “Twice The Software In Half The Time“), I make way more mistakes. Not only does it degrade the quality of my work, it propagates downstream and degrades the quality of the receivers/users of that work.
The Last Retrospective
In an ongoing agile endeavor, the practice for eliciting and applying freshly learned knowledge going forward is the periodic “retrospective” (aka periodic post-mortem to the “traditional” old fogeys). Theoretically, retrospectives are temporary way points where individuals: stop, step back, cerebrally inspect what they’ve accomplished and how they’ve accomplished it, share their learning experiences, suggest new process/product improvements, and evaluate previously implemented improvements.
As the figure below depicts, the fraction of newly acquired knowledge applied going forward is a function of group culture. In macho, command and control hierarchies like culture B, the application of lessons learned is suppressed relative to more flexible cultures like A due to the hierarchical importance of opinions.
Regardless of culture type, during schedule-challenged projects with a fixed, do-or-don’t-get-paid deadline (yes, those projects do indeed still exist), this may happen:
When the elites upstairs magically determine that a panic point has appeared (sometimes seemingly out of nowhere): retrospectives get jettisoned, the daily standup morphs into the daily inquisition, corner-cutting “practices” become best practices, and the application of newly acquired knowledge stops cold. Humans being humans, learning still naturally occurs and new knowledge is accrued. However, it is not likely the type of knowledge that will help on future projects.
My Erlang Learning Status
Check out this slide from Erlang language co-designer Joe Armstrong’s InfoQ lecture: “Erlang – software for a concurrent world“. I’ve circled the features that have drawn me to Erlang because I’m currently developing product software where those qualities are hugely important to my customers. Despite their importance to success, they’re almost always given second class status by programmers and managers because they’re not domain-specific, “glamorous“, features.
The blue arrow is my sore spot. You see, I’ve been programming imperatively in FORTAN, then C, and then C++, since Jesus was born. Thus, learning the stateless, recursive, functional programming mindset that Erlang is founded upon is a huge hurdle for me to overcome. Nevertheless, as I’ve stated before, I’m half-assedly trying to learn OMOT how to program in Erlang with the aid of this very good book:
Here’s my learning “status” in terms of the book’s table of contents:
I don’t have an ironclad, micro-scheduled plan or BS risk register pinned on the wall in my war room, so I have no idea when I’ll be 100% done. But who knows, if I don’t abandon the effort:
Note: OMOT = On My Own Time
Powerful Tools
Cybernetician W. Ross Ashby‘s law of requisite variety states that “only variety can effectively control variety“. Another way of stating the law is that in order to control an innately complex problem with N degrees of freedom, a matched solution with at least N degrees of freedom is required. However, since solutions to hairy socio-technical problems introduce their own new problems into the environment, over-designing a problem controller with too many extra degrees of freedom may be worse than under-designing the controller.
In an analogy with Ashby’s law, it takes powerful tools to solve powerful problems. Using a hammer where only a sledgehammer will get the job done produces wasted effort and leaves the problem unsolved. However, learning how to use and wield powerful new tools takes quite a bit of time and effort for non-genius people like me. And most people aren’t willing to invest prolonged time and effort to learn new things. Relative to adolescents, adults have an especially hard time learning powerful new tools because it requires sustained immersion and repetitive practice to become competent in their usage. That’s why they typically don’t stick with learning a new language or learning how to play an instrument.
In my case, it took quite a bit of effort and time before I successfully jumped the hurdle between the C and C++ programming languages. Ditto for the transition from ad-hoc modeling to UML modeling. These new additions to my toolbox have allowed me to tackle larger and more challenging software problems. How about you? Have you increased your ability to solve increasingly complex problems by learning how to wield commensurately new and necessarily complex tools and techniques? Are you still pointing a squirt gun in situations that cry out for a magnum?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 