DEV Community: Davide Boncompagni

dxday: A Report

Davide Boncompagni — Tue, 18 Jun 2024 09:00:00 +0000

Introduction

On the 14th of March we were at DxDay, the first conference organised by GrUSP dedicated to the Developer Experience.

It was very cool to see so many different focuses on the same topic, showing how delicate and articulated the DevEx concept is.\
GrUSP will upload the videos of the speeches in the next few months, but if you are already feeling the fear of missing out, we will try to give you the essence of the speeches in this article to give you a taste of what the conference was like.

What is DevEx?

Developer Experience is the study of how people, processes, culture and tools affect the ability of developers to work efficiently. This is a definition provided by Github in one of their blog posts.
As mentioned before, developer experience is a complex and holistic concept, and we need to understand that none of these aspects can overcome the lack of another area, if you want to improve it, you need to work on each topic: technologies, tools, processes, culture and people.

This means that building a good DevEx requires a lot of effort!

It's also a dynamic, evolving concept, and improving it is a continuous process, not a static goal.
But even small steps can contribute, so you should manage the improvement gradually and develop a DevEx improvement process rather than a single big action, dividing the effort required into subtasks.

Why working to improve DevEx

Pleasure in work brings perfection to work.
(Aristotele)

The main reason to improve DevEx is to increase productivity and quality in its broadest sense.

It's not only about increasing revenue, but could potentially lead to it. The goal is to remove most of the friction, reduce cognitive load, automate repetitive tasks, improve communication and processes, create a positive mindset, flesh out the company's vision and mission, and unleash the full potential of human capital.

Striving for quality, creating a trusting environment and being transparent about areas that need improvement could create engagement and a proactive tendency where employees feel they can contribute to improving the overall structures and start to do so.
However, the main output metric of DevEx should be increased developer motivation and perceived satisfaction.

Talks

Ok, with that concept disambiguation out of the way, let's talk about the conference.
First of all, 4 of the 7 talks focused on tools for developers and the other 3 on process management and culture fostering.
The speakers come from very different backgrounds, which might justify the different focuses of their talks

Tools focused talks

Let's start with the tools, Maxim Salnikov, Developer Productivity Lead @ Microsoft showed us the power of GitHub Copilot and its ability to understand the context of your project, a tool that claims to allow developers to request all the boring tasks that keep them in the zone, making it easier to experiment the world famous Mihály Csíkszentmihályi flow state. Such a very ambitious claim and also a very ambitious goal: to offer a pair programming experience without the need for a senior engineer and increase productivity.
If you live in the desert or come from another planet and have never heard of Copilot, take a look at this "magical" looking tool.

Talita Gregory Nunes Freire Engineer @ Spotify and Vincenzo Scamporlino Senior Engineer @ Spotify have demoed Spotify Backstage, a tool that allows you to easily build a developer portal, an interface that could aggregate all your utilities for your microservices, allowing you to have a schematic view of your microservices' dependencies for example, but also much more!

They claim to address issues such as discoverability, system ownership, fragmentation, duplication and context switching. The focus is on reducing cognitive load, improving collaboration and transforming complex software into manageable units. We also use Backstage for some projects at SparkFabrik and its adoption is growing every day, confirming it as the de facto standard tool for complex cloud project management. Oh yeah, I forgot, this tool is completely open source, great!

Lou Bichard, Product Manager @ Gitpod, talked about his groundbreaking and, in such cases, futuristic Gitpod, a cloud development tool that removes the pain of onboarding and transforms your projects into code-ready, globally maintained development environments, removing the abstraction of infrastructure in your environment, what Lou called outer loop removal, a production-like environment. It looks like VSCode but in your browser, a future where you can upgrade hardware resources without changing your PC.

