Hacker News Reader

Comment by tmorton | Hacker News Reader

I think this is a great idea. The ruby community is a wonderful thing, and part of that is reflected in the technology.

However, the original Agile Manifesto was powerful because it made tradeoffs. "We value X over Y", even when Y is a valuable thing. For this HDD thing to take off, it has to make the similar tradeoffs explicit.

For example:

  We value readable code over runtime performance.
  We value open-source frameworks and libraries over developing for popular ecosystems.
  We value inclusiveness, diversity, and respect over pure meritocracy.
  We value teaching, learning, and improving our craft over short-term productivity.
  We value creating wealth over capturing wealth.

View on HN

That's a really nice feel-good list, but it also doesn't make a lot of sense in several cases:

"We value open-source frameworks and libraries over developing for popular ecosystems."

Most popular ecosystems nowadays are all open-source frameworks and libraries? Unless you're talking about Windows or Mac OSX, I guess?

"We value inclusiveness, diversity, and respect over pure meritocracy."

These are not mutually exclusive goals--even if they are, I'd rather have really good code, even if written by a racist or sexist, than bad code (period). Again, I'm not sure we have to make that choice.

"We value creating wealth over capturing wealth."

What does this even mean? This is a programming language, ffs. Your statement makes sense in, say, the heyday of APL or Smalltalk or some other very vendor-specific language, but that's not quite the case today. Are you talking about not doing data-mining to monetize your fellow man? About not creating yet-another analytics or ad platform? What then, exactly, are you driving at?

"We value teaching, learning, and improving our craft over short-term productivity."

Again, not mutually exclusive. Also, part of learning and improving your craft is knowing when a quick hack is the right answer instead of a full solution.

I think this comment shows exactly what I was getting at. If no one disagrees, the happiness manifesto will die in a sea of nods and shrugs. :)

> I'd rather have really good code, even if written by a racist or sexist, than bad code (period).

That's a perfectly valid choice. In some cases, it's a completely correct choice. But that's not the tradeoff that I want to make.

Take a look at the original Agile Manifesto: http://agilemanifesto.org/

Sometimes you can have it all: good process, good tools, good individuals and interactions. But when they conflict, the AM says that we should favor the individuals over the processes.

I'm saying that as a development community, we should favor inclusiveness and respect, even at the cost of (some) technical merit. Similarly, we should favor open-source infrastructure, even at the cost of the App Store audience.

"That's a perfectly valid choice. In some cases, it's a completely correct choice. But that's not the tradeoff that I want to make."

The problem is that it's used too often to shun or control people that don't agree with a political ideology. A good example of this is the Mozilla CEO.

An open and "accepting" community should also accept people they might not agree with..otherwise you should't call yourself open, accepting, or inclusive.

> An open and "accepting" community should also accept people they might not agree with..otherwise you should't call yourself open, accepting, or inclusive.

Being "accepting" does not imply being accepting of those who are themselves intolerant, and indeed the meaning and value of liberalism dissolves into something toothless and even dangerous when interpreted that way.

If the Russel's paradox aspect of this you bugs you, then label the position "accepting of all other beliefs except those which are themselves intolerant." In practice, this is what most liberals, even die-hard ones, subscribe to.

Nah, I think that you've still got to accept and engage with people who are intolerant of others--again, you yourself are a member of that group.

It's not usually a big deal if you are interacting in a strictly professional capacity: if they let their bigotry get in the way of good business and engineering and teamwork, you can drop them on those merits alone irrespective of their reasons for being subpar engineers or businessmen.

He was CTO for quite some time, so it appears people were OK with him making technical decisions.

Edit: Also, is there evidence that he was a vastly superior choice? I'd accept sufficiently advanced technology even from a wicked murderer.

Doesn't that depend upon the project? What if I want to build for the App Store audience? Should I be shunned by the "community".

I don't like the idea of associating political views with technologies.

Can we use this as an excuse to drop Node.js, please?

