To Get Better You Must Practice
Almost everyone explicitly understands that physical activities such as golf or running or weight lifting require lots of repetitious practice in order to get better but most people don’t recognize that mental activities and business processes require the same practice. We all studied in school to learn languages, algorithms, etc. but most of us either swore off studying upon graduation or forgot that study and practice are prerequisites to proficiency and excellence. From the engineer to the manager to the CTO, everyone has skills and processes that need to be practiced and critiqued in order to improve.
As professionals no longer under the guidance of professors, we need to take responsibility for our own continuing education. If you think that coding new features will provide you with enough stimuli for expanding your skill set, you should reexamine that idea by looking back over the past twelve months to see what you have learned that makes you a better engineer today. It is most likely that if you have relied solely on assigned features you have fallen into the trap of using what you know to code them rather than stretching to learn new designs, patterns, or algorithms. The wondrous thing about programming is that there are many ways to solve the same problem, some faster than others, some more eloquent than others. We recommend a couple practices to help the engineers continue to learn and perfect their skills but these can really be expanded to other groups such as QA. The theme behind these recommendations is leverage the shared knowledge of the entire organization to learn from each other. This is one reason the whole is greater than the sum of the parts.
Start your engineering all hands meeting with someone presenting a creative solution to a problem. Have the engineering managers or architects decide whose solutions qualify for being interesting enough to share with the group or leave it to the individual engineers to decide. Another idea for ensuring that you and other engineers continue to learn is practice code reviews. Engineers sometimes get persnickety about someone reading over their code but this is a great way for the reviewer to learn new techniques as well as the engineer. A final suggestion is to establish a Joint Application Design process where members of the operations team join the engineers and architects in the design process of the feature. This inclusion of different perspectives will help broaden all participants understanding of technology.
In terms of practicing processes this is similar to practicing skills. If you never exercise the process or you do so in a halfhearted manner, you will never be good at it and when the time comes that you need that process to work perfectly it will assuredly not. Some of the processes that get skipped too often are failovers and disaster recoveries. If you don’t practice failing over when the failure occurs that requires a failover the process will not work. It will either take way longer than you thought, result in unexpected outcomes, or possibly fail to work at all. Obviously you must do these without impacting the production site but it is possible to exercise the failover without bringing down production.
Remember what Sun Tzu said in the Art of War: “The more you sweat in peace, the less you bleed in war.”
Image provided by Mike Kline