There is no better way to improve your skills and expertise than by routine peer review and constant critical feedback. It is important to remove yourself from your own echo chamber and get real and relevant feedback on your code from others. Your code is rarely, if ever, perfect and could always benefit from a different and fresh set of eyes. In fact your code will benefit from as many different sets of eyes as possible. The more the merrier. Also, if you have any insecurities about your code, now is a great time to rip that Band Aide ™ off.
Every piece of code can benefit from a peer review and if you have the resources and staff to do it, every piece of code should have a peer review as a standard. In order to enforce standards and accountability it is a good idea to create a templated document for your peer reviews. This could be as simple a word document or could tie into your source control and project management systems. Whatever you choose, it is important to consider the peer review as an artifact that should be preserved.
A peer review is something that tracks the date of the review, the reviewer, the purpose of the code being reviewed and then any notes from the person doing the code review. The peer review may also contain a checklist for all your standards and requirements. i.e. PSScriptAnalyzer Rules, Pester Tests, Documentation, etc. Rarely should a peer review be completed with no recommendations or the only notes being “Looks good!”. That is, simply put, a terrible peer review. There is almost always something that can be improved or made clearer. When doing a peer review you should be looking for problems not functionality. Think about all the different ways the script could break and ensure the testing covers those scenarios. Feel free to get weird. Sometimes the freaky stuff can uncover some pretty well hidden bugs.
It’s not personal
Try to never fall in love with your code. Your code is like a used car, eventually no matter how well maintained and cared for your code is, someday it will need to be replaced. Accept this reality. Sometimes your code will last years in service before being replaced and other times it will never even see production. This is a fact of life and it’s a good thing. Also, your code may suck. It is hard to call your own baby ugly, but sometimes you are going to write some bad code and not know it until someone points it out. Be thankful when this happens. This will help you in the long run. Take your bad code as an opportunity to learn and improve. Being able to replace and rewrite solutions regularly is very important. Remember, iteration is the key to the game now. Brush aside your delicate sensibilities and disregard others delicate sensibilities. Code reviews should be critical and concise. If you think something needs fixing call it out and expect the same from your peers.
Feedback There are many kinds of feedback and all of them are very valuable. There is no such thing as useless feedback. There is always a shred of value in each and every piece of feedback received. There cannot be enough feedback actually, just ask Microsoft. Their use of telemetry is an incredibly advanced use of feedback and it’s use and analyzation has led to some really great product releases recently. (Windows 10, Office and Azure come to mind).
The important part about receiving feedback is understanding and appreciating that each person may looks at a solution under a different lens with a different perspective. People from different teams and departments are going to have a completely different outlook on what they expect from a tool and how it can help or hurt them. I promise you they will see things you would have never thought about it and without soliciting their feedback you never would have known about.
Be sure that after you write anything you give yourself the chance to provide your own feedback. Here are the things you want to acknowledge in a self-feedback:
- Reiterate what you were trying to do.
- Did I do it?
- Can anything be left out?
- Is there anything that should be called out?
- Anything that is cool?
- Is there anything that has a potential for reuse in the future?
- What is missing or could be added in the future?
This could go hand in a hand with a peer review. Team feedback is important to make sure that your script is aligning with the team vision. Team feedback should be very technical in nature. In addition to the chance to improve your future deliveries team feedback is a great way to ensure that more people than just you are very familiar with your code. Ideally everyone on the team would be able to iterate on the code at any time and doing a good in depth peer review is a great way to get familiar with something.
- Does this solve the problem using the proper tooling?
- Are the standards being followed?
- Can anything be improved?
- Is the code clear and concise?
- Are all expected artifacts accounted for?
- Does the code work as expected?
- Does this solve the problem using the proper tooling?
This is going to be feedback that is likely coming from a completely different perspective than the self and team feedback. The motivations, expectations and incentives held by members of your department may be considerably different than your team’s so you are likely going to hear some feedback at this level that is surprising and unexpected. Do not dismiss any of this feedback as it is all very valuable. You need to have feedback from different perspectives so that you can improve your deliverable in ways you never would have thought of. Take this information and further polish your automation solution. You don’t live in a bubble or a vacuum, don’t pretend your automation solutions do.
- Does the solution align with the department vision?
- Will this impact existing offerings or processes?
- Can it be expanded or contracted?
- Does this open any doors to further automation?
Depending on your size and scope your department and customer feedback may be the same. But if not, it is very important to regularly ask the user / benefactor of the automation tool you put into play how it is going, what can change, what would you do differently next time, etc.
- Is the problem solved?
- Was the scope accurate?
- Is anything missing?
- Was the delivery timely?
- What would you change next time?
- What do you want to do for the next project?
A key to successfully obtaining quality feedback is quantity. You want to make it as easy as possible for people to submit feedback. Not everyone has the same likelyhood of providing feedback in the same means so make as many different avenues as possible avaliable to people to solicit and receive feedback. Use all the tools available to you like Email, social media, pen and paper, SharePoint, some existing HR mechanism, SurveyMonkey, etc. Ask early and often throughout the process. If you can provide any kind of incentive to people to give feedback you will receive more feedback. Even something small like a monthly drawing for a free lunch or something could go a long way.
http://media.wizards.com/2015/podcasts/magic/drivetowork199_feedback.mp3 This is an amazing podcast about feedback. Listen to it immedietely.