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.
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.
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.
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.
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"
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?
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.
I have no reservations about making a 'reddit' comment in a thread named "The Motherfucking Manifesto For Programming, Motherfuckers". It's humorous, people.
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.
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!?
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.
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.
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
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.
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.
"Kudos to Zed for pulling it off" ? C'mon, he's the prototypical "rockstar programmer", just putting his name out there and a few profanities is enough to push it to the top. Honestly, I don't mind the (debatable) humour of the submission as much as the fact that it's a case of "the message is the messenger". If this was posted by the random Joe P. Rogrammer (a) it wouldn't be #1 post in HN and (b) it wouldn't be welcomed with so many open arms.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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."
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 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.
296 comments
[ 3.9 ms ] story [ 219 ms ] threadNice try, Zed. <3
You have achieved a zen I only dared dream of as a child.
Oh look, a feature short by Goatse Man and 2girls1cup.
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...
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.
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.
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.
hell yeah.
http://www.youtube.com/watch?v=My-P4LssMsI
It seemed appropriate.
I agree with the parent comment. "Just programming" looks nice on a manifesto, but you need processes when you want to scale.
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 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.
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.
And yes, I did well actually you.
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.
Here's an example: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
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.
[Piling] bodies at [the door] can help, though.
FTFY.
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"
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?
I'm going to start a post-Agile programming methodology called, "Programming, Motherfucker." It'll be awesome.
http://twitter.com/zedshaw/status/23267170323
Only on HN would you see a topic called "Programming, motherfucker" and see a comment asking "But does this scale?"
http://dropbox.jedsmith.org/programming-motherfuckers.jpg
http://www.youtube.com/watch?v=avaSdC0QOUM
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.
right. kidding. love it. make t-shirts.
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.
I wonder why?
(This is gonna cost me some points, I am sure)
(That is gonna cost me some points, I'm sure)
http://www.youtube.com/watch?v=5PsnxDQvQpw
and this: http://www.youtube.com/watch?v=7vofXcC0rj4&NR=1&feat...
we really need to just to the thing on the right
s/just to/just do/
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.
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.
I especially like the inaccurate[1] and racist ending.
[1] プログラミング、マザーファッカー (puroguramingu mazaafakkaa)
e: I was referring to http://oppugn.us/posts/1300784321.html I did not notice the link was different.
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.
I just wish he hadn't built a caricature.
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.
I'd probably Wrong your post, then UnWrong it so I could Wrong it again.
5. an outcome of events contrary to what was, or might have been, expected.
6. the incongruity of this.
Seems fine to me.
Not if you run it through ReadBetweenTheLines().
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.
Ultimately the evolving community here will make the final judgement. I just feel that the guidelines can be adjusted to reflect what is acceptable.
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.
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.
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.
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.
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.
That path leads to http://www.reddit.com
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.
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.
Lighten the hell up - the message between the lines is that many programming teams are heavier on process than they need to be.
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.
On another note: sorry about your day.
- Douglas Adams in "Mostly Harmless"
http://www.russianpaintings.net/articleimg/malevich/malevich...
With a title containing 'motherfucker' ----- you should have known it wasn't totally serious.
Yak shaving means getting deep into a series of tasks that are apparently unrelated to your final goal, but which logically follow from it: http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_t...
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.
Now I'm going to go and do some programming.
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.