Jakob Wolman
Attending cphdevfest was a blast. Here are a few of my takeaways, and recommendations of sessions you shouldn’t miss.
I’ve learned that an enthusiastic consultant who has just returned from a conference is one of the most dangerous things for a software project. Inspired they will pull out the old, boring, reliable enterprise framework the whole application is built on, and replace it with an exciting new technology, with new programming paradigms and a framework that has barely come out of alpha. Don’t be that person. Be inspired, and adapt the knowledge to your context.
As with any bigger conference, you get exposed to many ideas, practices, and tools. Attending all sessions that look interesting is impossible, and sometimes you get disappointed with the sessions you choose to attend. Fortunately, all sessions are filmed and made readily available. It is not until after the conference that you understand that the biggest value comes from interacting with all the wonderful people you meet. To me, that is the biggest value of an in-person conference. I’ll share some of the sessions I attended and my takeaways.
In-person conferences are also a great chance to improve your sticker collection. Thank you Dylan Beattie for rocking 🤘 the stickers game.
Note — as this article is published all the videos have not been edited and released online, yet. So I am including links to the live stream, with correct timestamps.
Autonomous teams require great managers
Shameless plug. This is Gitte Klitgaard’s and my session. Everyone talks about autonomous teams, but few organizations realize the investment it takes. For teams to be able to make their own decisions, be accountable, decoupled, and deliver value you need a different kind of leadership than most organizations foster. At the same time, leadership is a skill that can be trained. In this presentation we share some of our own experience of autonomous teams, what we have observed worked well, and a few things that hindered the teams.
Unfortunately, my lightning talk on assessing teams was not filmed, but you can read the blog post instead.
How to be a rockstar developer
What started as a joke
someone should invent a language called Rockstar to confuse all those companies looking for “rockstar developers”
turned serious (kind of) when Dylan Beattie decided to create a specification of such a language. There is no such thing too stupid for the internet to build it — hence someone, or rather several people, on the internet implemented the spec. In this presentation you get a very entertaining journey of how a language is created, the considerations when creating a compiler, and a syntax. And of course, the grand finale where Dylan performs, live on stage, a program written in Rockstar.
Developer happiness
As a lot of research has shown (DORA, SPACE, DevEx, and much more) happy developers show results on the company’s bottom line. It is not about beer and ping-pong tables. It is about the work environment, including everything from company culture to proper tooling. Damian Brady did a great job of creating an overview of the research, and what it says. He used many examples from The Good Day Project that focus on personal flow. The research points to the difference it makes to write and ship code in an environment that is designed for the purpose, as opposed to being forced to use tools or processes not fit for the work.
Residuality theory
This talk by Barry O’Reilly was probably the one I was looking forward to the most. Barry’s research is about using random simulations from complexity theory to software design (paper here, book here). This is a complex topic that I have not fully grasped, but I enjoyed the talk. Software architecture IS a complex topic, and this is a systemic approach that I find appealing. There is a lot of theory behind the approach, but in my opinion, you can skip right ahead to how to perform the design. It is interesting to dig into the research about how NKP analysis and Kauffman networks are used to create a better system architecture. But you don’t need to understand all the details. As opposed to many other methods of software design, having something that is built on a foundation of research rather than best practice feels comforting. Make sure to watch the video to the end where Barry shows examples of how to design a system using the theory. Designing the simplest system possible, and then exposing it to stresses to create an antifragile system. I enjoy topics that require more than a single presentation, one article, or a cartoon to grasp. Designing a software system that survives unknown challenges is a complex task, and requires a lot of deep thinking to get right.
Practices of DDD
This presentation by Chris Klug was a great way to dust off my DDD skills. There is nothing new and revolutionary here, but a great overview of some of the practices used in Domain Driven Design, complete with code examples. It reminded me of the difference it makes to name your functions and variables correctly. And to have a strategy for that naming that is the same throughout the whole codebase. Practices like using value objects and creating anticorruption layers are patterns that can improve your whole codebase.
How to build a database
As a developer, I’ve often used databases, integrated with them, thrown data at them, and written lengthy SQL statements to get data back. But I’ve always taken them for granted. In this session, Liam McLennan showed how to build (a very simple) database in Typescript. Meet Wormwood. I found it interesting to reflect on the choices you make when designing your database, how your SQL queries are parsed, and how the data is retrieved. This was a great “how does this thing work” kind of session.