Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better.
I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple".
The problem of overcoming bad habits is a really tough one.
In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming.
I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors.
If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.
Regarding performance tests: maybe just try to write code that works the first time, see how big a chunk of code you can write at once and still have it work the first time. And when it doesn't work, don't just fix it, analyze what happened and learn from it specifically to avoid making similar mistakes in the future. You'll acquire (I'm guessing) a list of things to avoid that eventually become good habits, enabling you to get stuff done faster and concentrate on more important things. I guess it's mainly a matter of avoiding the avoidable mistakes.
You've described, very roughly, the basis of the SEI's "Personal Software Process". Keep records of your errors, study what you do wrong, change your personal process to drive them out, repeat.
Have a look at the Joel test. It's outdated, and might be a little controversial, but it's it list of ways to fix "stupid shit".
I don't have a copy of "Code Complete", but from what I've heard it's a similar deal. XP arguably eliminates a lot of stupid shit, but arguably introduces a lot of stupid shit at the same time (as do many dogmatic processes).
While "best practice" lists are always going to be controversial (in both programming and music, but not chess), they do have a lot of value if you don't overuse them, and take them with a grain of salt.
I think you're also missing idea of "fundamentals" as essential thing that article means by "stupid shit" - fundamentals meaning habits and not just instructions.
Not all "bad stuff" is "stupid shit" in this approach. The "joel test" really doesn't relate.
Just about all Chess players know to avoid hanging pieces - the article described going from there to making that understanding habitual. Essentially, the article, if it was consistent, would be looking for some equivalent to musical scales that a software engineer could do practice before actually programming. It is not a matter of knowing best practices but a way of systematically developing the habits to put them into practice.
It is the difference someone telling you not to make a mistake and going over and over doing things to actually get in the habit of not making mistakes... A person can learn theoretically how to play music in a week and if producing keystrokes at the proper time didn't matter, people wouldn't spend more than a week learning the skill. As it is, a lot more practice is required.
But really, I'm pretty sure there isn't a software equivalent of musical scale because software isn't as specific a skill as reading or performing music. Software involves a large variety of logical skills which most adults already have to some degree. It is so complicated on some levels that mistakes are sort-of inevitable on other levels.
It's very interesting to get ahold of a "best practice" book or an organization's SOP manual just to see what battle-tested advice is given for various situations... you may disagree but they embody wisdom. At the very least you can find out where they're coming from.
The Joel Test isn't really intended for individuals, though. It's more of a "how to fix stupid shit" on an institutional level. I think what people are looking for here are ways to fix stupid shit on an individual level.
I think there is a simple equivalent in programming. A lot of programmers I know can rattle of the benefits of 3 or more frameworks. They can program in half a dozen programing languages. But they couldn't tell you the basics.
They couldn't say what the difference between functional and object-oriented programing is. They couldn't tell you what a good name for a variable is (maybe they have somewhat good variable names, but they don't really know why they are good or bad). They couldn't properly define an architecture for a new project.
There are basics in programing that should be known before all the programing languages, frameworks and what not. And I think from time to time everyone should try to learn more about the basics instead of a new language. From time to time think really hard why this variable should be called that. Why we need a new package for that. Why is a method built the way it is.
Hmm, It seems so on the surface. I'm on my third trip through, and it's going to take me less than a month and a half. It really gets substantially easier once you "grok" it. The first time is AWFUL though. This isn't to say of course that I don't get very much out of subsequent readings. SICP is very deep. It's just after a first reading (and doing all the exercises) you're free to focus on concepts more than "tactics."
I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple".
The problem of overcoming bad habits is a really tough one.
In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming.
I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors.
If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.