Oskar Dudycz

Pragmatic about programming

Revolution now!

2020-12-02 oskar dudyczEvent Sourcing

cover

Did you ever get an offer that someone will pay you for what you are currently doing as a hobby? What would be your decision if that would mean leaving the project that you liked? A team of people that you built from scratch being its first member? Leave the company department that you created?

I got such offer over a month ago. I accepted it.

Yesterday I started my new job. I’ll be a full-time DevAdvocate at EventStoreDB!

OK but, who is DevAdvocate?

To be true - I can’t precisely tell you that. However, I can tell you how I imagine it. What will be in my duties:

  • Explaining Event Sourcing, building awareness of its existence among programmers. Broadening the niche, explaining not only why it is worth using it, but keeping it pragmatic.
  • Providing helpful content - blog posts, examples and tutorials. Trying to show the big picture, how to integrate Event Sourcing with other patterns and tools,
  • Creating tools, maybe also libraries that will be helpful for developers. EventStoreDB is not a library (like, e.g. Marten) - it is a database for events (so ummm, you know event store). Its API is relatively low-level, it may be worth to create OSS tools that will reduce cognitive load and boilerplate,
  • Communication with developers and being their advocate to the project team. For example, EventStoreDB had a bit of a false start with revolutionary version 20. It had so much breaking change that people had problems with migration. It could have been mitigated with communication or different release plans.
  • Working on the documentation,
  • live coding, podcasting and other ideas that will pop out.

OK, but how did I get here?

For many developers Event Sourcing is like a Nessie, most of them have heard of it, but not so many saw it. I was one of them. I started my journey with Event Sourcing over four years ago. Practical journey - before that I mostly read books, which shouldn’t count. Why? Because there was not a lot of them showing how to apply Event Sourcing practically. When my colleague said that “well, you’re doing financial system then Event Sourcing sounds like a good match” - I was curious. Then I was thrilled, as finally, I was able to use the pattern known from the books. I used Marten library. First steps were hard. I was irritated. I started to get doubts if that’s something for me.

I’m not the type of person to easily give up. Step by step, I understood more and more. Then making mistakes and learning from them, I started to get better vision. I noticed that Marten have some missing pieces, and I began to send pull requests. I also began to interact with users on Gitter channel because I saw that they had the same struggles as I did.

Two years ago, Jeremy D. Miller invited me to become the co-maintainer. I’m currently responsible for the Event Sourcing part and second committer. My current attitude is summed up best by Greg Young quote: “When you start modelling events, it forces you to think about the behaviour of a system. As opposed to thinking about the structure of the system”.

I also started to give more often talks on conferences, local meetups and webinars. I created the popular repository “Event Sourcing in .NET” that contain lots of samples, exercises and materials for doing Event Sourcing in .NET - https://github.com/oskardudycz/EventSourcing.NetCore/. I’m trying to continuously provide practical examples to show that Event Sourcing is much easier and much more realistic than many folks believe.

TLDR - I hustled because I felt passionate about the practical aspect and what one can achieve with Event Sourcing and in general with Event-Driven Design.

OK, so that was my story, but how did I get the job?

I sent an email for the offer I saw by accident on Twitter. Looking at it, I thought - this is a job for me. However, I didn’t send the application right away. Why? Because I felt that it was going to be a conflict of interest with Marten. Plus, I wasn’t looking for a new job because the current one was a decent one. Yet then I realized that maybe I don’t have to give up Marten. I knew that there are people in EventStoreDB who work at EventStoreDB daily and contributes to other OSS Event Sourcing tools.

I didn’t want to be a renegade - I’m a loyal person. I’m thankful for the chance I got from Jeremy D. Miller.

Luckily Mat McLoughlin was fine with that and Jeremy saw no problem with it.

Conclusion - sometimes, a person lives in his imaginary world and tries to create problems that do not exist. It’s usually better not to assume.

Few zoom calls and email later, I got an offer, and yesterday the revolution began!

I am thrilled because for me it is a great chance to work with people like Mat and Alexey Zimarev. Not always one gets the opportunity to follow the passion. I’ll be working on a great product, gaining more knowledge and even more opportunities to share it!

I think that having a perspective of knowing different event stores, understanding the view of the everyday developer struggles I’ll be able to present and share Event Sourcing from different angles. Do it pragmatically, as I like the most. At least - that’s the plan!

So don’t be surprised when someone knocks on your door and asks “Hello. Do you want to talk about Event Sourcing?”

Was it an easy decision? In theory, it was a no-brainer. In practice, it is difficult to leave the company that you have grown into. I spent almost ten years in Euvic. The company that during that time changed its name from LGBS, and grew into one of the largest Polish programming companies. I helped build the Wrocław branch. I rose from the senior dev into the Technical Leader and Architect. What’s the most important I made a team with whom I had a great time working.

Well. Life is the art of choices. For me, it was an offer that I couldn’t reject. Is it the right decision? I believe so!

Please keep your fingers crossed and don’t afraid to reach me! I will be grateful for that!

Oskar

p.s. as you know how it started, read also how it finished in Why I’m leaving Event Store and getting ready for the next episode.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar

Why a bank account is not the best example of Event Sourcing?

Architect Manifesto