The move from tinkering around with code as an amateur programmer to going full-time in the professional world can bring a host of new challenges — among them, the need to consider the future engineer tasked with maintaining your code months or years down the line.
For their benefit — and your own, as the task may fall on future you — your code needs to be not only functional but also clean, well-documented and easy for others to understand.
Art Baker, a junior software engineer at Two Barrels, has heard this idea expressed in a few memorable ways during his two years in the field.
“We've all heard the saying, ‘Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability,’” he told Built In Austin.
While that might be an unlikely scenario at a family-owned software company, the motivation rings true regardless. “In a professional environment, the code you write could very well determine the quality of someone's day in the future,” Baker continued. “Descriptive variable names and intention-clarifying method names go a long way in making code readable.”
Working alongside more senior engineers, he’s come to understand writing great code as an art and has pushed himself to refine his skills through reading, integrating feedback from code reviews and taking on increasingly challenging projects.
Read on for more about Baker’s approach to learning and what he’s accomplished with his new skills.
Two Barrels is a product-focused company that provides custom software development, marketing, information technology and operations support.
How have your code-writing skills improved since joining Two Barrels? How did the company help facilitate that improvement?
Working at Two Barrels has exponentially improved my coding skills. Before I started coding professionally, I didn’t prioritize code readability when working on personal projects or exercises. Getting things to work mattered most. Shortly after starting with Two Barrels, the emphasis the team puts on code readability became clear. I distinctly remember a senior developer saying something that was so strange to me at the time, but that I now keep in the back of my mind whenever I write code: “Your code should read like poetry.”
How could code possibly be remotely similar to writing poetry? This question lingered in my mind for months, haunting me day in and day out. But as time went on, the sagacity of her advice became more potent as I progressed and learned from other experienced engineers.
Tell us about a project you completed thanks to your leveled-up code skills. What was the project, and how was it made possible by your improvement in skills?
After working on an existing project, I had the chance to start a new project from scratch. The project was to create an extract, transform and load pipeline for business formation and registration data available from various Secretary of State APIs for specific jurisdictions. The first challenge was dealing with how different each data source was. Sometimes it was obtained by a simple HTTP GET request, sometimes by an SFTP server. Sometimes it was located in one CSV file with lots of duplication, other times, it was very normalized and split up into multiple CSV files. For the data to be usable, we had to convert it into one schema. If I had attempted this project earlier, I would have been tempted to scatter the logic for making those conversions throughout the codebase.
Around the time I started the project, I began reading the book “Design Patterns in Ruby” by Russ Olsen. I remember the first principle presented was, "Separate the things that change from the things that stay the same." That simple principle gave me the foresight to abstract that logic away from the main import processes, which cleaned things up a lot and allowed us to easily add new importers.
For engineers just starting out, how can they best improve their code-writing skills while on the job?
A huge leap forward in my code-writing skills came from taking the time to learn as much as possible about the specific language the team uses (Ruby) as well as language-agnostic design patterns that come up frequently in professional-level code. I recommend asking your coworkers about the resources they used to level up their skills. Order those books and read them. Internalize each concept and try applying them in your code. Not everything is as simple as the book examples present them, but through trial and error, you'll learn what works in different situations.
Another important thing I'd like to remind people of is humility. Just because you spent a lot of time writing something you are proud of does not automatically make it the best solution. Outside of the work environment, long before I started programming, I found it's good practice to treat all people as if you can learn something from them until they prove otherwise. This is no different when programming. Treat each code review as a chance to improve and learn from the unique backgrounds of each of your colleagues.
Treat each code review as a chance to improve and learn from the unique backgrounds of each of your colleagues.”
