97 Things Every Programmer Should Know Kevlin Henney

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you’ll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

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.

95. Good tests act as documentation for the code they’re testing.

• They describe how the code works.

96. To be a good programmer, you have to care about the quality of the code.

97. Really, really discuss things with your customers before assuming you understand what they want.