Business Tech: You Could be an Ostrich Farmer!
For those who don't know, the young lady in the pilot's seat is my wife and co-editor, Syd Barouch. No, she isn't a pilot. She has, however, been a day manager at a mixed martial arts school, worked in childcare, painted hats for a charitable organization, and raised two kids. Why is that the lead-in for a Business Tech article? Keep reading.
I used to work for a man named Eric. He had an excessively well-maintained computer room. When I asked him why he put the time into it, he said, "I used to be rented, with the audio equipment, when people like Rod Stewart played arenas and concert halls. To me, a cable is something that holds a speaker over the heads of thousands of attendees." We bring these experiences — the other jobs and other lives we live — into our work. Sometimes for the better, and sometimes, not.
Fly on the Wall
Not too long ago, I was on a flight during which I sat next to a recent retiree, and we fell into conversation. She'd done software quality assurance during much of her career. The encounter could have stopped at "My daughter mentors women in technology. Now that I'm retired, I'm helping her with that." But under the conversation about tech being a boys' club and the details about her writing for her daughter's business, lurked a long, rich vein of common topics between us.
I learned a lot about a company I had briefly done training for — she'd worked with them extensively — and I picked up a new perspective on non-MultiValue software. We may also have set a record for the number of times Rational Clearcase came up as a point of reference outside of a conference room. It was a random conversation on a plane that will improve my job performance.
Attributes on the Rocks
Knowing the secondary skills and off-topic experiences of the people you work with can often make communicating with them easier. For example, I run into a lot of IT people who are also musicians. This is not my skill set. I have G-clef envy. I admit it. I can't even keep a radio in tune.
Talking about my appreciation for the patience, effort, and dedication that their playing requires allows me to pay them respect. Mutual respect and genuine interest in what they know smooths the way for other — on-topic — conversations.
Gaming the System
Like music, board and card games are referred to as 'play' even when you apply rigor to them. I have friends who are brilliant analysts, but have never written or reviewed code. They use their analytics in their hobby. When you hear things like, "a move that doesn't cost you any resources still costs you a move, and this game only allows x number of moves," you know that you are in the presence of people who don't play around when it comes to games.
This is where I use my on-topic-for-work skills in a social setting. What I do for a living allows me to participate effectively in conversations about game mechanics. Net result: I view hobbies differently when hiring people.
Aboard the Train
When I train people to work in MultiValue, I find that students who posess either an accounting background or a Cobol background tend to make excellent MultiValue programmers. Bonus points for those who have both.
These professional experience sets lend themselves to developing disciplined habits. Building on that, when teaching the - ahem - frequently less disciplined world of MultiValue, helps them connect to our sort of work in a way that leads them toward a more successful path. Linking our other lives to our current work allows us to be better at our jobs.
One of my favorite training stories is one where I was the student, not the teacher. I was brushing up on a language I had picked up on my own. In service of that goal, I took my first formal class even though I was already working professionally in that field.
The teacher was (A) very good at teaching, and (B) not very good at the subject. He didn't have a grasp of several core commands. He didn't understand efficiency. Here's what I learned: He used very few commands over-all, his code was very easy to follow as a result, and it worked. In a classroom setting, it was a brilliant approach. I changed my teaching methods to emphasize smaller code vocabularies and only introduce the better (i.e. faster, more efficient) methods after showing the simpler ones.
This is the corollary to my previous point. He didn't do this because it was a better teaching approach. He simply brought his lack of skill as a programmer into the classroom and made it work. I've followed his postings, so I know this wasn't a clever ploy. The old saying, "those who can't do, teach" is not intended to be a compliment, but this was the unusual case of bad-at-the-job but good-at-teaching.
You Could be an Ostrich Farmer
The title comes from a conversation that occurred at a (non-Spectrum) conference. The lunch area was set up to encourage people to sit with strangers in order to maximize the social networking aspects of the event. Three of us ended up at a table, set for ten, together. One gentleman declined to talk at all; he was content just to listen. The other man and I engaged in a robust exchange of opinions about the merit, or lack thereof, of various technologies. Finally, I said, "Enough business talk. What do you do when you're not doing this?"
"I'm an ostrich farmer," he said.
I looked over at the silent partner in our discussion and decided to have a little fun. Implying I knew the newly-revealed ostrich farmer better than I did, I turned to our third wheel and quipped, "And he lives in a tiny apartment."
That's a Wrap
For those of you who were hoping this article would teach you how to become an ostrich farmer, I suggest you strike up some random conversations with strangers and co-workers. There might be someone near you right now with a deep background in the ostrich or emu industry. You'll never know until you ask.
Send your best ostrich farming stories to editor@intl-spectrum.com