notes #18: on feedback, plus three thinking tools for better engineering

Hey friends,

In today’s notes, I want to share some thoughts about giving and finding feedback. Plus 3 thinking tools that are invaluable for the strategic engineer.

Didn’t get a chance to read much this week - been busy on work, projects and creating videos. Gotta get back to it next week.

On Feedback

It’s crazy how just one stranger can change everything.

You could spend months creating videos and be on the verge on giving up - when a stranger on the internet comments: “dont stop makin videos, ur gonna blow up soon”. And you decide to push through and keep going.

And so here’s two things that I learnt:

• First, if I see good work - I should strive to provide encouragement and support as much as possible. Even if it’s just constructive feedback. It really helps people.

• Second, find a way to get feedback. What makes frontend development or day trading so enticing are their immediate feedback loops. On some other things like videos, your viewership count may not always be the best indicator of your progress.

Sure, there are some people out there that are strong enough to push through for years without seeing results. I personally doubt there’s anyone like that — they’re just using a different metric to measure progress.

After all, you’ll probably go crazy doing the same thing over and over again without seeing results.

🧠 Thinking Tools

1. CCN Framework (Paddy Galloway)

Originally a strategy for YouTube growth, the CCN framework—Core, Casual, New—is surprisingly relevant for product development and feature design in tech.

• Core: These are power users. Engineers should build with them in mind first, creating fast, reliable, and flexible features.

• Casual: Occasional users benefit from simplicity. Think defaults, guides, or smart automation.

• New: Onboarding matters. Your code and UX should reduce friction for first-timers.

Thinking in layers helps prioritize efforts and balance trade-offs: robust for experts, usable for the masses, welcoming for beginners.

2. 70/30 Rule (Jeff Bezos)

Bezos encourages making decisions when you have about 70% of the information you'd like. Waiting for 90% slows momentum. This rule is useful for engineers hesitant to ship or start something new. It encourages bias toward action, experimentation, and iterative learning. In agile teams, this mindset promotes shipping MVPs, collecting feedback early, and learning fast. It also reduces overengineering and avoids paralysis by analysis.

3. Catalyst Thinking

Catalysts create outsized impact with minimal effort—they change the state of a system without being consumed by it. In engineering, this means identifying leverage points: writing documentation that enables teams to move faster, building internal tools that unblock others, or designing APIs that reduce repeated conversations. Instead of just solving problems, catalyst thinking asks: What system-level change could prevent this class of problem in the future?

Thanks for reading.

Each week, I’ll keep showing up with something useful for your mind, your code, and your growth. If it helps, share it with a friend.

Till next week, Joesurf