Only on HN would you see a topic called "Programming, motherfucker" and see a comment asking "But does this scale?"
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.
I'm going to start a post-Agile programming methodology called, "Programming, Motherfucker." It'll be awesome.
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.
the communication and coordination isn't between
all 1,000 developers.
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.
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.
And yes, I did well actually you.
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"
[Piling] bodies at [the door] can help, though.
FTFY.
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 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.
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.
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.
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.
Lighten the hell up - the message between the lines is that many programming teams are heavier on process than they need to be.
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.
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...
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.
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 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.
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.
With a title containing 'motherfucker' ----- you should have known it wasn't totally serious.
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.
That is effective project management. Anything else is just spinning your wheels.
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.
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.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.
(This is gonna cost me some points, I am sure)
You have achieved a zen I only dared dream of as a child.
Nice try, Zed. <3
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.
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.)
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.
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.
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.
right. kidding. love it. make t-shirts.
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 mean... It's kind of childish. Using profanity to fake coolness and rage driven by allegedly unique insights and experiences...
Meh.
The fact that I'm here commenting on this story saddens me.
Still, I fear the message may get suffocated by the style.
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.
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.
we really need to just to the thing on the right
s/just to/just do/
"Mine's the one that says 'Bad Motherfucker' on it."
In contrast I thought the Cluetrain Manifesto was better developed: http://www.cluetrain.com/
I wonder why?
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.
Motherfucker: 40 occurrences
Fucking: 18 occurrences
Fun thread. It's ok to cut loose sometimes.
- The PM methodology - introduction into the workflow.
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.
EDIT: I cannot believe I just Motherfucking upvoted all of you Motherfuckers.
I wouldn't want to work with someone who believed in this philosophy.
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."
http://learnpythonthehardway.org/
And download it for free, including checking out all of the .rst files that make the whole book.
Deleted comment
If you know your shit, you don't need all the process wazz around you - it just happens.
Reminds me of: http://halfarsedagilemanifesto.org/
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.