O'Reilly Site Lists 165 Things Every Programmer Should Know (oreilly.com)

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

Comments

Re:Lots of links to articles, phfft

[Anonymous Coward]

Didn't take me long to start disagreeing with them. This one.

I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.

(The real failures when other people edit my code usually come in not understanding how classes inter-relate and the layers of the program - the architecture if you will. And at the moment, the only real way of communicating this? Comments describing the architecture.)

And, do comment your code - not 'as little as possible', but not 'what's obvious from the code'. Remember what's obvious to you might not be obvious to someone else -- write code for humans, not machines. I'm really REALLY not sure that creating another class to hold four parameters for one method is any clearer than just those parameters - especially since I work in languages that support named parameters anyway (a much neater solution)).

The dead giveaway that this person is full of it is their lack of justification - explain to me WHY the "rule" exists..

(NB: This is really a collection of 97 micro-essays -- it has, actually, 97 authors - so each author is different.)

Picking one at random

[russotto]

The Professional Programmer

What is a professional programmer?

A professional programmer is someone who gets paid to do the job of programming.

Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

Sorry, bud, but professionals take responsibility for what they're paid to take responsibility for; no more and no less. And push responsibility off when appropriate too, like when their boss commits them to a schedule they can't make without compromising workmanship.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way?

Hell, yeah, they do. What do you think a resident is? Maybe the author is confused because after residency, many doctors are owners of their own practice, at which point they are not just professionals but business owners. Me, I draw a salary. If my training is going to benefit The Company, it's on The Company to provide it.

Professionals take responsibility for the code they write. They do not release code unless they know it works.

Again with the confusion between a professional and someone with independent authority. My code goes out when the boss says it goes out, ready or not.

Professionals are team players. They take responsibility for the output of the whole team, not just their own work.

Obviously not familiar with life in a corporation. Managers and leads take responsibility for the output of the whole team, when that output is good. When things are fucked up, THEN the programmers get the responsibility. Shit flows downhill, credit is taken upward.

Professionals do not tolerate big bug lists.

Professionals fix those bugs, and only those bugs, they're being paid to fix. The rest can sit in the issue tracker until doomsday. Ain't no point in getting the boss riled up over spending time fixing a minor floating point division error when you're supposed to be working on the shiny new feature.

Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush.

A professional rushes when being paid to rush. A professional keeps the code clean when practical under the constraints of the job. If that means we're getting the code out on time only with a bunch of copypasta and a goto or two, that's how it's going.

Professionals get paid. If they have a rare combination of independent authority and a client with respect for them, maybe they can have other principles too. Otherwise, they write the code which gets them paid.

Re:Lots of links to articles, phfft

[JustAnotherOldGuy]

Anyone wanna summarize the list so I don't have to read 160 articles to see if I agree/disagree with them?

1) Don't do stupid shit.

2) Think ahead.

3) Don't reinvent the wheel.