6 ms·

Top 6 List of Programming Top Lists

153 points by urbannomad 15y ago

fosk 15y ago
I'd add a quote from Jamie Zawinski: "At the end of the day, ship the fucking thing!" in "Top 10 Things Ten Years of Professional Software Development Has Taught Me"
- kunjaan 15y ago
  Reminds me of the http://programming-motherfucker.com/ http://programming-motherfucker.com/
- statictype 15y ago
  Another good one from him: "You're not paid to write code. You're paid to ship products."
thisisblurry 15y ago
There couldn't be four more lists to add? A-he-he-he-he.
edw519 15y ago
Oh, what the heck, here are mine... 1. Start with the answer, then work back. 2. It worked. You changed something. It doesn't work. It's probably something you did. 3. The answer is always "yes". Sometimes, "yes, but", but always "yes". 4. Never write the same line of code twice. 5. All names (variables, functions, routines, etc.) should accurately describe what they represent as closely as possible. i.e. an intelligent user should be able to read your code and get a fairly good idea what it does. 6. No variable name should be fully self-contained within another variable name. 7. Indent however many spaces you want and use white space however you want. Who gives a shit. 8. Shop standards only count if they are published. 9. Only enter your IDE if you have actually have something to code. Otherwise go back to your pencil/paper/whiteboard (or whatever you use for analysis and design) and don't come back until you're ready. 10. Prototype something and let the user rip it to shreds. Funny how much less bashful they become when they have something to critique. It's much easier to criticize something that exists than to imagine something that doesn't.
- pama 15y ago
  These are wonderful, thank you. What is your rationale for item 6?
  - edw519 15y ago
    for(a=0;a<aa;a++){ if(bbb[a]<bbbb[aa]){ bbb[aa]=bbbb[aaa] }else{ bbbb[aaa]=bbb[aa] } } I'll be out of jail in 30 days. The original programmer will be fine once the stitches are removed. Actually, all kidding aside, yesterday I enhanced a 1700 line program with these variables: Cust CustCmmts CustComments DelCmmts CustNbr DelDate Cmmts CustID Comments CustDel Del The variables "Cust", "Cmmts", "Comments", and "Del" should have different names. What are they? I spent half a day just trying to figure out what everything was, one line at a time. You can't globally locate, edit, cut, paste, or change without fucking up everything else. (And please don't ask me to use a fancier IDE. Just name your variables so the next guy doesn't have to suffer.)
    - numeromancer 15y ago
      Just structure your data so the next guy doesn't have to suffer. Cust.Name Cust.Cmmt (commit?) Cust.Comments Cust.Number etc.
- swah 15y ago
  Meh, just downvoted accidentally on the iPhone.
numeromancer 15y ago
1. Beware the enthusiastic newcomer who wants to redo everything The Right Way. 2. Don't make standards so stupid that no one can follow them and be sane. 3. Make a scratch directory for small throw-away tests. Use it often. 4. Avoid auto-doc systems that require elaborate comment formatting. 5. Never allow failure to look like success. 6. Make everything easily testable. 7. Make as much as possible configurable, and make all configurations automatable. 8. Know what your compiler does to your code; if it will make your code clearer and easier to change, do it yourself. 9. Substitution is the key to modularity. 10. Study theory, and practice; theory gives meaning to practice, and practice gives reality to theory. 11. A bit of wisdom always sounds more profound when formatted as a chiasma, and a chiasma always sounds more profound with a bit of wisdom. 12. Never stop at 10.
- amirhhz 15y ago
  Interesting - what's your objection to auto-doc systems (4)? I assume you mean things like javadocs and python docstrings, which I make use of a lot and people I code with find helpful, too.
  - numeromancer 15y ago
    My objection is not to auto-doc systems in general. Note the restrictive clause after the noun.
mnazim 15y ago
Something I always tell newcomers/freshers(and also remind myself) 0. Learn the basics first(and keep hitting F5 on them occasionally), then start at 1. But there are many 1's and many are correct; choose your own 1, heck define a new 1 for yourself.
Jun8 15y ago
Almost all of these are gold and should be framed and hung in every cuce and meeting room. But the following three should be tattooed to the forehead of each manager and executive: * Process is no substitute for thinking. * If everything is equally important, then nothing is very important. * "Complex problems require complex solutions". NOT!
- billswift 15y ago
  True, but one of the reasons it is often mistaken for thinking, or managers try to force others to use it instead of thinking, is that "process" or "rules" can substantially improve the output of novices and other lower competence people. The biggest problem with rules is that they degrade the usefulness of experts to the level of anyone who can effectively follow the process; which sort of undercuts the value of having experts in the first place.
pnguyen 15y ago
It's more of a bottom list but this one is pretty good too. Coding languages that never took off http://www.focus.com/briefs/software-development/12-coding-languages/ http://www.focus.com/briefs/software-development/12-coding-l...
geebee 15y ago
I liked the "Top 10 Signs Your Software Project Is Doomed" I'd add a few more... these mainly relate to the isolation of a development team from the end users and/or purpose of the software application. * End users communicate only with Business Analysts, never with developers. * Developers become aware of end user needs only through functional or technical specifications written by business analysts. * Architects who do not write code have complete authority to dictate technology choices to developers * Developers are unable to describe what the software does from a user's point of view. * Developers are unable to explain why they are using a particular technology, other than that it was chosen as a standard for the project.
vvnraman 15y ago
I couldn't help but observe that these lists, read independently, would apply to any aspect of life and not only to Programming. Sure we need to replace the technical jargon with their generic counterparts.

