The view of the prototypical programmer as a nerdy, non-athletic type is, becoming, thankfully, a thing of the past. Nevertheless, one still finds members of the tech community who regard the ex-athlete programmer with curiosity. For a person to both play a sport and program computers, they must master completely different skill sets, right?
Hardly. In fact, some of the most important lessons I learned as an athlete have been fundamental to my improvement as a programmer.
And if you were never an athlete, this might be even more important for you to read than if you were an athlete: it’s like a cheat sheet that you can use to approach programming with an athlete’s mind without ever having to get sweaty yourself :).
1 . Find your strengths and weaknesses, and practice them both.
Every athlete has things that they’re better at as well as things that they need help with. The things that they are better at become easy to practice: after all, the method they are good at will become their go-to solution for situations on the court or on the course. The weaknesses, though, require focused practice. If flexibility is preventing a rower from assuming the proper position at the catch, then he or she needs to perform specific stretches every day to get better at that thing. Becoming better at that specific thing will also make them better at other skills in their sport, because they won’t have to devote as much energy to doing the catch correctly.
It’s the same in programming. Guys, I sucked at regexs. Like, I really sucked. I hated them. So, I devoted time every tay for ten days to experimenting with regexs. I challenged myself to create a regex that checked for an e-mail address. To check for a website URL. To check for a method call. After those ten days, I could use regexs with ease in those places where I needed them—to the point that I could program one from scratch without referring to any external resources. That saved me time and leveled me up as a programmer.
2. When you’re not programming, you’re preparing to program.
You don’t have to be totally vegging out to give your mind a break, though. As an athlete, I would read or do homework while my body was resting, then let my mind go dark while I was running or lifting weights (P.S. sometimes you can run longer distances and lift heavier weights when your mind isn’t yapping at you the whole time). Programming is a very syntax-specific and often logical process. I find that, if I switch from programming to drawing a picture or writing a fiction story, I exercise parts of my mind that I didn’t use while I was at my terminal, and somewhere on the backburner those new exercises pick up my programming problem and devise a new approach that I did not consider.
3. Food is fuel.
I am a horrible programmer immediately after consuming a Starbucks chai tea latte and a cheesecake brownie.
The sugar absolutely destroys my ability to focus, I suppose. After far too many tries at this, I noticed the correlation.
Programming fuels that work best for me: greek yogurt with granola. I once added eleven features to a puzzle-solving application in nine hours on greek yogurt with granola. I didn’t even know I could program for nine hours in a day. That said, I don’t do it often. Other foods that boost my focus: bananas and nut butter (doesn’t matter what kind of nut butter—fancy ten dollar almond butter didn’t perform any better than plain ol’ peanut butter. My preference is chunky. Maybe you like the creamy kind. That’s OK, we can live in this world together). I thought that my lunch, which is typically chicken and brussels sprouts, would make good programming fuel, but it didn’t—I think because blood got redirected to my digestive system to break down the high-fiber brussels sprouts. Lentils also didn’t work—again, high fiber. I don’t know if that’s really the problem. It’s just a hypothesis. In a pinch, I can use string cheese to program well. I haven’t tried much else, and I’m still recording observations. I highly recommend you try the same.
4. Have a stupid amount of team spirit.
Make yourself a valuable part of the team. Contribute to open source projects because it feels good. Teach people what you know—I don’t care if you don’t know that much. Find something you do know and teach it. Attend programming meetups and make friends. Work on projects with your friends. You’ll all become better programmers for it.
But perhaps most importantly, don’t let a competitive spirit turn into hatred. This is a major mistake that a lot of athletes make. A lot of programmers are guilty of this, too (just google basically any disagreement about which language, IDE, or computer to use, and you’ll see what I’m talking about. FUN FACT: You didn’t look it up because you already know what I’m talking about. See how bad it is?) Don’t be those guys. Walk over to the other team at the hackathon and ask them how they came up with that brilliant implementation. Maybe, if you’re lucky, they won’t be arrogant jerks, and they’ll tell you about it. Then, someday, maybe one of them will want to know about what you’re working on. Talk about it. Share. The better we get as as group, the harder we are pushed to get better as individuals. STOP THINKING ABOUT IT AS YOU VS ME. Any human whose value depends on keeping others in the dark is doomed for failure. So spread the light. I think you’ll find yourself a more passionate programmer for it.