5 ms·
I don't know. Unless anyone actually tells me this person is in fact a "superstar developer" I may not believe it. Rule 3: Don’t take time to document your cod
by dbz 17y ago
I don't know. Unless anyone actually tells me this person is in fact a "superstar developer" I may not believe it.
Rule 3: Don’t take time to document your code, or add little comments explaining potential pitfalls in modifying some of the less clear statements you’ve introduced. You don’t need them, you wrote the code.
Gosh. I understand the rule "Code is twice as hard to debug as it is to code, so never code as cleverly as possible" because one wont be able to debug his or her own code, but saying no comments? I do NOT know the structure of the program I made five years ago. If there were no comments, it would take me a little while to edit something- build in a feature, ect. Who the fuck says you need to stop documenting to become a superstar developer? Not even that. It's one of the three rules to becoming a superstar developer? I can't believe it is true. I see so many things wrong with the statement.
- Freebytes 17y agoWhile I know this work was satire, in some cases, it is advised to leave out comments in code. While some comments are necessary, they should exist merely to state what the code does not. The best written code often explains itself through easy to read layout, variable naming, and intelligent function and class development procedures. If the code already says what it is doing, there is no reason to repeat it in a comment. A good programmer is always trying to write code like this. As for having a set of rules to become a superstar developer... you would need to actually be a superstar developer to make the rules. If they are extremely rare, we should rarely have any rules because there would be few people posting such rules. Therefore, I am skeptical of any such lists unless they are from someone I recognize as extremely gifted prior to the writing of the rules.
- moconnor 17y agoI think you've missed the satirical nature of the article...
- Proleps 17y agoI think you missed something. Postscript for the naive: This post is a mild satire on programming in teams. These three rules, while undoubtedly effective, are evil. They harm overall project progress for your own benefit. They don’t make you a better programmer intrinsically, only compared to the rest of your team. You may, like I and countless others, have done something like this completely innocently in the past, when you didn’t know better. Now you know better.
- dbz 17y agoAwww Damn. I hate when I'm the idiot =/