Observability for emerging infra: what got you here won't get you there - by Charity Majors

The first talk was by Charity Majors and she discussed how the currently available monitoring tools have been left behind the current automation tools and systems that we have. The increase in complexity of our systems over the past years made the old-fashioned monitoring tools such as traffic and system load virtually useless in that they measure the wrong things. Charity suggested how the tools could be improved by focusing on observability instead of just system performance. For instance by letting applications write events to logs instead of just measuring server health. For me, the take away from her talk was that next to standard unit testing, I as a java developer should spend more time implementing code that reports on the functioning of the system. Not only when there is trouble but also when the system is functioning properly so that system maintenance gets more tools to observe deviations from baseline.

How Convenience Is Killing Open Standards- by Bernd Erk

Another talk that caught my attention was that of Bernd Erk, on how the cloud community is not properly producing standards, simply because we are not willing to spend the time, money and energy on this. Which is weird, because not doing so will result in severe problems in the long run. Without us, as a community, enforcing standards on the current cloud vendors, plug-in and plug-out of our systems whenever and wherever we want, will simply not be possible because the configuration of each cloud is different. No standards in the long run will ensure vendor lock in and thus drive up costs. Why is nobody addressing this? We cannot expect vendors to put much energy in it as it would hinder their progress and sales. Who do we think should put time and energy in implementing objective standards? Governments that lack the necessary knowledge for doing so? Bernd asks us as customers and as a community in whole to demand that vendors use the same standards. We should formulate open standards for containers, as these are the multiplug tool of the future to bring our systems to the different clouds. Besides containerization, quick continuous delivery/integration (CI/CD), also requires standardizing deployment and environment configuration in a similar way.

Come listen to me, I’m a fraud! - by Joep Piscaer

Joep Piscaer gave a reassuring talk about imposter syndrome. This is feeling that you are constantly fooling everybody into thinking you’re qualified to do your job. It is rooted in a severe lack of confidence in one own’s skills compared to others. Joep gave funny examples how this affected his development and his career, and how you could try to overcome it. First, with great hair. Secondly by stopping to compare yourself to others. It is impossible to adequately estimate their level of expertise anyway. He told us how he works on his own insecurity by e.g. repeating the silly morning mantras in front of a mirror telling yourself how competent and smart you are. They really do work. Another great way to tackle your insecurity is writing down any compliments that you receive of others on your work in a small book. Reading back the compliment now and so often helps you gain more positivity. Especially after setbacks. Joep’s talk was one of the funniest talks that I had seen in ages and spot on. We underestimate the effect that this syndrome has on our community. It prevents people speaking out when they are stuck in their work, and accepting the help of others, in a fear of losing face. Joep made this issue discussable, focusing on the irony and humour in it, instead of the shame most of us feel when talking about it. Well done!

Upskilling and Uplifting Women in Tech with Empowerment, Encouragement, and Support - by Tarah Cleveland

Tarah Cleveland talked about her experiences in tech, both as a student as well as a young professional, that made her realize why there is a shortage of women in our field. Young women often have not learned to code during their teenage years because it was discouraged as not being a female hobby. When they start their education this gives them a severe disadvantage. She was often treated as being less of a programmer because of it. With a lot of blood, sweat and tears she struggled through her education but finally found her spot when she started to work for Target. Here, not only her tech skills were valued but also her soft skills. In the past years in the role of product owner she created workshops in which the basic skills of coding are taught in a fun and quick way to people that do not have any technical skills yet. Mostly to women in jobs at Target that were considered to be superfluous. They hoped to retrain them for the open tech jobs at the company. The workshops were a big success, most of the women participating could start working in one of their tech teams after finishing the workshop. This shows that you do not have to have a so-called (sexist & racist) “coding brain” for working in tech. There are no special abilities involved in learning to code, just training. Everybody can code. And we should stimulate this for people in dead-end jobs. Give them the tools to get back on the job market. Especially within the same company, this would be a better solution than layoffs. But most importantly, the women liked it, showing we can easily draw more women if we stop labelling coding being “complex, math-related, male-orientated stuff” and start giving them a chance to enter the field without prejudice.

Fight, Flight, or Freeze - Releasing Organisational Trauma - by Matty Stratton

The final talk I would like to discuss it that given by Matty Stratton on organisational trauma. Just like in people, the thought processes within organizations can be permanently damaged after encountering events that influenced them in a very negative way. An inappropriate fight, flight or freeze response to a situation can be considered to be just as bad for its outcome in business as posttraumatic stress syndrome in daily life of an individual. One way to treat post-traumatic stress within organisations is by planning therapy game days. These real-life simulation games focus on creating and automating the correct physiological response to traumatic incidents by practicing the response. E.g. by using planned failure injection. More importantly, a safe environment should be created in which no blame is placed on anybody after mistakes. This enables teams to quickly learn from their mistakes and adjust their responses accordingly. Finally, post-mortem talk about the incidents and its repercussions and consequences will also help with the team processing any emotional trauma after the incident. I found Matty's talk very insightful and recognized that certain management decisions that I encountered in the past were indeed very similar to post traumatic stress responses when I was working in the organizations where productions issues could have severe financial consequences or create life threatening situations. I hope Matty's suggestions on how to decrease the damaging effects of post-traumatic stress reach a broader audience than just tech people, so that they can alleviate the negative consequences of this response in such organisations on a higher level.

Thank you for taking the time to read this blog. I would recommend DevOpsDays Amsterdam for anybody interested in IT culture and its effects on organisation's efficiency. I know I will be there again next year!

Christa Falk