Software Totemism | Hacker News Reader

Software Totemism

250bpm.com

79 pointsrumcajz46 comments

I agree immensely with this. I recently attended DebConf 15, (the conference for Debian), and in an introductory session some long-time attendees were asked to express why they attended the conference. What they said were things like “This is where all my friends are.” and I even heard someone say “Debian is my family.”. This is emphatically not why I go to any conferences. I go to conferences in order to advance the state of the field by listening to talks and getting to personally talk to people also working to advance the field, in this case the Debian GNU/Linux operating system distribution.

I did get a lot of that done, but this spirit of chummy familiarity was pervasive. Every problem of getting people to cooperate and collaborate more was approached as a problem of not enough socializing. But I don’t want to socialize with lots of random people. I want to make Debian more awesome, not shoot the breeze with random people with wine and cheese (yes, DebConf has a Wine and Cheese event in addition to the large social outing). Beyond having a title and summary for talks (and some rather narrowly scoped BoF sessions), there were no concerted efforts to get people in the same field of interest to get to speaking about common topics and solving common problems. I voiced a complaint to someone about this, that in order to find anyone who was interested in the topics I wanted to discuss I would have had to basically randomly wander around and ask every person I met about what they did, which would have taken a lot of time and energy. But the person I talked to saw it as a good thing to essentially force me to socialize with people even though pure socializing was not my goal.

Optimizing groups to be more social to the detriment of all else is not what you want to do if your group has any other overriding reason to exist beyond being a pure social club, since you exclude people who would rather work towards the group’s proclaimed goal than being social and chatting with friends.

Socialising is very important (hell, why are you talking on HN if you don't want social interaction)? The teams that have lunch together perform better.

http://ridiculouslyefficient.com/boost-employee-productivity...

I think the precious little time at Debconf is good for socialising. It seems ok if that's the main purpose. There is already plenty technical discussion in Debian mailing lists.

1. Strawman. I never said that socializing was unimportant. But socializing is not the only way to actually collaborate. You don’t have to be best buddies with your collegues to work with them. “Having lunch together” does not imply being friends with people, but it could certainly imply having a set time to talk more informally about more general problems without a set “owner”.

2. I was at Debconf for two weeks. I hardly consider that to be “precious little time”.

But you emphatically said that you do not go to conferences to socialise. That's the most important part of a conference. I daresay, it's really the ultimate goal. Otherwise, we could just all post screencasts online instead of having a conference. That would be a lot cheaper.

Emphatically not wanting to socialise sounds exactly like you think socialising is not important. A less emphatic "no" might still make it sound like you think it has some importance.

And two weeks a year is precious little time, if you compare it with having lunch with your coworkers every day.

You, (like many people, including the organizers of many conferences) keep conflating socializing with collaboration. I tried to make the difference clear in my original comment, and it was also the point of the linked article. Being friends with someone isn’t the only way to collaborate with them. It is simply a way to do it, and if you want to collaborate that way, then socializing is certainly important to keep that friendship alive. But if I want to collaborate as a professional colleague instead of as a friend, then no, I don’t think I should be expected to socialize with great masses of people in order to simply collaborate with some of them.

Neither of jordigh's comments said anything about socializing being the same as collaboration; in fact, the first claimed that socialization improves collaboration, implying that the two are completely different things. You're being preemptively and repetitively belligerent here.

I hate the conference socializing, too.

Having lunch with your coworkers gives you 250 chances per year to have an important work-related conversation. A conference offers precious little time, so it is important to be efficient in getting people together who have things to say to each other.

Funny, where I'm working you'll get nasty looks when "talking shop" at lunch.

Important work conversations happen at work. Not on the break.

In that case, why spend your break with your work colleagues?

You may not believe it, but people can actually talk about other things than work. We all have private lives.

At Pycon, there's a lot of socializing and community building going on, and those are very important. But if you really care about meeting people with specific technical interests in order to advance on some project together, there are plenty of strategies to go about that.

1) Give a talk about the technical problem you are interested in. People who also care will attend, and later meet with you to discuss the topic (and related ones) in person. Giving a talk yourself is probably the best way to find people interested in your subject.