After all, Javascript was created by a homophobe. We should use a more minorities-friendly language and not encourage the use of problematic technologies made by bigots.

Edit: also, someone claimed that a lead maintainer of the Linux kernel is a rape apologist. That's good enough to drop Linux, right?

`also, someone claimed that a lead maintainer of the Linux kernel is a rape apologist. That's good enough to drop Linux, right?`

If that was proved to be the true, then I would want him or her to work on Linux from jail.

I read it as "given a choice between A and B, I'll choose A". So...

When choices are available for a software library, pick an open-source one over a well-tested black box, and perhaps even contribute. If the black box is the only reasonable thing out there, then use it.

Rather than try to hire by a strict ordering of skill, create an environment with varied viewpoints that can all be heard. (Of course you still hire among the top candidates, and avoid bad coders)

When choosing between two jobs, one of which creates a new product that people love, and the other cuts into someone else's profits through algorithmic/technological superiority, pick the first one. If you don't have such a choice, it's not relevant.

Last one I'm not sure about, but one possibility is "go learn Haskell/Lisp or experiment with the latest algorithms/libraries in the evening rather than work 18 hour days for your job." If you really have to get something done for work, by all means do it.

It's not "always do this", but rather "when you do have the freedom to choose, pick this"

The Agile Manifesto is the opposite of tradeoffs.

"We value X over Y" is not a trade off, it's a dogmatic claim.

"We should do X in these conditions and Y otherwise" is a trade off.

