Encourage continuous improvement

While working at REDACTED, I reported the following issue.

Provide a working environment where each programmer can share their doubts and their improvements. Seniors’ attitude alone would go a long way here, but I saw they were very territorial.

Provide more programming freedom and use code reviews for correcting problems caused by that freedom, not for forcing programmers to use predefined (and questionable) templates.

At the same time, provide as much standardization as possible at information level and style level. For example,

• Use the full English infinitive, all capitals, for enum-erated actions, like CREATE, DESTROY, … (information)
• Use a switch instruction for enum-erated branches. (style)

Use code reviews as an opportunity of continuous education, to teach colleagues about company stantards, styles, and how to detect certain patterns and apply best practices. For example, often juniors don’t know how specific a name should be with respect to its context / contents.

• A list variable with items elements is not a bad choice for a generic function that applies to any list of items, but it’s questionable when it expects to be filled with some order lines, with a quantity and a price.
• The code review should suggest to change those names to something like orderLines and orderLine respectively, highlighting the fact that the concept of list / item is then conveyed by that of plural / singular.

Instead I saw code reviewers force the code author to add useless comments to their code, like this:

/**
 * Initialization
 * @return void
 */
ngOnInit(): void {

which is doubly useless because

1. No programmers will ever have any doubts that a method with an Init in its name will be called during initialization.
2. Angular programmers won’t ever have any doubts about how a fundamental piece of Angular, like ngOnInit, is used.