Hacker News Reader

In political science, a fairly well-known basic idea is that the two ways to dissent are exit and voice. Exit means you leave and go somewhere else, and was common in early political eras when most civilizations were small and surrounded by plenty of nomadic/lawless regions to retreat to. As populations increased, voice (i.e. protest, class warfare etc.) became increasingly common. The classic reference on this is "Exit, Voice and Loyalty" by Albert O. Hirschman. It's been on my reading list for a while.

http://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty

For developers, it is swinging back towards exit, since the Internet can be considered a kind of virtual equivalent of the nomad regions to retreat to.

"Center-periphery" dynamics is the common term in geopolitics for dissent dynamics driven by movement inside/outside a core. Class warfare is the better known kind of dissent involving unionization etc. and involves fighting up and down a class structure.

Guilds, historically, were a medieval kind of institution that had characteristics of both exit and voice. The classic guild professions (weaving, masonry and in more recent times, things like typesetting in pre-lithography days) used their portable skills to leave kingdoms/cities and move elsewhere if they didn't like their current situation. This option was not really available to laborers tied to the land, and was essentially an urban phenomenon. This is the origin of the term "journeyman" for instance... apprentices who would follow master craftsmen around until they became masters in their own right.

Dude, that is fascinating.

Is there some way I can contact you?

I wrote the original piece. You can contact me via my blog http://ribbonfarm.com

Oh, it's you. I am already in touch with you, heh.

This is the origin of the term "journeyman" for instance... apprentices who would follow master craftsmen around until they became masters in their own right.

No, that's not right. When an apprentice finished their apprenticeship, they would usually have to leave their master's service. The openings for masters would be fixed per town by the guild, so journeymen would work itinerantly until they found an opening to become a master. Journeymen would work for a series of masters, and their relationship to these masters was entirely different to the relationship of apprentices.

The status of journeyman became institutionalised, so that the criterion for taking up a mastership was that one had travelled widely enough as a journeyman for some length of time and had crafted a masterpiece.

I've never heard of the idea of guilds organising flights: I should think that master guildsmen had more to lose than agricultural laborers from relocation. Perhaps if several guilds coordinated, it could be less than massively destructive. Where did you get this idea?

It may help to know that while journeyman and journey come from the same French word, journée (meaning, essentially, day), that journeyman simply means someone who is entitled to charge a day rate for his work. (Masters were the "contractors" of their day; they were paid for the project, and apprentices got to eat -- they usually paid for the privilege.)

Yes, the guild system and town laws often made the journeyman itinerant, but it wasn't travel that put the "journey" in "journeyman".

Interesting, thanks for clarifying. I assumed too quickly that journey in journeyman meant what it means to us today.

Don't quite recall, but I think it was from a book about cathedral builders or something. But I'll admit my knowledge of medieval guilds is largely superficial and drawn from books where it was a side issue rather than the main topic. Your description sounds like you know what you're talking about. Got any good references (books, not articles) worth reading to get a clearer idea of how guild economies worked?

I'm not an expert: I spent a bit of time about ten years ago researching the topic, back when there was a lot of talk about guild structures being appropriate to software development.

Epstein has an article on craft guilds in the Oxford Encyclopedia of Economic History: http://www.oup.com/us/pdf/economic.history/craft.pdf

Based on the other replies (which I greatly appreciate - thank you), I think I have a better understanding of the paragraph. I was particularly interested in understanding the author's distinction between individualistic and guild-minded developers. It seems to me that he is suggesting the following:

When a developer find herself working in a company that undervalues her, she will typically react one of two ways:

1. "Individualistically": Such developers might begin by bargaining for better terms at their company, but they are quick to leave the company to 1) consult, 2) join/found a startup, or (following way in the distance) 3) join another company. Individualistic developers invest time in learning new technologies to stay current, because their ability to be so mobile exists primarily because they can work in such varied environments. These developers still seek large windfalls, so they "hedge their bets" - taking high-risk jobs more often than most people. Individualistic developers are probably younger than other kinds of developers.

2. "Guild-Minded-ly": Such developers will respond to workplace injustice by leveraging their connections to find another job - probably at a company with similar specifications to the one they are leaving. A guild-minded developer might be an ex-Google employee who - over the years - has built relationships with people at Microsoft and Facebook. In order of preference, such developers seek jobs with 1) another company, 2) a startup, 3) themselves (consulting). Stock options are less effective at retaining guild-minded talent, because they are not as concerned with large windfalls. Guild-minded developers are probably older than individualistic developers, and they also probably want to stay at a job for longer.

The above is probably not a 100% accurate representation of what the author was trying to say. But if it is, I don't much care for it.

While it's true that some of us are more likely to work for ourselves, or tend to be risk-averse, or desire long-term relationships with a company, I don't think the author's division of mindsets encapsulates these motivations.

