![\"git](\"https:\/\/mshaeri.com\/blog\/wp-content\/uploads\/2023\/11\/vcs.jpg\")
<\/a>
<\/p>\n\n\n\n
2. Good Enough Software<\/h2>\n\n\n\n
Seeking perfection often prolongs projects indefinitely. If you don\u2019t know when to stop, you’ll end up in over-embellishment and over-refinement. Instead, aim for “good enough” and iterate. Deliver value early and often. Write code that works, prove it by writing tests, and ensure they are executed automatically. However, the phrase \u201cgood enough\u2019\u2019 does not imply sloppy or poorly produced code. (Topic 5, Good-Enough Software, Page 11)
<\/p>\n\n\n\n
3. Refactoring<\/h2>\n\n\n\n
Refactoring isn’t about big changes. Avoid starting a huge refactor. It’s more like tidying up your garden while weeding as a day-to-day process, not a major change. It’s the art of making small, low-risk changes to keep the code clean and efficient. And, last but not the least, unit testing is your trusty sidekick for keeping the code’s behavior consistent and dependable during refactoring. (Topic 40, Refactoring, Page 209) <\/p>\n\n\n\n
<\/a>4. Don’t blame, just fix it
<\/h2>\n\n\n\n
Sometimes, you will find lousy code that someone else wrote. Sometimes, you will find bad code that you wrote some time ago. Pragmatic programmers don’t say, “I didn’t write this, so I will not fix it” but do something about it and open a debate in a team about why. Avoid spending time and effort in assigning fault to the creator. The responsibility of fixing a bug remains, it doesn\u2019t really matter whether the bug is your fault or someone else\u2019s. It is still your problem.(Top 20, Debugging, Page 89)
<\/p>\n\n\n\n
5. Broken Window Theory<\/h2>\n\n\n\n
The Broken Window Theory suggests that if something is broken, others will break it even more in the future. As a pragmatic programmer, you should fix all significant problems you find in the system while working on it. Don’t continue walking on the wrong path the last developer walked on. Don\u2019t be a slave to history. Don\u2019t let existing code dictate future code. I’ve recently worked on a legacy code-base where the original coder used incredibly poor variable names. Whenever I encountered these confusing variables during development, I took the initiative to rename them. Gradually, I managed to update the entire code-base, significantly improving the clarity of variable naming. However, I must admit that my initial plan was to rectify all names at once, which contradicted the refactoring principle of making incremental changes as a day-to-day activity rather than undertaking a massive overhaul. (Topic 3, Software Entropy, Page 7) <\/p>\n\n\n\n
<\/a>6. Stay Up To Date<\/h2>\n\n\n\n
Continuous learning is essential in software development world. Stay updated with new tools, technologies, and best practices. Learn at least one programming language, tech stack or framework every year. It doesn\u2019t matter whether you ever use any of these technologies. Once you feel comfortable with some new language or bit of technology, move on, learn another one. Investing in your skills yields substantial returns in your career advancement. ( Tip 9, A Pragmatic Philosophy, Page 15)<\/p>\n\n\n\n
<\/a>7. DRY (Don’t Repeat Yourself)<\/h2>\n\n\n\n
Try not to repeat the codes, and when you notice duplication, refactor it into a shared function or module, because redundant code is more complex to maintain, and duplication is the root of all evil. DRY is not limited to code. Wherever you have to change code and documentation, or a database schema and a structure that holds it, your code isn\u2019t DRY. (Topic 9, DRY\u2014The Evils of Duplication, Page 30)<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>
8. Programming By Coincident<\/h2>\n\n\n\n
Understand your code deeply; don’t rely on coincidental successes. If you\u2019re not sure why it works, you won\u2019t know why it fails. Make sure you know why your code works, not just that it works. Understanding the underlying mechanisms and environment in which the code works ensures confidence in the reliability and efficiency of your solutions. (Topic 38, Programming by Coincidence, Page 197) <\/p>\n\n\n\n
<\/a>9. Keep Your System Orthogonal<\/h2>\n\n\n\n
Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface. Enhanced productivity and reduced risks through modular, reusable, and isolated components are benefits of an orthogonal system. Three most important techniques to maintain your system orthogonal during development are :<\/p>\n\n\n\n
- Keep your code decoupled<\/li>
- Avoid global data<\/li>
- Avoid similar functions<\/li><\/ul>\n\n\n\n
(Topic 10, Orthogonality, Page 39) <\/p>\n\n\n\n
10. Be a Good Listener<\/h2>\n\n\n\n
To help your users, you’ll need to understand them first. Be careful when others speak, and ask good questions. When engaging with individuals such as product managers, developers, and business analysts, remain attentive and discerning to extract meaningful insights. The art of posing insightful questions plays a key role in uncovering comprehensive information, enabling you to craft solutions that resonate deeply with user requirements and expectations. Good questions comes after good listening, and well understanding. (Chapter 1, A Pragmatic Philosophy, Page 22)<\/p>\n\n\n\n
![\"If](\"https:\/\/mshaeri.com\/blog\/wp-content\/uploads\/2023\/11\/Active-Listening-Featured-Image-1024x638.jpg\")
<\/a>If you don\u2019t listen to them, they won\u2019t listen to you<\/figcaption><\/figure><\/div>\n\n\n\n 11. Take Responsibility<\/h2>\n\n\n\n
Before you explain limitations or problems, assess yourself: talks to the rubber duck beside your laptop, evaluate the validity of your reasoning, anticipate your boss’s response, consider alternatives, and offer solutions rather than excuses. need to spend more time? need to learn some technique or technology? Don\u2019t be afraid to ask, or to admit that you need help. (Chapter 1, A Pragmatic Philosophy , Page 4)<\/p>\n\n\n\n