Learning (to Swim) as a Software Engineer

As I was leaving the lap pool this morning a couple of swimmers were taking jabs at each other in passing. They looked to be happy men in their 70s. The gentleman heading towards the pool turned to his friend and joked, "you're too old for the pool." The other gentleman replied, "I am too old for everything." They both laughed out loud.

I just completed my third week of triathlon training and I can assure you that both gentleman would swim laps around me and still have energy in the tank. Up until a few weeks ago it had been over two decades since I showed up to a pool to swim laps. I was not a strong swimmer then and I can assure you I am not a strong swimmer now.

A few weeks ago a family friend had come by the house. She had once been a C++ programmer in the 80s but shared that she switched paths to project management. She felt like she stopped finding joy in her work because you constantly had to learn new technologies. I thought to myself "that's the fun part!", but as I have been learning to swim I can empathize with being on the learning struggle bus. This is what I have learned about learning the last few weeks and I think it loosely applies to how we learn as Software Engineers.

Jump In The Deep End

How does a middle-aged man just suddenly decide to start swimming? Well, he doesn't. He has a friend that convinces him to do a triathlon. I showed up at the pool to find a single empty lane and a lifeguard that was dozing off. I apologized in my head to her that she might actually have to do something today.

I jumped right in finding myself needing to tippy-toe to keep my head above water. As I started towards the other side of the pool I realized I had jumped in to the deeper end of the pool. After a few weeks of observing the other swimmers I realized that I was the oddball that started in the deep end, but I continued to make this my habit.

Jumping in the deep end has forced me to swim a quick check length. I take a quick "out lap" to get my bearings and check my goggles at the beginning of each swim and then a forced extra length at the end of each swim to get out of the pool. As with learning anything, the hardest part is starting and the second hardest part is finishing. When learning a new skill, do anything you can to gain that extra little bit of consistency and time you have set aside. And just do it.

My favorite way to learn a new programming language is through "Koans". Many years ago I ran across the EdgeCase Ruby Koans and I have since used them to learn the basics of a few other languages. The Koans are a series of failing tests that you need to fix to learn the language. They are a great way to jump in the deep end and be in the code rather than just reading documentation.

Ask for Help

This morning the pool was pretty full and it was the first time someone had ever asked to share a lane with me. I wondered if I was going to be a nuisance to the other swimmer. I was slow, in the way, testing out different tactics. He looked like an olympic swimmer. Shaved head, fast, efficient, and shoulders that showed he had put in time. I was honestly a little embarrassed to be sharing a lane with him.

When he stopped to take a break I asked him if he had any tips for a beginner and told him my first week goal was "not to drown". He agreed it was a pretty good goal, but also had some good training tips. He ended with "there's so many other optimizations, but don't worry about all that. Just work on a consistent stroke and keep at it."

I took his advice for a few laps and I was suddenly far more comfortable. The stats on my watch showed that I was not necessarily more efficient, but I could definitely go for a longer stint. I owed all of this to a friendly swimmer's time and the courage to ask a seemingly experienced stranger to lend their expertise.

I see so many early career engineers not knowing when to ask for help. I think for some they fear it makes them look like they don't know what they are doing without realizing that people expect them to not know what they are doing - and are ok with this. I always encourage banging your head against the wall on a problem for at least 10 minutes, but to not be afraid to ask for help. Asking a question, pairing, or a draft Pull Request are fantastic ways of learning.

Keep At It

As I walked out to the pool this morning it was drizzling. I was tired because I fell asleep on the couch. I was hungry and dehydrated because I only had an espresso shot for breakfast. I was cold because... it was cold. I had more excuses not to swim this morning that I am sure I could dig up but I jumped in anyhow.

Coursera has this clever course completion estimate that paces your learning at an achievable pace so you can keep at it. It guilts you in to falling behind. I found a 12-week triathlon training plan that I am following. My desire to stick with the program was greater than my laziness or the weather.

If you are anything like me you have a knack for finding new shiny things to learn all the time and the hardest thing to do is to keep at the it du jour. Write out your goals and stick to the plan. This will help you stick to keeping at it. When I have trouble keeping at it, I often use the Pomodoro Technique. 25 minutes keeping at it, 5 minutes for a mental break. Or pick your pomodoro rhythm. I guarantee that keeping at it will help you slog through the worst parts of learning a new software framework or a challenging project.

Stop Thinking So Much

The last 100 yards of today's swim was the first time I truly felt relaxed in the water. Maybe it was the pro-tips from my lanemate or that I now have thousands of yards of keeping at it instead of just trying not to die. As I thought about it more, I realized that I had stopped thinking so much about the mechanical minutiae of swimming and just started swimming.

When it comes to writing software, sometimes you just need to put your hands on the keyboard and start typing. Throw away code, prototypes, they are relatively inexpensive ways to get started and learn a thing or two. The same goes for experienced engineers. I have seen many a development team get stuck in analysis paralysis on a whiteboard instead of just trying to do something. And sure enough the project retrospective comes around and we all agree that we should have done some prototyping.

There is a saying that when you are planning you are making decisions when you know the least amount of information. With less thinking and more doing you gain information and experience that can help level you up without even realizing it.

Sink or Swim

Learning to swim at this stage of my life has reminded me that the basic principles remain pretty constant, whether you're diving into a pool or diving into code. Sometimes you need to start in the deep end. Sometimes you need to swallow some water before you swallow your pride and ask for help. Most of the times, you just need to show up. Stay curious, stay humble, and keep moving forward.