Why do we avoid engaging?
"It's too hard for the benefit." "I don't have anything to contribute." "That's not the priority right now."
That list could go on awhile but let's start with those as some of my excuses for neglecting this blog for a few years now.
Alas, my excuses have run out...again. As an Enterprise Integration Practice Architect at Red Hat, blogging is now part of my job. And not just any random blog content I struggle to write but technical blog posts covering Red Hat JBoss Fuse, A-MQ, and associated technologies and platforms.
That having been said, I intend to put my more "official" content on a new blog I'm starting called Integral Systems. Here at Relax. Think. Do Your Job. I'll keep more of my one-off projects and crazy inanities.
http://integralsystems.blogspot.com/
Maybe getting into the habit of writing content for one will benefit both. Maybe now, my priorities will have shifted enough to contribute something beneficial to the technology community at large as a matter of course as well as whenever I remember, "Hey, I have this old blog laying around."
Monday, October 10, 2016
Wednesday, June 20, 2012
Demanding Perfection
Now the dojo is built and the training has started, the expectation of success follows. Train hard and be rewarded with better results than you ever dreamed possible.
The problem is when. How soon can I expect the results I need? Come on! I'm in the middle of the montage. Shouldn't the flying round kick breaking only the blue plates on odd numbered Thursdays be easy yet?
No, no, no!
Demand perfection...eventually! Dare to suck with the goal of getting it wrong to learn what it takes to make it right.
Thursday, April 26, 2012
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.
Friday, March 30, 2012
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!
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!
Tuesday, November 2, 2010
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....
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....
Sunday, May 10, 2009
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.
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.
Saturday, May 9, 2009
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.
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.
Subscribe to:
Posts (Atom)