This may suit the author's style and that's great. But I strongly disagree with several of these. Calling them "rules for good code" just seems like a lot of hubris.<p>> 0. Use Git and Github. I'm not going to dignify this with a non-zero number. If you aren't using git and github.com then you are already making excuses for doing it wrong<p>Okay? I'm glad you found a tool that works for you, but there are plenty of others. And he's not saying "use source control". He's literally saying that no other tool is good enough.<p>> 2. Make it Open Source<p>I don't wanna. Doesn't make my code bad.<p>> 3. Always Be Making APIs<p>This is extremely web centric. For web specifically there's a case to be made here, but he certainly didn't make it<p>> 4. Don't Document the Code<p>I guess don't ever work on a team of more than two then.<p>> 6. Better is the Enemy of the Good [...] Do not optimize your code. Aim for "OK" and then stop<p>That may work for your project, and maybe every project you've worked on. But it won't work for an airplane's safety systems.<p>> 9. Make Portable Code [...] Your code should run on every box there is<p>Why? Everything else he's talking about is very web-centric, so let's assume that. Don't you control your whole stack from metal to OS then? Why bother making it super portable when you know everything about the system that will be running the code? You have all of the same upsides of programming for a game console. You're in one of the few environments where you can use <i>all</i> of your platform's features. Use them!<p>> 10. Lie to Your Management [...] When they demand schedules, plannings, designs, and architectures, lie to them<p>I don't even know where to start here.