97 things every programmer should know: personal notes

Last month I saw a book flying about the office, containing useful tips from developers. 97 suggestions from experienced developers. Amazon is still selling it, so I suggest you read it if work as a software developer or you occasionally dip into coding: 97 Things Every Programmer Should Know: Collective Wisdom from the Experts

I’ve finished reading it, and I took some notes while reading. Some concepts and suggestions were obvious, as I hear them many times from the community (blogs, conferences, colleagues) or I’ve already personally experienced them. I’ll paste those my notes here, with the hope that you can find something valuable from looking through them.

  1. Avoid the technical debt;
  2. Watch the users (clients) using your product;
  3. Automate coding standards;
  4. Write simple objects with a single responsibility containing similarly simple, focused methods with descriptive names;
  5. Before refactoring: learn from existing system mistakes;
  6. The style or the structure of the code does not meet your personal preference is not a valid reason for restructuring
  7. Don’t share few lines of codes among components if you create more dependencies (it’s like tieing the shoelaces of each foot to the other);
  8. Use frameworks to concentrate on business-domain code and less infrastructure code. (Obvious, but I liked the concept written in one-line)
  9. Buying may be cheaper than building, but we aware of architectural mismatches (surrounding infrastructure, data model that can lead to hacks and workaround what will make the code more complex than necessary) and different lifecycles (upgrading one component can be a problem);
  10. Use model objects (entities) instead of primitive data types or array. Suggestion:  data mapper;
  11. The purpose of code reviews should be to share knowledge and establish common coding guidelines, not only for code quality and less defect rate;
  12. Various coding suggestions: use small scope for variables, use empty line to separate sections, move nested into separate methods, Prefer narrow interfaces, Prefer class invariants (set the properties via constructor) then setters (a setter breaks the object invariance);
  13. Make sure that your comments clarify your code but do not obscure it. Sprinkle code with comments;
  14. Try to express as much as possible through code. rename, move and avoid commenting;
  15. Keep learning to stay marketable;
  16. Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened;
  17. Learn a new language every year;
  18. It’s duty to the caller to call with right parameters;
  19. A business logic exception (e.g. transfer money when you have no funds) should be a separate class from the exception class thrown fpr technical exceptions (e.g. database, or wrong method call);
  20. Use domain-specific languages (DSLs);
  21. Don’t be afraid of breaking things: “you need to break eggs to make an omelet”;
  22. Work on projects you like, or you won’t learn;
  23. Make test for open source code, you’ll lear a lot;
  24. There are barrier to improvement, they are only perceived barriers;
  25. Act like a professional: do not work more then 30h a week: prepare, effect, observe, reflect, and change. I like this one, but who pays you normally doesn’t 🙂
  26. Write code because it adds value, not because it amuses you.
  27. If you don’t need it right now, don’t write it right now. That’s the YAGNI principle, a common pitfall as we developers enjoy doing what they feel like, that normally does not match the business requirements;
  28. Definition of commitment: a promise to deliver specified functionality at a certain level of quality by a certain date or event;
  29. If your code needs comments, consider refactoring it so it doesn’t. Strive for good names;
  30. Use clear class naming. E.g. name a class Velocity_In_Meters_A_Seconds, not only Velocity when convenient and clarity is important;
  31. Limit the user input using choice lists or calendars (for dates). It’ll be easier than parse the data and handle the errors;
  32. Log the validation errors to have an user feedback about the interface;
  33. A test should be readable, and explain what the tested class do;
  34. – “Testing alone isn’t sufficient, but it is necessary. Testing is the engineering rigor of software development.” Neal Ford
  35. First make it work, then make it work fast. But don’t make it work slowly since the beginning if it can be easily avoided (example, calculating the lenght of an invariant array or string as a condition of a loop);
  36. “Write code as if you had to support it for the rest of your life” Yuriy Zubarev

I was expecting to find something mentioning the importance of knowing well your tools. As an example, not knowing how to use an aggregate function of your db server will mean spending lots of time writing code to solve a problem that you could have efficiently solved in a few minutes with a GROUP BY query;

Which one do you agree the most with ? Any other useful suggestion ?