As my time is getting increasingly tied up with Summer of Shipping, I’m going to streamline my Software Mentor posts. To that end, each post will be focused on something small.
Today, I want to talk about a quote from Joel Spolsky:
It’s harder to read code than to write it.
Whenever you join a team, you’ll feel a very strong urge to complain about bad legacy code.
Bad legacy code is unpleasant to use, turns a 5 minute task into a 5 day one, and kills the joy of programming.
But remember, it’s always harder to read code than to write it.
So take a deep breath. Getting angry at the code won’t make it go away.
Research and understand the code. Have an answer for “Why is it bad? Can you point to lines which demonstrate subpar code? Any alternatives the author could have considered?”. This process might take all day, if not many days.
Once you can articulate why it’s bad, show offending code examples, and offer pseudo code for a better implementation, you’ve become an expert.
Instead of a complainer, you become a cleaner, and you might just find this brings you some peace.
When you’re coding, you rarely realize that it’s easier for you to write code, than it will be for your coworkers to read it. When you’re coding, empathy is hard.
There are two tricks that will raise your empathy:
Write unit tests
In both circumstances, you will become a user of your code, and all of the bad design decisions you’ve made now affect you.
So, put yourself in your teammates/users shoes and write documentation and unit tests. Update your code if it’s hard to use.
In fact, you can do one better. Write docs and unit tests before you write your code. You can tweak the interface to perfection before any of the implementation is even touched.
Super short idea today - writing code is easier than reading it - but there are ramifications to your day to day. Think about that concept frequently, and you’ll be a much more pleasant teammate to be around.
Alright, that’s all for today!
Until next time,