Developer Week 2021: Building the Right Thing

Before the Event

I first heard about Developer Week through a raffle promoted by the hosts of the Tech Excellence Conference. The schedule looked very interesting, and since I won a free ticket for the online event, I took the opportunity to attend.

About The Event

Developer Week is split into an on-site event in Santa Clara (California, USA) and a virtual conference the following week, both running in the PST timezone. This meant all talks happened late in the evening for me (6PM to 1AM).

The topics covered a wide range, and the ones I found most interesting spanned everything from product development lifecycle, company culture, and UX to more engineering-heavy topics like testing, APIs, AI, and security.

Schedule

The schedule was packed with interesting talks—many met my expectations, and quite a few surpassed them.
Here are the ones I attended:

• The Third-Wave of API Management by Adrian Machado traces the evolution of APIs and highlights established standards.
• Busting the Biases That Block Innovation by Leslie Grandy explores how biases like Problem Framing can hinder creative thinking.
• Radical Transparency for Software Teams by Gregory Lind emphasizes the importance of trust and open communication.
• Stop the Silos: From Files to Apps, Integrate Your Dev Approach by John Wilson illustrates why integration is crucial as teams rely on more and more tools.
• Managing Growth Pains: Lessons from Scaling Engineering Teams by Amir Shaked shares strategies for scaling teams with less overhead.
• Where Is the Love? Why Automated Regression Testing Isn't Getting the Attention It Needs by Jens Wessling makes a strong case for investing in regression testing to save money long-term.
• API Security 101: How to Not Be Featured in a Top Ten Breaches List by Dan Barahona stresses the importance of authenticating and validating all endpoints.
• Breaking Down Silos: Enhancing Security in AppSec Programs by Aruneesh Salhotra encourages developers to become security champions within their organizations.
• Bridging Minds and Machines: Understanding Human Mental Models in UX and AI by Bhrunali Gokhe explains how mental models shape user expectations.
• Intuit's Strategy for Maximizing Developer Productivity Using GenAI by Jothimani kanthan Ganapathi and Anish Dhason suggests leveraging RAG to enhance AI support for internal SDKs and standards.
• Product Value Curves | A Practical Approach to Building Effective Product Strategy by Lakshmi Sowjanya Uppala demonstrates how value perception differs among users.
• Bottom-Up Transformation: Changing Company Culture One Team at a Time by Jim Morris shows how communication and value-driven iterations can transform projects.
• Beyond Failing Fast: How to Use Fast Feedback to Learn Without Failing by Michael Mace proposes improving feedback cycles to ensure teams build the right thing.
• How to Ensure Your AI Investments Pack the Most Punch by James Evans debunks the myth that simply labeling something as AI guarantees returns.

Key Takeaway

Every talk had interesting points, but the recurring theme in the ones I found most valuable echoed a lesson that has followed me since last year's Tech Excellence Conference:

Involve your customer and their feedback as early as possible to build what they really need.

It sounds obvious, but in practice, it's far from common. Amir Shaked's talk on Managing Growth Pains had a line that stuck with me: "Don't fall in love with your code." I see that as transferable to products as well: "Don't fall in love with your idea." Or even more broadly:

"Love the process, not the result"

It might sound counterintuitive, but getting too attached to an idea or a piece of work makes it harder to stay objective. Seeking feedback becomes difficult because, after all, you're the expert—you know what you're doing... right?

The longer you go down this path, the more planning you do, and the harder it becomes to involve others who might challenge everything you thought was right.
But the issue often starts earlier, especially in startups, greenfield projects, and fast-changing industries. A question worth asking upfront is:

"Who are we doing this for?"

When I first transitioned into freelancing, people often asked me what kind of clients I was looking for. My answer was usually something like, "Companies willing to pay my rate with money not earned in conflict with my ethical values." That wasn't wrong, and I understood the "beggars can't be choosers" mindset, but if you don't clearly define your clients, it's even harder to figure out what they actually need.

Lakshmi Sowjanya Uppala's talk on Product Value Curves made a great point: even when looking at the same thing, different people value different aspects. She repeatedly emphasized that features are not values, which made me chuckle because I've fallen into that trap more times than I care to admit.

Take something as simple as a food storage container. They all serve the same core function — storing food — but what makes one product better than another depends on what you value: Is it affordable? Dishwasher-safe? Microwaveable? Eco-friendly? Ethically produced? The key question becomes:

"What does your customer value?"

When I started in software engineering, waterfall development was still common, and convincing clients to go agile was tough. Understandably so—it seemed like a risk, an excuse for ballooning costs. But Michael Mace's talk on Beyond Failing Fast presented hard data showing how companies like Microsoft spent the vast majority of their time planning too far ahead—only to see that effort wasted.

Finding the balance between enough planning and too much is tricky. What came to mind for me is something that a coach recently said to me in at a Brazilian Jiu Jitsu Camp, when asked about his style of teaching:

"Don't address problems you didn't see or weren't asked about"

Although a lot of technological advances, including AI, try to rid us of the friction that communicating with humans involve, Jim Morris's talk on Bottom-Up Transformation reinforced that one of the most effective ways to avoid wasted effort is still simply talking to people. Define the problem. Establish metrics. Build an MVP. Measure the impact. Iterate.

Because in the end, building great software is more about building the right thing than building the thing right.