Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the collect-them-all dept.

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

27 of 234 comments (clear)

  1. Lots of links to articles, phfft by Snotnose · · Score: 4, Interesting

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

    That said, I trust O'Reilly to produce quality books. One fail (Make) in maybe 20 books I own from them is a good record.

    / The Gnu make manual is the best Make doc I've seen.

    1. Re:Lots of links to articles, phfft by godrik · · Score: 4, Funny

      What ? This is slashdot! Since when do we read things before disagreeing with them?!

    2. Re:Lots of links to articles, phfft by Anonymous Coward · · Score: 5, Insightful

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

    3. Re:Lots of links to articles, phfft by DontBeAMoran · · Score: 3, Funny

      I don't even know what the hell you guys are talking about, but I disagree!

      --
      #DeleteFacebook
    4. Re:Lots of links to articles, phfft by geoskd · · Score: 4, Interesting

      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.

      What the author was implying is that you should take relatively straightforward components of a function and break them out as their own sub-functions with a very descriptive name, especially the inner workings of nested loops. If you take the inner loop and replace it with a function call that describes what the inner loop does, then your outer loop actually gets much easier to read, as it does not have the distraction of the gritty details of how the inner loop performs its duties. With properly written sub-functions, you can simply read the name and understand what it is doing without having to actually read the function at all. I have personally done code reviews on code that has been re-factored in this fashion, and the readability of the code is night and day.

      --
      I wish I had a good sig, but all the good ones are copyrighted
    5. Re:Lots of links to articles, phfft by JustAnotherOldGuy · · Score: 5, Insightful

      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.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    6. Re:Lots of links to articles, phfft by Anonymous Coward · · Score: 2, Insightful

      That makes sense if the inner loop is quite large, but not so much if it is small, or the inner and outer loop are very similar (e.g. obviously just looping over a multidimensional array). It doesn't take much for this idea to make code very difficult to read and maintain. I had to take over some code that automated some equipment and at some point we changed the equipment such that a default setting was no longer appropriate. It took two people way too much time to dig for where that default value came from, finding it was some 30+ functions deep for a program that basically: loads two different settings files, setups up a device, reads data from device, then saves it. The code was refactored and 500+ functions reduced down to about 60 functions, none more than a page long. Even with descriptive names for functions like DefaultValueForSettingFoo, it didn't help when a certain condition at a later in function LoadValueForSettingBar sets a different default value to Foo.

      Functions are best when done for reuse. Occasionally a single use function has its place when you're segregating very different types of code. But going to the point of many functions having one or two lines of code then a call to another function that is used nowhere else, you end up with spaghetti code.

    7. Re:Lots of links to articles, phfft by Pseudonym · · Score: 2

      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.

      Actually, I agree with the author on this one, but the title is wrong. It should be something more like: "Write your code under the assumption that dozens of mediocre programmers will be eventually responsible for maintaining it."

      This "thousands of 15 line methods and small classes" approach is the only way that we know of, so far, to scale up codebase to dozens or even thousands of mediocre programmers. It sucks, but really good programmers are hard to find.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    8. Re:Lots of links to articles, phfft by grep+-v+'.*'+* · · Score: 3, Funny

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

      1. THE ROBOTS ARE COMING -- find a different job.

      --
      If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
    9. Re:Lots of links to articles, phfft by Anonymous+Brave+Guy · · Score: 2

      You write 10 small functions and then have another function that ties them all together. Problem solved, your system isn't any more complicated

      Yes, it is. It's more complicated by now having 11 parts instead of one, and 10 extra relationships between them.

      None of the rest of your claims follow automatically just from having more, smaller functions. Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions can make code harder to understand. While the individual functions are simpler, the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    10. Re:Lots of links to articles, phfft by angel'o'sphere · · Score: 3, Insightful

      Indeed, the point several of us are trying to make is that exactly the opposite may be true: breaking everything down into very small functions
      That is a strawman. Nobody said very small. They simply should be small enough, that is all.

      the number of potential relationships between them grows exponentially, and those relationships may not be as transparent once you've broken everything down into tiny pieces.
      Then you are doing it wrong.
      By "definition" a function only works their arguments and returns a result. Usually, if it is a method in a class, it does not even manipulate the attributes of its associated object.
      The only relation functions have to each other is their call hierarchy, which is easy to figure and in an IDE trivial. Worst case use the debugger.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  2. Pair Programming by Anonymous Coward · · Score: 4, Informative

    Not sure "pair programming" qualifies as something every programmer should know. Though perhaps every programmer should know that a few programmers are rather fanatical about it.

    1. Re:Pair Programming by TechyImmigrant · · Score: 3, Funny

      Pair programming sounds horrible and I'm glad I don't have someone staring at my screen while I'm trying to slack off and read Slashdot.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    2. Re:Pair Programming by Anonymous Coward · · Score: 2, Insightful

      ... trying to slack off ...

      It's called, interrupting job tasks to prevent boredom and burn-out.

      ... read Slashdot.

      That's gaining external perspectives on important issues; which is the very point of 97 Things Every Programmer Should Know.

    3. Re:Pair Programming by __aaclcg7560 · · Score: 2

      Pair programming works better when you have the opposite sex sitting on your lap.

    4. Re:Pair Programming by ockegheim · · Score: 3, Insightful

      Not if they're a 3yo asking for a video.

      --
      I’m old enough to remember 16K of memory being described as “whopping”
  3. Unix Tools vs IDE by Crashmarik · · Score: 2

    Depends which do you think you can recreate faster as you need them.
    Small Unix Tools using the IDE
    or the Large IDE using small Unix tools.

  4. Stupid and Lazy by tobiasly · · Score: 2

    "Be Stupid and Lazy" sounds a lot like Lary Wall's "Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris" http://wiki.c2.com/?LazinessIm...

    Of course, maybe the "Be Stupid and Lazy" author was just being lazy :)

  5. Good book for getting back into Java... by __aaclcg7560 · · Score: 3, Interesting

    This week I had to install Ant to automate some Python programming tasks. Of course, Ant requires Java. I haven't touched Java since I graduated from community college 10 years with an A.S. degree in computer programming and had to learn all flavors of Java because the CIS department couldn't afford to renew the Microsoft site license for Visual Studio, and, when the site license got renewed, none of the computers could run VS .NET. I really wanted to learn C++ instead of Java, but industry surveys showed that local employers wanted VS C++ and not GNU C++.

    Anyway, Ant renewed my interest in Java. Any good O'Reilly book to get back into that language?

    1. Re: Good book for getting back into Java... by TheRaven64 · · Score: 2

      Did you really just say that make is arcane, but XML is straightforward?

      --
      I am TheRaven on Soylent News
  6. Picking one at random by russotto · · Score: 5, Informative

    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.

    1. Re:Picking one at random by ath1901 · · Score: 4, Insightful

      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?

      I just can't stop thinking about the stupidity of this.

      Doctor: Hey, patient, would you like to try some new meds I read about on the internet yesterday while my kids were screaming? I haven't tried them or read any scientific studies and I am unsure about the use-case compared to existing drugs but they are very popular in some facebook groups.

      Navy Officer: Hey, we're getting a new aircraft carrier next year so I expect all of you to go home and read up on it and start practicing at home. We'll call you when there is a war and your skills are needed. You'd better be self-trained experts by then!

      University head: What's all this "research" I keep hearing about? Take some responsibility for your own careers and stay up to date in your spare time! Now, go back to work. We need more folded napkins!
           

  7. Personal responsibility? Why not start at the top? by Anonymous Coward · · Score: 3, Insightful

    I just f*** love it when the lowly programmers were asked to take "personal responsibility" when everyone else who earned more and have more authority, such as managers, wouldn't.

    Where's the guy taking "personal responsibility" for the requirements document, which changes weekly/daily?

    Where's the manager taking "personal responsibility" when the project have to keep going on the original schedule even when short staffed?

    Where's the PM taking "personal responsibility" when unreasonable death march schedule was accepted?

    So when sh*t hits the fan, the *programmer* should take "personal responsibility"? You think we were fools?

  8. Production server by nasch · · Score: 4, Informative

    Under no circumstances — ever, at all — should a developer have access to a production server.

    I'm one of two developers on a five person team. The other people are: CEO/sales, marketing/customer support, and QA. If I didn't manage the production server, there would be no releases. Perhaps this would be more accurate:

    Under no circumstances — that I've personally experienced — should a developer have access to a production server.

    1. Re:Production server by coofercat · · Score: 3, Insightful

      The real advice is that "while working in the role of Developer, do not have access to the prod servers". If you additionally have the role of "sysadmin" from time to time, then so be it, but don't abuse your development power, nor your sysadmin power.

      In my experience of big companies, small companies and a few in between this really does work best. People talk of 'creating high walls' and whatnot, but by forcing devs to mould their output into something system-friendly results in a far superior product and far less maintenance overhead. It appears to take longer to get things into production, hence the 'high walls' comments, but the alternative is almost always worse in the long run.

  9. Re:O'Reilly Posts One Weird Trick Every Programmer by Pseudonym · · Score: 2

    Number 38 will shock you!

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  10. Re:Problems with pointers by Wootery · · Score: 2

    Yeah, don't you hate it when someone with an idiotic political agenda finds a way to work it into every topic?