There also seems to be a lot of overlap between his divisions: Both sets of developers are active in the community (individualistic developers via open-source, and guild-minded developers via whatever a guild is - and probably via open-source, too); both developers are very mobile despite attempts to retain them; and both groups supposedly represent highly talented ("10X") developers as opposed to average ("1X") developers.

I found the article interesting - though I'll need time to digest it and form an opinion. But his decision to close with an articulation of this division is strange. It seems tangential to the larger point, which is that good developers (of whatever group) are important.

I think you hit the nail on the head already with the first part of this paragraph:

>>While it's true that some of us are more likely to work for ourselves, or tend to be risk-averse, or desire long-term relationships with a company [...]

Basically, developers with more of a mercenary mindset are more willing to work for themselves, while developers with a more guild-like disposition tend to be more risk-averse and/or desire long(er) term relationships with a company.

Both groups definitely overlap in terms of their achievements and community involvement. But how they see themselves in the market, and more importantly how they react to changing conditions, seems to be the primary distinction between the two.

Being a Forbes article and the general audience that the author seems to be writing for, I doubt that much of this is anything new for a HN audience. However, it's probably a good radar ping/wake-up call for the more general audience.

tl;dr Polarizing divisions make it easier for people to retain information.

It's quite funny because a group of my friends used to call ourselves the mercenaries because we had no loyalty to any existing company, and would leave in a heartbeat if the project was doomed or a bad manager was drafted in.

But there was also an element of guild behaviour in that anyone who found themselves in a good project/company tended to bring in others.

I think this is what the author was trying to convey, and the article does a fairly good job of providing information from and insiders prospective, even if it does objectify developers. I think most developers move between the two, what you stated seems to be very normal and 10x'ers seem to pick up other 10x'ers along their way. I have about 8 guys in my (guild) now and we float in between contracts and start-ups. I am working on funding of our next venture and I will be calling them in. When I do, they will come and that is very hard for someone on the outside to understand. Our dynamics work very different than other industries and it is very hard for people outside of it to understand. That is probably the think that I think made Steve Job's so formidable was his understanding of the dynamics of creative employees.

Drawing a superficial parallel to some other poorly understood or fictional organizing principle seems to be the author's main schtick.

http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...

One man’s superficial parallel is another’s thought-provoking analogy. I think a lot of what Venkat says loses substance – or even falls apart – under scrutiny, but I keep reading, because another lot of it hits on some key insights.

This is a style of writing that should be valued more for the questions it raises than for the ones it answers. As another example, take Marshall McLuhan; much if not most of what McLuhan says in e.g. Understanding Media is somewhere between flimflam and complete bullshit... but the mode of thought starts the wheels turning, and some otherwise solid seeming cultural assumptions are questioned at their core... and at the end I’m really glad I spent the time reading it.

Perhaps. But the danger of clean, attractive, reductionist metaphors and analogies is that the general public -- including decisionmakers in the business world -- tend to reify the analogies, and treat them like immutable laws of physics.

Witness, for instance, the rise and fall (and rise again?) of "The Long Tail." As a concept, the long tail certainly applies to some businesses. But not to all, and not nearly as successfully as the concept's author once claimed. But the business world was frenzied with long-tail fever for years on end. "Long tail" became the buzz-phrase of the day, even in companies for whom the concept made no sense whatsoever. People with no understanding of the underlying principles could, nevertheless, grasp the surface-layer metaphor -- and, in so doing, assume that they understood the whole thing. That's a dangerous mindset.

So there's a sort of Faustian bargain in all of this. Appending a nice metaphor on top of a concept increases the likelihood that the concept will be disseminated, talked about, and taken up. But, at the same time, it invites intellectual laziness and fads of half-baked thought.

These clean and crisp ideas are dangerous if you just repeat them (news stories, cocktail parties, management retreats), but not if you use them as a way to evaluate your other ideas, plans and so on. I do agree completly with how annoying these things get, like your long tail example, when repeated so often.

I totally agree. The problem here is not the creation of these metaphors though, but their elaboration and reception. And the bigger problem is that we already carry around so many obsolete or suboptimal cultural concepts without subjecting them to scrutiny despite changed social circumstances or improved technology. I think continuously trying to both (a) collect granular data by immersing ourselves in its context so we can sniff out bad aggregate explanations and (b) come up with new metaphors for what we see is essential – the former keeps us honest, and the latter extends our mental reach.

As you say, the problem is just grasping the surface metaphor without examining the details. For myself, I like having the surface metaphors as a way of storing and communicating ideas, because once I’ve established that someone has a deep understanding of a concept, I can talk about it at a high level with a high data transmission rate.

Rather than move the mountain by unionizing and forcing big employers to pay up, skilled and connected developers can simply go around the mountain and disappear to the slightly better job down the street. As long as you are wired into a community of talented developers (and perhaps willing to relocate) you will have options. Spending years trying to "fix" a BigCo IT group from the bottom up is not likely to be the most rewarding use of a talented dev's time.

Just to let you know you're not alone, that one went completely over my head as well.