This is the first of a three part series on protecting your time as an engineer (see Part 2: Focus). Even though our primary job is to create software, we often spend an inordinate amount of time on other activities. Whether its meetings, interruptions, chasing bugs in old code or just plain procrastinating, there’s a lot of time we could spend being more productive and enjoying work more.
So today we’ll focus on coding. Have you asked yourself, how does the code you write today impact your time in the future? Good coding practices require you to trade off time and effort now for a larger benefit down the road. Think about the following:
- Validating your inputs
- Writing good error messages
- Checking boundary cases
- Eating your vegetables
These are all good habits, but we often think of them as things we should do just because ‘it’s the right thing to do’. But software is typically written under time pressure and other constraints. Without additional motivation it’s easy to just return null and order pizza.
Lost time is never found again.
But what if we can add a dose of self-interest to our altruistic motivations? Meaning, if it’s the right thing to do and it’ll make my life easier, I’m much more likely to do it. So now I often ask myself, would I rather spend my time writing awesome features or debugging problems for hours only to find it’s some other component that caused the issue? Can the way we write code free up our time to do the things we like? you bet!
To illustrate with an example, let’s say you have some code that has to parse TSV (tab-separated) files line by line, where the first column is an integer ID. You could do something like this:
Can you see the problem looming? Sooner or later your code will encounter a malformed line, and you’ll end up with a non-descript IndexOutOfRangeException or a FormatException. This may appear in a log (if you are lucky!) or just as a mysterious crash. In either case, you’ll be on the hook for figuring this out and it can be a real time sink. As Murphy’s law would have it, this will happen in a machine you can’t debug on and with data you have no access to! You could spend a lot of time trying to reproduce the problem and even if you do, you may not be 100% certain you’ve fixed it. And remember that bugs are a ‘guilty until proven innocent’ affair.
Consider the alternative:
Now if some funky data is fed into the system, guess what? You might not even hear about it. Whoever is producing the input is now in a great position to troubleshoot the problem. And even if that’s you (it’s a DevOps world after all), you’ll be much better equiped to fix it. In this example I’m using an exception but the specifics of how the error surfaces can vary based on requirements (e.g. you may log and continue).
Another example comes from API design. Let’s say you write the following class in a library:
(There are good reasons to not do too much work in the constructor. E.g. in a more realistic setting you would want to read the file asynchronously)
At one point or another, someone will write code like this:
Which of course will crash with a NullReferenceException. This will likely come back to you and steal a chunk of your time. But a slight variation in the API can prevent this type of misuse:
(and yes, you should validate the file parameter, but I’m trying to keep the examples concise)
These examples are not meant to be comprehensive, but are just trying to help you think about your personal support cost when you write code. The same reasoning can be applied when putting in place your logging, designing interfaces, writing unit tests or even commenting code. I’ve made mistakes in all of these categories and paid (with interest!) in our most valuable currency: time.
I sometimes hear engineers say part of their role is maintaining this or that piece of code, and there’s usually not a lot of joy in those statements :). And while maintaining and supporting code is part of being a software engineer, we can do a lot to minimize this load.
Do you have any other ways in which you protect your time? Leave a comment below, I’d love to hear about it!
You can continue with Part 2: Focus