Oskar Dudycz

Pragmatycznie o programowaniu

Don't be like Ebenezer Scrooge. A few words about workaholism

2022-12-29 oskar dudyczCoding Life

cover

There is a cult of workaholism in our industry. Just like the guys from the gym brag about how much they pulled on the chest or did in the deadlift, we brag about how many overtime hours we worked. Or how long did we work to fix the production bug. All those jokes:

  • “5 PM and you are going home?”
  • “Yeah, I’m on vacation today.”

Ha. Ha.

I’m also struggling with that. I have strong workaholism tendencies. I also bragged about overtime. I even came up with my lame joke “I don’t work too much; I just do my overdued overtime.” Probably to this day, among my colleagues, I may have the opinion of robocop, which works non-stop. It’s justified as I had a span of ~2 years where I worked an average of 220 hours per month.

That’s something to be proud of.

not

NOT!

I felt uplifted for a long time when I heard, “damn, Oskar is a stunner, he works so hard”. Or by the feeling of saving the project once again. It was also a boast of being so multitasking. Seven projects at once? No problem. Two calls at a time. Sure, why not.

The reality is that all a myth. Multitasking is inefficient. You can’t do many things at once for free. None of these things is done as satisfactorily as possible if you focus only on them. Saving the project and taking on the most challenging stuff is blocking others from learning and proving themselves. It’s a dead end. Especially being a leader, it is worth restraining your workaholic tendencies. Even if we never ask anyone to work overtime (e.g. I never did), and we don’t undervalue those who work only from 9 till 5, we still put pressure on them. That’s dangerous, especially for juniors. Keep this in mind. It doesn’t have to be toxic at work.

We’re lucky that we have a job that is also our passion. Plus a well-paying hobby. Yet, it cuts both ways and can be a curse.

Are there deadlines that you can’t move? There are no. At least at work. I assure you there are no deadlines that cannot be moved. I haven’t seen such in over 15 years of my career.

I will tell you one more secret. We are not unique. The worn-out slogan that there are no irreplaceable people is true. Seriously.

You, too, can be replaced.

At work.

There is an area where we cannot be replaced.

At home.

So let’s remember (I’m writing to you and myself) to focus less on work issues, especially in our free time. Deadlines will come and go. Let’s focus on here and now. Let’s focus on the people, e.g., those around the table during your next dinner. You never know if you may meet in such a configuration again.

Let’s not be like Ebenezer Scrooge.

Let’s laugh at the dad’s jokes told for the hundredth time; they’re still funnier than our overtime jokes.

We’ll miss grandma’s food that we hated some time ago. We’d like to hear that boring uncle’s story again at some point.

We’ll likely miss them more than ephemeral deadlines at work or overtimes we did.

Read also:

Cheers!

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 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

Let's build event store in one hour!

Explicit events serialisation in Event Sourcing