Return to Fundamentals

We do miss good fundamentals. In digital products, often could sound a feedback, simplified into “return to fundamentals.” Have you got a similar feedback before, and could not make sense of it?

May sound something cheese corporate concept, yet I believe the sentiment is good behind, as I experienced over time missing pieces of a well-rounded engineer pop up again and again:

• normal forms, never heard of or can’t reason between levels;
• networking layers and how protocols fit into them;
• optimizing code, yet without an understanding of the conveyor belt architecture of CPUs, caches, RAMs;
• deeming a code is legacy or “bad” when can’t attach a debugger to a process, claiming memory leak without able to trace memory usage;
• leaving code paths to crash when the negative path is just another business outcome;
• can’t figure out a production bug if can’t connect a debugger into the system.

And could continue the examples. Mistakes some of us made before, learned how to avoid them in the future when we had to fix it late at night, giving a healthy motivation to not make the error ever again.

When I say, we need to work on our fundamentals, I mean exactly these:

• Learn to write good log messages so even in bad situations, unable to access the remote machine, you can figure out what is wrong - without sacrificing enormous amount of time plastering everything with log messages.
• Learn normal forms, apply them practically, especially if you work mostly with document/key-value pair databases - knowing these are crucial, usually it is not about the engine we use, but how we structure information for later use.
• Learn to read code, debug code, especially unknown ones. Download open source projects, build it for yourself and debug them, analyse how they work. It is a skill unique and really valuable on the market, forever.
• Understand how computers work on the byte or electronics level. Don’t have to be able to write assembly code yourself, but understanding these will help you reason better about your code’s performance.
• Learn about defensive coding practices. Always handle null references as the error message tend to be unhelpful. Always avoid stack overflow or out of memory by limiting cycles, pre-checking availability. Take time to look at your code and restructure for the same outcome around how it will fail less. Especially good way is to learn to auto-test your code!
• Write your own end to end code. Instead of always relying on code generators (be it scripts or AI), write a few examples yourself. This deepens your understanding. When you can stably reproduce, now you can rely more on automated tools.

These are some of the examples that consists the senior engineer’s toolkit. While not all of them will come naturally when you start, juniors tend to not have the life experience, you need to build these skills over time.

What do you consider essential knowledge for a senior engineer?