
Sign up to save your podcasts
Or


Most engineers focus on building the actual application and infrastructure. The best ones focus on outcomes.
In this video, you will learn how to think like a product engineer, move faster without cutting corners, and build things that truly matter as a Product Engineer. From decision-making to execution, these principles will help you stand out and grow into someone who creates real value, not just shipping software.
I’ve developed numerous projects on my GitHub over the years. Feel free to browse them for inspiration or to contribute! And I’ve got more content coming your way on my LinkedIn.
Become a Product Engineer today! Subscribe for free to receive new posts and support my work.
A strong product engineer is not defined by how much they ship, but by the decisions they make.
This video covers how to think in terms of users, metrics, and real impact. How to stay close to the problem, understand what truly matters, and choose what to build with intention. It is about improving daily and staying consistent over time.
If you want to grow, make better decisions, and build things that people actually use, this is where it starts.
I’ve spent the last decade building projects on my GitHub. Check them out for inspiration and contribution. And I’ve got more content coming your way on my LinkedIn!
A clear guide for software engineers who want to build products that actually solve problems instead of adding noise. Because let’s face it, the world doesn’t need another half-baked app or feature that nobody asked for.
This video breaks down how to think, design, and deliver solutions that matter. Not solutions that look impressive on your portfolio. Not solutions that use the latest trendy framework. Solutions that actually address real pain points and make someone’s life measurably better.
I’ll walk you through practical examples drawn from real engineering work. How do you validate that a problem is worth solving before writing a single line of code? How do you scope features so they’re useful without being bloated? How do you know when to ship versus when to keep iterating?
Here’s the thing: building products is different from writing code. Code is implementation. Product thinking is about understanding who you’re building for, what problem you’re solving, and why it matters. Get that right, and the code becomes the easy part.
If you’re tired of building things that sit unused or feel like they’re missing the mark, this video will help you shift how you approach product development from the ground up. Let’s talk about building things that actually matter.
Thanks for reading The Healthy Scientist: Build Using AI With Healthy Habits 💪
I’ve built many projects on my GitHub over the years. Take a look for inspiration or jump in to contribute. I’ve got plenty more exciting content coming your way on my LinkedIn!
Make sure to hit that follow button so you don’t miss out! 🔥
A space dedicated to product-first software engineering, where the focus stays on building meaningful software with clarity, intention, and strong fundamentals.
I share how to think like an engineer who is responsible for outcomes, not just code. It is about understanding problems properly before solving them, designing systems that remain simple over time, and making decisions that improve both the product and the experience for real users. The goal is to move away from unnecessary complexity and towards solutions that are direct, reliable, and easy to reason about.
It reflects the daily reality of being a software engineer: managing endless cognitive/mental load, staying consistent under pressure, and maintaining direction when everything feels fragmented. Technical work is always tied to mental structure, so part of this writing focuses on how to organise thinking, how to prioritise effectively, and how to keep momentum without losing clarity.
This is about building software with care and purpose. It is about improving as a builder over time, learning from real-world constraints, and developing habits that support long-term progress rather than short bursts of output.
I’ve built many projects on my GitHub over the years that you can check out for inspiration or contribution! I’ve got plenty more content coming your way on my LinkedIn! Hit the ‘follow’ button so you are sure to not miss out! Enjoy!
Thanks for reading The Healthy Scientist: Build Using AI With Healthy Habits 🌱
Improving as a software engineer does not come from big, rare efforts. It comes from what you do every day. Starting something new, challenging yourself, iterating, and refining your work builds real progress over time. In this video, I share how small daily actions, combined with the right mindset, can help you grow steadily and become a stronger, more confident engineer.
Focused outside, building and improving step by step, turning small daily effort into real progress.
Get inspired by open-source projects I’ve built over the past years on my GitHub. And I’ve also plenty more content coming soon on my LinkedIn! Don’t forget to follow and stay tuned!
Modern engineering is no longer about writing every line of code manually. It is about orchestrating systems of intelligent agents that can explore, build, test, and iterate in parallel.
By combining Claude Code agents, product-focused Claude agents, and Git worktrees with tools like Superset.sh and parallel task execution, you can split complex engineering work into independent streams. Each stream solves a part of the system while you keep full control of architecture, quality, and intent.
The real skill is not prompting. It is structuring context clearly so agents operate with precision. A strong context prompt becomes your execution layer, defining constraints, goals, and boundaries so every run produces meaningful output.
In practice, this is what high-leverage engineering looks like today: active exploration of codebases through better reading and learning loops, daily and weekly self-challenge cycles to avoid stagnation, full ownership of source code and every decision shipped, deep focus on problem understanding before execution begins, running multiple AI agents in parallel environments, curiosity-driven iteration over linear development, and scheduled automation jobs that keep systems running and improving without manual intervention.
This is how strong engineers operate in the AI era. Not by doing more work, but by designing systems where work happens concurrently, intelligently, and under clear ownership.
I’ve built many projects on my GitHub over the years. You can check them out for inspiration or contribution!
I’ve got plenty more content coming your way on my LinkedIn! Hit the follow button so you are sure to not miss out!
Problem solving is what separates good engineers from great ones. In this video, I show how top engineers approach challenges, debug smarter, and find solutions faster. Follow these methods to boost your skills and handle any problem with confidence.
Look, anyone can follow a tutorial and build something that works. But when things break? When you hit a bug you’ve never seen before? When the solution isn’t obvious? That’s where problem solving actually matters.
Here’s what I’ve noticed about top engineers: they don’t panic when something goes wrong. They have a system for approaching problems that works every single time.
First, they clarify the problem. This sounds obvious, but most engineers skip this step. They see an error and immediately start changing things randomly hoping something fixes it. Top engineers pause and ask: “What exactly is broken? What’s the expected behaviour versus actual behaviour? When did this start happening?” Getting clear on the problem is half the battle.
Next, they isolate variables. Instead of staring at 500 lines of code trying to spot the issue, they narrow it down. Comment out sections. Add logging. Test smaller pieces individually. Binary search your codebase until you find where things go wrong. This approach finds bugs in minutes instead of hours.
They also debug smarter, not harder. Read the error message properly (seriously, most bugs tell you exactly what’s wrong if you actually read the message). Check the obvious things first (is the server running? is the API key correct? did you save the file?). Use proper debugging tools instead of adding console.logs everywhere and hoping for the best.
And here’s the thing about finding solutions faster: it’s not about knowing every possible answer. It’s about knowing how to find answers. Top engineers are brilliant at searching documentation, reading source code when things aren’t clear, and asking good questions when they’re genuinely stuck. They don’t waste hours being stuck on something they could solve in 10 minutes by asking someone who knows.
I’ve built many projects on my GitHub over the years. Check them out for inspiration or jump in to contribute!
I’ve also got plenty more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out!
Product-minded engineers are developers who genuinely care about the product, not just the software. They want to know why decisions are made, how people actually use what gets built. What makes this mindset powerful is outcome thinking.
Most engineers focus on tasks, tickets, and shipping. Head down, execute, repeat. That’s the default mode. And look, it keeps things moving, but it’s also exactly what keeps a lot of engineers from growing.
Product engineers think differently. They don’t just ask how to build something, they question whether it should be built at all. They care about the user, the outcome, and the real-world impact of what they ship, not just closing tickets and moving cards across a board.
In this video, you’ll learn how to make that shift. How to cut through the noise, prioritise what actually matters, and make decisions with clarity. How to stop just contributing and start genuinely owning the product you’re working on.
And here’s the thing: if you want to grow faster and build things that actually matter, you need to stop measuring success by what you shipped, and start measuring it by what actually changed for the person using it.
A product-minded engineer doesn’t ask “did I ship the feature?” They ask “did it move the metric? Did it solve the real problem? Did the user’s experience get any better?”
That’s the difference. And once you start thinking that way, there’s no going back.
I’ve developed numerous projects on my GitHub over the years. Feel free to browse them for inspiration or to contribute! And I’ve got more content coming your way on my LinkedIn.
Now, go build something that truly matters to you! 🚀
Getting better as a software engineer rarely comes from a single breakthrough. It’s more about the small things you do every day: learning from mistakes, trying different approaches, and taking on projects that push you outside your comfort zone.
I’ve often found that you understand things differently after you’ve built something yourself, made a few mistakes, and figured out how to fix them. You start noticing things you would have missed before, and problems that once seemed complicated become easier to handle.
You don’t need to know everything or be the best engineer in the room. Just keep building, stay curious, and don’t be afraid to try things you haven’t done before.
I’ve built several projects on my GitHub over the 10 years. Check them out for inspiration or contribution! 🤠
I’ve got plenty more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out!
Software engineering is often reduced to writing code, but the real value comes from how we think about products, users, and systems as a whole.
In this series, I regularly invite guests to discuss building software products, startups, and the realities of working across different environments. These conversations go beyond tools and frameworks. They explore decision-making, trade-offs, and how engineers shape outcomes in real organisations.
My own background spans startups, large enterprises, and lead engineering roles across multiple countries. That range of experience has shown me that knowledge grows fastest when it is shared. Every discussion brings new perspectives, moments of clarity, and practical ideas that can be applied directly to how teams build and operate.
We also explore how modern systems, including agent-based tools and evolving workflows, fit into everyday engineering work. Not as abstract concepts, but as real mechanisms that influence productivity, organisation, and product thinking.
At the core of it all is a simple idea: becoming a better engineer is not only about writing better code, but about improving how we think, communicate, and build together. Each conversation is a chance to refine that mindset and bring it back into real work.
From the publisher's feed