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.

I wondered, why do we need to manage stakeholders' expectations?

If you have a stake in the investment, you should expect the associated risk and uncertainty. It is irrational to be frustrated when things do not go to plan.

I have a similar qualm with the idea of managing up.

Was in a deep conversation about work-life balance, and I came in assuming that the individual is experiencing too much work.

Questioning and listening more, I discovered that it's the opposite situation! The individual is having too many tasks that are not flow-inducing.

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.