This week I attended and spoke at the Newcrafts conference in Paris. The following is a mix of notes and personal observations I wanted to share, centered around some of the talks I saw there.

Romeu Romera: Bourdieu's Social theory and our work in tech

I had never attended a talk by Romeu before. I really enjoyed this one. Somehow I already knew that he uses a mindmap to support his talk. I thought he would use an existing mind map to navigate through the talk, but it turned out he was creating one during the talk. For me personally, a slide deck helps to keep track of the story, and it helps me remember all the different topics I need to talk about. Not so much for Romeu, who knew exactly what he was going to talk about, and didn't seem to forget to mention any important part, or make important connections.

The topic is one that seems close to his heart. Still, he called himself "not an expert", saying that this talk was an experiment. It turned out that he was hinting at the fact that the subject matter is vast, and he could only cover some parts of it during the talk. Still, the things he covered, maybe simplified a lot, were very impactful, and very interesting. I'd definitely recommend watching this talk once it becomes available online.

More than with any other talk, I think you can't help it but apply the ideas mentioned to your own situation when you listen to Romeu. He covered three parts of Bourdieu's social theory. The first part is about icons of power. The way you look and behave shows how much power you have. This modified appearance is called Symbolic Violence; an act of violance people in positions of power put onto themselves. I think in the context of conferences, being a public speaker is a great example of violence the speaker puts onto themselves. Personally, I often find it a painful experience (although I'll keep doing it as long as there's a way to help people do a better job in any way).

The second part of the theory has to do with Cultural Capital. Everyone has their own amount of cultural capital. Take for example the people in your team. Some will have more experience than others, a deeper understanding of design, architecture, etc. People with less cultural capital will be seen as lesser people. Having more cultural capital can also be an issue with speakers at a conference, where they will be automatically taken to be experts, to be better humans (or at least, better designers, programmers, etc.). They will be perceived to be more powerful, and more right. This isn't fair to either party; speakers, and attendees alike, but it's how the game gets played.

Differences in the amounts of cultural capital between people will result in Dissociation. The first thing that might happen is that you see a person with less cultural capital as someone you can ignore, not take seriously, etc. The other thing that could happen is that you'll feel that a person with more cultural capital than you is unreachable, and that they wouldn't be interested in even talking to you. Personally I can relate to this problem a lot. When I'm at a conference, it totally depends how I feel: if I feel like I have a sufficient amount of cultural capital, I'll be perfectly fine, and can speak freely with anyone in the room. If I feel that I lack cultural capital, I'm very shy, and generally tend to avoid other speakers, as I will quickly feel like an imposter, noticing a mismatch between the expected and the actual amount of cultural capital.

The third part of the theory is about Hexis, which means something like to what level you feel like you belong somewhere. Hexis could be considered "high" if you never doubt that you should be where you are now. It's low if you have doubts about your presence. Being self-condident is much appreciated, showing doubt is a signal of fragility, and it will look punishable. The immediate association I had, was how code reviews show a difference in seniority (which comes with self-confidence, never a doubt that you're in the right place). The senior developer is likely to provide a lot of nitpicking comments to the one who is more junior. The junior developer will likely have a hard time providing feedback to the senior. The situation gets worse if the senior is considered to be the boss/manager/team lead as well.

And this is where Romeu brings the discussion back to software development. The problem with some agile practices is that they assume equality in the workplace. Pair programming is easy if none of the programmers are the (perceived) boss. Retrospectives are easy if the (perceived) boss isn't there.

If you have enough cultural capital, and symbolic violence, you can ignore the problem. But if you have not, you can't. The problem is real. And of course, it's better if nobody would ignore the problem. It's also a good idea if the one with all the symbolic violence, in this case the speaker himself, doesn't provide a solution, because that solution would be made from a power position. Instead, we should all work together, so we can all feel like we belong here, like we're all equally important, like everybody can bring in their ideas.

Alberto Brandolini - The Gordian Knot

Alberto is always a joy to listen to. I found this talk very well-structured. He started out with some words about the book "Accellerate", which gives scientific support for certain practices we already considered to be best practices in our industry. One of the things so-called high-performing teams have is a short time between a commit and the release of that commit to production.

Being able to release code quickly to production requires a good culture, and that will be one of DevOps, one where there's a focus on quality, testing, and autonomy. What is culture? Alberto defines it as the accumulation of winning behavior in a group. And what is the winning behavior has a lot to do with the design of the system with which this group works. Alberto thinks it's very annoying how people ascribe a lack of quality, discipline, etc. to a mentality issue, or a culture issue that simply can't be fixed. It does seem like there are bigger issues, that can be fixed.

Daniel Pink's ideas about what motivates lead Alberto to introduce the "Pink Test" for software development teams. To be motivated, developers will need:

1. Autonomy
2. Mastery
3. Purpose

After showing several examples of teams that score different results on the Pink Test, Alberto concludes that a Bounded Context (a Domain-Driven Design concept), can help you score maximally on the test, because it will be an autonomy context; one where you and your team can work mostly on your own. You can show and practice mastery within that context, and you'll be fully responsible for only this part. You can't move responsibility to another team, or other people. So, you'll be motivated to make it work well.

In order to feel purpose in your work, you still need an extra ingredient: feedback. You need to know how to get feedback, when to expect feedback. Will you hear positive feedback, or only negative feedback? Do you hear it from users, or from managers? Seeing how your software makes its users happy, is very important for a sense of purpose.

Not receiving positive feedback, can easily lead to fear of changing things, because if you break something, you'll definitely get that negative feedback. If you fix it, it will be assumed to be normal. For me personally, many, many experiences come to mind where this was the case. In fact, even if teams have celebrate-with-cake moments, they aren't really satisfying, because they usually celebrate a milestone, in terms of finished work, but not in terms of appreciated work. In my experience, celebrations don't involve users, nor focus on how the users enjoy the work that was just finished. The people in the celebration meeting may even be quietly angry about how much money it has cost them, how much still doesn't work, or how their managers are already pushing for the next thing that needs to be done.

Fear of negative feedback, but also fear of not being allowed to do something that you and your team think is necessary for your project, leads to lack of motivation. If you take a look at the Pink Test again, having to ask permission for testing means you're not very autonomous. Being dependent means that you're likely not able to perform your work in a masterful way. It robs you of purpose as well, since it's not your own boat you're sailing, it's someone else's.

Alberto gets back once more to the idea of a bounded context, and besides its function in domain modelling, points out how it's going to be really helpful in establishing a place where people can feel responsible, and experience pride in their work.