And it's not just Gitpod's product manager who is betting on cloud environments, but also Francesco Corti, Principal Product Manager @ Docker, with his talk on the future of growing DevEx tools, highlighting how companies are increasingly interested in this type of solution. He also tried to foresee the future of AI tools, predicting a future where we will move to a whole team of specialised AI assistants that will help you not only to automate boring tasks, but also to create documentation, debug, deploy, make data entries, get feedback on requirements, respect and test your software, an environment where developers don't usually code, but ask AI to do it for them.

If you have never heard of any of these technologies, look for demos, tutorials and so on, because it takes too much effort to explain all their functionalities in this blog post, the good news is that there are tons of resources about them.

Processes and culture-focused conversations

As I said, it's not just about tools, history has taught us that: the aeolipile was the first steam engine, but it didn't lead to a revolution, probably because the Greek culture didn't need to replace servant work. For DevEx, it is also easier to demonstrate because we work in teams: communities made up of people with social dynamics that affect our ability to perform.

Abiodun Olowode, Senior Engineering Manager @ Factorial, introduced us to Documentation Driven Development, which focuses on process optimisation, and how this could shine a light on team collaboration and knowledge sharing, potentially reducing code churn and introducing a faster feedback loop that could accelerate development.
One thing we've too often forgotten is that developers want to know why something works the way it does, why one implementation was chosen over another, we can understand code but we can't always deduce the reasons behind it and it's not always possible to ask someone for an explanation, we need a more robust and shared tool like documentation.
And also this kind of development could lead to less intolerance about writing docs, because it became part of development, you don't have to pass back your whole implementation process to describe it, the task becomes progressive and manageable. However, it was cool that maintaining and developing a tool together could improve DevEx.

Thomas Khalil, DevEx Head of Platform & Site Reliability Engineering @ Trivago, with his beautiful allegory of the Wizard of Oz, described some of the behavioural patterns that people in the organisation tend to adopt in order to challenge the psychologically complex situations that our jobs require today, and how empathy and awareness could lead people to unleash their true potential.
For Kahil, DevEx is about deeply understanding people's needs, motivations and aspirations, building trust, finding answers behind their defensive behaviours without needing a guru, keeping processes adaptable and choosing metrics wisely, keeping in mind that they are and should be holistic metrics. Even though it wasn't the focus of his talk, I'd like to focus on Kahil's use of surveys to identify areas for improvement and employee perceptions.

Suffering comes from trying to control what is uncontrollable, or from neglecting what is in our power
(Epictetus)

This quote used by Kahil highlights the main problem of the archetypes he describes and reminds us to try to improve what is in our power and to take care of it.

Dulcis in fundo our Paolo Pustorino, Head of HR @ SparkFabrik with his talk focused on the influence of culture on DevEx, alignment of values, sense of community, engagement, commitment, caring, transparency and the importance of psychological safety as a driving engine of developer experience satisfaction. He gave a lot of information about the processes of recruitment, onboarding and also career paths within Sparkfabrik and how the company tries to support you along the way, asking you for feedback on relationships, core values, training needs and perspectives. He gave an insight into the company's goals, such as the pursuit of quality in a broad sense (not only technical quality, but also relationship quality, communication quality, which revolves around the value of transparency, etc.) and the decision to make cultural fit and team fitness the key guiding values required during recruitment in order to preserve the culture and DevEx quality within the company.

"The chef is not the best cook in the kitchen, but he helps everyone to succeed" is probably the most emblematic phrase describing the previous assumptions. He also talked about the so-called Expert's Deception, the bias that innovation is a process driven by exports when their main quality is to offer experience, assumptions based on the past rather than challenging the status quo, and the desire to avoid the Peter Principle with career progression.
He gave us an introduction to the Cynefin framework, which could help you to support line managers in their work, remembering that you need to avoid instilling fear to get people to perform at their best.

I hope that you now have a broader perspective on DevEx and that you understand that a good company culture usually coincides with optimising tool adoption, but no tool adoption can improve your company culture.

Metrics

