Forem: Tim Kaetzel

Purpose in Painful Engineering

Tim Kaetzel — Fri, 27 Dec 2019 22:04:59 +0000

Software engineering and pain go side by side like two peas in a pod. Nonetheless, we continue to see more and more widespread interest and passion in the field. Is this purely masochism, or something deeper? In Viktor Frankl's book, Man's Search for Meaning, he writes that the meaning of life is to find purpose in your suffering. Our line of work certainly can provide suffering, whether it's due to a painful bug, or a tight deadline, or complexities in process - so, how can we find more purpose in it?

Finding Purpose in Painful Debugging

Most of us have a similar story to tell of how we first experienced purpose in suffering within coding. We've all had the experience of banging our head against the wall trying to debug a particularly convoluted issue, likely over a much longer than ideal course of time, until it clicks. Most of us don't particularly directly enjoy muttering obscenities at our computer screens. That being said, once you get the satisfaction of the end result, the preceding suffering is given purpose. This connection to purpose fuels our efforts the next time we find ourselves at that wall.

Finding Purpose in Solving Pain for Others

We can find purpose not only in the process, but the product itself. Our code is ultimately used by or for someone. Considerations for the end user's experience directly impact people's lives, both on roll-out and consequent iterative improvement. If developers can empathize with the user based on their own pains of being a user, then they can connect meaning with their own experiences and apply that to their work. This ultimately benefits you as a developer, the product, and the end user.

Finding Purpose in Growth Caused by Pain

