Congratulations on your first day on your first software job.
Like many of your peers, you’re starting on support. Because reading other people’s code gives you a great feel for what’s nice to work with and what isn’t, and dealing with customers helps you understand what’s important and what isn’t. You will write better software knowing both these things.
But as this is day 1, we’re not going to expect you to rush in and fix everything. Take your time to look around and understand things. Your first bug fix is as much about learning the process as it is about fixing the problem. Because the process exists to help make sure this bug is fixed now and forever, and that this fix doesn’t break something else.
You wouldn’t fix a smoke alarm by removing the batteries, although that will disable the alert. Let’s find the root cause and fix that instead.
From experience:
- Treat it like science : have a hypothesis and test it. Don’t just randomly change things.
- Make notes on every hypothesis, test and discovery. One of them will be important but you likely won’t realise it at first.
@code_likeagirl From experience:
1. Treat it like science : have a hypothesis and test it. Don't just randomly change things.
2. Make notes on every hypothesis, test and discovery. One of them will be important but you likely won't realise it at first.
And once you've fixed it, do self-retro.15:21 PM - 31 Aug 2020
And once you’ve fixed it, do self-retro. What went well, what didn’t go so well, what do you wish you knew, what are you going to research to prepare for next time, what are you going to publicise about this fix for the next person to sit in your seat?
Well done on fixing this bug. There’ll be another along in a minute.
How will you write your next feature to make this easier next time? How will you write it so the next time is less frequent? How will you pay things forward to help the next developer, who may well be your future self?
Top comments (0)