I made a promise to myself. Never work in the middle of the night again. Even bugs go to bed, I suppose.

I've been keeping that promise lately, which comes as a welcome surprise. Almost every software engineer understands the inevitability of staying up late to code. We're notorious nocturnals according to our ancestry. But should we really be?

This week, I broke my promise though. I shutdown at 01:35 AM and was at it again at 05:08. Double espresso with a dollop of steamed milk on hand, I rushed a few commits in time for the review. The feature ran, the backlog moved. Hurray. You're forgiven for the slip-up.

But it's time to let the old ways die.

So why the extended hours days before the end of sprint? Architecture creep. It's a thing. It's when you're about to implement a story and realize there's a better way to do it.

In our case, we're refactoring a simple api to make it an asynchronous, long-running task. The new feature for creating the entity must call additional external endpoints to fulfill a new business logic.

For this, we decided to convert the existing HTTP-triggered Azure function to a Durable one . Fine. We've done this before. We're on track.

Then I called the team for an architectural workshop to review our original event model. It's a tooling we recently adopted to help us design better software.

Event modeling is a framework coined by Adam Dymitruk, for expressing any event-driven systems. The concept is simple. You describe what happens to the system through a timeline, using Events, Commands, Read Models and Interfaces.

So far, it's been a great help. I recommend that you start here to learn more

The thing with architectural sessions is that your creativity goes amok. In the end, we discovered more events and commands than what we originally planned for. Hence the extra tasks. Here's what we came up with for what was supposed to be a short story:

We also needed to draw a sequence diagram to go deeper into the logical details. Sequence diagrams are not always necessary. Event models are most often enough. But sometimes, the brain requires different artifacts to accurately manifest its complex intent.

The other side-effect of architectural sessions is that it unleashes what I would refer to a Star Trek syndrome. It's when the team embarks on a mission "to boldly go where no man has gone before".

What if we use the existing CosmosDB as the event store? Ok obviously this has been done before . But not by our team and not on this project. So let's do it team! Yeah why not?

Architecture creep.

Should we have let it happen? Maybe not. What would you have done?

I've been in the industry for a long time. The question of what matters more - the code or my well-being, has been in my head since I was a junior programmer. I can still remember that one incident when we were driving on our way to a company outing in the mountains. I was sitting next to the driver, along the zigzaggy cliff of Mt. Balingkilat, laptop screen light illuminating my face in the dark, still debugging code, on what was supposed to be a holiday trip. I didn't mind that one time. But the same happened over and over again.

And now I'm in charge of a company, with several engineers whose well-being I'm primarily responsible for. The question is still the same, and we've always known the answer.

We matter more.

But it's not always easy to keep promises. I'm a living proof. And I desperately want to fix it. For my team's sake. For my own sake.

So when a good friend showed a clip from one of the sessions at Microsoft Build, during a watch party that we hosted at AZUGDK, I think I might have found a silver lining.

Introducing Developer Velocity Lab to improve developers’ work and well-being

In her session, Nicole Forsgren, VP Research and Strategy at GitHub, talk about SPACE. A framework for increasing developer velocity by addressing 5 key metrics: Satisfaction & Well-Being, Performance, Activity, Communications & Collaboration, and lastly, Efficiency & Flow.

Their "mission is to discover, improve, and amplify developer work and well-being."

Hey that's my mission too. So should be yours, if you work with any technology teams. Or with any team for that matter.

There's much to learn. We have so many opportunities to improve our way of building great software, without sacrificing our well-being. This time, I don't want to make any promises. But I commit to do whatever it takes to let old ways die, and open the SPACE for our developers to thrive.

That's all for this week

Marilag