Archive for August 2010
Facts are not my personal fucking opinion. When I quote the manual for a product we are using, or describe something that you, as a professional developer, should be aware of — such as the differences between clustered and non-clustered indexing — then you don’t have a great deal of options. You can either sit down, shut the fuck up, and learn something; or you can describe how this may not be relevant to the situation.
There is no option C: “well that’s what you think, perhaps we should try my idea anyway”. The whole point of hiring a consultant who knows what the fuck they are doing is so you can avoid the trial-and-error treadmill; and if you don’t think you can trust me, why are you paying my bills? Seriously… get someone else, we’ll both be better off. You’ll have someone who will accompany you on your wild goose chase of “performing a join client side will be faster”, and I won’t have to work for a bunch of fucking retards.
Ta-dow. How’d you like me now?
I do not turn up to work to join your internal politics. I am getting three to four times your shitty salary, and thus have already pissed higher than any line you can imagine. I am there to keep myself in fast cars, strong booze, and loose women — I am absolutely not interested, in the slightest, in carving myself out a unique smelly patch of your local flavor of fail. You can keep it.
The only reason I am trying to do my job well is so it looks nice to the next chump who hires me. You claimed I would have the resources so I can do my job in the interview process. No fucking backsies.
You will find this design pattern in Knuth and K&R. This is because it’s not specific to the underlying design pattern, but how its applied. A team will take an advanced tool or some architectural guidance, and use it to vigorously fuck themselves right up the pooper. This is because they assume they can implement something complicated, for free, without any of that complicated book-learnin’. There ain’t no fucking freebies. First law.
Never Picked Up a Book
There will be a solution to a problem. The solution is probably a little complex – it will require a rough understanding of the problem. Noobs don’t understand — they just see that solution exists, and that is “best practice”. The inevitable fail then goes down in one of two ways:
They will create their own version of a “best-practice solution”. They will do this without understanding the problem or how the solution relates to the problem. They will then end up fucking themselves by creating yet another shitty code-generated data layer that doesn’t support the concept of a unit of work or relationships.
Either that or they will use a “best-practice solution” to a problem they don’t have. They will take on all the disadvantages of a solution without any of the benefits, or even any knowledge of what the benefits should be. I’ve seen whole websites implemented using a Web-Part-per-page model, without using any of the features of Parts – just using the disadvantages.
16 Layers of Abstraction, Look!
There must be some fuzzy feeling, or herd mentality, in applying the same solutions as everyone else. We see this kind of crap fairly often in people discussing Google level scalability regarding their shitty Rails app — which on an unusual day may have to deal with two simultaneous requests…