Building the Dojo

The training seems to start with building the environment, creating the tools, getting the bare necessities in order.  Not as a precursor to training but as the act of initiation itself.

Scala, Akka, SBT, Google App Engine, eclipse, Scala IDE, sbt-eclipse, sbt-appengine, DataNucleus JDO, cars to wax, a fence to paint, floors to sand, flies to catch with chopsticks...perhaps there's even enough left of the handyman/drunken master in there somewhere to pull it all off.

The Getting-Better Montage

Someone's been remiss while taking himself too seriously. Well, both must stop!

Time for a change and a chronicle of the change. Isn't that what a blog is supposed to be anyway?

Decision time has come. There's no escaping it, no delaying it, no dodging it.

Cue the music--the getting-better montage is about to begin!

Radio Silence

There's a point at which a lack of communication ceases to surprise and becomes the expected norm.

So goes it with system monitoring, alerting, and instrumentation when everything just hums along.

When was the last time a drill was scheduled for a system outage? When was the last time an alert was fired and appropriate action taken? When were the alerts shut off due to too many false positives?

So yes, I had the greatest of intentions with this blog. Alas, posting never made it to my daily, weekly, monthly routine. I doubt anyone noticed the year and several months since the last post, but that got me thinking....

Code Reviews

My current job sometimes entails reviewing other Java programmers' work and providing solutions for "better" ways to implement something. Sometimes I find outright bugs, but usually my recommendations are for more efficient approaches.

How do we determine one approach is better than another objectively? Profile!

Run the application's functional and/or unit tests through the code path in question with a profiler. Check for object allocations, time spent in methods, lock contention, and the like. Decent profiling tools provide this functionality, but the best ones I've used provide better visibility into these areas and aren't free.

If your approach can't be shown to exceed the original objectively, don't hesitate to throw it away. On the other hand, don't throw away an approach you believe should be better because the first implementation doesn't blow the doors off the original.

When afforded the time, spend some time looking through profiler results searching for the obvious inefficiencies. Balance the desire to wring every last byte, microsecond, bytecode instruction, etc. out of an approach with source code maintainability and the value of your time on other tasks. Spending a week working exclusively on a 5% improvement is the exception, not the rule.

Objectivity has one added benefit during code reviews as well, particularly for "outsiders" looking at a team's code. Objectivity helps defuse the nasty politics and ego bruising that sometimes (usually?) accompany code reviews. Code reviews have always been a learning experience for me and should be for everyone. Taking pride in one's work is one thing, but taking a review of one's work personally is quite another. How many times have we reviewed our own code days, months, years later only to say "What was I thinking?" A review from a colleague should be no different and offers a chance to fix mistakes before they become costly issues.

The Unfortunate Four

Inhabiting the earth are four unfortunate souls whose only requirement for inclusion in this set is having the distinct displeasure of working for me. Each did nothing more than accept a job at one of my former employers to be assigned to my team.

They are "The Unfortunate Four."

I embarked on my foray into management with open eyes. Eight upper-division classes in school was all that separated me from a Management degree. I did reasonably well in the required Principles course and had grown up listening to my dad and grandfather talk about aspects of managing people. To say I knew nothing of management was not true. To say I was ill-prepared to try was also untrue. To say I was any good at it was equally false.

Sure, I fulfilled all the objectives--turned in necessary paperwork, conducted performance reviews, approved vacation requests, met with team members, divided up work, etc.--but that was about all I did. There was no drive to assist team members along their chosen career paths. There was no fostering of team cohesion or unity. There was no management.

Why not? Instead of answering the age-old question of "what makes a good/bad/indifferent manager?", I will simply respond with what I believe got in my way.

In every fiber of my being, I am an individual contributor.

My contribution may be directly applicable to the task at hand or it may be assisting others to their own successes. Either way, managing people isn't where I can make my biggest contribution.

Fortunately, the prevailing corporate approach requiring employees to transition from contributor to manager as a required part of career progression seems to be waning. More experienced contributors who desire to remain contributors can be a huge benefit to a team, division, company. The experience levels contribute directly to the company's bottom line--reduced errors, faster recovery from issues, greater agility in responding to customer requirements. Losing that experience with requiring "up-or-out" and transitioning to management costs companies every day.

Did "The Unfortunate Four" and, as a result, the company benefit from my experience as a contributor with the title of manager? Probably. Am I thankful I found out something about myself through my trip to management? Definitely.

Relax. Think. Do Your Job.

This is one of my watch-phrases. It comes from a few years of being a software developer and consultant punctuated by a couple of years managing and working in operations and production support.

The order of these tasks is important. It has been my experience that people don't tend to do their best work without at least a bit of forethought. Clear thinking also doesn't tend to come in moments of extreme agitation. So, relaxing, even in the face of extreme pressure, leads to thinking clearly about your task which enables the implementation of a better solution.

Now, what gets in the way?

Pressure, both from within and from without, is easily the most common barrier to relaxing. In the middle of a crisis, our managers, colleagues, executives, stakeholders, and the like want a solution yesterday. If you're like me, technologists can be a bit arrogant and think that we can solve any issue in front of us. Pressure from the outside, and pressure from the inside.

Experience, or a lack thereof, is one of the barriers to thinking. Not a lack of overall experience, but a lack of experience with a situation, set of systems, area of a business. I work with quite a few truly gifted technologists, but there are only a handful I'd trust working on a Java-based application crisis. My experiences put me one step away from useless on a mainframe. No one has a monopoly on good ideas though. Our points of view affect our ability to think of solutions to problems. Those points of view are driven by the sum of our experiences.

Never making it past the thinking stage is another pitfall. We've all heard of "analysis paralysis" and believe we can avoid it easily. In the midst of analyzing log files, talking to subject matter experts, opening tickets with vendors, bouncing ideas off of colleagues, and the like, we don't believe we are overthinking the solution. Providing the "best" solution doesn't always mean resolving all outstanding issues with a system. The business value of a down system is, at most, zero and probably negative. Timeliness is an aspect of the "best" solution. Part of the outcome of doing your job can be an action item list for engineering, development, and/or architecture. One way or the other, a solution has to be implemented.

Welcome to my blog. Believe me, it's not going to be all work and no play. Relaxation comes in many forms and isn't only necessary when resolving IT issues. Thinking includes philosophical pursuits and educating ourselves. Doing our jobs is only partly about occupation but is also about being part of humanity.

Enjoy!