notes · lessons from practice

Are we solving problems, or just playing with tech?

One thing years of working in software teams left with me: what looks "cool" is not necessarily "useful". We get excited by a new framework, an attractive architecture, a complex tool — and part of the excitement is the feeling of progress, of being professional, of being different. The honest question is whether any of it helps the user — or only us.

Real value versus false value

The distinction that matters is between real value and false value. Real value means the product we build lifts something off the user's shoulders, makes their life easier, or helps their business run better. False value is everything that looks attractive from the outside but, in the end, matters neither to the user nor to the project's success.

This distinction has become sharper than ever in recent years, especially with approaches like Agile and Lean. Their central push is that instead of constantly building new features and new tools, teams should actually stop and ask: what change will this make in the customer's life?

Kent Beck has a famous line I love:

And it's true. The simple habits — listening to what the user needs, writing code others can understand, refusing the things that only add complexity — these are what make a team successful.

Where the book comes in

Looking at "value" this way can change how a product gets built. Translating Leading Effective Engineering Teams made much of this clearer for me again. The book is by Addy Osmani — one of the engineering leads on the Chrome team at Google — and instead of clichés, it works through his real experience: how teams are built, how to tell output from outcome, and how to make sure the work actually has impact, not just presentability.

If you're after a practical, precise resource on managing software teams — as a lead or as a developer — I think the Persian translation can help you a lot.