153 points by urbannomad 15y ago

fosk 15y ago

I'd add a quote from Jamie Zawinski: "At the end of the day, ship the fucking thing!" in "Top 10 Things Ten Years of Professional Software Development Has Taught Me"

kunjaan 15y ago
Reminds me of the http://programming-motherfucker.com/ http://programming-motherfucker.com/
statictype 15y ago
Another good one from him: "You're not paid to write code. You're paid to ship products."

thisisblurry 15y ago

There couldn't be four more lists to add? A-he-he-he-he.

edw519 15y ago

Oh, what the heck, here are mine... 1. Start with the answer, then work back. 2. It worked. You changed something. It doesn't work. It's probably something you did. 3. The answer is always "yes". Sometimes, "yes, but", but always "yes". 4. Never write the same line of code twice. 5. All names (variables, functions, routines, etc.) should accurately describe what they represent as closely as possible. i.e. an intelligent user should be able to read your code and get a fairly good idea what it does. 6. No variable name should be fully self-contained within another variable name. 7. Indent however many spaces you want and use white space however you want. Who gives a shit. 8. Shop standards only count if they are published. 9. Only enter your IDE if you have actually have something to code. Otherwise go back to your pencil/paper/whiteboard (or whatever you use for analysis and design) and don't come back until you're ready. 10. Prototype something and let the user rip it to shreds. Funny how much less bashful they become when they have something to critique. It's much easier to criticize something that exists than to imagine something that doesn't.

pama 15y ago
These are wonderful, thank you. What is your rationale for item 6?
- edw519 15y ago
  for(a=0;a<aa;a++){ if(bbb[a]<bbbb[aa]){ bbb[aa]=bbbb[aaa] }else{ bbbb[aaa]=bbb[aa] } } I'll be out of jail in 30 days. The original programmer will be fine once the stitches are removed. Actually, all kidding aside, yesterday I enhanced a 1700 line program with these variables: Cust CustCmmts CustComments DelCmmts CustNbr DelDate Cmmts CustID Comments CustDel Del The variables "Cust", "Cmmts", "Comments", and "Del" should have different names. What are they? I spent half a day just trying to figure out what everything was, one line at a time. You can't globally locate, edit, cut, paste, or change without fucking up everything else. (And please don't ask me to use a fancier IDE. Just name your variables so the next guy doesn't have to suffer.)
  - numeromancer 15y ago
    Just structure your data so the next guy doesn't have to suffer. Cust.Name Cust.Cmmt (commit?) Cust.Comments Cust.Number etc.
swah 15y ago
Meh, just downvoted accidentally on the iPhone.

numeromancer 15y ago

1. Beware the enthusiastic newcomer who wants to redo everything The Right Way. 2. Don't make standards so stupid that no one can follow them and be sane. 3. Make a scratch directory for small throw-away tests. Use it often. 4. Avoid auto-doc systems that require elaborate comment formatting. 5. Never allow failure to look like success. 6. Make everything easily testable. 7. Make as much as possible configurable, and make all configurations automatable. 8. Know what your compiler does to your code; if it will make your code clearer and easier to change, do it yourself. 9. Substitution is the key to modularity. 10. Study theory, and practice; theory gives meaning to practice, and practice gives reality to theory. 11. A bit of wisdom always sounds more profound when formatted as a chiasma, and a chiasma always sounds more profound with a bit of wisdom. 12. Never stop at 10.

amirhhz 15y ago
Interesting - what's your objection to auto-doc systems (4)? I assume you mean things like javadocs and python docstrings, which I make use of a lot and people I code with find helpful, too.
- numeromancer 15y ago
  My objection is not to auto-doc systems in general. Note the restrictive clause after the noun.

mnazim 15y ago

Something I always tell newcomers/freshers(and also remind myself) 0. Learn the basics first(and keep hitting F5 on them occasionally), then start at 1. But there are many 1's and many are correct; choose your own 1, heck define a new 1 for yourself.

Jun8 15y ago

Almost all of these are gold and should be framed and hung in every cuce and meeting room. But the following three should be tattooed to the forehead of each manager and executive: * Process is no substitute for thinking. * If everything is equally important, then nothing is very important. * "Complex problems require complex solutions". NOT!

billswift 15y ago
True, but one of the reasons it is often mistaken for thinking, or managers try to force others to use it instead of thinking, is that "process" or "rules" can substantially improve the output of novices and other lower competence people. The biggest problem with rules is that they degrade the usefulness of experts to the level of anyone who can effectively follow the process; which sort of undercuts the value of having experts in the first place.

pnguyen 15y ago

It's more of a bottom list but this one is pretty good too. Coding languages that never took off http://www.focus.com/briefs/software-development/12-coding-languages/ http://www.focus.com/briefs/software-development/12-coding-l...

geebee 15y ago

I liked the "Top 10 Signs Your Software Project Is Doomed" I'd add a few more... these mainly relate to the isolation of a development team from the end users and/or purpose of the software application. * End users communicate only with Business Analysts, never with developers. * Developers become aware of end user needs only through functional or technical specifications written by business analysts. * Architects who do not write code have complete authority to dictate technology choices to developers * Developers are unable to describe what the software does from a user's point of view. * Developers are unable to explain why they are using a particular technology, other than that it was chosen as a standard for the project.

vvnraman 15y ago

I couldn't help but observe that these lists, read independently, would apply to any aspect of life and not only to Programming. Sure we need to replace the technical jargon with their generic counterparts.