2) At Pycon you can book open spaces (e.g. https://us.pycon.org/2015/community/openspaces/). There are basically a bunch of small rooms, and you can book some time slots to assign the room a certain topic, and see whether like-minded people will show up. (You could also do something non-technical like board games...)

3) After Pycon proper, there are usually a couple of days of code sprints (e.g. https://us.pycon.org/2015/community/sprints/). This gives people the chance to advance an open source project together. Some people use that as a way to meet in person with other developers, or it's possible to recruit new developers for a project.

Yes, things like those “open spaces” are exactly what I like to see! Very nice. I also remember the tables they had at a CCCC I once was at, with lots of people from a project sitting and working at tables, with large signs on each table so you could simply walk up to a table and talk to the people there about their project.

Also: The “big names” in the community, the more famous people, do not have this problem. For them, the “unplanned social chaos” model of conference organization works perfectly – lots of people are constantly coming to them to talk about the topics that they are interested in – they don’t see the problem, they live in a kind of bubble. But in reality, this is a symptom of the problem – people seek out the big names because they are the only persons that people know of who are intestested in the topic. There is no mechanism to make people aware of each other’s interest.

At the risk of sounding provocative, Debian are a political effort first and a technical project second. They're much more of a target platform than a leader in their own right.

As such, I'm not surprised that there was significantly more interest in self-preservation and socializing than in any technical work. I don't recall Debian ever pushing boundaries.

Debian has plenty of technical work done within its boundaries. (Don’t forget the pioneering work that Debian did with its package format which was greatly superior to that of Red Hat’s RPM at the time.) A distribution is not created by simply downloading all software from the upstream authors, compiling them and burning a CD. Simply read the Debian Policy manual to get a feel for the vastness of an undertaking which creating a distribution really is:

https://www.debian.org/doc/debian-policy/

Of course they've done technical work, they're a distribution. Of course they have a distribution standard, they're a large committee-driven project. None of these are pushing the boundaries as such.

I never said anything to the contrary, but rather that those are all secondary to the primary political goals. A distribution having a detailed technical policy does not refute any of this.

I don't support Red Hat, either. dpkg's original conception was a tarball-based package management Perl script with rudimentary substring match dependency processing. It evolved as time went on.

GNU is the same. Politics first, technology second. They've generally been much better at both, however.

Any time you put more than two people in a room together and ask them to finish something, there will be politics. The only thing you can do is make sure everyone has some goals that are the same as the organization's. In a corporation, this is achieved by paying people to be responsible for certain aspects of the company's operations. In a volunteer organization, this is accomplished by having the people in the organization socialize around the organization.

Everyone has their reasons. Some people are motivated by producing beautiful functional code. Others are motivated by the ideals of Free Software. Still others want to use the community to sell hardware. At the end of the day, as long as they're all moving in a similar direction, the movement is successful.

Whether or not the movement is a good thing depends on your values and motives.

> Debian are a political effort first and a technical project second.

And that may well be what is wrong with the Linux ecosystem today. I keep seeing formerly technical "projects" go social over and over and over, with the inevitable result that it turns political and gets derailed from its technical efforts.

This in large part because going social attracts people that end up using the name and reputation of the project to ride political hobby horses (potentially for social ladder climbing outside the project).

You're doing conferences wrong, then. The entire point of conferences is the interpersonal networking. Online materials are far better way to disseminate information, the speaking sessions are literally a waste of time, just an excuse to get people in the same hotel together.

I can certainly do networking, but there’s a difference with that and pure socializing. When you network, you want to know that the people you’re about to talk to have some reasonable chance of being interested in your topics. In pure socializing, it doesn’t matter, you just mash as many different people together as possible and it’s all good.

When I network, I want to know that this group, here, at this time or in this room or at this table, is actually interested in a specific topic which I wish to discuss. I can’t do that with a conference of hundreds of people most of which are not interested in the topics I want to discuss.

A conference should not be simply an opportunity to socialize. If that’s how you do conferences, then you’re doing them wrong.

Debian is your common topic. The people who are there are interested in a topic you're interested in. From what it sounds like, you want to precognate that down to one or two people.

Networking is about meeting people you can get along with who maybe, one day, some day, if things work nicely, might have a mutual benefit. You don't begin it with a pretense about what they can do for you now. That sort of opportunism is phony and can be smelled from a mile away. Networking works best when you just meet people to become friends with them, then hope to figure out ways you can help them, as friends do. My experience is that people pay it back in spades.

If it were just about merits, resumes would be a thing that actually worked and were important. Conferences are about networking and networking is about socialization.

Yeah, it could be years before the networking you do today pays off. That's just the way it is. You're dealing with people, not machines. It's like dating, you can't magic up a spell to make someone like you. People have their own agency, but they tend to congregate around and like to help out other people who are friendly and helpful without expecting anything in return, too.

You think its "phony" when someone shows up at X conference transparently focused of talking about X?

You think its selfish when some knows how we wants to help, and wants to find the people he wants to help?

I feel like I am taking crazy pills, where technical content gets zero attention in a technical project. It sounds to me like the conference are getting taken over by vacationers who want to have a party week (possibly soft-embezzled by expensing an employer) pushing out people who care about the project.

It reminds of when the college resume padders took over the high school math club, and instituted a substantial membership fee to finance a trip to a math competition where they didn't actually compete, and I had to create a new club to gather people for math activities.

I feel like you've already decided that these people who value soft skills are garbage ("soft-embezzled"--please!), but what the hell, I'll feed the troll.

Every technical project--and I think you'll find few people within Debian who'd claim it to be primarily one, it's a social movement with a technical component--is fundamentally an interpersonal enterprise, and face-to-face interaction is exactly that. Positive interactions are the underpinning, in functional communities, of the assumption of good faith and the ability to work with people who do not necessarily agree with you; it is the difference between "ugh, Bob is such a prick and he's wrong" and "I like Bob, we disagree, let's hash this out." You may (think that you do) not need this. Most people do. And most people recognize that they're better off working within a culture of positivity, rather than the bizarre flat "professionalism" you've described in this thread.

Everything, always, is about people. Assuming otherwise leads inevitably to disastrous ends. I think Debian, among others, has done well to harness that truth. We aren't a bunch of meat robots, no matter how hard you assert it.

> Debian is your common topic.

What is necessary is a topic to narrow the scope down to be few enough people for me to actually have time to talk to most of them. I can’t (and I feel I shouldn’t be made to) talk to hundreds of people merely to find them. Also, I could be of more help to people who need help in a field I know something about.

> Conferences are about networking and networking is about socialization.

Why do you assert this, when my point was that it is not so?

You can't know ahead of time who will be useful for you in the future.

It depends on the conference I guess. At some of them the talks are pretty good and something you want to attend.

If the programme really never mattered then the organisers wouldn't put as much trouble into it that they do.

It sounds like you've had a lot of bad experiences with conferences let you down by not focusing on the technical discussion. I'm really sorry you've had to go through that so often. In thinking about your predicament, it seems like there's an opportunity here for the organizers to put together an online forum before the conference so that people can put in for being put into groups and sessions where people have specific things that they want to talk about. It seems like both you and the other poster you were discussing this with were equally bothered by the other's preferred activities of conferences. I think if you could arrange discussions ahead of the conferences, you'd enjoy your time a lot more.

Sounds like a good idea. One other thing which organizers should watch out for is not to create enormous distractions away from discussions and networking:

https://web.archive.org/web/20130808111450/http://ryanfunduk...

(Previously discussed here: https://news.ycombinator.com/item?id=6373983)

Seconded. I always find it hard at conferences to find people who are genuinely interested in stuff that I care about.

I recently finished three small projects in the sense, that there are no essential features, that I want to add in the near future. It is refreshing and I hope can level up the not really trivial analysis effort needed to actually define the limits of a project and yet be useful.

I wish this kind of "limited projects" engineering skill would be easier to learn.

I've written two major projects: a window manager, and a fuzzy matcher.

The window manager inherently requires a lot of configuration because everyone wants window managers to work differently, and even the same person will want to change how they use their window manager. So I've written about a dozen implementations of this; the most popular one one just wraps system calls as Lua functions, but it's also the most difficult to maintain because of the complexity of wrapping system callbacks with Lua callbacks and tracking them and allowing live code reloading etc.

The fuzzy matcher was written in one day, and I use it every single week day. It just uses stdin and stdout, and takes very few options. I haven't compiled it since I wrote it, and it's working beautifully.

So all in all I'd say the UNIX philosophy is a win.

I'm interested in learning more about the fuzzy matcher you wrote. What kind of problems does it solve for you?

Suckless.org disproves the authors thesis. Heck, UNIX itself disproves the thesis. A project can grow to include more compatible components, without needlessly cluttering each component. Finishing one program is not the end of all software development.

I think this is part of a larger issue of people making programming their lives. Our profession encourages obsessiveness more than most - and making your work your life is something people seek out! (just look at startup culture)

I find it makes finding professionalism a lot harder. Most companies expect you to be friends with your coworkers/boss/etc. and then leverage that to exploit their workforce.

I like the artist alternative he proposes. With github you can now take ownership of your work/contributions. You can go into an open source project and make a contribution and then never touch that software again - yet your accomplishment is something that's tracked and stays with you

Hmm, complicated.

I don't get the wanting to be anti-social bit, but I do get the part about projects that are sometimes too much about the social bit. Or rather, the stress that can create. I felt some of this at times, namely the idea of a project became that it must absorb all contributions, and trying to not offend people while trying to mediate that.

This is exactly what a project shouldn't do, and in many cases, it's a giant challenge.

OTOH, much of what spawned good OSS was people working together across company boundaries, and that means letting up a bit to let other people get their ideas in, even if those ideas aren't the ideas you neccessarily feel are the most important.

It's a hard balance.

I do like socializing with people I meet through OSS projects, but it can be hard to close the door and say "this code isn't good enough" and "I'm not interested in this" without being percieved as anti-social, or greatly overcommunicating to avoid percieved slights.

I do agree with one thing I did read about 0mq though, which was it wants to merge things first, and break things. I prefer more to see software that is designed and strictly looked after. The social element is definitely not first, but it sound be fun.

The problem is, with a lot of people in the game and not monetarily invested (this is free, etc), people can get their feelings hitched to the project more than they ordinarily should, if it was a business transaction -- they feel their price for spreading things or contributing should be that the big social element takes over and everybody gets their code in... which is anti-quality in the long run.

Again, balance -- and really only you get to feel this when things start getting really busy.

I do believe software can be finished though. If you're just continuing it to keep the community around, I think that's when you don't have a purpose. But that doesn't really happen unless you're doing it for fun (like a game) - and if so, great!

But yeah, the first goal of OSS isn't just to collaborate for the sake thereof. It should be for the purpose, and you can still enjoy the heck out of the collaboration part.

I think that UNIX-y "do one thing" projects kind of solve the problem. It's easy to reject a contribution as being out of scope: "This little program prints out contents of a file. Your patch that sends it via email is nice, but you should rather make it a separate project built on top of the existing one."

I've been involved at various times with both Martin and Pieter on the projects that motivated this article. The dichotomy here sounds compelling, but I think it hasn't any basis in reality at all.

Let's look at the data. nanomsg ("the technical endeavor") is, objectively, a project with declining activity, and little of any import has happened in 2015. [0] libzmq (the "social club") merges some 20 patches/week. [1]

Now, maybe this is because nanomsg is "done", and has simply already achieved its status as a "small component that does one thing and does it well" where nothing else needs to be added, while libzmq faces "strong pressure to add one more option, one more feature".

Except that nanomsg is now in its fourth year of unstable beta, and even its own mailing list is riddled with statements that things are so bad don't even bother to file bugs [2], features are "horribly broken" [3], and you should use a different project instead [4]. From my own experience deploying nanomsg in large environments, this criticism (from core developers!) is absolutely true.

One cannot look at these projects and fairly conclude that there is any tradeoff at all between "software as a social club" and "software as a technical endeavor". In reality libzmq is both, while nanomsg cannot even succeed at one. libzmq may be a social club, but it's a social club that ships.

Don't get me wrong, libzmq has plenty of problems, technical and otherwise. I am no champion of it. And it was totally plausible, in 2012, that the philosophy enshrined in nanomsg would produce a better library. I believed that.

What is wrong is now – now that we have the data – to ignore it and pretend that doubling down on a failing strategy is a good idea. What is wrong is to gloss the serious technical inferiorities of nanomsg as a "personality difference", or that the reason it is in a perpetually unusable state is because "we focus on the code".

For nanomsg to be healthy, it needs to do a real postmortem. Admit things aren't working. Think about why. Change the philosophy to something that isn't proven to be broken. Kill some of the sacred cows.

Instead, puff pieces like this are written, that tell stories that "feel true" to developers instead of addressing the real facts at any point. The software can never get healthy when this is the approach.

[0] https://github.com/nanomsg/nanomsg/graphs/contributors

[1] https://github.com/zeromq/libzmq/graphs/contributors

[2] http://www.freelists.org/post/nanomsg/inproc-bugs,1

[3] http://www.freelists.org/post/nanomsg/v07beta-released

[4] http://www.freelists.org/post/nanomsg/release-of-nanomsg06be...

Maybe you can help them with a postmortem? It's difficult to admit a project you spent a lot of time on isn't going to survive.

In other words the geeks has taken over the domains of the nerds?

Something i get the feeling started with the web going commercial, and people that was more interested in presentation and bullshitting than technical aspects smelled money and potential fame.

And it has been going down hill ever since...

Brief and well written article giving insights into how group dynamics shapes software development.

thanks

help me

I'm not familiar with what lead to this post but lots of projects on GH do feel like social clubs. It would be interesting if GH had a feature that, when enabled, would make all comments on a project's PR/issue tracker anonymous so that they can be considered purely on their technical merit.

You can still recognise people behind the words. I can usually tell who wrote a particular line of code within the projects I work with.

It is disingenous to pretend that writing software is a pure robotic activity that can be separated from its humanity.

There used to be a concept called "professionalism" where people didn't let their personal cultural biases crowd out contributors, and people applied their humanity problem at hand at work, and engaged in unrelated conversations on breaks and after work, not disrupting people who are working on the project.

The traditional socializing gets in the way. Making protocol working groups and manually implementing them. Or meeting at conferences to decide things.

The modern approach to contrast is a semantically versioned registry like npm. The next step is to do something similar with web assembly that can handle many programming languages.

Reply on news.ycombinator.com