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..."
Why?
The first entry is for Abstract Data types, but the entry http://programmer.97things.oreilly.com/wiki/index.php/Abstract_Data_Types clearly refers to polymorphism or perhaps even Duck Typing.
I pretty sure that the idea of an Abstract Data Type pertains to the idea of a implementation of Tree / List / Stack independently of the object that is being actually implemented. In this case the concept of a List may be implemented with an Array backing store, a Linked List, a Doubly Linked List etc. You can swap in/out the implementation of the list in such as way as to best suit your use/needs of List type. The List is the abstract data type. Customer/Supplier in the example is nothing like this.
Sigh... Something was lost to developers when developers no longer had to LEARN how use pointers properly, and all the extra learning that was required when developers had to learn how to implemens these Abstract Data Types
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.
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.
Did "how to kiss ass?" make the list?
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.
"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 :)
Programmers in school today have problems with pointers because SJW nimwits teach them to believe that "men's room" is a pointer that can be interpreted in two ways
The ordinary prick vs. the overloaded prick. After all these years, you would think the latest version of C++ would have settled this problem.
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?
Not surprising. An editor told me it wasn't his job to edit the stories that appear in his magazine if the author didn't do a thorough job in editing before submission. An editor no longer edits anymore. That was during the transition from snail mail submissions to emails submissions.
Do Lots of Deliberate Practice ... "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."
The quote about deliberate practice is taken out of context.
1) It is said it typically takes 10,000 of deliberate practice to become "elite", but it can take as few as 100 hours for those "naturally" good at something
2) This mostly applies to professions where practice matters, like playing an instrument. As a profession becomes less about muscle memory and more about thinking, practice becomes less useful.
Becoming an elite in a purely intellectual profession can require virtually zero practice. Some people are able to learn by thinking. They can reason through to the conclusion without having to actually practice/experience. Of course nothing is purely intellectual. Even with programming, we have to deal with other humans and need to deal with the fact that we are also human and can make mistakes. You must learn to write clear and defensive code, and be able to communicate with others.
Rule of thumb, don't write any code until you understand the problem and have thought of a good solution. If you were wrong at any point, figure out what was wrong with your reasoning that lead to the mistake and don't make that same logical mistake again. It really comes down to having strong fluid intelligence. This is how someone realizes what they don't know and if what they do know will work for the situation at hand. If you suffer from Dunning–Kruger effect, have a golden hammer, or don't realize you're doing something wrong, you probably need to exercising your fluid intelligence.
A professional programmer is someone who gets paid to do the job of programming.
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.
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.
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.
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 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.
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.
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?
Oh, and use MVC (Model View Controller).
No, never, ever. Not even at gunpoint. Not even if you were holding my wife and kids at gunpoint.
MVC has caused more heartbreak and aneurysms than tequlia and bacon combined.
Ok, why?
My ism, it's full of beliefs.
Start lists with an index of zero.
Have gnu, will travel.
Composite/Structured Design was published way back in the late 1970' and detailed how rules should be in one place only as well as touching on the interfaces to access data and rules. Apple used the MVC structure to separate data from the viewer and methods. OO programming made this much easier to do. Computers are so fast any penalty, in most cases, is irrelevant.
My suspicion is that most software people now simply are connecting widgets to interfaces, and there is no actual knowledge of development or process. this is fine because the frameworks we have are so sophisticated that we can pay people to solve problems rather than figure out arcane error messages on why the code won't compile.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Dirty code is defined as ' overly complex or highly coupled.' As a programer you are expected to deliver X number of features by Y date. Unless one of those features is 'simple and loosely coupled code' what does that have to do with predicting anything? For performance you don't predict. Experiments are the only thing you have that work: test and change and re-test and un-change and re-test, endlessly. Anything else is voodoo programming, not to insult the pracitioners of Santaria, Vodou or Hoodoo.
How about predicting the schedule? I recall that Steve McConnell once joked that to get better at estimating we need to get better at estimating. (This may have been someone else.) Greg Wilson showed we can do this in programming, and Computer Science in general. We only have to do scientific experimentation with various methods. We throw away what doesn't work (instead of writing pulpy business books to bilk people out of money.) But you'll still have to run a lot of tests to do that, too.
It is my opinion that any refactoring that cannot be done by an automatic program isn't refactoring. The original definition of refactoring is just 'factoring' or re-organizing the code. It is not a re-writing as in an 'several months' effort.
Misuse of a sexy, trendy name from the 90s does not change this. All re-writing suffers the risk of second-system syndrome and not in the throw-one-away sense of prototyping. Do you have a button to press in your IDE to make the change? Do you have in mind a short sed statement, simple awk program, EMACS macros or a on-hand shell scriptlet to do the transformation? If not then you cannot get away from re-thinking the problem. This will require re-design of the solution and re-implementation of the feature. Each of these carries time risk at least as high as the original work.
What if the problem is overly complex or highly coupled? The code may merely be an expression of this. In this case only a paradigm or perspective change by the customer, developer or user can untangle the problem. The computer cannot help you do anything but automate making a mess if the problem is a mess. Changing perspective is often an unbound-in-time problem for human beings. Good luck with estimating completion dates for that.
In fact, Greg Wilson showed in his presentation that almost every metric on the market when analyzed showed no better and usually equal predictive power as simple counts of Lines of Code.
The situation in programming is almost as if more code equals more bugs while less code equals less bugs.
This seems obvious and
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
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.
You are dead on right. Thanks for writing much better what I was thinking.
This particular section highlights several of the working conditions that are standard in programming/IT and reasons for leaving this non-profession.
Ignore the naysayers, they are just more bosses who want champagne and caviar work for cat-food wages.
Number 38 will shock you!
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Yeah, don't you hate it when someone with an idiotic political agenda finds a way to work it into every topic?
Q: what's the resemblance between an engineer and a dog?
A: both have intelligent eyes, but none can express themselves.
(My father told me this, he's an engineer)
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Was going to suggest Urdu, but it's already there at number 49.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
It's often used for systems that are way too small to ever need the resulting complication. And when the system needs to be extended, it frequently appears what it needs to work with doesn't fit the current implementation in the least, and instead of writing a trivial interface, you are forced to massage the MVC engine/framework into fitting the new thing.
It's a decent system if you know majority of requirements a'priori, the system is big, and can only grow in well understood ways.
If the system is to grow a lot from a small root in ways you can't even roughly foresee, MVC feels like the smart way to make it flexible and easy to expand. Until you encounter requirements that are completely orthogonal to current design, say, deadline/realtime reply requirements, massive parallellization, making the system distributed, or porting to small embedded.
Adding an extra page with some report, or a summary, or shuffling a piece of UI into a different UI branch is nice and clean in MVC, and these are the typical expansion types you foresee. But if it's something like mentioned above, you're suddenly in for a long haul and a lot of heartbreak. Modifying stuff within a framework is nice. Modifying the framework engine - not quite so. And MVC frameworks tend to be heavyweight and very complex; in a lot of cases more complex than your application written on top of them. Suddenly you need to modify code written by total strangers, often either way smarter than you, or worse, quite opposite... and the simplicity of your neat application means nothing in face of complexity of the framework engine.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Actually, the demand I have upon employers is that they treat employees fairly and compensate them fairly for whatever work they ask them to do.... if the employer wants people to work extra hours, then he should be compensating the employees in some way for those extra hours, but people who are making a decent enough wage at what they do already are not going to typically care whether or not they get any extra remuneration for putting in more time than what they know they are actually being paid for. Studies have been done on this matter.... after a certain point, more money does not equate to more happiness or satisfaction.... but that does place a heavy onus on the employer to be treating their employees fairly and compensating them commensurate with their efforts and achievements.
File under 'M' for 'Manic ranting'
Some of these "things every programmer should know" are just wrong. They are wrong from their observations, their non sequitur conclusions, and their misunderstanding of computer science.
BAH!
Not necessarily that most that they possibly can, but certainly no less than what the employee is rightly worth, given whatever it is that they do for the company. If an employee believes they are worth more than the employer is paying, they should rightfully try and secure alternative employment. In the meantime, however, failing to perform to the best of their ability at whatever task that has been set out for them regardless of how much they might have been paid to do it it is a failure in work ethic, and that failure is going to impact their chances at the jobs that are better paying than the one they might have right now.
What I would expect both from employers and colleagues is integrity, empathy, and humility.
File under 'M' for 'Manic ranting'
Shouldn't you be teaching advanced Haskell Agile Buzzwording to the first-trimester ftus to get that competitive advantage in the workplace of 2025?
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
I wish I had mod points. This is a delightful trolling.
Actually, the only thing the employer *has* to do is offer enough money that he can find people who will do whatever job it is that he wants done. This does not have to be anything resembling what he thinks or even knows that the job may actually be worth. The only thing the employee *has* to do is fulfill the expectations of work completed that the employer has on him. That's it.
I am suggesting, however, that these are merely the minimums that one can offer at a potentially sustainable level... it's a pitifully low bar, and if it as high as anyone ever reaches, then I can only suggest that they are probably never going to be happy with themselves or their choices, or probably almost anything in their life, which is truly unfortunate. Ideally, an employer pays what an employee is *actually* worth, and not just whatever minimum amount they might be able to get one for, and the employee actually cares enough about the quality of their work that any extra time that they might spend on it without any addition remuneration is going to be inconsequential to them (because the employer is already paying them fairly anyways). This ideal is the standard that I hold to, and I do, quite frankly, think that people who settle for less either have too poor a self-esteem to believe they are actually worth more, or else who simply do not have the integrity to maintain a positive work ethic that is transferable to *ANY* job, regardless of how much money it may make a person. It is, I am sorry to say, an ideal that is not always achievable, but if I do not reach beyond whatever standard I know I might achieve, I know I can never discover my fullest potential..
File under 'M' for 'Manic ranting'
Haha, I got downvoted by a Python programmer.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Ok, why?
Lots of reasons, but one of the killers for me was that it scatters code all over the place. If you need to make a change you often end up having to screw around with multiple files. Change the model, change the controller, change the view. Lather, rinse, repeat. Need to change the view? Great, you'll have to change the model and the controller more often than not. Same goes for the model and the controller- any change anywhere usually necessitates touching multiple parts of the project over and over again.
Also, as someone else pointed out, it's often needlessly complex for smaller projects or one-off jobs. I just find the whole MVC paradigm to be a pain in the ass from start to finish. If it works for you, great, but it's not my cup of tea.
Just cruising through this digital world at 33 1/3 rpm...
You got me.
I said that those were the minimum standards that are potentially sustainable on a job, not that those standards are necessarily actually going to be considered sufficient by anyone.
File under 'M' for 'Manic ranting'