The Emotion Of Development

So I’m going to go off the the track of my usual humor posts and talk about some more serious issues. Though talking about emotion seriously is somewhat of an interesting concept. Serious is itself an emotion contrasted by cheerful or lighthearted. So maybe not completely serious, but I digress.

Technology is very objective at the root level. A PC is either turned on or it isn’t. You have a net connection or you don’t. Your program works or it doesn’t. There’s no real in betweens, though complicated state can make it seem that way. Code doesn’t, assuming a sane environment, lie to you at all. It doesn’t know how to lie.

However, people write code. People have emotions. As such code can often give hints of emotion. A developer may give a function a funny name, or leave a frustrated TODO for a troubling piece of code. Code organization can often show if someone was in a rush to get down, or had plenty of time to give things organization. It is similar to novelists leaving pieces of themselves in books they write.

The term technical community is often used in a way to make emotion seem weak. A great example I’ve seen of this is in the Ruby Code of Conduct thread. Emotions seemed to scare people. However it’s a simple fact that they are there. People are there. Emotions will be there. Their fear is a strong testament to this.

In a business setting, emotions are a bit less subtle. Workplaces have rules and professionalism to abide by. While differing depending on company culture there’s always a general rule of keeping the code in line with some form of customer need. A developer may have to give their emotional attachment to structure on hold to get some feature out in time. It’s what can make development in a workplace stressful for those who have always kept to such philosophies.

Then you get into open source. While some of it is business backed there are often projects volunteer run. This means that compared to business there is a tendency to more emotional freedom. Though also important to note is there is still some basic restrictions the likes of a social contract. Size of the project can additionally affect how much emotional freedom is available. Even in these cases it is often that the group decides their emotions align with a single group or individual.

There are other technical elements besides code that can be linked to emotion. A project that uses strictly open source libraries can have a different set of emotional attachments than someone who is working with one connected to more proprietary software. This also ties in with licenses. There are different values behind which license a project chooses. Do you wish complete code freedom? A compromise between free and commercial use? Maybe it’s public domain so anyone can do whatever they want with it. It’s all there for us to take in.

So what action can be taken with this knowledge. First and foremost when discussing someone’s code with them you’re also in a sense commenting on some form of emotion. The developer may want a straightforward explanation, or may be nervous a need something more lighthearted to help them out. Consider also that code may not be great because the person didn’t have a chance due to some external pressure. Try to look for these signs, and acknowledge the emotion of development.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.