Recent Posts
-
October 23, 2022
Operational vs. Strategic DevX
It is 2022, and Developer Relations (DevRel) and Developer eXperience (DevX) teams are to be found in almost any organization whose offering has anything to do (even if very little) with software developers. Many prominent examples prove that DevX-done-well significantly contributes to the organization’s success. Way more organizations hope to replicate the success story by merely “sprinkling a DevX spice” on top of their traditional marketing/sales-driven practices.
There is nothing wrong with that per se. A better developer experience doesn’t hurt anyone. But building it sometimes does. It may be challenging, confusing, or even frustrating for DevX professionals to constantly confront their goals with sales and marketing objectives that do not account for the nature of the target audience. Here are some hints on how to approach the situation if you are one of those professionals.
-
February 20, 2022
The macroscale of micro frustrations
I have experience with two GPS navigation systems. My Android phone has Google Maps. My car also has one, powered by TomTom. All things being equal (as when I drive my car) both are in direct competition. I have to put my trust in one of them. I can’t objectively tell which one is better. Yet, somehow I tend to use one of them often and avoid the other.
In this case, my decision-making process seems as irrational as the ones software developers have while adopting frameworks and tools. So I got intrigued and tried to debug and backtrace it. The more I think about it, the more I believe both are influenced by the same perception of reality.
-
February 10, 2022
From DevRel to Developer eXperience
At the time of writing this, the DevRel team at AxonIQ consists of four people (including me). We are two Developer Advocates, a Community Platforms Developer, and a Learning Experience Designer. The flat structure makes perfect sense at this team size. But our plans are huge, and four people can only cover so much ground. Clearly, the team needs to grow.
Instead of just rushing to hire a few more folks, I started asking myself how the team would look like in, say, two years from now? What roles and responsibilities are crucial and aligned with the company’s growth? How should those be organized? I like to have a plan. Even if only to change it later on. So here is one. And I’m going public with it. Perhaps it may help other folks facing the same challenge.
-
February 09, 2022
What dev heck?
There are a lot of publications explaining how crucial DevRel (Developer Relations) and DX (Developer eXperience) are for software vendors. It seems more, and more of them establish such teams. The goals they hope to achieve probably vary a lot. Yet, according to the 2021 edition of State of Developer Relations report, most often, such teams report to marketing. Is DevRel a fancy name for developer-focused marketing then?
There are also plenty of posts about what the Developer Evangelist and Developer Advocate roles are about. One can sense the struggle to convince others that those are actual professions and need to be appreciated as such. There is always (at least indirect) relation to revenue generation. It’s like those folks feel guilty that what they do, does not directly translate to dollars or euros. I can’t help but wonder why that is. I mean, do you know an HR professional or an accountant worried that their work does not generate revenue?
So this post is my take on the whole DevRel, DX, Evangelism, Advocacy, … thing. I’ve spent over 10 years on the field and have a “strong” opinion that I want to share with you. That does not make me right about any of it. My experience shaped my opinion. I understand yours may be completely different, so you are more than welcome to disagree with me.
-
August 30, 2020
Data classes in Java
I recently joined AxonIQ to help them evolve their Developer Relations to the next level. One of the things I am currently evaluating is the steepness of the adoption curve of Axon Framework and Axon Server. One of the things that catch my attention was that, in almost all examples and demos, the classes representing events, commands and queries are written as Kotlin data classes (here is an example).
It got me thinking and last week I put this poll on Twitter
Say you work on a project primarily written in #java and it needs a lot of data classes (only fields and methods for accessing them). What would you use to avoid the boilerplate code? Please RT for reach.
— Milen Dyankov (@milendyankov) August 17, 2020The tweet received some comments and suggestions about solutions and approaches I wasn’t aware of. I thought that may be the case for other people too. So in this post I’ll talk about the options one has to implement a data classes in Java (and JVM languages). I hope it’ll help readers pick the right approach for their own use case.