Technical reviews and mentoring

Recently a novice engineer sent a technical document for review, for which I was one of the reviewers. When I opened the document, I saw that it was littered with problems typical of a novice: No proper introduction explaining why this document was created, not specifying assumptions, simplifications and constraints, endless rows of data instead of clear graphs (i.e. signal buried in lots of noise), no clear conclusion, missing references, what still needs to be done, i.e. future work. See Why I gave your paper a Strong Reject

I told him that I will not review it and forwarded the document to a less senior colleague. As a grizzled veteran, I find it untolerably boring to provide basic feedback because I have done it a thousand times before.

How can we make both the novice and the veteran happy:

• Prepare a checklist listing frequent mistakes. Novices prepare their reports with this checklist in mind. My previous blog posts that can be helpful:
• How to write a technical report
• Basic Software Design Report
• Working with a junior developer
• Minimal Software Design
• Modular design
• Stop worrying that your expertise isn't worth much
• How to use engineering standards
• My software development cycle
• Have two levels for review/mentoring: Seniors (more than 2 but less than 10 years of experience) and masters (more than 10 years of experience). A novice/senior submits his work (code/document/presentation) first to a senior for review. Only after the work has been updated with a senior's feedback is it sent to a master. This way, the master is protected from boredom/loosing his faith in the new generation and the novice/senior is protected from humiliation.