Quotes That Changed How I Approach Software
When you say enough words, the law of averages ensures that some of them will be profound. One of the neat things about blogging is that you have a record of when you manage prophetic statements. On that note, if you aren't current blogging or journaling, start. More on that later.
These are some of my favorite quotes from the last couple of years. Each has become a guiding principle that has changed how i approach software. I hope they do the same for you.
"The fastest, highest quality code crumbles at the hands of a future, confused developer."
There are a number of traits that code can be judged on: quality, speed, cleverness, clarity and maintainability. Among this list, i consider maintainability and clarity to be of the utmost importance. This is because both of these contribute to your code's ability to be modified in the future.
The reason for this is simple: code that cannot be readily understood will be either be rewritten or fall into "legacy" status. Don't believe me? How many days ago was the last time you re-wrote working code because it was too troublesome to understand? Legacy systems are perhaps worse: mission critical code that works but is written so poorly it is difficult to understand what it is actually doing.
Of course, neither of these outcomes benefit the company. One of code's primary benefits is its flexibility. Unclear code isn't flexible. It's a black box that will either be replaced or will exist unmodified for years, cursed regularly by those very same future, confused developers.
"The only thing whiteboard coding measures is penmanship while nervous."
Whiteboard coding is a useless exercise perpetuated by bad interviewers ignorant to better processes. Not only does it fail to accurately measure a coder's ability, it can categorically reject quality candidates who are shy or perform better when given time to contemplate problems. Worse still is that whiteboard coding reflects poorly on the organization.
When you are interviewing at a company, that interview is their first impression of pulling back the curtain. If behind that curtain is a shitty interview process, what does that say about the company as a whole? Honestly, very little. But the perception is irreparably damaged.
Thankfully the industry perception on this is starting to shift. Companies are slowly starting recognize the futility of whiteboarding candidates. Good thing. At this point i would seriously consider walking out of an interview if i was asked to code on a whiteboard. That is how far i look down on the practice.
"I'm not afraid to be wrong as long as it gets the conversation started."
I believe deeply in a group of people discussing a solution to a problem. Better ideas are regularly achieved by a candid discussion of ideas and concerns.
The issue with this approach is that we all hate being wrong. I used to argue my points up and down, simply because they were my views. Others stay quiet during these discussions, avoiding the vulnerability of asking the "dumb question".
To both of these approaches i wave my hand dismissively. Each places a higher value on our egos than the solution we reach. Resist this defensive posture. The person who asks the dumb question or offers the silly idea is usually the one to spark a conversation that functionally improves the current solution. It just takes someone brave enough to be wrong.
"Culture isn't vitamin water in a fridge."
We often equate good culture with company perks. When culture or morale at a company is slipping, perks are usually the tool of choice for improving that culture. When we are looking for new companies we do the same: we assume more perks means better culture.
But the culture of a company is not a list of the perks that company offers. Culture is the people, mood, morale and interactions. Sure a ping pong table might help those things, but it hardly defines them. When you are looking for good culture, or when you feel like culture is slipping at your company, remember that culture is people not perks.
Document your growth
I've written before about the untold benefits of blogging. This post points other another one: when you document your growth you occasionally come across learnings you might not have given proper attention to otherwise.
To the engineers out there who are passionate about growing i suggest you start writing about it. Journal, blog, whatever fits you best. Point is, recording your thoughts is a great way to reinforce those lessons and uncover other learnings at the same time.
tl;dr: Writing is a great way to uncover lessons you may not realize were important. These are the lessons i've learned by writing down my growth.
