"The path of the righteous programmer is beset on all sides by the inequities of the clueless and the tyranny of evil project managers. Blessed is he, who in the name of achievement and solid technology, shepherds the users through the valley of ineptitude, for he is truly his customer's keeper and the finder of lost solutions. And I will strike down upon thee with great vengeance and furious anger those who would attempt to deploy without testing. And you will know my name is zedshaw when I lay my software upon thee."
It's fucking job motafukaz. Scrum scrotum over-manage.
There is one solution for your mental programing motafukaz.
Get a foking pussy. Then iterate. Regularly.
Real programerz like to be functional. GTD. Then get beer. Then code.
Does Programming, Motherfucker really scale though? Every process listed is about teams of people Programming Together, Motherfucker. I've seen two people engaged in Programming, Motherfucker without Talking to Eachother, Motherfucker and the results were Disastrous, Motherfucker.
It is like that in parts of my company. If I need something, I wander over to the desk of the person who works on it, who I know, and I say, how about it, and he says, cool (or vice versa).
The other group write up huge requirements documents, set up Sharepoint sites and wikis, raise tickets and Jiras, you name it, but they never talk to each other and so they get nothing done...
That's the thing, Scrum basically assumes that all software teams are so dysfunctional that they won't talk to each other unless and until everyone is watching.
Nothing in scrum stops you talking to anyone at any time. The stand-up makes sure that you have to say a few words to the whole team and other interested parties, daily.
I like to read criticisms of scrum, when they're not straw-man ones.
How was the parent a straw-man? He suggested that teams that can't talk to each other without the prodding of Scrum are dysfunctional (which I happen to agree with). That's not even necessarily a criticism of Scrum, it just points out that Scrum can be good for teams that, as you say, have bad habits.
I didn't mean it as a straw-man criticism, just an observation that scrum is very rigid and prescriptive; it's all about the what and the how instead the why.
I'm a big believer in trying to persuade people to keep feedback loops short, make teams small and cross-functional, and to design/code/test/ship in the smallest increments possible. At this point, calling an approach agile/scrum/xp carries a lot of baggage.
If people don't get the why (e.g. the team isn't small and cross-functional, and people aren't working on tiny increments) it kind of doesn't matter if you get everyone in the room at the same time every day.
Nothing really scales. There is no process that will allow 100 hacks to make a Michelangelo, if you want a Michelangelo you're going to have to fucking hire him. If this bullshit really worked then corporate IT departments would be the envy of every startup out there.
If your software is late/buggy/whatever the solution is rarely adding people / process. It's usually removing people / process. Process is what allows managers to fuck up projects.
Not necessarily. I was once working in a large software project (500+ people), which went off-track, and then some added processes helped to save it, like for example continuous preintegration and more rigorous testing before each check-in.
I agree with the parent comment. "Just programming" looks nice on a manifesto, but you need processes when you want to scale.
I saw your comment and laughed, then realized you were serious.
If you are working with 500 programmers, they are likely to be mostly mediocre - the good ones would have run away screaming to better jobs.
Sure, if you have 500 mediocre programmers, you need to rope them in with systems. If you hire 5-10 great programmers, stand well clear and let them do their job.
I've struggled with how to respond to your comment. You seem to be taking the view that any project that requires more than 5-10 great programmers is inherently flawed. I think this is false.
I've worked on very large software systems before, places that had around 1,000 developers spread throughout the organization. While there were a lot of mediocre, and truly some flat out bad developers, I guarantee you that 5-10, or 10-20 great programmers could have developed an equal system.
Throwing bodies at a deadline doesn't usually work. Throwing bodies at a problem can help, though.
What single project requires more than 5-10 programmers?
Places with 1,000 developers spread throughout are working on hundreds of interacting projects. But, the communication and coordination isn't between all 1,000 developers.
Your last line: "But, the communication and coordination isn't between all 1,000 developers." Deserves more than one upvote - in any successful large scale project, the programmers work in very small groups, often just pairs, and interact with other groups mainly through the code-base itself. I am tempted to say almost exclusively through the code. That is why open source works as well as it does; if management actually added much value, linux could not be as useful as it is. In fact, I suspect management often is a negative factor; when large commercial projects work it is the result of superior design, and their ability to maintain adherence to the design, which is when management does add value.
Having all those 1000 developers talk to one another would solve all problems, but this is a problem of scale which processes solve to a certain extent. Your opinion also highlights what's wrong with software development as a whole -- you seem to be under the impression that you can go and hack stuff in a vacuum, without interacting with others.
Sorry, but that's one of the stupidest arguments I ever heard (not referring only to you, but also to the parent's parent that brought it up).
Linux is a monolithic kernel, and because kernel parts depend on one another, unfinished changes are often blocking other changes and/or are breaking other parts.
Of course you aren't going to have 1000 developers working on the same line in the same file.
Linux is a product by itself, not a distribution of independent parts. You either have the whole kernel, or you have nothing. And I would die to see another kernel developed by 5 people, achieving the same feature-parity / stability and all that jazz as Linux.
I've placed a ceiling at 5-10 programmers, because most tasks can be broken into modules such that only 5-10 programmers are working on a module, with decent separation between modules.
Beyond ~7 people, someone needs to begin to coordinate, which is the logical introduction of management and process. But again, avoid large teams where possible.
Linux, Windows, Microsoft office - all great examples of a huge number of modules working together. For instance, the programmer writing the font rendering doesn't need to work closely with the video driver developer, they interact through a carefully designed interface.
But if you are in a startup, odds are you are slinging many large libraries and iterating quickly on new code (that often only you consume). In that case, you're better to "Program, Motherfucker"
This completely misses the point. Corporate IT doesn't want a Michaelangelo--they don't even particularly expect to be the envy of every startup out there. They just want to get shit done. It doesn't have to be spectacular shit, but the people working there generally harbor no illusions--they aren't offering stock options, and the people they hire generally don't care about the problem domain. They want to get shit accomplished given these constraints, not chip the perfect webapp out of a solid block of (fucking) granite.
But the reality is that 99% of the time, companies don't need a chapel roof painted, they just need a quick watercolour to put in reception (abandoning the painting analogy now).
It's a business decision - is it cheaper to hire one genius to produce something amazing or to hire a few mediocre programmers and manage the heck out of them to produce something that just about works?
The fact that I agree with all of this just makes me sadder at how it was presented. Thanks for building a handy straw man for the methodology developers to attack.
I flagged this --- it's virtually content free --- but that's a futile gesture given how susceptible HN is to this particular form of social engineering.
Hey Thomas, lighten up. Normally I'd agree with you, but not today. This post hit me just right...
I'm having a shitty day. Really shitty. 6 levels deep into garbage that never should have been written, trying to add one little feature. Asking myself every 7 minutes if I have time to rewrite without shifting everything else out a week.
I just returned from my 5th candy bar break in the past two hours, wondering why I'm still a programmer. Honestly, today was one of those days when supermarket clerk actually started sounding good.
Then I read this post and suddenly found the energy to make it through the day. I'll strap some kludgy fix onto this shit, ship it out, have a beer, and all will be fresh tomorrow.
Frankly, I'd rather read one post to save my day than 50 to save the world. But that's just me, motherfuckers.
I liked the article, I just hate the inconsistency here on HN when it comes to humorous/evocative submissions and comments. We scold some for violating the guidelines, and we bless others. Can we sometimes be more relaxed about what is submitted? If the answer is yes as you are indicating, can we make it this way all the time?
Ultimately the evolving community here will make the final judgement. I just feel that the guidelines can be adjusted to reflect what is acceptable.
We scold some for violating the guidelines, and we bless others.
That's really the curse of comedy. The whole point of comedy is to be subversive, to sneak in under the radar of "good taste" and "propriety." But it's hard to do that, a lot of the time it gets rejected out of hand, and it seems very inconsistent.
Absolutely, HN has its fair share of inappropriate/bad jokes, but I think it happens more often because the guidelines are fairly agnostic.
Comedy is subversive, but the venue is usually not. When a comedian gives a routine on stage, the audience is primed and has certain expectations. When the audience's expectations are not aligned, it is bad for both the comedian and the audience.
My limited experiences on HN as a junior user have yielded a certain kind of fuzziness as to what is acceptable. On any given day, there is a lot of variance in the content, but usually HNish and that's a good thing. Officially, the guidelines are posted and they have an emphasis on intellectual stuff/tone, but leave evocative content unexplained. So the community decides, which is usually sporadic, hap-hazard, heavily-dependent on who posted the submission (people have expectations about what Zed Shaw is going to say), and the touchiness of the content. This probably doesn't happen in other communities that are more clearly guided as either relaxed or strict.
That's easy. It's the Picasso rule -- follow the rules until you understand how to break them.
It is true that you are given more slack when your name is known. Think of it as a corollary to the Picasso rule -- others have to know that you know the rules before you are given more leeway on how to break them.
Back in the everything2 days, this was a meme caled "Earn your Bullshit", which they then subsequently expunged from the record because once too many people "earned their bullshit" they realized the proliferation of bullshit was destroying the site.
The bottom line is that humour is easy to upvote, and in-jokes are easy to accumulate in any online community, and so we must be ever vigilant. There's nothing wrong with humour now and again, but it requires ongoing, active rejection, and yes, a bit of hypocrisy to avoid becoming Reddit, where every single story has a contentless pun-filled thread 20 levels deep with a reputation of 1000 at the top falling off logarithmically.
> My limited experiences on HN as a junior user have yielded a certain kind of fuzziness as to what is acceptable.
I think that's a good thing. It keeps people on their toes, rather than trotting out the same stupid jokes time and time again. I'll vote for something that's funny in a unique way, but downvote anything smacking of a stupid meme that's been done to death.
But this isn't really funny. I know the comparison is highly frowned upon, but this thread reminds of Reddit. Or what I remember of it, anyway, back when I didn't mind wasting so much time.
And what's wrong with that? If I don't like what I'm reading on Reddit, I move on to the next comment, story, or subreddit.
Reddit does a better job at support a diverse community of interests and personalities than any single Web forum in the history of computing, IMHO. It could be the next Usenet if it received the funding and infrastructure it deserves.
I honestly do not get all the hating on Reddit that takes place on here.
If you want Reddit, you go to Reddit. Why must HN become one?
I can't keep up with Reddit. Too much noise. Good you have time to. HN currently give ~80-100 RSS items daily to me which is good enough to keep me from surfing all day, and still keep up with latest tech news.
No retreat! No surrender! I'm here watching the battlements keeping the undesirable content out when you can't be. It's what's called "watching your back". I know you'd do the same for me! :|
I really do believe this stuff is a slippery slope. It makes the site worse. Just like yesterday's "Apple Says Yes" comment thread. But I made my snarky comment about it, hit my flag button, and now I'm done. I'm not out for a holy war.
"Tricia had just been to see Woody Allen's new movie which was all about the angst of being neurotic in New York. He had made one or two other movies that had explored the same theme, and Tricia wondered if he had ever considered moving, but heard that he had set his face against the idea. So: more movies, she guessed."
I wish there was a flag like flagging, but instead of "flag" it would say "Does Not Understand The Word Irony". Actually, I'd settle for just a "Wrong" badge.
I'd probably Wrong your post, then UnWrong it so I could Wrong it again.
I liked the piece, it made me smile. Also, I don't think it's inappropriate for HN -- why, we need things like that now and then.
But the fact that this link has 700 upvotes and so many comments makes me cringe. All those talks about HN quality getting worse -- I was never sure if I agree. I am now.
I'm not sure how this is content free. It's offering up a gateway to a discussion/criticism of a lot of crufty-methodologies. Opinionated and vulgar maybe, but it is still about software, hacking, and maybe even business.
Yeah, I'm totally serious about it with that picture of Samuel L. Jackson right at the top. Totally dead serious. Going to start the conference tomorrow.
Apart from the picture of Sam Jackson and some but not all of the words "motherfucker" on this page, which part of this post do you not believe?
Note: we're just nerding out. I'm reacting to your attempt to imply that that this is entirely or even mostly a joke. I don't really care. And, like I said, to the extent that it's not a joke, I agree with it.
MotherFuckerCon 2011. It's a bunch of Agile coaches all standing around in circles passing rubber ducks to each other waiting for their turn to talk about what they're going to do...someday.
When you're shaving a yak, it might be a productive step whose necessity is not apparent until you analyze the problem. However, the term is usually employed when you feel logically compelled to do something, but your intuition tells you that it isn't necessary. You trust your intuition more, but you feel compelled to shave the yak anyway because there's a logically compelling argument for shaving the yak, and you can't justify not shaving the yak.
Yak shaving as applied to process means things like the Dilbertesque meeting to define the goals for choosing the committee to comment on the draft of the process to change the process. Logically, if you believe in the value of process, changing your process is an important thing and can't be done without process. Process requires buy-in, so you need a public draft of the process before it can be adopted. Obviously, the comments of random stakeholders won't automatically assemble themselves into coherent feedback, so you need a committee of representatives from different process stakeholders to compile the feedback. Choosing the committee is a politically sensitive task, so it should be done transparently, and the choices must be justified. So let's get together to define objective goals for choosing the committee members to head off any hard feelings.
Somewhere that chain of logic must be interrupted. No, we don't need any meetings, we don't need any documentation of goals, we don't need a list of stakeholders, and we don't need to produce a public draft for review. We can just do it and it will be fine. Maybe that comes at the top level -- we don't need a process to change the process -- or maybe you stop at a lower level -- okay, we need a documented process to change the process, but we don't need to publish a formal draft and get feedback.
You can't logically justify doing something without any process. You can always imagine things that can go wrong, and you can always imagine more layers of process to prevent those things from going wrong. You could justify an absence of process by performing an evaluation of the risks involved in proceeding without process, but that itself would be a layer of process.
At some point you have to stop trying to mitigate risk and JUST DO IT. At that point it may be helpful to pretend you're Jules from Pulp Fiction and toss around a few "motherfuckers" so you feel bad-ass enough to face the awesome responsibility of, say, choosing a meeting room without consulting a committee and without even articulating a reason for not consulting a committee. That last part is what makes it completely bad-ass, because you aren't even pretending to be responsible. You don't give a FUCK. You're going to choose that motherfucking meeting room for that motherfucking meeting, and you aren't going to explain how, and any motherfucker who wants you to explain how you chose that motherfucking meeting room can talk to your motherfucking balls, and if he can't pull his head out of his motherfucking asshole to find them you will stick them in there so he can chat with them at his motherfucking leisure.
I have seen many projects fail in big companies because management are frightened of programming. The "risk mitigation" is using large teams of people with the right "skillset" who don't need to think very much because they are doing things according to the "industry best practice" using expensive third party software so that the in-house programmers don't have to make hard decisions.
If you work in an environment like that, and you're reading this, you are probably part of the problem because you are keeping the stupidity alive by struggling through the process and letting management get something delivered. Best to step away from the stupidity and let it fail.
I have no reservations about making a 'reddit' comment in a thread named "The Motherfucking Manifesto For Programming, Motherfuckers". It's humorous, people.
I'm currently tasked with cleaning up a project which no one can explain how it all worked because none of the Programming Motherfuckers bothered to write any Documentation, Motherfucker.
You may be right about why, but I don't agree on what. Good names for functions/methods can tell a lot.
I feel like I am getting spoiled by Objective-C and Cocoa Touch APIs.
Is software good at amplifying or replacing people?
The idea that a system (software or whatever) of any complexity could lose every person involved in it, exist without problems by itself, and then new people could easily pick it up solely with the help of documentation is laughable.
I've always felt project management should just be 1 person going to each programmer/designer on the team and saying "Hi, are you on schedule? Do you need me to clear any roadblocks or clarify any requirements for you? No? Good day to you, sir."
That is effective project management. Anything else is just spinning your wheels.
Second time today I am quoting this from "Peopleware" by DeMarco and Lister:
Sharon knew what all good instinctive managers know:
The manager's function is not to make people work,
but to make it possible for people to work.
That actually comes after this anecdote:
One snowy day, I dragged myself out of a sickbed to pull
together our shaky sys- tem for a user demo.
Sharon came in and found me propped up at the console.
She disappeared and came back a few minutes later with a
container of soup. After she'd poured it into me and buoyed
up my spirits, I asked her how she found time for such
things with all the management work she had to do. She gave
me her patented grin and said, Tom, this is management.
As she walked away, I started to sip from the bowl.
Suddenly, I noticed blood flowing down my arm. Looking
over my shoulder, I noticed a knife sticking out my
back. "Ah, yes. The other side of management", I pondered.
Funniest part? I KNEW it had to have picture of Samuel L. Jackson on the page.
Bingo!
Damn I love satire. I've always said we can say more through satire in ten words than we can with reasoned argument in a thousand. As long as it's not overdone.
To Thomas' point, yes, the author of this piece socially-engineered the hell out of it. But that's okay. I can deal with one of these made-for-hn pieces every week or so.
Not more than that.
There's an important point here that outsiders consistently forget: it's tough to be a programmer. It's tough, and the people who are trying to help us many times are just huge pains in the ass. They say one thing and mean something else entirely.
One of my favorite things as somebody who tries to help teams is when I tell management what's needed: more team control, less micromanagement, more freedom to experiment with various things to see what works (and not only the things in the book). Most times they look at me and say "We absolutely want to get better! Just don't change anything"
Their idea of "agile" is 1) doing the same old thing but sticking a new label on it, or 2) following some recipe from a book or a seminar and not giving a crap about what the actual developers are saying.
We need to make these jokes. We need to keep bringing this up. I don't think folks are listening. But the page is also pandering, so it's a close call.
Not at all! Just try not to repeat yourself. Be creative. Invective can be a form of poetry. See, e.g., Gunnery Sergeant Hartman in Full Metal Jacket. http://www.youtube.com/watch?v=t8Nf1MK7lts
I started LPTHW last night and I'm 14 exercises in. And I can't believe the same guy who wrote the most gentle programming book I've laid my hands on...is all about "Programming, Motherfuckers! We fucking do programming, motherfuckers!"
You have achieved a zen I only dared dream of as a child.
Programming is a subset of software engineering. A large number of important disciplines surround programming, including ones that just join one programmer's output to another. To state that you can get by solely with programming is foolish if you are tackling a problem of any complexity.
Of course, reducing the overhead and improving the morale of developers is always a good thing, but somehow I don't think this is what you were implying.
Stop trying to be all boring and rational. We are busy ecstatically voting up an article in which Zed Shaw says "motherfucker!" numerous times, providing much mirth for all. Next up are funny cat pictures.
I know this goes against the old guard, but I'd much rather laugh at a post like this once in a while than have HN be serious and dry, every day, every submission. That's never going to happen, but I haven't gotten as much amusement out of a HN item and its threads in a long time, and that's of value to me.
It's an outright tragedy that any lighthearted submission immediately brings out people replying "flagged!" and lamenting that HN is turning into Reddit.
Kudos to Zed for pulling it off. If only it had been Lighten Up, Motherfuckers.
Software engineering is a subset of programming, particularly the subset that values unit tests, methodology, and a whole host of other bullshit over shipping code.
I enjoy when Zed is appropriately flippant (irony intended). While, I don't have experience working for any teams that consider "XP, Scrum, Kanban, Waterfall," etc, to be gospel, I can see that being more than "fucking" annoying.
That being said, I can see some people who haven't tried these methodologies as immediately devaluing them. Don't do that. As long as you don't view the methodologies as a silver bullet they can teach you a thing or two. Critically playing with something helps you think about why it works and where it doesn't.
(I'm not saying Zed is saying that they are not worth learning; in fact, I don't want to put any words in his mouth, especially because he's here and will probably weigh in, even though he's known for being so reserved and unopinionated.)
In all seriousness, all of the methodologies out there start out being used by some group of programmers. At this phase they're fairly successful since it's mostly programmers writing code and very little management overhead from non-programmers.
Eventually though, all of the advocates of these methodologies realize that it's management that buys what they're selling. Management buys the books, hires the consultants, pays the billable hours, and mostly in some desperate attempt to figure out what's going on despite their lack of knowledge.
In the end, all of these methodologies end up being more about management babysitting and less about actually writing the code necessary to get product out the door. In fact, I think even something like this, even though it's a joke, would end up with the same fate if it were taken seriously.
I had something along those lines happen at a company I worked at a few years ago, where the CEO was a notorious micro-manager. In desperation, I ordered him a copy of 37signals' Getting Real.
He apparently read it over the weekend, because the following Monday he announced at the managers' meeting that he was enlightened about project management now. Of course, he just latched on to one idea out of the whole book: that the ideal project team size was 3 people.
So what did he do? He drew up a list of 20 or so ongoing company projects on the whiteboard and assigned 3 managers to each project. Since there were around 12 managers, that meant that we ended up co-managing around 5 projects each.
Agreed. Furthermore, I would say that's true of most things requiring a lot of experience
The people who come up with the methodologies initially are probably the people who have needed them the most / longest. They had experience that informed the development of the methodologies not methodologies that substituted for experience. Therefore, these methodologies are more successful given people who could figure out a similar methodology independently and could conceivably be worse than nothing for people who couldn't.
But how do we get certified? It can't possibly be a valid way to work if there isn't a certificate program, or some test I can take. What about all the coaches!?
Zed is the ultimate troll whether it's intentional or not. He must spend a lot of time laughing at all the time & attention he gets for doing and saying silly things, things that people end up taking far too seriously.
The fact that I'm here commenting on this story saddens me.
Could be that people just aren't looking for the humour and fail to see that you're joking. Maybe you stand out because you tend to write what's on your mind without trying to spare everyone's feelings and that gets people talking, for better and worse.
This is interesting as a postmodernist critique of the ineffability of programming practice.
You have on the one hand, techniques with gurus, certifications and thick tomes. Juxtaposed with this, a completely undefined process, just do it, swoosh. Coupled with this is a heavy dose of skepticism, that the defined processes are nothing but snake oil, sold to incompetent managers in bloated companies, rather than practitioners of the art.
Normally Zed posts piss me off; but I've got to say this one is spot on.
Familiar enough to know that anything which has his name on it becomes pretty popular. Would this page have 91 upvotes if it wouldn't be signed "Zed A. Shaw And The Programming Motherfuckers"?
Maybe, maybe not. It's not just his name that gets the up votes, but the context which it provides. If you've read the previous stuff Zed has written, it kinda gives you context for this site, and adds to the humor.
You may be missing one thing "we" don't have to deal with that "they" most certainly do: insurance against bad programmers.
Lost of best practices, from the workflow methodologies you lampoon to the widespread use of (and reliance on) design patterns, only appear to exist to give bad programmers a way to contribute -- or at least to avoid them doing harm.
I hope people do realize this will not actually accomplish anything besides giving us a laugh today? In the long run, a piece of criticism that lays out exactly what goes wrong with these methodologies, when management push and prescribe them instead of (teams of) programmers adopting some choice techniques because they help the do their programming more efficiently, will be more effective. It could be quoted by motherfucking programmers to their motherfucking managers for years to come. This will fade away in a few days.
I'd like to propose that the first Monday of every month be devoted to hard tech content on a theme - starting with Monday, April 4th which will be Scala Day. Anybody else with me?
That reminds me of a (satirical) development process we have here in Brazil. It's called goHorse Process.
The site is entirely in portuguese but with a little translation help you can have fun too.
A lot of people use that word, motherfucker. Try searching for it on twitter, asshole. You'll be surprised how many of the tweets are unrelated, douchebag.
It gets the job done! <center> is deprecated (or not supported at all) in HTML5 but I'm sure it'll be at least a decade before we have to worry about that.
When I first came across Agile Manifesto, it sounded to me pretty much the same.. except for the PF references and mathafakas. IMHO, when you do not obscure agile method with management processes, agile is "programming, motherfucker!".
Who does that? I don't know anyone that actually does XP that does that. There's no such thing as XP certification, and I have never seen an XP class offered. There's not even an XP conference anymore.
It looks like there's a lot of programming going on there. The lack of continuous deployment has been an admission of omission by Kent Beck, but other than that, is it the fact that there is a meeting once a day and once a week? Planning of any kind gets in the way of programming?
I didn't say that at all. Once I worked with a guy who would work out the entire application on paper before even touching a computer. Think Fortran, C, and hardcore information theory. If he owned a laptop I never saw it.
His company has been profitable for years and years and years. So, sure, planning can work out very well and I do a lot of it too.
1. Write out a list of shit to do, using software written with some programming, motherfucker.
2. Do some of the shit, again using programming, motherfucker.
3. Test if that shit's any good, and if not then go fix it with programming, motherfucker.
Amusing at the very least, though I do feel some empathy with the sentiments expressed as well. I think the real trouble is its very hard to distil the act of programming into abstract 'methodologies' (I hate the [ab]use of that word) that are not language and technology specific.
It seems like this is basically just a way of the author saying "I can't be bothered to be accountable for my work or work in teams. If you make me test my code or talk about it I will curse at you and quit."
I wouldn't want to work with someone who believed in this philosophy.
Yeah, that whole mental ninja trick of saying a programmer who doesn't want to do your bullshit "process" isn't a "team player" has to stop. It's just a manipulative way of calling someone autistic, a nerd, anti-social, and other offensive things that aren't right.
I mean, I don't go running around calling you a cheese eating brown nosing smiling sales douchebag with no real skills other than talking and pressing palms do I? Then don't say I'm an "anti-social nerd", I'm pretty damn good at talking to people.
"This book is Copyright (C) 2010 by Zed A. Shaw. You are free to distribute this book to anyone you want, so long as you do not charge anything for it, and it is not altered. You must give away the book in its entirety, or not at all."
As such, if you can't afford to buy yourself a copy with the above coupon code, send me an email at (gregorylyons@gmail.com) and I will send you a copy.
Is this really #1? Like, is it really the most important thing I can read today?
Having read it: no, no it's not.
I agree with the ideology: it would be better if programmers instead of managers made decisions, but I don't think this piece expresses that very well. It also seems that the only reason this submission is at the top is that it uses "shocking" profanity associated with incest. I'm unimpressed.
I've generally held "motherfucker", when used as an insult, to imply incest. But I guess when self-applied as a synonym for "badass", it implies the mother of the ubiquitous second person. What the mother of a rhetorical abstraction might look like, and how copulation with such an entity might occur, I leave to the reader's imagination.
