I've been reading the book The Pragmatic Programmer for a while and here's a summary of what I learned from this book.
- Care about your craft
- There is no point in developing software unless you care about doing it well.
- Never run on auto-pilot
- Constantly be thinking, critiquing your work in real time
- You have agency
- Make time to study new stuff that look interesting.
- Instead of excuses, provide options
- Don't live with broken windows
- Neglect accelerates the rot faster than any other factor.
- Keep an eye on the big picture
- Constantly review what's happening around you, not just what you personally are doing.
- Great software today is often preferable to perfect software tomorrow
- Invest regularly in your knowledge portfolio
- Learn a new language
- Critically analyze what you read and hear
- It's both what you say and the way you say it
- The more effective you communicate, the more influential you become.
- Build good documentation in
- It's easy to produce good-looking documentation from the comments in source code, and we recommend adding comments to modules and exported functions to give other developers a leg up when they come to use it.
- Good design is easier to change than bad design
- Decoupling is good because by isolating concerns we make each easier to change.
- Single responsibility principle is useful because a change in requirements is mirrored by a change in just one module.
- Naming is important because good names make code easier to read, and hence make code easier to change.
-
DRY -- Don't Repeat Yourself
- save you from having to rewrite logic
- prevent you from having to rewrite code when you have to make changes
- avoid human error as you will only be modifying one piece
- make code easier to read
Make a point of reading other people's source code and documentation, either informally or during code reviews. What you're trying to do is foster an environment where it's easier to find and reuse existing stuff than to write it yourself.
Top comments (0)