For each of the items you list above, I can come up with a few scenarios where doing the opposite of what the Agile Manifesto says would be the better approach (and that's probably one of the main reasons why hardly anyone takes that Manifesto seriously these days).

It is interpreted as a dogmatic claim but it wasn't intended to be one. After all, the very essence of the Agile Manifesto is to always be thinking.

There's that bit at the bottom of the Agile Manifesto: "That is, while there is value in the items on the right, we value the items on the left more." I think the spirit of it is to try and discourage outright dogmatism. That said, I'm coming to think of the Agile Manifesto as a collection of four rather ugly false dichotomies. It's the assumption that those 4 pairs of things are somehow separable that's what's really dogmatic about the manifesto.

For example:

Processes and tools can often be one of the best ways to improve interactions among individuals. See Scrum, which is hardly a panacea but sometimes it works wonders.

For a large project, comprehensive documentation is essential to producing working software. Ideally the documentation should be so comprehensive that it pervades the very fabric of your application in the form of good factoring, command-query separation, etc.

Contract negotiation can be an important first step in customer collaboration. Everyone needs to know where everyone else's needs, boundaries and comfort zones are.

Without a clear plan, how can you be sure of the best way to respond to change? See: Duke Nukem Forever, WinFS, RIM.

I think you might be confusing "tradeoff" with "compromise".

"I'm willing to give up some valuable-thing-Y in exchange for more X" is a textbook example of a tradeoff.

> We value inclusiveness, diversity, and respect over pure meritocracy.

Heh, until not long ago a "meritocracy" was seen as something good and desirable. Nowadays it seems to be something bad (at least in some circles). Funny how things can change.

Meritocracy is good, but not when it creates a homogenous pool of points of view.

points of view aren't all equally valid. Example: any pov about something that can be factually checked.

Sure, but if you shut out people you'll never find out if they're valid or not.

What does that mean? I can generate an infinite amount of nonsense ideas. Or worse, a good amount of superficially-nice-sounding-but-terribly-flawed ideas. You can't consider every "point of view", if only from the fact that there's limited time.

The guy that coined the word in the 1950s used the word in a negative sense. http://en.wikipedia.org/wiki/Meritocracy#Etymology

I must admit I never read the school book definition of the word - so yeah, maybe I'm not understanding meritocracy.

To me it means: The words/opinion of person with the most expertise on a certain topic should have the most weight in a discussion/decision.

In that sense I don't care about gender, skin color, religion, etc. as long as the person knows what he/she is talking about. So I don't see how it would be opposed to diversity or inclusiveness.

The one recurring problem with meritocracy is that there is a strong danger of misdefining the measure of merit.

(In the case of discussions of the tech industry, a common error of this type is the equation of "success in the environment as it exists" with "merit", which makes the claim of meritocracy neatly circular, but its not the only way this can go wrong.)

> "The words/opinion of person with the most expertise"

That's oligarchy, or a hair's breadth away, rather than a recent ideal of meritocracy. The problem is that it's all too easy for the "smart people" to become the ones who just run the show without consideration for others' ideas on their merit. That is, "meritocracy" as applied to individuals vs. their ideas can rapidly result in very different things. And it's not always so easy to distinguish between the two in the moment.

Part of the problem is that over the past few years, we're beginning to learn that our collective sense of who our experts are, who we do/don't listen to, is broken. Even those who would self-describe as being very meritocratic easily end up having massive blind spots based on gender, etc. So the bit about "inclusiveness, diversity, and respect" hits to the community trend towards efforts to acknowledge and deal with these problems.

The idea that expertise matters is fine.

Where meritocracy gets bad isn't the "merit" part, it's the "-ocracy" bit - the idea that people who have the most merit get to call the shots.

It's problematic in all sorts of ways. First, who gets to define merit? Well, probably the meritocrats. If we assume they're rational agents (which we must, by definition), then they will choose to define merit in the most self-serving manner possible, in order to consolidate their own position, status, and power. And even if we don't assume they're perfectly rational agents (which is more likely, if contradictory to the basic idea behind meritocracy) we should still expect to see self-serving definitions of merit that grow organically out of everyone's bias for their own perspective. Consider the history of racial bias in IQ testing, for example.

Second, by the people who merit the highest in a meritocracy have different backgrounds, and therefore slightly different interests, from everyone who's lumped together in the lumpy part of the bell curve. This is inevitable - in a world where education costs money, you'll have a hard time getting to be the most educated at anything without coming from a position of relatively greater economic privilege than others. Pythagoras was no peasant, nor was Galileio or Newton or Einstein or Feynman. Therefore, we should not assume that they will make decisions in accord with the best interests of society as a whole. And their current circumstances are probably sharply different from most others' too. Probably the person who knows more than anyone else about investment banking is himself (I think we can safely assume it's a he - see below) an investment banker. That by no circumstances means that this person is the most fit to dictate investment banking regulation. It's true that he's got the expertise to draw up a set of rules that will encourage almost any outcome, but the outcome we should all be most worried about is the one where investment bankers get outlandishly wealthy at the expense of everyone else.

Finally, it's impressive how effectively people can use their pre-existing merit to influence others' ability to acquire merit. Often their ability to do so is so well-honed that they can wield it almost constantly without even realizing they're doing so. See: White men in academia, white men in fraternities, white men in software development, etc.

Ok, I see how this could turn bad. But what is the alternative?

In our current system people "run the show" who are good at politics and know how to use their elbows. In my books that's not any better than what you described.

I think viewing it as a pure good is the odd view. Most people recognize that, A. It's impossible (who is doing the evaluating?), B. That it leads to a single vision/set of experiences dominating, C. That it ultimately leads to dissatisfaction amongst the majority.

The way I understand and use the word meritocracy is as an opposition to nepotism (or other forms of favoritism) - i.e. promoting people because of who they are (founders/first/oldest/high-born/...), not because of what they do, as in meritocracy. As such, I see/use "meritocracy" as something purely positive.

  "We value readable code over runtime performance."

Yes, well, that's obvious given Ruby's God awful performance. I think this is a mistake that puts Ruby squarely in the "toy language" bucket.

There's a strange, delightful joy in finding that I agree with every statement here and in the original post/repo

I think that's a great idea-want to start us off with a pull request? :)

Done! https://github.com/scottefein/the-happiness-manifesto/pull/7

Reply on news.ycombinator.com