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.

Remote working

Working from home (remote working) is used by many tech companies, e.g. Scott Hanselman from Microsoft. The main counter argument is that people will be less productive. It assumes that being physically present in an office for 8 hours makes you automatically more productive. My argument is that we have to measure productivity by examining the outputs, not by how much time has been spent. Also, design work requires high quality people and those types of people have less problems working on their own.

Risks and Mitigation

• Not being able to use lab equipment:
• Pure algorithm/software development requires no extra equipment other than a computer and internet connection. Examples of algorithm development: Guidance and control, navigation.
• Most analyses are done on a PC with special software, e.g. finite element analysis, aerodynamic analysis.
• Most equipment is relatively cheap and can be used at home (e.g. medium grade power supplies, oscilloscopes). For the remaining 10% of testing and analysis needs, you go to the lab. Criteria: If the equipment fits on your computer desk, it can be used at home.
• Social isolation, loss of motivation
• Assuming a four level hierarchy (team member -->  lead --> coordinator --> boss), organize daily online scrum meetings with tools like WhatsApp / Skype. Team leads meet with team members, coordinators meet with team leads and the boss meets with coordinators.
• Issue tracking and sprint boards with Jira. Work in pairs with Teamviewer. Document sharing with Google Drive. Code repo with GitHub.
• Weekly physical meetings at a central office or cafe.
• Social events: Workshops at a resort, gym memberships, picnics, trekking, camping etc.
• Distraction by kids, computer games, movies etc.
• Have a saparete work computer that has no games on it.
• Work at a quite place like a library and use your smartphone as a modem.
• Not being able to measure productivity
• As I already said above, this risk exists in physical offices too. The team lead is very important because the lead has to check and evaluate outputs (code, documents etc.) of team members and give them feedback on a daily basis. For persistent reporting, team members enter their daily progress as comments on the issue tracking system (e.g. Jira) which the lead will read. The same method will be used by coordinators to measure productivity of team leads. I assume that the coordinator is also technically adept and peeks into outputs and issue comments. Finally, how will the boss know that the teams are productive and not a waste of resources, especially if he does not have a technical background? This problem is not specific to working from home, so I will not go into further detail here.
• Leak of confidential information
• Most (>90%) technical work is not confidential, it is re-using public knowledge. Use designs/architectures suitable for isolating security related parts. Examples: 
• Capture confidential information in data, not code.
• Use emulators/simulators to test interfaces with dummy implementations. Most of the logic problems can be detected and resolved with dummy implementations. Test confidential implementations on site.

Advantages:

• Attractive to talent --> You can select from a better talent pool.
• Adapt work hours and environment to your personal preferences, reduce interrupts, resulting in better concentration (being in the zone) which increases efficiency by an order of magnitude.
• Reduction of time wasted in traffic (in my case, 2 hours per day, i.e. 25% of the 8 hour work day).
• Much better for families with little kids where daycare or dropping kids to school and picking up them up from school becomes a major issue.
• Drastic reduction of logistics costs:
• Less transport and related liabilities like traffic accidents.
• Less office space --> Less building, heating, cleaning, maintaining.
• Less cafeteria space, less cooking.
• Fewer lavatory facilities and maintenance.
• Reduction of city traffic and pollution.