What Working in Baseball Taught Me about Web Development
Flatiron School Alum and Developer Adam Jonas left his job as a Major League Baseball Scout to pursue a career in software development. Although he thought he left baseball behind him, he found that successful ball players have a few things in common with successful developers—the ability to learn from mistakes, stay consistent, and be […]
Reading Time 7 mins
Flatiron School Alum and Developer Adam Jonas left his job as a Major League Baseball Scout to pursue a career in software development. Although he thought he left baseball behind him, he found that successful ball players have a few things in common with successful developers—the ability to learn from mistakes, stay consistent, and be professional. In this post, Adam shares what baseball taught him about building software.
Before I was a web developer, I spent my time on baseball fields helping teenagers realize their ultimate dream of playing in the Major Leagues. All of them had talent. Somewhere, someone had seen glimpses of it. Cultivating that talent and turning their potential into performance was the primary purpose of my job. Now, four years removed from the game, most of the players I worked with are out of professional baseball. Those who did succeed found a way to endure the grind and adjusted to the game’s emotional and mental demands.
In 2012, I hit the reset button on my career. I thought I would be leaving baseball forever. However, I found that many of the traits I saw in successful ball players, even those with very little formal schooling, were some of the very same characteristics I observed in talented engineers. The ability to manage failure, maintain consistency and learn how to be a professional are hard skills to learn—but they could make or break the dreams of the players with whom I worked.
When I see one of them on TV, it’s hard to not recall their younger, yet unmolded versions. It is why I was never the best scout. The baseball scout’s job is to imagine the possibilities. They envision a future version of a gangly youth whose body and mind has matured and whose flaws have been smoothed away to the point they can perform in the Major Leagues. It is a hard job but one that I wish existed in other industries.
Learning from mistakes
Successful people, in any field, often struggle with making mistakes. This isn’t surprising. We are wired for bad news. We internalize it. We personalize it. Repeated failure is exhausting. Ball players, whose hitting success rate is at best around 30 percent, are forced to cope because failure is an inherent part of the game.
Resilient players’ confidences seem immune to repeated failure. In fact, failure appears to be inextricably linked to their progress. This makes sense. We improve fastest based on negative feedback. The great thing about that big, red, error message is that it leaves an obvious clue. Sometimes these hints are more obscure than others, but bugs and errors inform us where to look and where to improve.
Getting repeatedly beaten by the same pitch provides feedback on where hitters need to improve in the same way that a familiar error in our terminal window instructs us where in the code to start looking for our mistake. As humans we learn through repetition and experience. The goal is to avoid getting beaten again by the same pitch or the same problem.
When I first started learning to program, I focused on never repeating the same mistake twice. This, of course, was impossible, but I recorded most my thoughts and posted them online to create a searchable collection of problems I’d encountered. The frequency of my posts have waned, but I still find myself searching my blog archives when I know I’ve solved a similar problem in the past.
While it was rare to see ball players jot down notes on opponents, most hitting savants can recall previous pitch sequences from past at-bats. Either way, the secret to coping with past mistakes or errors in judgment is to reframe them as valuable pieces of feedback for the future.
As developers, we know that consistent performance is important. We construct our dependencies on the most stable parts of our applications. The same goes for managers: when Sarah demonstrates that she can meet deadlines on a day-to-day, week-to-week, sprint-to-sprint or quarter-to-quarter basis, Sarah’s manager can rely on her to build the feature to satisfy the high priority business objective.
Consistency also creates the opportunity for measurement. Like the measurement of feature velocity based on a set period of time, comparison of player’s abilities would be worthless without a standard 162 game schedule where the participants play nine innings with nine players on the field. Without a level playing field, comparisons are no longer valid and people can get really upset (see baseball and steroids).
Consistency is difficult because we are wired to break free from it. We are not as perfectly repeatable as the scripts we write. Our brains thrive on novelty. The day-to-day becomes mundane without it. We seek out adventure and variety. We endeavor to learn new things.
But mostly being consistent is just showing up—being there when products ship and stuff goes down. Career defining highlights are created when people are in the right place at the right time. Crashes on the production server and DEFCON 1 bugs are inevitable but these panic moments create opportunities. Under pressure, acting as you always do makes you a hero.
Derek Jeter’s lifetime batting average was .310. A consummate professional, he hit .308 in the playoffs. Just being yourself when the pressure is on and more eyes are on you makes it seem like you are rising to the occasion. No one is perfect, but bringing your best everyday provides predictability to our human unpredictability and separates the amateurs from the pros.
Professional baseball is a child’s game played by overgrown men who make millions of dollars. Make no mistake about it, baseball is a grueling sport. The schedule is relentless. Players arrive at the stadium five-plus hours before the first pitch to weight train, stretch, hit, throw, review scouting reports, etc.
After a three hour game, players are expected to hold court in front of their lockers and answer questions that essentially boil down to, “Tell us about your glaring mistake that you made in front of thousands of people across America.” Each major league team plays 162 games in about 180 days—not to mention the the month of spring training before the season starts and, if they are lucky, a month of postseason games. Eighty-one of these games are in other cities, meaning players are switching time zones for weeks on end. The truly blessed ones do this for 20+ years.
While we developers don’t enjoy the fame and fortune of Major Leaguers, we do get to solve the worlds’ hardest puzzles for everyone. The impact of our code has touched the lives of nearly every human on the planet. All of the hours spent implementing a vision—all of the bug-fixing and small victories—are bolstered by a natural builder’s high.
Hacker News is littered with discussion on how writing software can crush your soul, but for many, the job retains its joy. Despite the jeering fans and elusive bugs, there are developers who simply love what they do.
Despite the jeering fans and elusive bugs, there are developers who simply love what they do.
Of course, there are stark differences between baseball and software engineering. Software has been in the hands of laymen for less than a generation and baseball has remained unchanged since before the Civil War. While software’s impact continues to accelerate, we should take a breather and remember that what is old becomes new again. There are lessons to learn everywhere we look and baseball has proven no different for me.
I love what I do. I’ve never been as challenged as I am when muddling through a new concept or totally lost in a self-created code mess. The wins and losses I’ve experienced as a developer are like nothing else I’ve experienced as an athlete or a coach. While I’m still a relatively new programmer, my experiences in baseball have taught me some valuable lessons on coping with failures, reliability, and professionalism.
Not all that long ago my work day consisted of spotting the subtle deficiencies in a pitcher’s delivery and the sound of a shortstop’s feet as he ran a 60 yard dash, but when I watch how a junior dev deftly uses her VIM shortcuts or the ease with which she writes a complex SQL query, I’m reminded it’s not so different after all.
Posted by Flatiron School / January 19, 2015
Learn to Code Python: Free Lesson for Beginners
What is the difference between a data analyst and a data scientist?
While data analyst and data scientist roles attract similar types of creative and logical people, their roles do have stark differences. Here’s our breakdown of the lines between these often mixed up roles.