97 Things Every Programmer Should Know

I hope you get value out of it.

Here it goes.

Whatever you undertake, act with prudence and consider the consequences.

“Shortcuts in the code make it harder to add features or refactor your code.”

Apply Functional Programming Principles (multicore shift in the Industry).

Ask, “What would the user do?” (You Are Not the User).

We all tend to assume that other people think like us. But they don’t. (false consensus bias).

Spending an hour watching users is more informative than spending a day guessing what they want.

Automate your coding standard.

“The beauty of style and harmony and grace and good rhythm depends on the simplicity of your code.”

You probably won’t finish this article. In fact, I may have already lost you to another tab in your browser. Or an email from your boss. Or a ping from a coworker. Or any number of other digital distractions that have come to define your modern life.

People educated in the arts have a different perception of (or at least approach to) beauty than people educated in the sciences. Arts majors tend to approach beauty in software by comparing software to works of art, while science majors tend to talk about symmetry and the golden ratio, trying to reduce things to formulae.

“Beauty is born of and found in simplicity.”

• The best approach for restructuring starts by taking stock of the existing codebase and the tests are written against that code.
• Avoid the temptation to rewrite everything.
• Many incremental changes are better than one massive change.
• After each development iteration, it is important to ensure that the existing tests pass.

“Personal preferences and ego shouldn’t get in the way.”

• New technology is an insufficient reason to refactor.
• Remember that humans make mistakes.

Always leave the campground (here, code) cleaner than you found it.
Frankly, this just sounds like common decency to me — like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed, the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn’t done.

“Check your code first before looking to blame others.”

When someone else is reporting a problem you cannot duplicate, go and see what they are doing.

Choose your tools with care.

The greater the number of tools, the worse the problem can become.

Licensing terms matter, even for free software. For example, in some companies, it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code.

Finally, there is one inescapable fact: great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different.

“Code layout matters.”

A non-programmer friend once remarked that code looks like poetry.

You should do code reviews. Why? Because they increase code quality and reduce defect rate. But not necessarily for the reasons, you might think.

Have a regular code review day each week.

Avoid using goto statements, as they make remote sections highly interdependent.

Avoid using modifiable global variables, as they make all sections that use them dependent.

• Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage.

“Make objects immutable whenever relevant.”

• Make the code readable by using spacing, both horizontal and vertical — e.g., aligning related structures and using an empty line to separate two sections.
• Make the code self-documenting by choosing descriptive (but relatively short) names for objects, types, functions, etc.

“If you need a nested section, make it a function.”

• Make your functions short and focused on a single task. The old 24-line limit still applies. Although screen size and resolution have changed, nothing has changed in human cognition since the 1960s.
• Functions should have few parameters (four is a good upper bound). This does not restrict the data communicated to functions: grouping related parameters into a single object localizes object invariants, which simplifies reasoning with respect to their coherence and consistency.
• More generally, each unit of code, from a block to a library, should have a narrow interface. Less communication reduces the reasoning required. This means that getters that return internal state are a liability — don’t ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, encapsulation is all — and only — about narrow interfaces.
• In order to preserve class invariants, the usage of setters should be discouraged. Setters tend to allow invariants that govern an object’s state to be broken.

“Comment Only What the Code Cannot Say.”

You need to keep learning to stay marketable. Otherwise, you’ll become a dinosaur, stuck in the same job until, one day, you’ll no longer be needed or your job gets outsourced to some cheaper resource.

“Always try to work with a mentor.”

Deploy early and often.

Distinguish business exceptions from technical.

The 10,000-hour rule applies to coding as well, 20 hours a week for 10 years.

Don’t be afraid to break things.

“Don’t be cute with your test data.”

No matter how unlikely you think an error is in your code, you should always check for it and always handle it. Every time.

Don’t just learn the language, understand its culture.

If you look at any activity, process, or discipline from far enough away, it looks simple. Managers with no experience of development think what pro- grammars do is simple, and programmers with no experience of management think the same as what managers do.

“Duplication is Waste.”

Repetition in Process Calls for Automation.
Repetition in Logic Calls for Abstraction.

Under no circumstances — ever, at all — should a developer have access to a production server.

Encapsulate behavior, not just state.

“Floating point numbers aren’t real.”

It should go without saying that you shouldn’t use floating-point numbers for financial applications — that’s what decimal classes in languages like Python and C# are for. Floating-point numbers are intended for efficient scientific computation. But efficiency is worthless without accuracy, so remember the source of rounding errors, and code accordingly!

Fulfill Your Ambitions with Open Source.

“Golden Rule of API Design: It’s not enough to write tests for an API you develop; you have to write unit tests for code that uses your API.”

Knowing how to submit a good bug report, as well as what to look for in one, are key skills for keeping a project moving along nicely.

A bug with plenty of contexts to make it easier to reproduce earns the respect of every- one, even if it stops a release.

Improve code by removing it.

• Write code because it adds value, not because it amuses you.)
• If you don’t need it right now, don’t write it right now.)

Fix every error, even the ones you can ignore for time being or those compile-time warnings that you know will never cause any trouble in production.

“Know how to use command-line tools.”

Write your own make file.

Know well more than two programming languages.

Know ins and outs of your IDE.

My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I’m typing my code, pressing Ctrl+Shift+I to inline a variable prevents breaking the flow, whereas switching to navigate a menu with my mouse interrupts it.

These interruptions lead to unnecessary context switches, making me much less productive if I try to do everything the lazy way.
The same rule also applies to keyboard skills: learn to touch type; you won’t regret the time invested upfront.

“Know your next commit.”

Large, interconnected data belongs to a database.

Learn Foreign Languages. Programmers need to communicate. A lot.

If you talk to accountants, you need a basic knowledge of cost-center accounting, tied capital, capital employed, et al.

If you talk to marketing or lawyers, some of their jargon and language (and thus, their minds) should be familiar to you.

All these domain-specific languages need to be mastered by someone in the project — ideally, the programmers.

Programmers are ultimately responsible for bringing the ideas to life via a computer.

Make interfaces easy to use correctly and hard to use incorrectly.

News of the weird: Testers are your friends.

If your code needs comments, consider refactoring it so it doesn’t.

“Pair program and feel the flow.”

The single most important trait of a professional programmer is personal responsibility.

“Put everything under version control.”

Do yourself a favor and read others' codes.

Step back and automate, automate, automate.

Test for required behavior, not incidental behavior.

Something magical happens when testers and programmers start to collaborate.

and finally…

Write code as if you had to support it for the rest of your life.

I hope you got clarity out of this article.

I’d love to hear your thoughts about this, so feel free to reach out to me on LinkedIn or Twitter or respond in the comments below!

If you are a novice programmer and want to build a Solid Technical Résumé, this article will be super helpful — https://zriyansh.medium.com/stop-ruining-your-r%C3%A9sum%C3%A9-c8ca15de5a98

If you like Data Structure and Algorithms, you’ll love this — https://medium.com/interviewnoodle/data-structures-and-algorithms-in-real-life-6b2b813d516e

If you are a Compiler or Interpreter fan, you’ll definitely enjoy this chemistry — https://medium.com/interviewnoodle/ms-compiler-and-mr-interpreter-2eeab8e0759e

— If this article helped you in any way, consider sharing it with 2 friends you care about.

Till then stay alive.