Principles every programmer should follow for success

<p>What makes a great programmer? Is it the capability to solve problems? Or the passion for coding? In truth, great programmers know that people matter. Whether you work professionally as a developer or you’re an enthusiast coder, you’re likely to be coding with and for other people. Being a great programmer isn't just about solving problems, but making sure that the solution is simple and that others can understand, maintain and extend it.</p><p>Let’s be honest, programming is hard. Regardless if you just started coding or you’re an experienced programmer, there’s always room for improvement. In the classic book <a href="http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/">The Pragmatic Programmer</a>, Andrew Hunt and David Thomas formulated a list of principles every programmer should follow. Here are our favorite ones:</p><h2 id="don-t-live-with-broken-windows">Don’t live with broken windows</h2><p>According to The Broken Window Theory, <em>“If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge. Soon more windows will be broken…”</em> Don't leave "broken windows" in your code. Bad designs or poor code should be fixed as soon as it's discovered.</p><h2 id="good-enough-software">Good enough software</h2><p>Write software that is good enough for your users and other maintainers. This doesn’t mean writing poor code, but knowing when to stop. Be consistent with your users' requirements and don’t try to add new frivolous features or over polish. Good software now is better than great software later.</p><h2 id="invest-in-your-knowledge-portfolio">Invest in your knowledge portfolio</h2><p>New techniques, languages, and environments are developed every day. Keep yourself updated. Learn at least one new language or framework every year. Read a technical book each semester. Diversify your knowledge. And don’t forget to be social! Attend conferences. Engage in a programming community. Just never stop learning.</p><h2 id="don-t-repeat-yourself">Don’t Repeat Yourself</h2><p>The DRY principle speaks for itself: <em>“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”</em> Create an environment where it's easy to read and reuse things.</p><h2 id="everything-s-reversible">Everything’s reversible</h2><p>As your project evolves, the user’s requirements might change. Keep in mind that there are no final decisions. Things can (and probably will) change, so be prepared. To avoid future headaches, minimize coupling, unnecessary dependencies are expensive to maintain and tend to be unstable. Maintain a flexible code, architecture and deployment.</p><h2 id="have-a-debugging-mindset">Have a debugging mindset</h2><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/fe/71/fe71aca7-b5d2-4467-9911-8f4fb422d641/rubber-duckie.png" class="kg-image" alt="buttons-example"><figcaption>Rubber Ducking</figcaption></figure><p>No one writes perfect software, so debugging takes a lot of every developer’s time. When debugging, concentrate on fixing the problem, not the blame. Start by gathering all data needed to reproduce the reported bug. If you can’t find the cause, try Rubber Ducking, this technique encourages you to explain the problem to someone else (or a rubber duck), by verbalizing the problem you may gain new insight. When finding the bug, don’t just fix it, always modify the automated tests to check for the bug, no matter how trivial it may seem. This way you’ll make sure that if the bug repeats itself you'll be aware.</p><h2 id="test-ruthlessly">Test ruthlessly</h2><p>Test early, often and automatically. After writing your tests, ask yourself: did I test all the boundary conditions? Create a safety net with regression tests — tests that compare the output of the current test with previous known values. As you develop, run your tests to ensure nothing has broken. There are many kinds of software testing, make sure you cover the most of the types: unit testing, integration testing, validation and verification, resource exhaustion, performance and usability.</p><h2 id="to-comment-or-not-to-comment">To comment or not to comment</h2><blockquote>"Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?” — Steve McConnell</blockquote><p>Most high-level languages allow you to write code that’s pretty readable. In general, the code should already explain how something is done and the goal, so before commenting evaluate if it’s completely necessary or if it's redundant.</p><h2 id="refactor-often">Refactor often</h2><blockquote>"Things change, requirements drift, and your knowledge of the problem increases. Code needs to keep up."</blockquote><p>Software development is a continuous cycle, as your code evolves you need to rethink your previous decisions. Maybe you discovered a duplication (violating the DRY principle) or you realized the design could be more decoupled. </p><p>Here are some tips offered by Martin Fowler:</p><ol><li>Don't try to refactor and add functionality at the same time.</li><li>Make sure you have good tests before you begin refactoring and run them as often as possible.</li><li>Take short, deliberate steps. If you keep your steps small, and test after each step, you will avoid prolonged debugging</li></ol>