Slashdot Mirror
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..."
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..."
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.)
It's called, interrupting job tasks to prevent boredom and burn-out.
That's gaining external perspectives on important issues; which is the very point of 97 Things Every Programmer Should Know.
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?
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...
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.
Not if they're a 3yo asking for a video.
I’m old enough to remember 16K of memory being described as “whopping”
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!
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.
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.