I started running cross country my first year of high school. It began as an attempt to stay in good physical shape for baseball season. The thinking was simple. Run all summer and fall to play baseball in the spring. By baseball tryouts, I was running circles around the other players. But that didn’t mean I was any better at baseball. Running is just one element of the game and it was there I realized the saying, “How you practice is how you play,” doesn’t always apply.
How you practice the sport looks different than how you perform in games. In practice, it involves drills and variety. But during the game it’s frankly a lot of waiting around. Practice isn’t like the performance.
Running is the opposite. Other than stretching, most of our preparation for cross country races involved running. Running during the week to practice and running during the performance. The pace was more intense and there were more spectators but one closely mirrored the other.
Software engineering is like running. It’s a sport where you very much practice how you play. Whether you’re learning to code, tinkering with a side project, or working professionally, it involves the same underlying skills. If you enjoy the critical thinking, problem solving, and learning involved in coding bootcamp, there is a good chance you’ll enjoy doing it as a job. Conversely, if every moment is agonizing or dull, graduating into a career of similar work will likely just compound the distaste.
The daily life of a software engineer involves writing code, googling solutions, and reacting to error messages. It’s a constant pursuit to improve, grow, and refine. If we’re lucky, the challenges get bigger, the technology changes, and our skill increases. The underlying elements are largely the same.
This never ending march toward bigger, better, and simpler is described in game theory by two types of “games”: finite and infinite games. Finite games are one in which the players, moves, rules, outcomes are spelled out. Success is clearly defined. There is an established start and agreed upon ending. One possible outcome. Sporting events and competitions are finite games.
Software engineering is an infinite game. Infinite games differ in almost every way from their fixed counterparts. There is a seemingly moving target that’s constantly evolving. Nuance characterizes problems and improvements can always are always possible somewhere along the way. This tension both drives the industry forward and provides a source of frustration. If it seems hard, that’s because it is.
Along with the continuous cadence of problem solving, tools are another main staple of an engineers daily life. Engineers love tools. Few careers interactive with as many tools as software engineering, which could probably be attributed to the nature of problem solvers with the low cost to create software.
There are tools to perform engineering tasks, others to collaborate, and many more for communication. The most common engineering tools are the web browser, text editor, and command line. Nearly any work in software requires them. There are thousands of examples of each type and even more locations online with engineers debating which is best. As long as opinions are allowed to exist, people who disagree will as well.
Chrome vs Safari.
Github vs Bitbucket.
Trello vs Asana.
Jira vs Basecamp.
Sublime Text vs Textmate.
Ruby vs Python.
React vs Angular.
In reality, I have found the differences aren’t nearly as important as the output they facilitate. Great teams and skilled professionals can produce great results in spite of inferior tools. There is no tool that can compensate for a poor team or careless professional. I’ve found one question to be the most help when selecting a tool: “Does it allow me to consistently deliver greater work with less friction?”