What are the characteristics of a good programmer? What traits and qualities distinguish a “good programmer” from an “average programmer”?<\/p>\n\n\n\n
In The Clean Coder<\/a><\/em>, Robert C. Martin, describes six qualities of a great programmer: 1) commitment to professional development, 2) discipline, 3) honesty, 4) professional communication, 5) time management, and 6) ability to work with others. Further, he shares the lessons learned the hard way, in the hopes that he can help the reader cultivate these traits and avoid making some of his mistakes.<\/p>\n\n\n\n In this article, you’ll learn about Martin’s six characteristics of a good programmer and how to develop them.<\/p>\n\n\n\n\n\n\n\n Many people (including developers) don\u2019t consider developers professionals, and this is partly because developers don\u2019t act like professionals. Robert Martin certainly didn\u2019t, when he started his career\u2014he missed deadlines, didn\u2019t test code before releasing it, and was such a bad leader<\/a> he got two people working under him fired. In this book, he shares the lessons learned the hard way, in the hopes that he can help you avoid making some of the same mistakes.<\/p>\n\n\n\n Here are the six skills and characteristics of a good programmer.<\/p>\n\n\n\n The first quality of a professional is a commitment to professional development. <\/strong>The hours you put into your day job rarely contribute to your professional development because at work, you often perform tasks and skills you already know how to do. Therefore, to be a professional, you should spend 20 hours per week of personal time on improving your programming skills and learning new ones.<\/strong><\/p>\n\n\n\n Use these hours to:<\/p>\n\n\n\n Professional quality #2 is discipline\u2014a collection of rules and standards around the act of coding. Everyone\u2019s discipline is personal and unique, and in this section, Martin shares his rules as inspiration.<\/p>\n\n\n\n Rule #1: Avoid doing damage, or when you can\u2019t, take responsibility<\/a>. <\/strong>To avoid doing damage:<\/p>\n\n\n\n Rule #2: Don\u2019t code while you\u2019re tired or worried.<\/strong> if you\u2019re not in a mental space in which you can concentrate, you\u2019re going to make mistakes and have to throw out most of your work. If you\u2019re tired or worried:<\/p>\n\n\n\n Rule #3: Don\u2019t wallow in writer\u2019s block.<\/strong> When you\u2019re feeling stuck<\/a>, try the following techniques to get past the block:<\/p>\n\n\n\n Rule #4: Avoid or minimize time pressure<\/strong>. The best way to deal with pressure is to avoid it. To do this:<\/p>\n\n\n\n No matter how well you employ the above techniques, you\u2019ve inevitably going to encounter pressure.<\/strong> When you are<\/em> under pressure, you should:<\/p>\n\n\n\n Rule #5: Avoid the \u201czone\u201d when you\u2019re working. <\/strong>The \u201czone\u201d is a state of mind that makes you feel <\/em>focused, productive, and invincible. In reality, you\u2019re not being more productive\u2014the zone is just a meditative state<\/a> in which parts of your brain shut off. You\u2019ll write more code, but because you\u2019ve got tunnel vision, you\u2019ll probably have to revise what you\u2019ve written so it fits into the larger structures. If you feel the zone approach, arrest its onset by taking a break or pair programming (you can\u2019t get hyper-focused on your code if you have to talk to someone.)<\/p>\n\n\n\n Rule #6: Be careful with music. <\/strong>Some people find music helps them concentrate; for others, it pushes them into the zone or distracts them.<\/p>\n\n\n\n Rule #7: Finish properly. <\/strong>Completely finish all tasks before declaring them \u201cdone\u201d and define \u201cdone\u201d as \u201cpassed all tests\u201d (for more on tests, see Quality #4). Don\u2019t accept partial completion for any reason, including if you\u2019re short on time.<\/p>\n\n\n\n Rule #8: Give and accept help.<\/strong> Programming is so hard it requires more than one brain. When people ask you for help, always give it, and if someone appears to be struggling, offer to pair program with her even if she doesn\u2019t ask. Similarly, always accept help when it\u2019s offered and ask for it when you\u2019re stuck. It\u2019s unprofessional to waste paid time staring at a screen when help is available.<\/p>\n\n\n\n Rule #9: Deal with interruptions efficiently and gracefully.<\/strong> You\u2019ll inevitably be interrupted while coding. Here are some strategies to quickly refocus on your work after an interruption:<\/p>\n\n\n\n The third professional quality is honesty, especially in the face of estimates and deadlines. Whenever you\u2019re programming something for someone, they always want to know when it will be done. Most of the time, you won\u2019t know exactly how long something will take, so you\u2019ll provide an estimate instead of a guaranteed commitment<\/strong>. Estimates aren\u2019t promises, so missing them isn\u2019t unprofessional, but professionals do <\/em>make their estimates as accurate as possible.<\/p>\n\n\n\n To that end, estimates aren\u2019t single numbers\u2014they\u2019re probability distributions. <\/strong>They factor in the following three <\/em>numbers:<\/p>\n\n\n\n When giving estimations, you should mention all three numbers. <\/p>\n\n\n\n There\u2019s always the possibility that people won\u2019t like your estimates and will want something done faster.<\/strong> If this happens, you have three options, not all of which are professional:<\/p>\n\n\n\n 1. Saying \u201cno.\u201d <\/strong>Saying no<\/a> has a bad rap, but it\u2019s the most professional thing to do in many situations. If it\u2019s impossible to get something done properly (adhering to discipline) by a certain deadline, and you say anything other than no, you\u2019re essentially lying.<\/p>\n\n\n\n 2. Saying \u201ctry.\u201d<\/strong> Never agree to try to do something in a time period shorter than your estimation. People often interpret \u201ctry\u201d to mean \u201cyes\u201d or \u201cmaybe,\u201d and both are lies because if you\u2019re a professional, you\u2019ve already been giving the project your full effort. There\u2019s nothing more you can do that would make things go faster.<\/p>\n\n\n\n 3. Saying \u201cyes.\u201d<\/strong> Only say yes when you know <\/em>you can meet a deadline because a yes is a commitment. If it\u2019s impossible to say yes to something in its current form, ask to change the parameters of the task so that you can <\/em>say yes. For example, you might ask to reduce the scope of the project so that there\u2019s less to do and you can finish in a shorter amount of time.<\/p>\n\n\n\n The fourth professional quality is communication, which is best done via testing. Tests ensure that a system works, but that\u2019s a happy bonus, not their main purpose. The most important purpose of a test is to communicate, specify, and document how a system is supposed to work and how it actually works.<\/strong><\/p>\n\n\n\n First, we\u2019ll look at acceptance testing, which is the main type of testing used for communication. Then, we\u2019ll look at how acceptance tests fit into the broader discipline of testing.<\/p>\n\n\n\n Acceptance tests are automatic tests that determine if the system behaves the way the business wants it to<\/strong>\u2014in other words, these tests specify what the system is supposed to do. Therefore, acceptance tests are the most unambiguous way to communicate about system requirements\u2014there\u2019s no possibility of misunderstandings or inaccurate assumptions.<\/p>\n\n\n\n Acceptance tests are co-written by clients and testers or QA (Quality Assurance)<\/strong>. The client will usually come up with the happy-path test and QA will write the unhappy-path tests that cover unusual scenarios. Then, it\u2019s the developers\u2019 job to add the tests to the system and build something that passes them.<\/p>\n\n\n\n There is a pyramid of testing that ensures a system works and that it behaves the way a business wants it to. We\u2019ll start at the bottom and move up:<\/p>\n\n\n\n Level #1: Unit tests<\/strong> test \u201cunits\u201d\u2014small sections of code. They cover as much of the code as possible (at least 90%) and their purpose is to specify the system. They run continuously and they\u2019re written before <\/em>the code by developers using test-driven development (TDD).<\/p>\n\n\n\n There are three rules to TDD:<\/p>\n\n\n\n TDD comes with several advantages:<\/p>\n\n\n\n Level #2: Component tests (which include acceptance tests) <\/strong>test individual components and business rules. They cover 50% of the system and run continuously, just like unit tests.<\/p>\n\n\n\n Level #3: Integration tests <\/strong>assess how well different components communicate (only relevant in multi-component systems). They cover 20% of the system, execute periodically, rather than continuously (they\u2019re time-consuming), and are written by the system\u2019s lead designer or system architect.<\/p>\n\n\n\n Level #4: System tests<\/strong> are the highest form of integration tests and they evaluate the whole system. They cover 10% of the system, execute infrequently (they\u2019re time-consuming), and are written by the technical leads or system architects.<\/p>\n\n\n\n Level #5: Manual exploratory tests <\/strong>are tests in which humans use the system to confirm how it works and report bugs. They cover 5% of the system, are executed infrequently (they\u2019re expensive), and aren\u2019t written (people explore the system however they like).<\/p>\n\n\n\n The fifth quality of professionals is that they manage their time well. There are three techniques professionals use for time management:<\/p>\n\n\n\n Technique #1: Attend meetings strategically. <\/strong>Meetings take up a lot of time and are expensive\u2014they require renting a location and paying for the time of the attendees. Therefore, professionals strive to make the best use of meetings by:<\/p>\n\n\n\n Technique #2: Use the Pomodoro technique<\/a>.<\/strong> Pomodoro is a way of reserving chunks of time for uninterrupted (and therefore productive) work. It works like this:<\/p>\n\n\n\n Technique #3: Avoid priority inversion.<\/strong> Priority inversion is when you avoid unpleasant work (work that\u2019s dull, frightening, or uncomfortable) by doing a lower-priority task instead (and often invent some justification). Do your tasks in the real priority order.<\/p>\n\n\n\n Technique #4: Avoid and abandon dead ends and messes.<\/strong> Abandon a course of action as soon<\/em> as<\/em> you realize it\u2019s going nowhere and try something else. Don\u2019t get mired in a mess before you officially hit the dead end\u2014turn back as soon as possible.<\/p>\n\n\n\n The final quality of professionals is the ability to work with others. In The Clean Coder<\/em>, Martin covers two elements of collaboration:<\/p>\n\n\n\n There are three techniques for effective collaboration<\/a>:<\/p>\n\n\n\nWhat Makes a Great Programmer?<\/h2>\n\n\n\n
1. Commitment to Professional Development <\/strong><\/h3>\n\n\n\n
2. Discipline<\/h3>\n\n\n\n
3. Honesty<\/strong><\/h3>\n\n\n\n
Defending Your Estimations<\/strong><\/h4>\n\n\n\n
4. Communication<\/h3>\n\n\n\n
Acceptance Testing<\/strong><\/h4>\n\n\n\n
The Pyramid of Tests<\/strong><\/h4>\n\n\n\n
5. Time Management<\/strong><\/h3>\n\n\n\n
6. Ability to Work With Others<\/strong><\/h3>\n\n\n\n
Collaborative Coding<\/h4>\n\n\n\n