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
- 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.
- Plan for uncertainty by leaving adequate margins.
- Planning with adequate margins often comes from similar experience, especially within an organization.
- 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.
- Don’t be fooled by short-term progress.
- Provide a quiet work place so that programmers can focus.
- Carve out times of day where there are no meetings.
- 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.
- 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.
- 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.
- Develop talent with training, such as for design, review, and test.
- Not all training is of equal value.
- 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.