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.

>>9
The cost of the sequential machine abstraction is far less significant than the flexibility it provides... at least for most tasks. But for everything else... have you heard of FPGAs?

>>17
When I program, I feel limited by hardware and preexisting software quite often.
That's why CS is engineering just like any other type of engineering; you have to work within the constraints of the system you're building.
For instance, when I program in C, I want for a more natural dynamic array type.
If you're irritated by that then move to C++ and use std::vector, although then you have not much control over resizing/allocation.

Not to mention primitive types greater than 2^64, easy-to-implement concurrent execution of loops, a sane way to provide syntactically-sweet language extensions (C++ classes/operator overloading are NOT sane), the list goes on...
All those things have additional costs, and making them easier to use encourages overuse where they're absolutely NOT needed. "Let's make all integers arbitrary-precision, then we'll never have to worry about overflow!" >>18 is an example of that. Now your code is a few orders of magnitude larger than it really needs to be, and correspondingly slower. Dynamic arrays are a perfect example of this, and IMHO not having them by default in C makes you think more about whether you actually need them in the first place, possibly making you reconsider and come up with a simpler algorithm (static allocation, in-place streaming) that does not require them.

One of my favourite interview questions is something like this:
"Write a program, in your language of choice, that adds line numbers to a file by prefixing each line with a decimal integer followed by one space. You may assume files have no more than 2^32-1 lines." No hints (you should try this youself) but I can tell you that if you thought of needing an array of some sort, you're not getting the job.