Uncle Bob’s Ski School

This is a guest post from Dan Walkes. Enjoy.

Dear developer,

I was thinking this week about my Great Uncle, Bob Van Gerpen, who died of pancreatic cancer in 2011. Bob was my Grandma’s youngest brother and similar in age to my Dad. He was a big part of my parent’s life as they experienced the same transition I did, going from South Dakota farm kids to Colorado “city” dwellers in their 20s.

In the long list of Uncle Bob folklore, there’s a particular story which popped into my head this week which I’ve thought about relative to my professional career. It’s the story of Uncle Bob’s Ski School.

As a South Dakota to Colorado transplant, Uncle Bob often had family and friends from the plains who would visit the Rocky Mountains to try skiing, often for the first time. Uncle Bob was not one to turn down a social outing and would always enthusiastically offer to take them up the mountain.

The visit would include helping them with rental equipment, making sure they had the proper gear, recommending the best place to go, finding discount lift tickets, driving them to the mountain, and getting them on the lift. There’d be some discussion about how to “pie” your skis (point the tips together to make a pie shape and slowly slide down the mountain) and some basics about keeping knees bent and suggestions about balance.

The flatlander trainee would ride the ski lift up to the top of the 12,000 foot peak and turn around to see nothing but what looked like a sheer cliff toward the distant specs of people and cars in the parking lot below. As the “student” was contemplating their most recent life’s decisions, Uncle Bob would ski past them, wave, and tell them he’ll meet them at the bottom.

A few hours later, bruised and tired, the newly minted Colorado skier would find Uncle Bob in the lodge at the base of the mountain with an adult beverage in hand.

I don’t know the total list of Uncle Bob ski school graduates and unfortunately the full list is probably lost to history. I do know he would proudly mention both of my parents in the list of successful graduates. He also liked to say his wife, my Great Aunt, was his only failure. After meeting him at the base of the mountain she informed him in no uncertain terms this would be their first and last time skiing together. Borrowing one of his favorite expressions, “a guy could” assume the true number of his ski school failures may have actually been a bit more than one.

As an Engineer, getting outside your own head and describing how to do something you already know how to do can be incredibly difficult. I’m grateful for my somewhat limited experience thus far as an educator to work on this skill. I have a long way to go. One of the things I’ve found to be the most difficult to do in my professional career, both in roles of educator or manager, is to give my students, employees, and coworkers just enough tools to figure out what they need to do on their own. Sometimes I suspect this feels to them a bit like Uncle Bob’s Ski School. Some of them are like my Great Aunt, who are understandably frustrated and ready to bow out after the first trip down the mountain.

Since I’ve been so fortunate to work with a pool of talented, resourceful, and persistent Engineers, however, I find that most rise to the occasion. They are able to overcome my shortcomings in course material or documentation and in many cases learn more themselves in the process. Course material or project documentation is never perfect.

When faced with a deadline the choice is to not share course material until it’s more perfect, or share what you have with the hope it will be useful. I usually error on the side of the latter and I feel like it’s worked out well so far.

If you are a student in a course or an employee working on a new project I encourage you to look at something less than perfectly structured content as an exciting challenge and an opportunity to learn how to learn. I also encourage you to think about what was missing which would have improved your experience and let the originator know or, even better, propose the change to curriculum or documentation which would have helped you and will help others.

When you become an expert, think about how you can optimize your Ski School professional equivalent to strike the right balance of being “perfect enough” to get the trainee started on their journey while minimizing the number who are ready to walk away for good when they make it to the base of the mountain.

— Dan

This post was originally published on LinkedIn.

Dan Walkes is Vice President of Embedded Engineering at Sighthound.

Always be replacing yourself

Dear new developer,

I had a friend who brought me into a club. The specifics of the club don’t matter, but like most clubs, it had a variety of executive roles. Someone had to run the meeting, other people had to take notes, someone needed to keep track of the finances.

As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. You don’t want anything to be your particular special area of knowledge. You should always be trying to train your replacement.

I think this is good advice for a software developer as well. At any new job, you are learning tons of new things. This is doubly true when it is your first or second job.

But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the eng team is relatively stable) or new hires (if you are on a rocket ship), in a year or so you won’t be the new kid on the block.

Obviously this is a discussion to have with your manager, but you should always be looking at ways to replace yourself. This will free you up to work on new tasks and learn new things.

Here are some ways to replace yourself.

Document all the things

Don’t rely on your memory. When you are performing a task for the second or third time, write down what you are doing and why. (If you only do a task once, this is not usually worthwhile.) Keep this under version control and share it widely. That way anyone can see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.

Offer to cross train

When you are working with someone else, you both gain knowledge. Whether this is a command line trick a different view of the world, or specific domain knowledge, working with someone on a task will help you both. This doesn’t need to be full pairing, it could be an impromptu design session or troubleshooting discussion.

Automate for the people

If you are doing a task and have time time, write a script or program to do all or part of this. Don’t let the perfect be the enemy of the done. If you can write a script to do 70% of the work in 10% of the time it would take to automate the entire task, write that script. This pairs well with documentation and is a living form of knowledge transfer.

Obliterate the task

Sometimes a task is always done because it has always been done. With your beginner’s eyes, you can ask “why”. Don’t be crotchety, but try to get to the root of the problem to be solved, rather than focusing on learning the solution. There may be other ways to resolve the issue. There may not. But by understanding the root of the solution, you’ll be better able to see if you can avoid doing it altogether. This isn’t strictly training your replacement, but it will be welcome and does make the organization more efficient.

Don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.

Sincerely,

Dan