We didn't talk so much about metrics to measure it, only Kahil did a little bit. We need to specify that we need to separate developer productivity or job performance metrics from DevEx metrics or job satisfaction.
Even if your ultimate goal is to improve productivity, make sure you have improved DevEx first. DevEx metrics could give you insight to better understand productivity metrics and could encourage hidden latent innovation processes.

One of the most popular tools in this area is the SPACE framework, which uses some performance metrics to gain insight into DevEx. It's an acronym that stands for the following concepts:

Satisfaction and Well-being: it measures how healthy and happy developers are, with a focus on psychological safety and satisfaction, worrying about workload and detecting and acting on possible toxic practices such as Compulsory Citizenship Behaviour (CCB) or lack of boundaries with personal life such as calls outside working hours. It also consists of assessments of personal goals and aspirations such as tool adoption and so on.
Performance: difficult to measure because the business outcome doesn't imply a quality outcome. To balance better quality and quantity outcomes, you will better separate the metrics for the two areas, allowing you to understand if you are sacrificing code quality to deliver fast, undermining developer satisfaction and increasing code churn with its associated costs.
Activity: Many activities such as brainstorming, meetings, or supporting a teammate are not usually evaluated by these metrics. Choosing the right metrics in this area could give you insights into quality, such as spending enough time on design decisions, code review, refactoring and identifying bottlenecks.
Communication and Collaboration: focus on information discoverability and dissemination, network metrics, role clarity, awareness, transparency and team member contribution to team fitness. These metrics could influence all other areas of the SPACE framework.
Efficiency and flow: the ability to complete work with minimal interruption or delay, measured by what is known as focus time. For efficiency, we could suggest the famous DORA (DevOps Research and Assessment) metrics: deployment frequency, change lead time, change failure rate and mean time to recovery (MTTR).

All these aspects could be measured individually or for teams, and we also have to mention that maximising one factor could have a negative impact on another, like for example reducing interruptions to improve flow could damage the collaboration of the team, it's not a law but consider that this could happen, so you will better have a holistic approach and also always consider that metrics by themselves are not reliable and could reflect other things, the choice of these metrics itself reflects company or team opinions and is influenced by irrationality processes.

Try to extract insights from metrics rather than using them as a driving force.

Conclusions

Unhappy the land that is in need of heroes.
(Bertolt Brecht)

DevEx focuses on improving the development environment with tools, but also in terms of a social environment that allows people to express their full potential.
A corporate culture less focused on workaholism and control and more on empowerment and trust contribute to DevEx, and in this sense could help the adoption of a transformational leadership style or Hansei framework, or encourage community participation and avoid silo mentality that could lead to a positive sense of identity with the larger organization and its members and could unleash Organizational Citizenship Behaviors (OCB) that consists in spontaneous mentoring, support, conscientiousness and sportsmanship that create virtuous cycles that put people in conditions to express their potential.

I don't know if future tools will move from promoting staying in the zone and achieving flow experiences to leading to Maslow's peak experiences, at least for those working from the Greek concept of Meraki, but as focused on Kahil's talk, the right tool at the wrong time might not be able to improve DevEx, and certainly gurus are not the answer, as Paolo also noted, we need to foster and nurture a psychologically safe environment with transparency, trust, communication, empathy, room for mistakes to avoid spreading fear because innovations arise from failure, so never lose the spark!

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.
(Samuel Beckett)

Open Source Day: A Report

Davide Boncompagni — Fri, 07 Jun 2024 09:00:00 +0000

Introduction

On the 7th and 8th of March we were at the Open Source Day organised by Schrödinger Hat, and it was a two-day conference full of enthusiasm and innovation in the framework of the innovative Nana Bianca coworker space in Florence, but if you were not there you can at least follow on YouTube their amazing talks https://www.youtube.com/@SchrodingerHat/streams or https://www.youtube.com/@SchrodingerHat/videos and the agenda https://2024.osday.dev/it/agenda.
As you can see there were a lot of amazing ones and I will try to help you decide which talk you should definitely follow.

