97 Things Every Programmer Should Know Kevlin HenneyJuly 15, 2016 - 1161 words - 6 mins Found a typo? Edit me
My main key takeaways
01.- Pay off technical debt as soon as possible.
02.- Learn and master functional programming.
- It makes your code less prone to error and easier to debug.
03.- Don’t guess what a user would do; get users to do things and watch them.
04.- Automate coding standards.
05.- Write simple code, simple descriptive names, simple relationships.
06.- Before you refactor: consider the existing tests and code.
- Work in increments, make sure the tests still pass after every change.
08.- Always leave code cleaner than you found it, even if you didn’t write it.
10.- Choose your libraries/frameworks carefully to avoid unnecessary complexity.
11.- Make your code easy to understand using domain terms.
13.- The layout of the code is also important.
14.- Use code reviews focusing on knowledge-sharing among team members.
15.- Objects immutable whenever relevant. Each variable should have the smallest possible scope. Never include more than four function arguments.
18.- Take responsibility for your own education and never stop learning.
- That can be done with just a bit of time each week and there are many ways to go about it (e.g. podcasts, lessons, books, etc.).
19.- When designing an API, aim to make it easy to use, not convenient to code.
20.- Deploy early and often – do not leave it until the end of the project.
22.- Improving your skills should be on your daily basis.
23.- Adapt the technical level of your domain-specific language to your audience.
24.- Don’t be afraid to break things if that’s what’s necessary to fix things.
25.- Careful with your test data because that might go public accidentally.
26.- Handle your errors as they appear, don’t leave it for later.
27.- Learn different programming languages.
- Learn their own “culture” or way of doing things.
- It’ll make you definitely a better programmer.
28.- Don’t just catch your errors, really handle them.
29.- Understand at least some complexities of your business, not just programming.
30.- DRY – Don’t Repeat Yourself.
32.- Encapsulate behavior, not just state.
33.- Floating point numbers inevitably can create errors in calculations.
34.- Open source is a great opportunity to do interesting work and develop programming skills.
36.- Give proper context when asking for help, because people can’t just guess what’s going on.
37.- It’s not about the long hours – learn to work effectively.
- Dedicate time to continuous learning and to think about what you’re doing.
38.- Write proper bug reports:
- Precisely how to reproduce the bug,
- how often it appears,
- what should have happened,
- what actually happened.
39.- Don’t write unnecessary code.
- Only write code that adds value and is needed right now.
- Remove dead code.
41.- The main cause of delays in application response time is a high number of remote interprocess communications, not the algorithm.
- DB connections, for example.
42.- If a compiler warning shows up in your build, fix it.
- Don’t leave it for later. Even if it’s not going to be a problem in production.
- Compiler == any static code analysis for non compiled languages.
43.- Learning to use command line tools is a valuable educational experience, and you might end up preferring them.
44.- Learn (at least) two different languages and paradigms well.
45.- Invest some time to master the IDE you’re using.
- It’ll make your life easier and save you time in the long run.
46.- Know and work with your limitations: budget, resources, time, etc.
47.- Work in small tasks, don’t be afraid to throw away changes.
- You’ll still have the insight you gained from the experience.
- Know what you need to accomplish beforehand.
48.- Use a relational DB if your application is going to handle a large, persistent, interconnected set of data.
49.- Learn to communicate well in many “languages”: not just to your machine, but also to business partners – and maybe even pick up a foreign language too.
- It’s good for connections and for life.
54.- Think twice before implementing “temporary solutions”.
55.- Make GUI easy to use correctly and hard to use incorrectly.
- Anticipate errors and find ways to prevent them.
- It’s about the user’s experience, not your own.
56.- In projects, find ways to make the invisible visible.
57.- Message passing leads to better scalability in parallel systems.
58.- Write code that other people can easily understand.
59.- Using polymorphism in your classes and objects reduces the need for if/else statements, which results in smaller, safer code.
60.- QA is your friend, not your enemy.
61.- Version your releases.
62.- Make sure your source code clearly states what the program is doing.
63.- Learn about the build process. It’s an important part of development.
64.- Practice pair programming.
65.- Prefer domain-specific types over primitive types.
- They make the code more readable and less prone to errors in development.
67.- A professional takes personal responsibility for their career and their code.
68.- Use version control.
69.- Sometimes the best way to solve a problem is to step away from the computer and let the solution magically appear in your mind.
70.- Reading code is a good way to learn. Other people’s or your old code.
72.- Reinventing the wheel is a great way to develop your skills.
75.- If the code you wrote is truly horrifying, don’t try to fix. Delete it and start again.
76.- Apply the Single Responsibility Principle (SRP).
77.- If a client or team member requests a product change, don’t dismiss it outright even if you don’t agree. Ask why instead.
- That will lead to a more productive conversation and better results.
78.- If you’re doing the same thing over and over, try to find a way to automate it.
79.- Take advantage of code analysis tools.
80.- Write tests based on the desired functionality of your program, not incidental behavior.
83.- Testing takes time, but it ensures the quality of the end product. Do it.
85.- There are many benefits to collaborative work and pair programming.
86.- Sometimes fixing a mistake in the code leads to uncovering a hidden error.
87.- Write code with other programmers in mind.
88.- Learn to use Unix tools. Learn how to use the terminal.
89.- Use the right algorithm and data structure for the job.
- To do that, you need to understand them well.
90.- Have a good logging policy.
91.- Using the DRY principle helps you identify and repair performance bottlenecks.
92.- Testers and programmers should collaborate.
93.- Write code as if you had to support it for the rest of your life.
94.- Try to write “small” functions.
- Good tests act as documentation for the code they’re testing.
- They describe how the code works.
To be a good programmer, you have to care about the quality of the code.
Really, really discuss things with your customers before assuming you understand what they want.