Quora Feeds
Active Member
Jessica Pennell
I have a simple method that has never once failed me for separating the wheat from the chaffe.
Good programmers throw away their own code.
Good programmers never throw away anyone else’s code.
You can derive other rules from the situation at hand. If a programmer isn’t familiar with version control, for instance, you’ll see projects littered with zip files (or if you’re lucky tarballs), or you’ll see large binary files (other than one time inclusions of files that aren’t likely to change) checked into version control. You’ll even see other repos checked in. You’ll work all afternoon on a few lines of code, and then you’ll close a window (because you really just wanted to know how to solve a problem) without saving, and their faces will go white. You’ll see them wrap incredibly complicated tools with a million arguments instead of opening them up and pulling a simple method out of them, and you’ll see them reinventing wheels when wrapping a simple, robust, maintained tool would do the job.
Generally, there’s a humility and deep respect for the works of even a novice programmer. Everything that’s written by anyone else is, to a good programmer, a solved problem, which can be trusted. They have this confidence and faith in their environment, not out of naivete, but because they know that if anything goes wrong - no, this is computers, when things inevitably go wrong - the failure condition will point out exactly what is going wrong and what needs to be fixed. They know that if they preserve contextual information and respect the thinking of others, that that information will allow the code’s context and operating environment to be reproduced under controlled circumstances effortlessly. If you see a good programmer commenting, at all, about another programmer’s coding style, rather than adopting it, they are a bad programmer.
At the same time, an experienced programmer has a deep mistrust of their own code. This is possible, because a good programmer knows how to quickly re-derive and re-implement things. Good programmers recognize patterns as they write anything, and they can apply these patterns and algorithms often to generate a lot of code rather than writing it out by hand. A good programmer loves version control, and loves copying, pasting, modifying, reducing, and testing. To a good programmer, the code of others is like a cup, and their own code is like the space inside the cup, to be filled and emptied as needed. Anything deleted can be recovered, and anything recovered can be deleted when it is no longer needed.
By and large though, the best programmers will end up realizing that both these rules are only possible and maintainable if they write tests. Tests let you refactor your own code quickly, and tests let you know whether others code is safe to use without reading it, when it’s a good idea to read it anyway, and how to implement their work seamlessly into your own. So in addition to the two rules for good programmers, I’ll add one more.
Good programmers write documentation, but the best programmers write tests.
One last little tidbit, when a good programmer does write documentation, their documentation is written in such a way that capturing tools such as doxygen will have a very easy time.
Actually one more tidbit. When programmers do need to edit the work of others, they recognize “seams”, or areas where the functionality of the code of others can be modified without actually changing the code itself. Often the only changes a good programmer will ever make to anyone else’s code are just two things : access control, to expose private or protected variables, and comments added, often with the programmer’s initials and a date. And both these things are always done with at least some way of communicating with the author. Even if the author is dead or has left the company, a programmer’s own notes are sufficient to compare to later when the author’s work is better understood, and once tests are written patch files can be written to restore access control. But otherwise, good programmers use seams and streams to edit the code of others. The actual source is sacred, and often a compiled binary is just as good as the real thing.
See Questions On Quora
Continue reading...
I have a simple method that has never once failed me for separating the wheat from the chaffe.
Good programmers throw away their own code.
Good programmers never throw away anyone else’s code.
You can derive other rules from the situation at hand. If a programmer isn’t familiar with version control, for instance, you’ll see projects littered with zip files (or if you’re lucky tarballs), or you’ll see large binary files (other than one time inclusions of files that aren’t likely to change) checked into version control. You’ll even see other repos checked in. You’ll work all afternoon on a few lines of code, and then you’ll close a window (because you really just wanted to know how to solve a problem) without saving, and their faces will go white. You’ll see them wrap incredibly complicated tools with a million arguments instead of opening them up and pulling a simple method out of them, and you’ll see them reinventing wheels when wrapping a simple, robust, maintained tool would do the job.
Generally, there’s a humility and deep respect for the works of even a novice programmer. Everything that’s written by anyone else is, to a good programmer, a solved problem, which can be trusted. They have this confidence and faith in their environment, not out of naivete, but because they know that if anything goes wrong - no, this is computers, when things inevitably go wrong - the failure condition will point out exactly what is going wrong and what needs to be fixed. They know that if they preserve contextual information and respect the thinking of others, that that information will allow the code’s context and operating environment to be reproduced under controlled circumstances effortlessly. If you see a good programmer commenting, at all, about another programmer’s coding style, rather than adopting it, they are a bad programmer.
At the same time, an experienced programmer has a deep mistrust of their own code. This is possible, because a good programmer knows how to quickly re-derive and re-implement things. Good programmers recognize patterns as they write anything, and they can apply these patterns and algorithms often to generate a lot of code rather than writing it out by hand. A good programmer loves version control, and loves copying, pasting, modifying, reducing, and testing. To a good programmer, the code of others is like a cup, and their own code is like the space inside the cup, to be filled and emptied as needed. Anything deleted can be recovered, and anything recovered can be deleted when it is no longer needed.
By and large though, the best programmers will end up realizing that both these rules are only possible and maintainable if they write tests. Tests let you refactor your own code quickly, and tests let you know whether others code is safe to use without reading it, when it’s a good idea to read it anyway, and how to implement their work seamlessly into your own. So in addition to the two rules for good programmers, I’ll add one more.
Good programmers write documentation, but the best programmers write tests.
One last little tidbit, when a good programmer does write documentation, their documentation is written in such a way that capturing tools such as doxygen will have a very easy time.
Actually one more tidbit. When programmers do need to edit the work of others, they recognize “seams”, or areas where the functionality of the code of others can be modified without actually changing the code itself. Often the only changes a good programmer will ever make to anyone else’s code are just two things : access control, to expose private or protected variables, and comments added, often with the programmer’s initials and a date. And both these things are always done with at least some way of communicating with the author. Even if the author is dead or has left the company, a programmer’s own notes are sufficient to compare to later when the author’s work is better understood, and once tests are written patch files can be written to restore access control. But otherwise, good programmers use seams and streams to edit the code of others. The actual source is sacred, and often a compiled binary is just as good as the real thing.
See Questions On Quora
Continue reading...
