I wouldn’t say that software development is exactly like fighting with someone trying to choke or submit you by tugging and twisting your limbs... but it’s also not as different as one might imagine.
The days of the (stereo)typical programmer are behind us. As the software development industry continues to grow and attract people from all walks of life, it’s what makes us atypical that helps us bring a unique and value-adding perspective to our team, our company, our IT ecosystem. And it’s being around other atypical programmers that makes being a programmer so interesting! Sometimes though, we get fatigued by the everyday life of tasks, pull requests, code reviews, bug fixes, etc… That’s where an outside perspective can prove helpful in rising above this perceived monotony and towards gratitude for practices which have become routine. This past September, I discovered a sport - Brazilian Jiu Jistu (BJJ) - that brought me just that.
BJJ is a martial art based on ground fighting that focuses on controlling an opponent, getting into a dominant position, and forcing them to submit via various joint locks or chokes. I wouldn’t say that software development is exactly like fighting with someone trying to choke or submit you by tugging and twisting your limbs... but it’s also not as different as one might imagine. And with similarities come important takeaways that can be applied to work as a developer.
Here are the top seven things BJJ has taught me about my work as a developer:
1. When time is of the essence, hire another set of eyes.
Pair programming has become a common practice for many software development teams. In pair programming, one person drives and the other observes and provides input/advice to the driver. In the jiu jitsu world, I experienced the value of this practice most recently at my first ever competition. During my competition fights, I as the competitor was the person “driving”, taking action. My coach was the one helping me from the sidelines. He obviously couldn’t step on the mat and begin literally directing my movements, but his advice - shared from a different perspective - was critical to my movement and decision-making. In the dev world, pair programming provides a similar purpose. Two sets of eyes, looking at the same code or problem from different angles, are more likely to spot errors, and take the appropriate action, especially when the clock is running and the situation is higher pressure than normal. In BJJ and in software development, don’t underestimate the value of another pair of eyes.
2. Thank teammates for their critiques.
In jiu jitsu, we have “code reviews” at every training session. Maybe not exactly under the name “code review”, but the essence is there. The BJJ classes I’ve attended generally follow a common roadmap: warmup, theory, drilling, and then sparring. It’s during drilling - the time set aside to practice the theory or technique just taught - where BJJ “code reviews” take place. Here you are paired up with someone and you practice. During this time the coach goes from pair to pair to answer questions and comment on the way things are being done - both positively and constructively, as he sees fit. But these code reviews are so impactful, not just because of the comments given, but because of their timing and mindset of those receiving them. Comments from the coach early on, help ensure that bad habits never form, which makes a big difference in the long run. Takeaway for the dev world? Treat code reviews - and the constructive comments they may contain - as the gold that they are. Be grateful to your teammates for their critical eye.
3. Turn some “unknown unknowns” into “known unknowns”.
When you start BJJ, you probably know close to nothing about how to win a BJJ fight. This is sort of like when you get an abstract programming task to solve or bug to fix (especially if that bug is difficult to reproduce…) What is the best approach for these types of problems dealing with the unknown? Defining what exactly it is that you don’t know. For jiu jitsu, this means learning which positions are stronger than others; which positions you are aiming to be in. Then and only then should you worry about the best approach to getting to those positions. For programming, this means working towards a clear definition of the problem before beginning to develop a solution. For bugs - including not only what is “wrong” in the bug description but more details around “for whom”, “on what browser”, “when”, and eventually all the way to “why” (causality). Properly defining the problem is the first step to working out a solution.
4. Accountability aids productivity.
Accountability doesn’t guarantee productive output, and its absence also doesn’t guarantee that there will be no output, but having some sort of accountability helps provide you with the external motivation you sometimes need when your internal motivation is lacking. In jiu jitsu, I feel accountable to my coach and teammates to come to training sessions. Teammates on the mat make me want to do more, learn more, be better than I was the day before. In the dev world, this accountability works similarly. If we set technical or developmental goals and share them with someone, we are more likely to achieve those goals. With this in mind, at Polar Signals, we have regular one-on-one’s with our manager where we set goals for each quarter and monitor their progress. This ensures that we are not simply “producing” something, but rather moving forward in the right direction.
5. Just show up - physically but also mentally.
Despite setting goals or finding accountability, in jiu jitsu, in programming, in life, some days will seem like you are making little progress. On these days, however, as long as you “showed up” mentally, the time you spent on a task is not wasted time. In jiu jitsu, learning a new skill requires quite a bit of drilling - in essence, repetition. Sometimes it may seem like a new technique is not for you. That a leg lock just isn’t “locking” as it should. That you’re repeating motions, but not really going anywhere with them. This is exactly where repetition proves key to progress. In jiu jitsu, we don’t just train a new technique during one practice and then move on. Rather, we focus on a position for an extensive time and during each practice of this conceptual block, we repeat the technique from the previous classes. In software development, there are likewise days when there won’t be a tangible “product” to your workday: no PR to share for review, nothing to push to prod, etc. On days like those, it is critical to remember that just showing up the next day can work wonders. The solution is there, even if it hasn’t immediately revealed itself.
6. One problem may have many potential solutions.
The more complex the problem, the more ways there are to approach it. In jiu jitsu, before someone looks to submit an opponent by chokehold or by applying leverage to one of their arms or legs, he/she must first get into a stable position from which to begin applying that leverage. That often means passing someone’s “guard” by moving past their legs and gaining control of the torso and/or head. This task seems clear, but the options to completing it are endless. Knee slide, double-under, getting good grips - just to name a few. Critical here isn’t arguing about which solution to use all the time, but knowing which solution is optimal at a given time. In programming, this translates to researching alternative approaches to solving a complex problem, rather than purely relying on your past experience. For example, you may have used Redux for state management in several previous projects (just like we do for the frontend of Polar Signals), but there may be a case where Mobx or React’s built in Context API would prove to be more optimal. Stay open minded and approach relatively large code decisions objectively.
7. Better teammates => better you.
When you work in a team where many people have the same job title as yourself, you may become more inclined to compare yourself to each of them. Am I outputting as much as they are? Do they produce more PRs? Do reviews of those PRs have fewer changes requested? In jiu jitsu, instead of job titles a different status symbol exists: belt color. White belts are generally least experienced and black belts are most (with some pretty colors in between). It is completely natural to compare yourself to the other white belts to gauge your progress or skill level, but this benchmark should not be paired with either excessive ego or excessive self-criticism. It is not in your best interest to wish that your opponents were weaker or less productive or slower learners. Quite the opposite. The better they are, the better you will become. The same is true for programming - the stronger your teammates at your level, the stronger you will become, purely through interaction with them and their code. Never be jealous of or saddened by the technical strengths of your teammates. Their strengths are your opportunities for growth.
In reflection, when we find connections between our job and what we do outside of it, it makes us appreciate both even more. So, next time you are on the jiu jitsu mat, or cooking, or gardening, or doing whatever it is you love to do, ask yourself the question that I asked myself before writing this post: what has your time away from the code editor done for your time in front of it?
p.s. I’m sure there’s more takeaways that could be added to the list, but hey, I’m only a white belt. I’ll save the more colorful list for the more colorful belts ;)