11 January 2016 Comments Off on Why Everything I Need to Know about Software Engineering I Learned from the Mormon Tabernacle Choir General Software Development
Author: Quinn Heiner
Imagine if your software company had an 18-month hiring process for all of its techs, and that your chances of actually getting hired were slim at best (really slim, as in maybe 5%). But no problem, let’s say you get the job! Great–now for your first project. You’ll be working with an all-volunteer team of about 460 developers on the next exciting app that’s going to influence the world for good and make people’s lives better. You have a week to complete the project, with two developer meetings lasting a total of about 5-10 hours. Oh, and at the end of the week, we’ll expect a demo that will be broadcast on live TV, as well as thousands of other cable, TV, and internet outlets worldwide. But no worries–this volunteer organization has been doing it for over 86 years, and although they’re not all programmers, they represent some of the most disciplined leaders in the world as the Mormon Tabernacle Choir.
A recent Forbes article about the choir highlighted five leadership lessons and applied them directly to the business world, but as both a performer in the choir and a software engineer, I couldn’t help but try and apply these lessons to our field as well.
- Embrace an engaging cause. You must be passionate about your work as a software engineer and take pride in the product you are creating. As the article points out, “”action without passion will not endure, nor will passion without action”. If someone were to ask you in an interview to talk about a recent project you worked on that you really enjoyed, would you be able to give them an honest answer? Although most of our work involves the less glamorous line-of-business applications (as opposed to thought-provoking algorithms or cool games), you should still strive to find self-fulfillment and purpose in your work. After all, isn’t forcing billions of transistors to obey your every command quite a satisfying feeling?
- Insist on sky high standards. Unfortunately, most software projects are just about solving business problems as quickly and cheaply as possible. Far too often, project and product managers view the time-scope-quality triangle as more of a time-scope-resources triangle, when in reality resources != quality. Or slightly better, high standards are discussed but never enforced or followed up on in any measurable way. One huge advantage (and irony) of sky high standards is that the more they are implemented, the more freedom you can achieve. Why do you think Netflix’s employees have unlimited vacation time, no annual performance reviews, and ridiculously high salaries? It’s because their standards are so high that they can treat their employees as “fully formed adults”.
- Be of one voice. Okay, so you have a passion to write excellent software and will settle for nothing less than the highest standard, but what about the rest of the team? Are you all on the same page? Software engineers are incredibly opinionated and often times want to do things their own way. Instead of checking their egos at the door, they sometimes feel the need to go against the grain, regardless of if everyone’s on board, because they think they know better. Avoid the need to be a diva and take a glamorous stand on everything. Yes, you will have disagreements, and unification is never easy or perfectly implemented, but clear, concise, and constant communication of mostly agreed upon standards can achieve spectacular results far beyond any one individual’s efforts. Never write code for code’s sake or to show off how awesome you are. Your code is intended for the humans that will be maintaining it.
- Think globally, act locally. It’s always important to stay focused on the big picture of your product and implement the vision; however, lifting where you stand and simplifying the complexities of the problems within your own sphere of influence are of equal importance. Always balance long-term and short-term goals. One is all strategy and no tactics. The other is all tactics and no strategy. Too often developers focus on one end of the spectrum and not the other. I like to refer to these as the “dreamers” and the “short-term doers”, respectively. In other words, there are people who love to dream up solutions and complicated architecture all day and forget they actually need to produce working code and release a product in a timely manner. Conversely, there are people who just write narrow-minded, “dirty”, code that isn’t extensible or cohesive, all because they want to meet a specific requirement (and thus fail to look at the larger picture).
- Adapt or die. Some of the most ineffective software engineers on the planet are those who refuse to embrace changing technologies, or even worse, those who refuse to unlearn fading ones. Furthermore, one must avoid being the cynical programmer that only likes the technologies they’re not using, and hates the technologies that they are (the reverse is also true). There are 50 ways to solve a problem with technology, and 50 tools for each of those ways, all of which come with strengths and weaknesses. As an industry, we’re moving away from a one-size-fits-all product to opinionated software with lots and lots of third-party tools in between to speed up development, so pick what works well most of the time, study it, and get with the program (pun intended).
Author: Quinn Heiner
Tags:
