STFUDD(chriscontinanza.com)
chriscontinanza.com
STFUDD
http://chriscontinanza.com/2010/09/10/STFUDD.html
10 comments
Sure, there are some productivity benefits of the "STFU and start writing something" part, but this post itself has a few contradicting points. If everything is wrong in some context, why should i care about writing README and tests first at all times? Say when starting a project using a new language, I don't bother writing tests because I know I'll probably revisit for a rewrite soon enough, and by then my tests will be better. It worked better for me this way. How did I know that? Hmm sometimes I stopped and asked myself what approach to take so I just STFU & take the same approach later. Oops that violated STFUDD in the first place :)
It is late night, and i'm trying to practice the SRHNDD ("Stop Reading HN and write something") so STFU and post something interesting.
Nitpicking, but is this any sort of conventional syntax for defining a predicate? I've never seen it before, and I don't find it particularly intuitive...
> ∃ {C(x) : x is a context}
> ∃ {C(x) : x is a context}
It looks straight out of my college course on logic. The backwards E is the existential operator. C is a verb. The sentence means "a context exists".
That's clearly the intended meaning, but what it really says is that there exists a set whose elements are of the form C(x) where "x is a context" and C is left undefined. This, of course, is meaningless. Understanding is left as an exercise for the reader?
The notation (C(x): x is a context) actually means "C(x) is shorthand for the following sentence: 'x is a context'". C is not undefined, it is the template "___ is a context".
I guess the way the brackets are used may not be standard and could be confusing.
I guess the way the brackets are used may not be standard and could be confusing.
[deleted]
I know what the existential operator is, and C is a predicate, not a verb. But I've always seen predicates defined using lambda calculus (or just English)...this notation makes no sense to me.
How do I say this nicely? This seems like something written by a 20-year-old, somebody who has worked in academia, volunteer projects, or a startup. Or put another way, somebody from an environment where endless talk prevents work from happening.
In timebox-driven development, every so often you have to produce something of value. So while I've never said STFU to a team, everybody knows that discussion has to start and stop based on the reality of doing something (which the author seems to be big on) Or better yet, the discussion continues all along; the topics and depth of discussion changes as the team moves forward.
Here's a little tidbit: in a corporate situation, once a team starts working at any degree of efficiency at all, the real problem is getting the rest of the business to understand and agree on what the team is supposed to be getting paid for. Lots of work can go into "business alignment" -- getting people on the same page. Technology teams become business decision-support teams. It makes sense if you think about it. Most of the time the real reason something isn't fixed is because people never could agree on exactly what the problem is or how to fix it. To the unaware and impatient, this can certainly seem like "endless talking". In fact it can become "endless talking" -- or not -- depending on the people skills of the team members.
So yes, if I were working on a volunteer team in a startup situation -- a place where there is no immediate customer and both the problem and solution are unknown -- I'd say we have to start putting some code down and getting more of a basis to talk. But I'd never say STFU. I don't know if the author thinks he's being cute or not, but that's just asinine. He's writing an article that applies to 30% of all X, generalizing to the rest of the group, and making sweeping profanity-laced statements in an attempt to drive his point home.
Unfortunately, no matter how many times you say "fuck", how much predicate calculus you use, or how confident you are, you can still screw the pooch by not knowing wtf you're talking about.
I'm not going to get into the whole "context is king" part of this because there's too much to straighten out in this brief format. He's on to something, just draws the wrong conclusion.
This article would have worked better as an "sometimes I get really upset and want to say STFU and start coding!" instead of a "This is reality, get used to it".
If the author is reading, keep the good work coming! Just be careful with generalizations: you can get away with them when you're right for 85-95% of the cases, but in this case it doesn't work.
In timebox-driven development, every so often you have to produce something of value. So while I've never said STFU to a team, everybody knows that discussion has to start and stop based on the reality of doing something (which the author seems to be big on) Or better yet, the discussion continues all along; the topics and depth of discussion changes as the team moves forward.
Here's a little tidbit: in a corporate situation, once a team starts working at any degree of efficiency at all, the real problem is getting the rest of the business to understand and agree on what the team is supposed to be getting paid for. Lots of work can go into "business alignment" -- getting people on the same page. Technology teams become business decision-support teams. It makes sense if you think about it. Most of the time the real reason something isn't fixed is because people never could agree on exactly what the problem is or how to fix it. To the unaware and impatient, this can certainly seem like "endless talking". In fact it can become "endless talking" -- or not -- depending on the people skills of the team members.
So yes, if I were working on a volunteer team in a startup situation -- a place where there is no immediate customer and both the problem and solution are unknown -- I'd say we have to start putting some code down and getting more of a basis to talk. But I'd never say STFU. I don't know if the author thinks he's being cute or not, but that's just asinine. He's writing an article that applies to 30% of all X, generalizing to the rest of the group, and making sweeping profanity-laced statements in an attempt to drive his point home.
Unfortunately, no matter how many times you say "fuck", how much predicate calculus you use, or how confident you are, you can still screw the pooch by not knowing wtf you're talking about.
I'm not going to get into the whole "context is king" part of this because there's too much to straighten out in this brief format. He's on to something, just draws the wrong conclusion.
This article would have worked better as an "sometimes I get really upset and want to say STFU and start coding!" instead of a "This is reality, get used to it".
If the author is reading, keep the good work coming! Just be careful with generalizations: you can get away with them when you're right for 85-95% of the cases, but in this case it doesn't work.
in a corporate situation, once a team starts working at any degree of efficiency at all, the real problem is getting the rest of the business to understand and agree on what the team is supposed to be getting paid for.
This happens in the consulting agency I work for, and we're only five or six programmers strong! There's far more situations, for us, that would be solved with more communication and not less.
This happens in the consulting agency I work for, and we're only five or six programmers strong! There's far more situations, for us, that would be solved with more communication and not less.
Akin to 'grow a pair' programming.
See also the "shut up and calculate" interpretation of quantum mechanics.
Links for the curious:
If I were forced to sum up in one sentence what the Copenhagen interpretation says to me, it would be 'Shut up and calculate!' [http://en.wikiquote.org/wiki/David_Mermin]
If I were forced to sum up in one sentence what the Copenhagen interpretation says to me, it would be 'Shut up and calculate!' [http://en.wikiquote.org/wiki/David_Mermin]
Please.... No more acronyms... I can't take any more...
"Conscious."
Zed Shaw imitation fail
"In STFUDD ... you don't write anything at first. " "STFU Driven Development ... its How quickly can we Shut the Fuck Up and write something?"
So, which is it - don't write or write quickly?
I also fail to understand this part:
"we're all full of shit. And that's why you test. That's why you write a README."
How exactly "tests" and "README" connected to "we're all full of shit"?