11 Things I Always Tell My Juniors to Keep in Mind When Programming

Summary

The article provides guidance for junior programmers, emphasizing the importance of simplicity, automation, and understanding in coding practices.

Abstract

The author reflects on their early programming experiences and the lessons learned that go beyond technical skills. They advise juniors to prioritize simplicity in code to avoid future complications, optimize with clear performance metrics, and automate development processes. The article suggests that comments should be minimal if the code is straightforward, advocates for statelessness and immutability to manage complexity, and recommends reducing the number of cases to limit potential bugs. It also cautions against unnecessary reinvention, encourages a clear problem statement, and emphasizes the importance of thoroughly understanding the problem. The author advises explaining the problem simply and writing a solution only after careful thought, including creating prototypes to refine ideas without committing to the final code.

Opinions

Optimization should be approached with caution and only when there is a measurable benefit, to avoid complicating the code unnecessarily.
Automation in the development process is crucial for efficiency and consistency.
Comments in code are unnecessary if the code is self-explanatory but are vital for explaining complex logic.
A stateless and immutable architecture simplifies code management and reduces the risk of errors.
Minimizing the number of cases in code leads to more straightforward testing and fewer overlooked bugs.
Avoiding the reinvention of existing solutions can prevent project delays and complications.
Clearly defining the problem is essential for finding the right solution.
Understanding the problem deeply can be facilitated by the "five whys" method.
The ability to explain the problem in simple terms is a sign of a thorough understanding.
Writing code should be a well-thought-out process, preceded by prototyping and problem exploration.

Because no one told me so.

When I started programming, I focused on coding, finding tools, testing my skills, reading code, and refactoring. I thought if I got better on all these, I’d become a good programmer but that all weren’t enough. I didn’t know I have so much to learn such as:

Make the code as simple as possible, today’s big hacks will give you nightmares when you have to modify them in 6 months.

Only try to optimize with an objective measure of performance (and it’s much more complex to do correctly than you think), otherwise you will violate the 1st rule.

Automate your development process as much as possible: the build and a series of tests.

Comments are not necessary if the code is simple and readable, they are only necessary if it is complicated (especially to explain the “why”, for the “how”, it is enough to read the code), but if the code is complicated see 1)

Be stateless as much as possible. Perfectly minimizing and controlling your states, an immutable architecture is much easier to manipulate and duplicate. Managing multiple states complicates the code very quickly. Immutable code creates new states but never modifies them (in general, destroying a state is less of a problem than modifying it).

Minimize the number of cases. Fewer possible cases mean less testing needed, and fewer missed bugs. This is the principle of the “washing machine code”, which works all the time and is therefore tested a lot.

Avoid reinventing the wheel. NIH (Not Invented Here) syndrome can be deadly to a project.

Clearly state the problem to be solved. In general, we have already discovered a lot of things that we had not anticipated.

Think about the problem, to understand it well. (at each stage of the reflection, one can use the “method of the five whys”).

Formulate a simple explanation of the problem (explain the problem to a 5-year-old child). If we can’t explain the problem very clearly, then we haven’t understood it well.

Write the solution — In the case of programming, the same methodology must be applied; just to think about some aspect of the problem, and also to explain the problem, we can write code, for example, a prototype, from which we can move towards the solution.

Above all, do not start by writing code without having thought about it beforehand! It’s the surest way to lock yourself into bad choices from the start.

It is important to make a prototype, a trivial version in a very fast programming language before launching into the real code: it allows you to work out a lot of problems quickly, and to avoid making a “ disposable version”.

In general, in a computer project, you have to keep in mind that you always have a “throw-away” version. As much as it’s the prototype on which we didn’t sweat too much.

More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.