Author: Dan Bunker
Pick any software company and take a stroll through their cubicle farm. You’ll find developers white boarding out problems, coding and staring at 2 or 3 monitors at a time and occasionally having nerf gun wars. Most will simply view this environment as a standard software shop but if you take a closer look you’ll discover something deeper lurking in every developer writing code for a living. What is it that every developer hides from those around them?
If you corner a developer in the break room and start prodding them about their project or what they’re working on, you might notice the nervous twitch in their eyes as they tell you everything about their work except for their one secret. This secret is rarely mentioned by college teachers or software books or online software tutorials. This secret isn’t a secret about being 5 minutes late to work in the morning or that the developer can fluently speak Klingon. This secret lives in just about every line of code that has ever been written and produced.
So what is this secret?
Nobodies Code is Perfect
Yes, some developers write better code than others but no one writes 100% perfect code. This isn’t referring to how many bugs are in the code or not. Coding is part science, math and art. You may have 0 bugs in your code but it’s put together so badly that it’s impossible to maintain. Or your code might look like a thesis example out of an MIT computer science research paper but your buddy on your team can’t make heads or tails out of it because it’s so esoteric and complex.
Ask any developer after they finish up a project if there are things they would like to change or something they would do different and all of them will come up with a list. This is in part because the software libraries and practices change over time and the way we build software changes. It’s also due to the fact that hindsight is 20/20. Once you have tackled all of the problems and jumped all of the hurdles, you’ve learned from your experience. That experience then tells you there may have been a better way.
The best developers don’t lose sleep over this little secret. They realize that their code is a work in process that will never be done and build it in a way that allows them to meet their job responsibilities and allow for ease of understanding and future maintenance. Sometimes this means doing things using a simple if/else statement rather than a ternary or a for loop instead of a recursive function. Just because you can do something fancy and tricky doesn’t mean it’s the best solution for your software product. Especially if you’re working in a team environment.
Striving for Perfection
Even though writing perfect code 100% of the time is not a realistic goal, there are things that developers can do to get further down the road of perfection.
- Gain experience. The more work you do and the more code you encounter will give you greater insights into building better code. If you are stuck working on an old project at work, take on some side jobs. Tackle projects that are really small to really large. When opportunities come up on the job, offer to take them on. Try working in a different programming language every now and then. All of the experience you gain will season you and give you an inside understanding of what good or bad code is.
- Test your code. We all talk about writing unit tests and testing our code but very few of us actually do it. And those that do write unit tests are simply writing them to follow a team rule or to comply with company standards. This leads to tests that don’t really test. They fire up the code and do a few assertions and call it good. Testing code well takes time and effort. The effort you put into testing will easily be rewarded with experience points (which we saw in item #1 gives you insight into what better code looks like).
- Care. Have you ever noticed the quality of work when you hire a teenage kid in your neighborhood to mow your lawn vs. how you mow your own lawn? The kid will probably leave grass clippings on the sidewalk. They might miss the portions of the perimeter. The same principle applies with the code you write. You should treat all code you write like it’s for your own personal project. Dot the I’s and cross the T’s. Don’t half heart the work you do because that ultimately produces less than desirable code in the long run.
- Never stop learning. This industry is constantly changing. If you’ve found you’ve become complacent you are treading in dangerous waters. Best practices evolve. The concept of what perfect code is, is always changing. If you stop learning and keeping up your coding solutions will begin to show their age.
The next time you are talking about your code with others, don’t hide the fact that there are imperfections in your code. Tell them, “I know this could have been done better here but I was under a deadline to get this finished. If anyone has any suggestions on how to make this better I’d love to hear them”. Getting feedback from your team, doing code reviews and being willing to change and learn will make you a rockstar developer. Even rockstars miss notes from time to time.
Author: Dan Bunker