Technology Trends

There were 2 main trends:

AI tools, especially LLM related ones, how to build LLM RAG based applications using open source tools from Hugging Face and Ollama.
WebAssembly and its wider implications for software development.

And there was also a "shadow trend", not an explicit trend, but an ecosystem of similar technologies, namely:

CDC (change data capture), CRDT (conflict-free replicated data types) and concurrent collaboration or real-time update platforms.

If you don't have experience with these tools, I recommend Stefano Fiorucci's talk on what an LLM application is, how it works, how to implement it, what it is and how to implement Retrieval Augmented Generation applications with Haystack, our Edoardo Dusi with his talk on WebAssembly, how it works and how it could become a new future standard due to its interoperability, versatility and great performance, Wasm component wrappers, integration with Docker and Kubernetes and much more, and Federico Terzi with a technical explanation of CRDT and what challenges you need to face to achieve real-time collaboration utilities.

My favourite technology tool talks

I will briefly report on my favourite talks and start with some lesser known extensions to a very famous tool, Iulia Feroli's talk, Senior Developer Advocate at Elastic, showed us how easy and powerful Elasticseach could become with the use of some specialised clients allowing us to perform sentiment analysis and semantic search for example.

Sentiment analysis is an NLP technique that allows you to identify the positive or negative polarity of a given query, while semantic search is the search or ranking of content based on contextual relevance and intent.
For example, you could analyse a list of customer comments and intercept those that could lead to an escalation, or perform a search without having to know the exact terminology (e.g. a search for 'brave' could also return 'courage' and so on).\
The client used to import LLM into Elasticsearch was Eland, the ELSER NLP model was used to perform semantic searches, she also did a little briefing on how vertex search allowed us to perform semantic searches and remembered that vertex search could also be used to search for similar images for example.

Noam Honig, creator of Remult showed us a new way from backend to frontend, a full-stack CRUD framework that removes all code duplication between frontend and backend like dtos creation, data validation and so on, providing ORM-like database interaction and archiving a Typesafe and DRY architecture. With a live coding session, he showed us how fast it is to build a full-stack application with Remult. It has a lot of features, but the one I find most interesting is the ability to do live queries, long-lived queries that automatically update as results change. It can be integrated with many JavaScript frameworks and many databases.

Give it a try, maybe with fast prototyping, and you will love the philosophy behind this tool with a clear focus on improving the developer experience.

Mario Fiore Vitale, Senior Software Engineer at Red Hat, talked about Debezium, an open source platform that enables Change Data Capture (CDC), the ability to intercept changes in your database and propagate them across different systems, which could be very useful for synchronising multiple linked data sources, data replication, updating or invalidating a cache, updating search indexes, data synchronisation or propagating database changes via Kafka or a WebSocket. CDC enables incremental loading and eliminates the need for bulk updates. Debezium captures database changes by monitoring the database transaction log, so it doesn't impact the database itself.

Other interesting technologies included Nanocl, a Rust alternative to Kubernetes that grew out of a study project, Irine Kokilashvili's talk, Camunda, a tool based on business process modelling (BPM), which is a way to orchestrate and describe complex microservices processes and flows, as shown by Samantha Holstine, LavinMq a very performant message broker described by Christina Dahlén, Scrapoxy the amazing web scraping Swiss knife by Fabien Vauchelles and finally Graziano Casto showed us Rönd, a lightweight Kubernetes sidecar that distributes security policy enforcement throughout your application based on OpenPolicy Agent.

A broad view of the conference

As you can imagine, an open source conference doesn't just focus on tools, but also on high-level analysis and experiences of open source development.

There was a focus on accessibility in a broad sense, not only for people with disabilities, but also for people with neurodivergence or temporary disabilities for example, and how to create an environment that helps them to be productive and satisfied with their work, improve their development experience and develop an inclusive workplace.
Also, although it hurts, I learned that Linux doesn't currently have great accessibility tools, so if you want to start an open source project for Linux, consider that we're trying to fill that gap!

