Better problem understanding leads to better design. This technique from @ericevans0 helps achieve exactly that.

https://read.ceilfors.com/p/concrete-examples-to-deepen-understanding

I attended Eric Evans' Software Design Masterclass held in @ddd_eu, and wrote one of my many learnings here:

https://read.ceilfors.com/p/unspoken-secrets-of-ddd-lessons-from-eric-evans

Has any of you built an open-source project and gotten it adopted by a company?

I'd love to know what important things you'd typically look at from the original creator/maintainer's point of view.

Two patterns of pair programming I recently observed from different engineers:

1. Avoid pairing for flow-inducing tasks (disappearing enjoyment)
2. Desire to pair for challenging or boring tasks

If you don't like pairing, trying it for pattern 2 could make pairing productive.

When focusing on one task, I noticed there's a tendency for engineers to procrastinate on other non-urgent but important tasks, such as documentation.

The Eisenhower Decision Matrix can be useful for engineers at any level.

Schedule those non-urgent but important tasks.

X: I had a great relaxing break, spending a lot of time with my family.

Me:

I'm still surprised people are subscribing, thanks to those who support my newsletter! It's motivating!

https://read.ceilfors.com/