It seems like my first day as an intern was a hundred years ago. I joined a small software team of three — My manager, a firmware guy who liked to be left alone, and me.
Our cubicles were tucked in a corner of the hardware engineering area next to work benches covered with prototypes, tools and breadboards. Sometimes I had to tune out sounds of pounding and drilling as I tried to stay heads-down focused on coding.
As interns usually do, I spent a lot of time making Taco Bell runs, flirting with cute hardware engineers (I learned to stop doing that, but that’s a story for another day) and chatting in front of the coffee maker.
Also, as interns usually do, I did A LOT of software testing and troubleshooting. I learned about acceptance criteria, test scripts and requirements traceability matrices. But more importantly, I learned a few things about troubleshooting that have nothing to do with coding.
I still use these universal problem-solving skills today.
I know experienced developers out there probably know some (if not, all) of these tricks but I’m offering them up to any of you who may want a refresher or a few new tools in your toolbelt.
Check your assumptions
This is the single-most effective problem-solving morsel of advice I’ve ever received.
The first time I got stuck trying to debug a complex issue, exasperated, I went to my manager for help. He was a brilliant developer who singlehandedly coded most of the application. He knew his stuff.
He simply said, “check your assumptions”.
I stepped back and looked at each and every line of code that I’d assumed was working correctly, and eventually found the culprit. Eureka!
I don’t remember the details of that issue after all these years, but I do remember the advice.
Checking assumptions works.
Sleep() on it
Oh, the hours I’ve spent swirling on a block of code that just.won’t.work and just when I’m about to give up, I think of something new to try. I get caught in the loop of despair as three hours turns into ten and my day slips away without getting anything done.
Did I learn anything in the meantime? Maybe, maybe not.
It’s takes experience and self-discipline to stop, walk away and come back to it later. Or better yet, the next morning.
I know all you coders out there have a hard time letting a problem go unsolved…but my best advice is to STEP AWAY FROM THE KEYBOARD.
When I get caught in the loop of despair, I walk away or work on something else to clear my head. By the time I log in the next morning, I’ve usually come to one of these conclusions:
- I figured it out in the shower and after two cups of coffee am ready to get back to my keyboard with my solution.
- I realized I’ve approached the solution all wrong, am ready to delete the problematic code and start over.
- I need help! I’ll join the morning standup and ask the team to linger on it after the round of updates.
Sometimes the key to solving a problem is getting away from it long enough to break out of an infinite loop.
Ctrl+Alt+Del
If you watched the British sitcom series “The IT Crowd”, you’ll remember when the company’s IT department changed their outbound voicemail message to “Turn it off and turn it back on again”. They stopped answering their phone and let calls go directly to voicemail and it solved all of the incoming helpdesk calls.
It was a great episode for a hearty, belly laugh because there’s more truth to it than we techies like to admit (especially if you are working on a Windows machine).
Sometimes I forget this simple trick and waste an hour trying to resolve a system level error that disappears after a simple restart.
When in doubt, reboot.
Clean the house
When you’re the only one on the team experiencing unexplained build errors, other than a global change you weren’t aware of, the team really can’t help you. You’re on your own.
If rebooting doesn’t solve the problem, you’ll have to break out the big guns and start from scratch.
Start with the codebase. Delete your build and local repository directories and re-import the main branch.
Build. Did it fix the issue? If not, uninstall and reinstall your SDK, Libs, etc.
Build again. Did it fix the issue? If not, uninstall and reinstall the IDE.
Nine times out of ten, starting with a clean environment resolves the unexplained build errors on my local machine.
This may seem time consuming but when you’re having environment issues, at some point it’s faster to rebuild than trying to zero in on something elusive.
Delete, uninstall, update.
Troubleshooting is sometimes as difficult and complex as writing code. Effective debugging may not have anything to do with expert coding and everything to do with problem-solving and critical thinking.
My SQA Engineer and Software Development colleagues are some of the brightest people I know. I have to keep my toolbelt full of fierce tools to keep up with them.
I hope sharing these tricks I learned as an intern, are useful reminders to help you spend less time troubleshooting and more time coding great software.
If you have other great tricks in your toolbelt, I’d love to hear them.
A little more about me. I’m a writer, tech professional, cat lover, and single mother. My favorite topics are tech, dating and random feel-goods.
Check out more of my writing on Medium at Sarah Writtenhouse – Medium for short articles and stories about dating apps, tech and short feel goods.
— Sarah Writtenhouse
Comments
Post a Comment