Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
All agile software developers are familiar with code reviews, but what about peer reviews? According to SmartBear’s 2020 State of Code Review, four out of five developers either agree or strongly agree that they learn from code reviews. There are two fundamental objectives with all code reviews – improve the code and help developers learn something in the process. Code reviews are good. Peer reviews can make them even better.
A good (maybe not the best) way to envision peer code reviews is like when you’re moving into a new apartment with a spouse or roommate. It’s a “good idea” – before you start moving the furniture to plan out where what will go where.
“Honey, what do you think? The couch would fit here, we could put the television there, and the bookshelves over there. And we can hang all the pictures of Fido on the wall… after we paint it a sickening lemon color. Does that sound good?”
The best difference with code reviews is that you can discuss the details with confidence that you won’t be forced to sleep on the couch. In real life at home with your significant other, it’s usually just best to agree, “Yes Dear. Whatever you say, Dear. I really like that layout!”
Besides, it doesn’t matter what you say, you’ll still have to move the furniture (iterate) four or five different times, anyway. But, in peer code reviews – you’ve got a really good chance of nailing it on the first attempt.
Otherwise, the substance and objectives of peer code reviews reinforce the rest of your development effort once the coding begins.
Our first objective is to do everything we can to make it easy for the individual reviewing our code. We’re asking for their time and expertise. We don’t want to waste their time on silly things like pointing out typos and style issues – or guessing about what they’re looking at.
The frequency of code reviews warrants setting a standard of what should be done before requesting one. This standard, or checklist, is best to formally keep as part of your team documents and provided to every new member of your team.
The Code Review Checklist below provides the essentials every team should follow, but customize it for your team and work processes. In a Test-Driven Development Team, test first requirements would be emphasized.
The same criteria apply whether we’re writing or reviewing code:
It’s important to include everyone in peer reviews. Equally important are guidelines for prioritizing who they are allocated to and when.
The process for structured peer reviews is nearly the same as, and can fit in line with, pull request reviews:
| Peer Code Review | Pull Request Review | |
|---|---|---|
| Step 1. | Author presents their idea/logic. | Author fixes/submits their code – addressing any questions. |
| Step 2. | Reviewer evaluates and can propose alternatives. | Reviewer evaluates the code noting any issues to fix, asking questions if something is unclear. |
| Step 3. | Steps 1 and 2 repeat until there’s agreement; author implements. | Steps 1 and 2 repeat until the reviewer recommends the code for merging. |
| Step 4. | Author checks in frequently with reviewer to verify they’re on track; submits PR when complete. Continues to PR Review >>> | The code is merged and proceeds to testing in a production environment. If it passes, all is good. If it fails, we go back to Step 1 of the Peer Code Review. |
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates
On a stand-alone basis, LOC is a silly metric. Combined with other statistics, it is more useful, suffice that it can be used for resource allocation. LOC will fluctuate quite radically day by day, hour by hour, by project, team, and individual developer for a multitude of factors. But over several projects, it is possible to get a rough average of the LOC produced by developer/team which can be helpful for allocating time for code reviews.
It’s generally expected for code reviews to cover 400-500 lines of code per hour and catch 70-90% of defects.
| Lines of Code | Case: | LoC Reviewed per Hour | Hours to Review. | Base Cost*: |
|---|---|---|---|---|
| 100,000 | Baseline for comparison | 400 | 250 | $13.2k |
| 100,000 | Faster Reviews | 500 | 200 | $10.6k |
| 80,000 | Reduced Code Complexity | 500 | 160 | $8.5k |
Peer code reviews should help developers start and stay on the right track. They can help avoid a lot of problems, like high code churn. Coupled with an effort to produce concise, well-structured code – the corresponding decrease in code complexity should make code reviews faster and easier to perform. That’s not to imply they should be rushed.
It’s always nice to try to put a dollar figure to things, though developer time is the true bottleneck.
Walkthroughs serve as an extension to mentoring and even as a hybrid “classroom” training session. Reverse walkthroughs, where junior developers try to explain the rationale behind a senior developer’s code is another practice to consider.
Leastwise, teams with many junior and few senior developers can benefit from frequent walkthroughs. Frequency is best tied to the urgency of team performance issues, from 1x to 4x per month.
For best results, the software engineering manager needs to identify what’s challenging their team the most:
Specific issues can be identified via performance analytics and defect tagging through Jira or other project management software. Code complexity is a killer that can be mitigated by showing examples that transform poor to good architecture/logic.
Remember, the Pareto Principle is your friend – a minority of solutions will solve the majority of problems. Four dozen walkthroughs over the course of a year should bring a severely challenged team up to speed. For that matter, you might look to pair walkthroughs with your retrospectives.
Protect your investment – keep a recording of your online walkthroughs (OBS Studio, ScreenRec, BandiCam, etc.). These give your new hires something to watch while onboarding.
