On the Fourth Day of Christmas…2011
On the fourth day of Christmas I gave a gift to you… Four Words to Live By
Three Training Events…
Two Twitter Handles…
and Mirrored Disks with Parity
Stop
As in “Know when to Stop.”
This bit of advice applies to many things. Knowing when to call it a day, turn of the lights, power down the laptops, and close the office door behind you is often a difficult thing for us in the tech sector. We’re driven towards problem-solving; we thrive on challenges. Not all those challenges get resolved at 5:00pm though and we need to understand when to take notes on where you left off, save your work, and decide to pick back up on it the next day.
This also applies to email threads. I have a rule of four in this regard: that rule states that if you’ve had four cycles of read/reply between parties, then it’s time to talk to either hop on the phone or schedule a brief stand-up meeting.
Finally, know when to stop an argument. Knowing when to end an argument or debate is often more important than winning the debate. I had a friend tell me once that when you wrestle with a pig you both get dirty. Know when to stop sometimes means know when to not start.
Look
As in “Know what to look for.”
When troubleshooting be sure to have an understanding of what to look for – what looks out of place and what thresholds should not be exceeded. This is why baselining is crucial for the database administrator. Depending on your environment some thresholds for disk queue length, page life expectancy, signal wait, and so forth that would look off for one server may be perfectly acceptable for another (or at least not a cause for concern.) It’s just as important to understand the concepts of performance tuning as much as it is to know when the tuning is needed and when it’s not.
Listen
As in “Know when to STFU Listen.”
There is a reason why we have two ears and one mouth. It’s so we listen twice as much as we speak. I know it strikes fear into the hearts of many of you when I say this, but in our roles as I.T. Professionals we need to interact with people. Actual, real people. They have problems we need to help fix and we can’t do that without allowing them to fully explain their issues, needs, concerns, and so forth. Many of us want to jump right in and start working, but we need to get a complete understanding of the project or request before we do so – and that involves listening, asking clarifying questions, collecting responses, and making commitments first.
Act
As in “Know when to Act!”
For you developers out there this ties back to listen first. Then it’s time to work through a rough plan to resolve, build, or perform. For the DBAs in the crowd this means know when to step in when you see something out of tune. Even if you’re receiving no end-user complaints. We DBAs see how the sausage is made – this means we see when we need to kick the meat grinder every once in a while. The trick is to do it without making a visible, negative impact on the end users. Know what to look for and know when to step in and make a fix versus letting something possibly run it’s course. Sometimes not doing something is just as important jumping into the action.