Speaking at conferences: A HowTo, part one

I’ve had the opportunity to talk as speaker on several development conferences during the last few years.

Interestingly, when talking about this to friends and colleagues a typical reaction when they hear about this is: “Oh, I’ve always wanted to do that as well but I’m not good enough” or similar comments.

As I had basically the same doubts just a few years ago I’d like to lay out a few thoughts about speaking on conferences and why you are good enough, no matter what you may think.

Developing a microservice in COBOL

At BetterDoc we’re currently in the process of step by step replacing an old monolithic application with a microservice landscape. Sometime in early January 2019 we talked over lunch we asked ourselves “What could be a crazy language in which we could implement one of our microservices just to prove that it can be done?”. I’m not really sure whose idea it was but one of us said “What about COBOL?”.

Of course it was meant as a joke, I mean who would start a new COBOL project in the 21st century? But I thought to myself “What the heck, why not?”. I’ve never really looked into COBOL so it sounded like a nice challenge to pick up. So I said actually tried it.

Naming things, part 3

At BetterDoc we’re currently in the process of step by step replacing an old monolithic application with a microservice landscape. While adding services whe recognized that we needed to find a consistent pattern to naming these services to keep the “service zoo” organized.

This post describes our overall scheme for naming our services.

Note that since writing this blog post our idea of how a service should be named has changed and the following rules are no longer valid. Our most recent thoughts can be found here: (Naming things, part 3B).

Naming things, part 2

I have already talked why it’s important to have a good name for your software here, today I want to dig a little deeper into naming, this time on a more technical level: Naming events.

Naming things

According to Phil Karlton there are only two hard things in computer science: Cache invalidation and naming things. We’re currently experiencing how important the latter one is. Finding the right name for something and then sticking to that name.

Joel score +1

From time to time, I check our Joel Score - partly because I see the need to improve on the topics listed there, partly because it reminds me why we do some things we do.

Confessions of a Ruby convert

I have been developing applications in Java for the last 15 years. I know the language, I know the API, I know all the important frameworks and at one point I even felt arrogant enough to talk about the Java internals at conferences.

But since starting at BetterDoc I’m using Ruby as my main programming language. I still try to sneak in a little bit of Java here and there, but Ruby is what I’m doing most of the time.

It feels a little bit like learning how to crawl again after having been an athlete. It’s a mixture between excitement, frustration, and pure embarrassment.

The story I want to write about in this post falls into the last category: pure embarrassment.

Repairing the car while driving it

One of the hardest things you can do in IT is replacing a piece of software that has both 1) significant complexity and is 2) currently in use.

So, how can you do this?

Don't be afraid to learn a foreign language

Like many other professions software engineering has its own language, its own vocabulary and its own conventions. However as software engineers in order to do our job well we need to collaborate with people outside of our own profession - which means we have to find a way to communicate efficiently so that we all understand each other.

DDD Sessions

Observation: when doing a DDD session with someone who is using a system you want to change or replace, you will discover that both language and assumed constraints will follow the mental model people have of the current system.