Two years ago, Jeff Atwood (of Stack Overflow fame) posted an article entitled “So You Don’t Want to be a Programmer After All”, which mentions the surprising number of emails Jeff receives from fellow programmers who have decided that they just aren’t a great fit for the profession. While the article ends up becoming a discussion about whether or not career-oriented questions belong on the Stack Exchange network, it did spur me to consider some of the non-obvious reasons why a programmer could become frustrated with software development as a career.
Even if a person possesses a great deal of passion for programming, developing software professionally can be an inherently frustrating experience. Due to long development cycles and the high risk of project failure (anywhere from 10 to 30+% depending on the survey) it can be quite some time before any work that you do makes it into the hands of your users. In addition, most software systems require a huge amount of code under the covers in order to provide the application users know and love. If you tend to work on the non-visual side of things, your work can tend to go unnoticed or unappreciated. Finally, beyond these broader issues, programming presents a myriad of day-to-day annoyances and roadblocks that, in sum, can seriously hurt job satisfaction.
So how do you deal with these day-to-day frustrations, and how do you foster a team environment where the team helps each other eliminate frustration?
Regardless of the programming language or tools you use, you’re bound to be required to do some tedious and repetitive work. Doing something manually once or twice is generally fine, and it’s generally not the best use of time to automate something if you’re unsure whether the automation will ever be used again. However, as soon as you find yourself having to do something a third time (similar to the rule of three) it’s generally worth automating. Not only will automating reduce frustration, you can also use automation as an opportunity to hone your skills in your favorite scripting language.
It’s commonly sited that the average person can store 7 ± 2 elements in short-term memory. Due to the complexity of most software systems it’s quite easy to constantly be at your limit of short-term memory capacity. Wiki’s, code comments, and other easy to follow documentation can help ease this memory burden by allowing you to offload information for future use by yourself or others. One caveat with documentation: if it is not maintained it can be a source of frustration rather than a solution!
Sell your ideas
Many times, a particular piece of code, UI design, or process that you may find frustrating is outside of your direct control. In order to remove this roadblock you’re going to need help. This is where the ability to sell your ideas to your peers (and even your manager) can be key. In many ways, programming is the art of the abstract, but if you’re going to sell me on your idea, I need something concrete. Data, working coding examples, even something as simple as a JsFiddle can go a long way toward convincing your peers.
Focus on the big picture
It’s easy to get frustrated by a particular problem or roadblock and lose site of the big picture. Working software is almost always preferable to software that may be architecturally beautiful but doesn’t work or doesn’t meet the customer’s need. You know you’re still learning and growing as an engineer if you can look back at code you wrote a couple of years ago and know how you would have done it better. It’s extremely difficult to do things perfectly the first time, and often you’ll have the opportunity to refactor and improve things as the software evolves. Enjoy the process, don’t sweat over every minor imperfection.
While these methods may sound commonplace, the key is consistency. It’s often easy to miss an opportunity to automate a task, or document a process because you’re too busy only to regret it later. If you make these methods a habit, you’ll be sure to reduce the incidental frustrations that can get in the way of the creative process of building software.
Do you have a tool or technique I’ve missed? I’d love to hear about it in the comments.