Hey there,
Have you ever done something that you think was just brilliant for this one bug? Something brilliant that you’ve gone the extra mile in thinking that it will be “better”?
Here’s news for you: what you perceive that is “better” will probably not be what your peers think. In fact, they might have a better solution that will fit the whole picture, whereas your version could be a narrowed-down one. This is why communication is important.
However, let’s rewind for a bit. Before diving into the code, it’s always good to spend at least a few minutes to think. Because to achieve something, you’ll always want to find the easiest way in getting there. Sure, you can code it straight away without thinking much, but that takes a lot more work with more unnecessary steps, which is probably going to even be that “brilliant” code you’ve written.
However, minimal and simple is key. For example, if that piece of code is not part of that bug, please don’t include it.
Rather, if it’s more of an improvement, then it’s much easier to file an improvement over that bug, and then include that piece of code, so then everything can be tracked down in each release.
Then probably another person can also work on it, or you, or both of you by pairing.
For most developers, this is how we work with code. A friend of mine told me this a little over a year ago:
Think of the simplest solution. In other words, how good is it? Can it be simplified further, or is it already optimized (usually this is within the coding phase)?
Does the code that you’ve written solve the problem?
How would another person feel about what you’ve written?
And that’s it. Once this is done, move on to the next task. Rinse and repeat. It’s a process that, if you haven’t developed it yet, it’ll benefit you in the long run when you are, or will be, working with a company.
So if you want to stay, stick with the requirements and that’s it!
Until next time and the next topic,
Brian.