profile picture

97 Things Every Programmer Should Know Kevlin Henney

July 15, 2016 - 1161 words - 6 mins Found a typo? Edit me
software general wisdom

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.

  1. Good tests act as documentation for the code they’re testing.
  • They describe how the code works.
  1. To be a good programmer, you have to care about the quality of the code.

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

250 pages