February 20, 2022
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
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
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
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, 2020
The 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.
December 14, 2019
Today I want to talk about something that has been bothering me for quite a while now - the side effects of how we teach people to use frameworks, libraries, tools, …
It’s an issue I’ve observed a lot over the years. To the point I have somehow trained myself to immediately notice it when I see it. It’s present in conference talks, blogs, articles, video tutorials, code samples, … virtually any type of learning material that shows Java classes in packages. A lot of those materials are created by people whose knowledge and intentions are unquestionable. I’m full of respect for the great work those folks do. Yet I can’t help but notice how many of them involuntary introduce to young developers a very bad practice.