"An ounce of prevention is worth a pound of cure" goes the saying. Having a strict coding standard is prevention. To create good code you must have good standards, such as commenting standards, naming standards, versioning standards and knowing the value of consistency.
But this can really only happen if you’re going to go the extra mile and stick your neck out and correct someone.
- Figure: Bad Example - Correcting someone in a mean way
- Figure: Good example - People make mistakes but correct them as though they’re a soft cute puppy 🐶
Every member of a team plays an important role in maintaining standards. Whether it's your work or someone else's, always keep an eye out for things that can be improved.
This rule applies to all company standards. Standards are important because they ensure your experience at work is consistent and enjoyable. For example, if there was no standard to stack the dishes in the dishwasher when you were finished using them, dishes would build up and create a big mess in the kitchen!
Be nice, not harsh
Do you know the nice way to correct someone?
Small things = Tiny Tip
When the 'mistake' the person made is not an actual mistake, but something that the company has decided to do in one way for consistency, without a strong argument.
Tiny Tip: I’d use international format on your phone number so people outside the USA can just click to dial - as per https://rules.ssw.com.au/great-email-signaturesFigure: Good example - nicely informing of a small standard oversight
Important things = Tip
When there is a proven better way to do something different from what the person has done. You should try to include the reasons.
Tip: I noticed your email has a very generic subject: "website". Please resend with a use a descriptive email subject as per Rules to Better Email. This way it is easier to identify, categorize and find this email later, without having to open it :)Figure: Good example - nicely informing of a better way to do something
Crucial things = Critical
When the error the person committed can lead to a misunderstanding or a security breach. You should include a task with action when necessary.
Critical: When sending a proposal never use the word "quote", but use "estimates" instead. As per Rules to Better Project Management we don't work with a fixed price, which is opposite to what the word "quote" implies. This might create different expectation and consequently frustration and legal problems with the client. Figure: Good example - nicely informing of a critical mistake
1. Please fix asap
Coding - For Developers
When you come across an error, don't just fix it, as the developer who made it is likely to make it again. Instead, write an email to the person explaining what has been done wrong and how you would've improved the code. CC relevant parties to improve others, to collect your brownie points or to set a good example.
No one likes being corrected but hopefully, with everyone doing this in the office, it's not a matter of finger-pointing, it is working together to write better code or developing better solutions.
Tip: In code, if you don't know who made the mistake, use the annotate tool.
What if it's recurring?
When you notice someone doing the wrong thing:
- First time just send an email with a pointer to the rule
- The second time, have a very quick chat with them
- Third time call them in and give them a formal talk about it
Focus on the meat first
When you receive a great 'done' email or document, make sure you mention how great it is before correcting any potential error.
Timing is everything - Don't bottle it up
It can be tempting to offer your feedback as soon as you think of it, but it's better to hold off until the recipient is in a place where they can hear it. If a person is busy, distracted, or in a poor emotional state, chances are your feedback won’t hit the mark. Wait until the person is calm and relaxed before asking them if now is a good time to offer your feedback.
For more, check out Do you know to create a safe space instead of jumping into feedback?
- Figure: Bad example - seeing a mistake and not pointing it out doesn't improve a person. Allow them to benefit from your experience!
When something is really personal, you can’t really correct someone unless you are a close friend and has credit with the person, so you should discretely ask your manager how to proceed in that specific case.
- Figure: Good example - say 'thank you' to a person's corrections to show you don't have thin skin and encourage further positive and negative feedback. It all helps you to improve
It's important to ensure others are doing their best to maintain and follow the standards. Remember, it can be just as important for someone's professional development to give feedback as it is to receive it. Being able to communicate feedback in an effective and professional manner can benefit you in any career.
To: Peter Figure: Good example - nicely informing of a standards violation
CC: Adam (Manager)
While you were away, I came across this page you edited, called ApplicationForm.aspx which was giving an error:
'The conversion of a char data type to a DateTime data type resulted in an out-of-range DateTime value.'
Please note that whilst inserting data from your Front End application, you should not use the format dd/mm/yyyy.
Instead, you should use yyyy/mm/dd as per Rules to Better Databases.
Let's fix it together when we get to work tomorrow.