Our brain works hard to keep us safe from pain. If you put your hand on a hot stove, it is guaranteed that your brain is going to do its best to keep you from touching that stove again - the hotter the stove, the stronger the aversion. This can drive us to grow in preventing ourselves from making the same mistakes twice (I'm looking at you, uncaught exceptions), to help others grow by learning from your own painful lessons, and to push for bigger picture systemic changes.

As individual contributors, we have to work toward connecting our suffering to a sense of purpose, which may not come easily or be readily apparent. As leadership, we should actively reinforce and create a culture of finding purpose in our work. There are plenty of jobs in software engineering with low stress and low pressure to perform. Yet many of us seek the additional challenges of demanding jobs nonetheless. As long as we are able to balance suffering with purpose, and our personal limits with our demands, then we can all find purpose in what we're doing. Not everyone is going to work for a software company whose product is saving the world. Yet we can find purpose in the work we're doing within ourselves, within our teams, within the process along the way, and within the people using our products.

Why Drummers Make Great Software Engineers

Tim Kaetzel — Fri, 19 Jul 2019 18:28:26 +0000

Once upon a time in college, I was faced with a dilemma - do I wish to professionally pursue music and drumming or computer science? When discussing this dilemma with others, I was often met with a chuckle, being asked, "could you have picked two more different majors to be split between?" In the end, I started as music education, and switched to computer science. Over the following years, I noticed something strange - I was joined in my CS classes by more and more musicians, especially drummers, and more and more of my CS peers disappeared only to be seen again in passing in the music building. What was going on?

In the end, I was ultimately referred to DealerOn by a fellow drummer/software engineer hybrid. While that was fairly mind blowing, what's more mind blowing is that today, on DealerOn's development team of ~40, we have 8 drummers. That's 20% of our team. What's going on?

I believe this is due to two factors: first, the shared natural inclinations that contribute to success in both, and second, the lessons learned due to similar challenges in both.

Aptitudes

It should be of no surprise that software engineering requires an affinity to math and logic. Perhaps more surprisingly to some, music - especially drumming - does as well. Rhythms represent complex mathematical structures across time. These structures, written in sheet music, are interpreted into the product: music to our ears. This is not dissimilar to programming algorithms, which are interpreted into the product: software.

These products represent the next similarity: creativity. Both music and software development are creatively applied mathematics. Both require both creativity and design: creativity at the base level of writing code and sheet music, and design of your product in the big picture, whether that picture is your vision of a software product or a song. Being able to take these cold, mathematical abstractions and use them to create awe-inspiring products is at the core of both passions.

Photo of sheet music by Cassi Stewart on Unsplash

On the other hand, most developers and drummers find a certain amount of comfort and pleasure in the absolute truths that coincide with the creativity. Coding is bounded by certain concrete rules and truths, peacefully coexisting with more flexible creative decisions. Drumline is bounded by some strict rules of interpreting rhythms, movements, and dynamics, peacefully coexisting with creative liberties and endless possibilities. In both, our experiences, personalities, and values shape the creative liberties and decisions made.

Experiences

Conway's law states that teams "are constrained to produce designs which are copies of the communication structures of these organizations."

To this, there are huge organizational similarities to musical organizations (such as drumlines) and software development teams. In a drumline, there are multiple sections - cymbals, snare drums, bass drums, tenors - all of which have to operate independently to create their individual product, while aligning goals and vision with the greater whole of the drumline, which must align their goals and vision with the greater whole of the band. This is similar to a software development team working on a given system, which develops their product as part of a bigger infrastructure handled by the larger team, which also must align with the company's goals. These experiences create unique challenges and lessons which inform one another.

These learning lessons arise out of necessity due to the inherent sense of ownership in drumline and software development. Both have tiered leadership, at the individual, sub-section, section, and whole level. If an individual fails to complete a task, it directly affects everyone at all levels above and below them, resulting in a direct sense of responsibility to the greater good. These smaller sub-section teams create more opportunities for everyone to experience leadership in some way, whether that's in creative leadership, ownership over your own practice and improvement, leading collaboration, or setting standards.

Concrete and flexible standards exist for both development teams and drumlines. For development teams, they may exist in the form of coding guidelines, collaboration channels, ticket process, branching strategy, deployment strategy, etc. For drumlines, they may exist in the form of stick heights/dynamic interpretations, technique, marching style, rhythmic interpretation, etc. These guidelines develop naturally and evolve over time, as well as being set in stone from the start. The dissemination, development, and adherence to these guidelines create challenges that lead to growth for participants.

Previously, I wrote a post about why car enthusiasts make good software engineers. So, is my assertion that car enthusiasts and drummers are better software engineers than those who aren't, and am I suggesting that software engineers should go out and buy a wrench and drumsticks? Certainly not. However, I believe that any passion and experience can be leveraged to build upon another, even if seemingly disparate in nature.

Lessons learned in anything can, and likely should, be applied cross-discipline and contribute to your growth as a person. One of the most important lessons I ever learned came from a drum lesson where I was too stressed and sleep deprived to effectively perform. So, what did we do? We sat and talked about drums and life. "We aren't here to get better at drumming - we're here to get better at life, and drumming is the vehicle." And so, whether you're a drummer, a dancer, a car enthusiast, a painter, a chef, an athlete - I challenge you to view these pursuits as vehicles towards the betterment of yourself, your products, and your peers.

Photo by James Toose on Unsplash

Why Car Lovers Make Great Software Engineers

Tim Kaetzel — Fri, 19 Oct 2018 15:40:12 +0000

Some of our best software engineers love cars, and we don’t believe this to be happenstance. Since DealerOn’s inception in 2004, we’ve found that automotive pursuits come with many of the same skills and challenges as a career in software engineering. In a regular work day, we see the melding of the traits tied to both pursuits: ingenuity, a curiosity for how things work, intuitive thinking, and a nearly obsessive desire to perfect the imperfect. By utilizing our personal passions in a professional capacity , DealerOn has shaped software development in the automotive industry through the lens of car enthusiasts.

Sitting pretty at a DealerOn company picnic

Car lovers appreciate the satisfaction of finally fixing an issue. After sitting in our garage trying to hunt down and fix a problem with compulsive dedication, we are proud of our work, and we love showing it off. This passion is deeply rooted in a love of experimentation — seeing what works and what doesn’t work. We love how our car is our clay to mold into whatever we want it to be, with ownership of results and pride for the world to see. At DealerOn, we strive to create an environment in which our software engineers experiment, find their niche, and become whatever they wish to be. That could mean quietly building out the infrastructure of our future, or leading the charge to spearhead initiatives.

While car people keep up with proactive car maintenance, plenty of others put it off until it’s necessary… That’s what technical debt is.

While car people keep up with proactive car maintenance, plenty of others put it off until it’s necessary. This could be waiting until the needle hovers over “E” to fill up, or it could be waiting until horrific sights and sounds are expelling from the engine bay to get an oil change. Well, that’s what technical debt is. Car enthusiasts solve these problems by being organized, caring about peak performance, and being willing to put forth additional effort, all of which are desirable traits in software engineers. At DealerOn, we have faced the challenges of exponential growth over the past decade while proactively maintaining our foundations to stay on the bleeding edge by leveraging these traits as a company.

Many car enthusiasts like to make their cars faster by swapping out for a bigger turbo or a bigger exhaust. As software engineers, we make swaps for performance as well, such as swapping out a small whitespace-removing regex in favor of a string replacement to accelerate site-speed and stability (Stack Overflow made a similar post about a week after we deployed our change).

Meanwhile, other enthusiasts focus on giving their cars an aesthetic face-lift. DealerOn is currently preparing for the biggest UX overhaul in company history in our aim to give users the most cohesive, clear, engaging experience possible. This has come with its fair share of trials to overcome, which we will share insight on in this blog along the way.

DealerOn Dev field trip to go-karts (with Luigi)

Every car enthusiast has hit a point of laying on the ground, wrench in hand, overwhelmed with mechanical woes and ready to throw in the towel. At this point, one has to remember why they ended up there in the first place — what they love and what drives their passion. It’s the chance to build something with pride and find a unique niche. That same principle is what makes us look forward to coming to the office every day. Whether you’re tenured with ten years of experience or landing your first professional gig, DealerOn offers the opportunity to pursue your professional and personal passions. As we continue to grow into our roles, we solidify our development team’s core values and wear them as a badge of honor. We trust each other, our process, and our purpose of creating the best development environment and experience for our users.

Whether you’re tenured with ten years of experience or landing your first professional gig, DealerOn offers the opportunity to pursue your professional and personal passions.

Our culture is standing on the shoulders of our engineers’ passions, and it shows. Come show day, it’s all about the quality of the build — nothing else matters. We have an exciting road ahead of us, so if you’d like to ride along, stay tuned.