11. November, 2015

It takes years and hundreds, sometimes thousands of people to build but only one person and a moment to destroy me. What am I?

Answer (link goes to Wikipedia)

Jazoon 2011, Day 2 – Who do You Trust? Beware of Your Brain – Linda Rising

26. June, 2011

Who do You Trust? Beware of Your Brain – Linda Rising

Are you prejudiced? No? Do you believe that some programming languages are slower than others? How do you know? Did you measure it or is it a … gut feeling?

Let’s face it, we’re all prejudiced. It’s human nature because survival is more important than getting along.

The better question is: What influences this process? Solomon Asch did a couple of very interesting experiments on that. It seems that if a trusted peer group is wrong, we tend to tag along anyway. So if everyone in the team believes that Groovy is slow or .NET is bad, we just suck it up, even if we happen to know better. The interesting part is why we do it.

Of course, we want to believe that we consider all options, carefully evaluate the impact of confronting the group, things like that. Yeah, that does happen – if you have enough time. Under pressure, your brain will just twist your view of the world until it fits. This means MRI showed that test subjects of the Asch conformity experiments actually “saw” other line lengths than were actually on paper.

But there is good news, too: If one person objects, this illusion breaks. This explains how a group of experts can be utterly wrong about something. Since groups tend to think of anyone else as them, an outsider can’t sway their belief but an insider can. So next time your team is doing something obviously stupid, speak up!

The talk also included reasons for social loafing (why a team doesn’t get stronger if you add more than three persons). Or how it was possible that soldiers in the First World War made peace with the enemy while entrenched: They inadvertently formed a team with the ultimate goal of survival.

A very interesting and frightening aspect is that our view of others doesn’t influence us alone but it also influences the way other behave. Women get the same results in mathematical tests as men if they don’t have to tick a gender box on the test. If you think a team member is an asshole, he will be, even if he hates you. Subconsciously, you’ll send the necessary signals and he’ll comply to them. Conversely, if you know that, you can turn an asshole into a normal person just by treating them better.

Very good, important talk. If you have a chance to meet/see her, go for it.


The Psychology of Dictators

17. October, 2010

I just found this interesting blog post: A look into the Psychology of Dictators

If you’re interested in real psychopaths (i.e. not the movie type), then this is for you.

When you’re right, there is no middle ground

15. January, 2010

Yesterday, I attended a talk by Tom Schindl (he’s the guy behind UFaceKit and Qooxdoo, QxWT, etc.) And he’s working on e4.

During our little conversation after the talk, he stressed the fact many people aren’t willing to pay for bugfixes in Eclipse. He’d be willing to work on many of them but someone has to pay the bills. I nodded like everyone else. And we talked about Eugene Ostroukhov and his complaint ““Participate in community!” they said…“. And I immediately saw a parallel in my own history. I had a similar, painful experience with Ed Merks a while ago. That was about EMF and how badly it sucks. And that he didn’t listen to me.

I was mad because I was right and he just didn’t get it.

Yesterday, on the train home, I understood.

I’d like to introduce two new categories of programmers. Both are passionate and enthusiastic about software. The difference is that one group is pragmatic and the other idealistic.

Ed and Tom are pragmatics. They think: “Great feature, I like it, how much will it cost?” If it’s too expensive, they don’t get upset. They think about it, mull it around, consider their options. If there just is no viable way to do it, they can accept that. These people get money to write software.

I’m an idealistic programmer. I get money to stop writing software. That is, I get money to stop writing the software in my head and to start writing the software someone else wants. Not getting what I envision drives me up the wall.

Things can get pretty ugly when those two kinds meet. Because both are egoistic and both are right. It would make sense to make all the changes to EMF that I want. For me and probably a few others. It would cause quite a few problems for Ed, though (mostly because he’d get a lot of complaints by those people who are happy right now).

I’m asking for changes because I have problems. I’m not complaining about petty things. I need to bend EMF and SWT more than the API allows. To solve my problems, I just can’t accept the status quo. The API has to move. But my solution would cause problems for many other people.

Right now, I’m writing software which doesn’t have a lot of customers, so a stable, reliable API is not one of my goals. I can change my API at a whim and no one bothers. Eclipse has millions of customers and every change to any API will cause a tremendous amount of pain around the globe. Say 0.1% have a problem now? That would be at least 1’000 people complaining. One happy, 1’000 after your head. At least. How big is the pressure on Ed to make me happy?

So how to win? I think Linux has the best solution that you can get today. Linux has several release streams that strive in parallel. It’s not a bunch of forks, it’s a bunch of branches. People can hand in stuff that really isn’t ready for prime time. It can be incomplete. It can break other APIs. It can be an experiment. It can evolve. In Linux, there is the next tree.

In Eclipse, evolution is hard. You have to get new features and patches past people you don’t know, who have more experience in evolving APIs, little time and little incentive to hurt themselves. API in Eclipse is hard to evolve because IBM pays many of the core developers. If someone wants some obscure API and the Lotus Notes team will have a problem with that, who will win? The bug report (even with a patch) or your next pay check? There are only a few big commercial products on Linux. Eclipse, OTOH, was created to form the basis for commercial products (hence the EPL). Products that have life cycles between five and ten years. Ten years ago, we had Linux 2.2, KDE 1.0 and SuSE 6.3.

For IBM and SAP, the one year release cycle of Eclipse is way too fast. They have to spend a lot of money on developers just to keep up with all the changes going on in Eclipse and this is for things that can’t be sold to customer (i.e. which don’t earn any money).

So I agree with Bjorn Freeman-Benson that Eclipse needs a set of public git repositories and a low-barrier entry to these repositories (which means one-click install for the build system, no IP checking). It should be a playground, a place where ideas can grow. Not all of them will make it into the mainstream but at least, people can solve their problems without hurting too many others.

At the same time, I’m afraid what will happen when this comes true. But then, I’m an idealistic programmer. I believe that time will tell who was right and that we shouldn’t bother too much upfront.

%d bloggers like this: