jaredrobinson.com

Twenty years ago, an extended family relation, a patent lawyer, expressed his opinion that there’s not that much variance between engineers — at least, not as much as people suppose. Companies draw from the same pool of talent, and the idea that one company has the bulk of talent is a misconception.

This article by Bill Nichols confirms that idea in the realm of programmers.

Programmer Moneyball: Challenging the Myth of Individual Programmer Productivity

My view is that hard work, good health, persistence, consistency, the ability to work with others make a big difference. On the other hand, poor health, inconsistency and confusion of priorities lead to mediocre results.

Key takeaways from the article, with my commentary below

1. Keep tasks small.
   • Reworking the design or the infrastructure (e.g. build system) is rarely small, but it can often be done in parallel with the existing solution.
2. Plan for uncertainty by leaving adequate margins.
   • Planning with adequate margins often comes from similar experience, especially within an organization.
3. Start critical work early since almost half the time it will take longer than expected, sometimes much longer.
   • There are edge cases that must be handled, and we discover things that we didn’t know up-front: new difficulties, new requirements, etc.
4. Don’t be fooled by short-term progress.
5. Provide a quiet work place so that programmers can focus.
   • Carve out times of day where there are no meetings.
6. Design to control the complexity and size of solutions.
   • Peer feedback is a good way to simplify design, especially when a first attempt has started to be overly complex, or not work as intended.
7. Encourage frequent peer review.
   • Agreed. Note that not all code changes need the same level of peer feedback, so saddling certain kinds of changes with too much process can be the antithesis of progress and quality in things like readme files, fixing spelling mistakes, adding a comment to clarify code, etc. Find a balance that works well.
8. Automate routine tasks such as regression test and deployment.
   • I mostly agree. Beware of automating everything, especially one-off-temporary-solutions. Manual testing has its place.
9. Develop talent with training, such as for design, review, and test.
   • Not all training is of equal value.
10. Since quality can be taught and benefits apply to the total lifecycle cost, emphasize quality rather than speed.
    • For a revenue producing product, I tend to agree. When there’s a critical time-to-market component that has been adequately quantified, it can make sense to initially prioritize speed over quality — with the understanding that it may require all-hands-on-deck to handle quality failures.

He concludes, “the most motivating and humane way to improve average performance is to find ways to improve everyone’s performance.”

When management doesn’t prioritize items on the above list, it’s important for a software engineer to mange themselves and make them a priority.

Useful information for reducing memory usage of Python programs:

• https://m.habr.com/en/post/458518/
• https://stackoverflow.com/questions/472000/usage-of-slots

TLDR: Dictionaries use a lot of memory. Possible solutions include using a class and slots, namedtuple, recordclass, cython, or numpy.

If you write Linux shell scripts (bash), you should use https://www.shellcheck.net/ to improve the quality of the script.

Microsoft has a long article in ACM Queue on what people think they’re getting out of code reviews, what they’re actually getting, as well as a list of benefits a code review tool should provide.

My main takeaways:

• Requiring two sign-offs is too many for low-risk changes such as renaming internal (not API) methods or local variables — only need one reviewer
• Tag the files/changes that are at the heart of the change
• Small reviews get better feedback. More than 20 files, and a code review isn’t going to provide much, if any, value.
• If code reviews are important, doing reviews should be tracked and rewarded, just like anything else that has value.
• Reviews tend to focus on: comments about maintainability, documentation, alternative solutions, validation, and API usage
• Reviews only identify bugs ~15% of the time, so some other form of validation is important
• A good code review tool can help greatly by recommending reviewers — lightening the burden and getting knowledgeable people involved
• Show entire file to give reviewers context
• There’s no one-size-fits-all solution for code reviews — i.e. each team and code base has different needs and different culture.