Hacker News Reader

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.

Not that I've done this. I should.

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.

Totally agreed.

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 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.

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.

The concept of code katas approaches this to some extent. http://en.m.wikipedia.org/wiki/Kata_(programming)

See also the 'design recipe' approach advocated in books like 'how to design programs'.

Programming Praxis[1] is a site that has been constantly updated with these kind of exercises.

[1] - http://programmingpraxis.com/

I work through SICP every year. It seems to ward against bad programming habits on most levels.

Wow, that's impressive. It seems a new category is needed in the poll at http://news.ycombinator.com/item?id=2846799

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."