Another topic was what open source is, its different forms, how to monetise or develop a business model for an open source project, how to protect it from being appropriated by big vendors and the differences between FOSS and OSS.

They also talked about the security of the software supply chain and how reliable open source technologies can be, with a presentation on the use of Linux in space missions.

There was also space for ethics, like a UNICEF talk on the challenge of making digital solutions and services accessible and 'profitable' for the most vulnerable, and also a focus on web sustainability, like that of our Valeria Salis, who wasn't able to be present at the event, but which you can watch from this link https://www.youtube.com/watch?v=KWK8Upl9-wU.

I would also like to focus on the talk by Andrey Sitnik, the maintainer of a widely used library such as Post-CSS and so on, who gave us a complete manual on how to manage an open source project, recalling how it is fully linked to relationship management, the need to give quick feedback, to trust contributors and to consider them as the people behind what they are asking for, inviting us to empathise with them, to gain insight into why, for example, your detailed documentation is never read as carefully as you expected, or to understand why some projects that you thought might be more popular are instead ignored despite their potential, to remember how the adoption of a framework or so on depends more on irrational processes than cold analysis.

Why Open Source

What emerged from the talks was enthusiasm and positivity, open source as a tool that could spread values of commitment, collaboration and tolerance, and develop social communities of mutual respect and status quo challenging innovation, a kind of friendly world utopia, a tool to indirectly promote a better world.
As PJ Hagerty's talk points out, don't expect this to always be true, we need to foster good open source citizenship ourselves first.

Nowadays many companies claim that their products are OSS as a marketing strategy, but this is not always completely true (especially for some AI tools) and some big projects started to change their licences to some more restrictive or sometimes closed ones.
However, open source adoption is still very high and it's growing, with more than 90% of developers relying on open source components in their proprietary applications.

But probably in the future, the need to protect large projects from being forked and the business models of the companies behind them, the adoption of open core strategies will change the definition of open source and it will only define projects where the source code is public/available for inspection and there will be a clear distinction between OSS and FOSS where redistribution will be free.
Until then, open source is still a philosophy, and to embrace it, to claim it, is to have a mentality around it.

And speaking of mentality, I want to focus on a term that is rarely quoted, but I think it should be a core concept related to OSS, and that is the autotelic concept.

Autotelic is an adjective that describes activities that exist for their own sake, because experiencing them is the main goal, but also people who do things moved by intrinsic motivation, not by wealth, fame, power research, not by concern for money, status, applause or recognition by others, and it's linked to the ability to experience flow more often and is used to describe some art, sport or play activities.

This perspective overwhelms the idea of contributors being driven by ego, which is relevant in open source development.

Public opinion perceives OSS as a tool that promotes free culture and considers it to be a more transparent system, and therefore a more secure system, without any dark patterns inside.
Can free access to source code be a professional standard in the future, demanded by people in the same way that we demand the components of a medicine in the package leaflet?

We don't know yet, a lot will depend on how events affect public opinion, whether people start to care more about concepts like their privacy and whether they start to trust open source software more than proprietary software.

Will FOSS continue to exist? Probably yes, because libraries or tools for developers focus on usage and if they're free it's easier for them to be adopted, also the development of these tools gives prestige to the people or companies that have worked on them and is also a way to create a process of continuous improvement.

The affirmation of open source lies in the transformation of users into active actors, able to report bugs and sometimes suggest new features, and this is very common in tools for developers, but still a little lacking in general-use tools for the general public.

There are also adoptions of the open source model outside of software development, such as in the arts or education, which probably need more resonance, and we probably need to spread the open source mentality beyond the boundaries of software development.

There are several challenges to overcome, but we hope that open source will be able to flourish, because "a mind is like a parachute. It doesn't work if it's not open" - and that certainly applies to software!