And yet. Many developers aren't taught to evaluate coupling and cohesion directly. *I* was never taught to evaluate coupling and cohesion directly. I had to figure it out on my own. And I only did it after watching Simple Made Easy. So the talk somehow is special *to me*.
-
Show this thread
-
I talk to a lot of developers today who seem to have little-to-no experience evaluating coupling, cohesion, resource usage, error modes, etc. And I think our industry is much worse off for it. The concepts are difficult to learn. They're even more difficult to apply.
2 replies 0 retweets 2 likesShow this thread -
But, at the end of the day, I don't know how to make half-decent long-term decisions *without* evaluating coupling & cohesion. I have to evaluate a bunch of other stuff too! Much of that "other stuff" is actually more important than coupling & cohesion. But C&C is always there.
1 reply 0 retweets 0 likesShow this thread -
Which brings us to the best advice in Simple Made Easy. The advice which always seems to be completely overlooked. OUR OUTPUT FRIGGIN MATTERS!
1 reply 0 retweets 0 likesShow this thread -
Programmers love to debate types, tests, build-tools, and semi-colons till the cows come home. We tell ourselves stories about how we're doing The Right Thing. But those stories rarely have basis in actual outcomes–in actual artifacts.
1 reply 0 retweets 0 likesShow this thread -
For example, the phrase "fully unit tested," is developer for, "good." But that statement by itself says absolutely nothing about outputs. It doesn't say what will be easy to change, how fast it runs, what failures it might encounter. It doesn't say whether it solves a problem!
1 reply 0 retweets 0 likesShow this thread -
The ones who suffer from our navel-gazing are the ones we are supposed to be helping: our users, our businesses, and our coworkers Very few programmers talk about this. And that, to me, is why Simple Made Easy was, and continues to be, important.
1 reply 0 retweets 0 likesShow this thread -
Aaaaand I realize now I owe
@danluu an apology. I should not have said that he's unaware of the reality of modern programming. He just missed the point of the talk. That's all.1 reply 0 retweets 0 likesShow this thread -
Replying to @potetm
This is the thing about this talk (which I think is illustrated by the replies to
@hillelogram 's original comment) -- the talk is so vague that you can interpret it in many different ways. I don't think your interpretation is wrong, but I don't think it's the only one.1 reply 0 retweets 0 likes -
Your interpretation explains the "guardrail programming" thing in a reasonable way, but literally every other time I've seen that section of the talk cited, it's cited to mean that types = bad since types = guardrails = crashing, which (IMO) is an absurd viewpoint.
1 reply 0 retweets 0 likes
You might say that all of these other people are misinterpreting the talk, but if that many people misinterpret the talk, I think that saying that they're misinterpreting the talk is blaming the user. This is the perspective I personally have when I write, YMMV on this.
-
-
IMO, Rich's style is similar to PG's, in that he makes a series of strong but vague claims that could mean many different things. I don't know about Rich, but PG will often respond to criticism by saying that he was misread, even when the majority of readers have the "misreading"
1 reply 0 retweets 0 likes -
I don't personally find this very compelling, but that's my own set of biases (I have correlated beliefs like, Death of the Author, descriptivism over prescriptivism, harm reduction in UX, etc.). I'm not saying Rich would say that, but I think that's the defense presented here.
1 reply 0 retweets 0 likes - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.