The /prog/matic programmer

ANyways, so... I was reading The Pragmatic Programmer [1] and it occurred to me that we should probably boil these principles down for the novices amongst us. ITT things you want to carve into your colleagues' faces.

* KEEP IT FUCKING SIMPLE, MOTHERFUCKER!
* You're code is not ``clever'', it is autistic.
* Code is /not/ poetry or art. Go away! Fuck your OCD.
* This shit has been solved a thousand times over.
* You do not need to design with the latest and greatest in gang-of-four approved OOP design patterns, using infinitely scalable NoSQL solutions in hip new languages that compile down to JavaScript (srsly WTF?!), just to create a CRUD application.
* Not everyone gets off on code, some of us just want to make a living doing the least amount of effort that is required to deliver a consistent quality for an extended period of time.

I swear by god if I see one more AbstractControllerFactoryInterface

[1] http://pragprog.com/the-pragmatic-programmer, easily found online.

This issue largely comes from traditional CS curriculum (SICP included). They start off by saying that complexity and abstraction are good things (only in moderation), "premature optimisation is evil" (it's never premature), and use those as arguments to convince the students that all software needs to be multi-layered elephantine systems broken up into hundreds of classes, packages, design patterns, and other cruft.

Quoting from the first SICP lecture:
"And these techniques for controlling complexity are what
this course is really about. And in some sense that's really
what computer science is about. Now that may seem like a
very strange thing to say, because after all a lot of people
besides computer scientists deal with controlling complexity. A large airliner is an extremely complex system. And the aeronautical engineers who design that air, you know, are dealing with the men's complexity. But there's a difference between that kind of complexity and what we deal with in computer science. And that is that computer science in some sense isn't real. You see, when an engineer is designing a physical system that's made out of real parts, the engineers who worry about that have to address problems of tolerance and approximation and noise in the system. So, for example, as an electrical engineer I can go off and easily build a one-stage amplifier or a two-stage amplifier, and I can imagine cascading a lot of them to build a million-stage amplifier, but it's ridiculous to build such a thing, because by the --- long before the millionth stage the thermal noise in those components way at the beginning is gonna get amplified and make the whole thing meaningless. Computer science deals with idealized components. We know as much as we want about these little programming data pieces that we're fitting things together. So there's... We don't have to worry about tolerance and that means that in building a large program there's not all that much difference between what I can build and what I can imagine. Because the parts of these abstract entities that I know as much as I want. I know about them as precisely as I'd like. So as opposed to other kinds of engineering where the constraints on what you can build are the constraints of physical systems, the constraints of physics and noise and approximation, the constraints imposed... in building large software systems are the limitations of our own minds."

Rubbish. CS is as real as any other science. Computers are physical entities in this universe like any other, and need to obey the laws of physics too. Thinking that abstraction and complexity has no cost is stupid.

(I enjoy some SICP myself but that's just mental masturbation.)