info.michael-simons.eu

This is gonna be the first of four parts accompanying my talk with the same name: Running free… A developers story of development. which I held in March 2020 at the inaugural launch of dev.next. I’m grateful that Venkat Subramaniam gave me the opportunity to do this.

Sadly, dev.next got cancelled respectively postponed due to the 2019–20 coronavirus pandemic.

I had created a readable version of the talk in hope anyone finds this motivating or can draw something for themselves out of it. I’m happy to have it now and I’m gonna share it in five parts over the coming weeks. If anyone finds it useful, I love to hear your feedback.

Overview

• Running free… A developers story of development (this)
• Miles are my meditation (Part 2)
• Why do we overwork and burnout? (Part 3)
• More lessons learned (Part 4)

Running free… A developers story of development.

This is “Running free”, a talk about a developers story of development. In this post I will tell you bits and pieces of my story that I hope you might find useful.

This talks needs a couple of warnings. The first – and shorter warning – it’s a personal thing, the standard about me page doesn’t apply. The whole talk is probably an about page.

I am gonna share a lot of personal stories and more important, personal recipes and strategies to cope and tackle various things. It should be obvious, that these approaches may work or may not work for you. They work in most cases for me, but your milage will vary.

Am I the right person for this?

I’d say, it depends… On a good day, of course I am. I’m confident in what I am doing, I am aware that I’m good at what I am doing. On a bad day, probably not.

There are actually tons of days where I

• Feel bad about me
• Feel bad about the stuff I do
• Overwork
• Stress out (myself, my family and colleagues (Hello, Gerrit… ))

But… let’s focus on the good days and keep it with Dajana here:

While I actually have training and I am certified to train other people for a job in computer science, i am not a personal coach and I have never been trained in coaching other people. I can only share my experiences the same way a lot of people shared their experience with me.

The talk will contain a couple of quotes from people I like and whose input helped me to rethink a couple of things. People and the network you’ll build over the course of a career are much more important than technology. Always remember that: Value relationships, in both directions.

So, let’s get started: who is this developer?

About me (Standard Edition)

Let’s start with the usual “About me” slide. My name is Michael Simons. What do we have here:

I work for Neo4j, the graph database company. We have a lot of cool things out there. First of all, the graph database with the same name and then the thing that I’m working on with my friend Gerrit Meier: The Neo4j-OGM and Spring Data integration.

Of course I have to brag around that I’m one of the Java Champions. It’s one of these things that made me really proud, actually. How did it come to this?

The slide explains it as well: I’m the current lead for a Java user group named EuregJUG, which I have been running now in the 5th year with great success. In that role I’m also actively involved with the JavaLand conference. I’m also the author of a couple of books: The first german Spring Boot 2 book and “Arc42 by example”,

Before I was at Neo4j, I worked most of my professional life at ENERKO INFORMATIK in Aachen, Germany. In between I briefly worked as a senior consultant for the well known German consultancy INNOQ.

In good moments I am able to honestly say that I’m proud about all of these things. In some others, my imposter syndrome kicks in and doesn’t let me realize that this is actually something.

At this point you’d usually find the company slide or slides, depending on how much marketing and legal material one is obliged to show but I like to quote Sébastien from RedHat here:

We are not just developers.

Sébastien runs the Riviera Dev in France and they have a track named this way about exactly that topic.
We spoke briefly about this talk here and the track name immediately clicked with me for a couple of reasons.

Hopefully it is clear that thinking about yourself as a Java or .NET, as Go or Rust developer or whatever
language you prefer these days, narrows the number of options and choices you might have.
So from a professional point of view it is of course a good choice to think as “I’m a developer”.

But thinking of oneself as just a developer and probably focussing on gaining appreciation from that single source makes you vulnerable and insecure.

First of all, we are humans, with different needs and hopefully, different interests and resulting from that, different inputs.

About me (Additional Edition)

So, I am a father of two, a husband to a beautiful wife, I cycle, run, read and do a lot of more things. I am probably a few more other things.

The things I do change over time, sometimes but less often, the things I am do too. It’s important to distinguish between something you need to be and something you do. Those are not the same (and please don’t get me started about “I have a wife” vs “I am a husband” or the same with “I have two kids” vs “I am a parent”)!

Sometimes it is appropriate to include an additional slide like this one, sometimes it isn’t. I think this time it was.

Keep a slide like this in mind next time you feel bad about code, a project or work in general.

I am We are not…

Actually, I think we could avoid a whole category of problems in our job when we could remember a couple of easy things here:

• We are not the code we wrote nor the project we maintain.
• We are not the architecture of a system we are responsible for.

If we don’t keep these things in mind we’re in danger of drawing all our self worth from external opportunities. This makes reasoning and speaking about technical problems so much harder, even when the other people in the room are good colleagues and your project has a good discussion culture.

Why? Because getting self worth and appreciation from only a single thing is a single point of failure and as such, a pain in the ass. Even if it does not fail, it bothers and bugs us.

As alway, there are smarter people in the room. When I tweeted about this thoughts – quite exactly a year ago – Roman Kennke, Java VM Hacker and Principal Software Engineer at RedHat, responded like this:

Don’t rely on any outside appreciation

I appreciate it very much that Roman replied with can. I mean, this is endboss-level-hard. Anyone of us likes a casual “thank you”, a “well done”. Even more so some verbalization that something we did was helpful.

By all probability not only the younger people in the audience but anyone who is in one form or the other on social media looks for hearts, stars, thumb ups, followers and what not.

Stuff like this becomes addictive and you will have a hard time getting off from it. I’m not saying it’s completely bad, not at all, but mind the dosage.

Find things that you enjoy, preferable a broad range of things, make yourself less fragile and more resilient.

For me, those couple of statements already required some kind of focus shift. Getting my head and my thoughts away from recurring patterns and thoughts. A cognitive therapy, if you like, so let’s start with that.

Continue with part 2: Miles are my meditation.