PierreHenry.Dev Tech Show

🎡 Pierre-Henry Soria 🌴

Speaking about software engineering, AI, productivity, happiness, and intentional living. 🚀 I enjoy exploring ideas, sharing what I learn, and building products that solve meaningful problems. Topics I regularly discuss include: * Software engineering and product development * AI and emerging technologies * Productivity and time management * Personal growth and lifelong learning * Building systems, habits, and processes that last * Creating a fulfilling and intentional life Through writing, building, and continuous learning, I aim to share practical insights that help people think more clearly, work more effectively, and live more intentionally. I’m always interested in connecting with curious people, exchanging ideas, and collaborating on projects that create a positive impact. www.pierrehenry.dev

  1. 2d ago

    HOW TO Build a Software Engineering Mission That Drives You Every Day

    Writing code every day is easy, but knowing why you do it is what truly matters. As a software engineer, having a clear mission can transform your daily work from a series of tasks into a purposeful journey. I’ve seen brilliant engineers burn out because they never stopped to ask “why am I doing this?” They’re shipping features, fixing bugs, attending meetings, but there’s no deeper purpose connecting it all. Eventually, the work feels hollow and they either quit or coast through their career half-engaged. When you have a clear personal mission, everything changes. You’re not just executing tickets anymore. You’re building towards something that matters to you. That shift in perspective makes even mundane tasks feel meaningful because you understand how they fit into your bigger picture. In this video, I’ll show you how to define a personal software engineering mission that actually motivates you every day. Not some vague statement like “I want to make an impact” that sounds nice but means nothing. A real mission that gives you clarity on what projects to take, what opportunities to pursue, and what to say no to. We’ll cover practical steps to uncover what drives you. What problems do you genuinely care about solving? What kind of impact do you want to have? Who do you want to help? What gets you excited about building things? These questions sound simple, but most engineers never actually sit down and answer them honestly. How to prioritise projects that align with your goals is crucial too, right? When you’re clear on your mission, decision-making becomes way easier. That exciting job offer at a big tech company versus the startup working on something you care about? Your mission tells you which one matters more for where you want to go. And why clarity of purpose can make even the toughest days feel rewarding? Because when you’re debugging that horrible legacy code at 11pm, if you know it’s part of building something you believe in, it doesn’t feel like suffering. It feels like necessary work towards something meaningful. Well... if you want your coding to have impact, meaning, and direction, you need more than technical skills. You need to know why you’re building what you’re building and where you’re heading long-term. Without that clarity, you’re just drifting through your career hoping things work out. In this video, I’ll walk through the exact process I used to define my own mission. The questions I asked myself. The patterns I noticed in what excited me versus what drained me. And how that clarity completely changed which projects I took on and how I approached my work. 🏁 Follow my Software Engineering Journey on PierreHenry.Dev. Thanks for reading The Healthy Scientist: Build Using AI With Healthy Habits 🔥! Subscribe for free to receive new posts and support my work. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev

  2. 3d ago

    Why Software Engineers Must CHALLENGE Technologies to Grow STRONGER

    One of the biggest mistakes software engineers make is becoming attached to the way they’ve always worked. Maybe you’ve been using the same programming language, framework, architecture, or development process since you started your career. It feels familiar, so you keep doing it. But what if there’s a better way? Challenge your assumptions. Try a different library. Compare different AI models. Experiment with a new language or framework. Read how other engineers solve the same problem. Not because newer is always better, but because questioning your habits is how you grow. Leave your ego aside. Don’t think, “This is how I’ve always done it.” Instead, ask yourself, “Is this still the best solution?” As humans, we’re naturally resistant to change. That’s normal. Stability has helped us survive. But in software engineering, refusing to adapt can become your biggest limitation. History has shown this many times. When Node.js first appeared, many engineers dismissed it. People said it wasn’t professional, that it was only for hobby projects, and that no serious company would ever use it. Today, it’s one of the most widely adopted runtimes in the industry, powering countless startups and large companies alike. The lesson isn’t that Node.js is better than every other technology. The lesson is that great engineers stay curious. They evaluate new ideas instead of rejecting them because they’re unfamiliar. The same applies today with AI models, programming languages, frameworks, and development tools. Don’t follow every trend, but don’t ignore them either. Evaluate them. Understand their strengths and weaknesses. Keep what genuinely improves the way you build software. Remember, The engineers who keep learning are the ones who keep growing 🚀 Thanks for reading The Healthy Scientist: Build Using AI With Healthy Habits 🔥! Subscribe for free to receive new posts and support my work. I’ve built plenty of projects on my GitHub over the years. Feel free to browse through for inspiration or contribution. I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit that follow button so you don’t miss out! This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev

  3. Jul 11

    What 40 Years in Tech Teaches About AI, Blockchain, and the Internet

    For this conversation, I sat down with Roberto Capodieci, a technology entrepreneur, blockchain researcher, and one of those people who has seen several generations of computing from the inside. Our conversation started with something simple: coffee. As an Italian living in Bali, Roberto still begins his mornings with a cappuccino before jumping into work. It quickly became clear that technology has been part of his life for almost as long as he can remember. He started programming when he was five years old. By the age of nine, he was already making money from software. As a teenager, he founded his first company and built video games for the Commodore systems, working in C and assembly when every kilobyte mattered. Listening to those early stories was fascinating because they reminded me how different software engineering used to be. There were no online courses, no Stack Overflow, no AI assistants. Learning meant taking machines apart, reading manuals, experimenting, and spending hours on bulletin board systems with other curious people around the world. We also spoke about the early internet. Long before cybersecurity became a recognised field, Roberto was already investigating online scams. One case involved malicious dialers that secretly redirected people’s internet connections to expensive premium phone numbers. He tracked down the people behind the scam and shared his findings with the authorities, eventually receiving a letter of thanks from Bill Clinton. What quite surprise me wasn’t the technical achievement here. It was his motivation! He believes that when you understand how something dangerous works, you have a responsibility to help others understand it too. Whether it is exposing online scams or explaining how software really behaves, his goal has always been to make technology safer for everyone. That naturally led us into a discussion about trust. Modern software gives us switches, buttons, and settings that we simply accept. We click “disable”, “private”, or “do not train on my data”, but very few of us actually know what happens behind the interface. We trust software because the interface tells us to. It is an interesting perspective, especially today as AI becomes part of our daily lives. We then moved into blockchain. Roberto was involved with decentralised systems long before blockchain became popular. In fact, when he first discovered Bitcoin, he did not immediately see its value because his focus was elsewhere. Over time, after working on multiple blockchain projects and protocols, his perspective changed. One part of his journey stood out to me. During the pandemic, he spent a significant amount of time and money building a new decentralised platform. The first attempt failed. Instead of walking away, he started again, rewriting the entire project from scratch in C, this time with the help of AI to speed up development. I think every software engineer can relate to that. Sometimes the first version teaches you more than success ever could. Towards the end of our conversation, we discussed AI. Like many engineers, I often think about the balance between the opportunities AI creates and the concentration of power behind today’s largest models. Roberto shares that concern. He believes AI is one of the most powerful tools we have ever built, but he also argues that it should become more decentralised over time. If only a handful of companies control the models, the infrastructure, and the data, they also influence how information reaches billions of people. At the same time, he is genuinely optimistic about what AI enables. He gave a simple example that stayed with me. Someone who owns a bakery understands their business far better than any software engineer ever could. Today, with AI, that bakery owner can build the first version of the software they actually need instead of trying to explain every detail to someone else. That idea extends far beyond bakeries. People closest to a problem can now participate directly in building the solution. For me, that is one of the biggest changes happening in software engineering today. This conversation is not only about blockchain or AI. It is about curiosity, questioning assumptions, learning continuously, and remembering that technology is only valuable when it genuinely helps people. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev

  4. Jul 6

    Why Flow State Might Be Your Biggest Shipping Advantage

    Shipping better products is rarely about working harder or spending more hours. It comes from focus, flow, and knowing what matters next. Clear priorities reduce hesitation and improve decision making, helping engineers ship with confidence. This is about building the right things at the right time without noise or distraction. Building software is rarely about generating code first. It is about making the right decisions at the right time, with a clear focus on what actually matters. The strongest engineers are not the ones who know every tool. They are the ones who stay anchored in the problem they are solving and avoid drifting into unnecessary complexity. Focus keeps everything aligned. When you are in flow, you stop jumping between tools and start asking better questions. What does the user really need? What is the simplest way to deliver that value? What can be removed instead of added? This mindset changes how architecture decisions are made. If the system only needs a few endpoints and caching matters, REST often fits better than introducing GraphQL. GraphQL has its strengths, but it is not always the simplest choice. The same applies to databases and infrastructure. PostgreSQL, ORMs like Prisma or Drizzle, or query builders like Knex all solve different trade-offs. The decision is not about using the most modern tool, but the one that keeps the system understandable and maintainable. On the infrastructure side, simplicity wins in most early-stage systems. Lightweight CI/CD pipelines often outperform heavier setups early on. ECS can be enough without introducing Kubernetes too early. Terraform is powerful, but not always necessary at the start. Good engineering is also about knowing when to stop adding layers. Middleware, authentication checks, schema validation, and error handling are necessary, but only when they reduce real risk or duplication. Every abstraction should earn its place in the system. Reliability becomes part of this mindset. Observability tools like Datadog or New Relic surface issues such as latency spikes and failure rates. SRE concepts like error budgets help prioritise what matters next. If the system is consuming too much of its error budget, stability takes priority over new features. Security and maintenance are part of the same loop. Dependency scanning tools like Snyk exist to prevent hidden vulnerabilities, but they introduce trade-offs in cost and complexity. The decision is not about using everything available, but what is appropriate for the current stage of the system. At the core of all of this is focus. Focus on the user.Focus on the smallest useful system.Focus on shipping, observing, then improving. Everything else is optional until it is not. Building software is an ongoing cycle of decisions. The better your focus, the better your system becomes over time. Avoid distractions to increase quality and productivity outcomes. Subscribe for free to receive new posts. I’ve spent the last decade building projects on GitHub. They are available for inspiration and contribution. More content is coming on LinkedIn. Subscribe for free to receive new posts 🚀 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! This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev

  5. Jun 30

    Becoming a Product-First and AI-First Engineer: Mindset, Tools, and Efficient Workflows

    Being an engineer is not only about writing code or shipping features. It is also about how you feel while you build, how you think about problems, and how you choose to improve your daily workflow. A strong mindset starts with something simple: doing work you care about and staying close to that feeling over time. There are difficult days, moments where things feel unclear or frustrating, but what matters is how you respond to them. Staying grounded in a positive direction helps you keep moving, even when things are not perfect. Positivity here is not abstract. It is practical. It comes from surrounding yourself with the right influences, choosing tools that remove friction, and building habits that keep you focused on progress instead of frustration. From there, the shift toward becoming a product-first engineer starts with one key idea: think like the user. Before writing solutions, understand the problem deeply. Before building features, experience the product as someone who depends on it. This perspective changes how decisions are made and naturally leads to simpler, more useful software. On top of that, the role of an AI-first engineer is becoming more real in everyday workflows. Modern tools are changing how engineers interact with their environment. Tools like Superset, Conductor, CMUX, and terminal-based AI integrations like Codex or Grok bring intelligence directly into your workflow instead of keeping it separate. Using MCP integrations with tools like Figma, Linear, Notion, or Webflow also changes how fast ideas can move from design to implementation. Instead of switching contexts constantly, you can stay closer to execution and iteration inside your terminal environment. Even personal workflow setups evolve around this. Some engineers use multiple terminal sessions, cloned repositories, or workspaces to isolate features, experiments, and debugging tasks. Others rely on Git worktrees. Newer tools like Superset and Conductor simplify this by abstracting complexity and making parallel work more manageable without friction. The key point is not the tools themselves, but the willingness to adapt. What you used last year is often not enough for what you are building today. The pace of change in software engineering means your workflow must evolve with it. Improvement comes from exposure, experimentation, and action. When you discover better ways of working, the value only appears when you apply them in your own environment. The goal is simple: stay positive, stay curious, build with intent, and continuously refine how you work as both a product-first and AI-first engineer. Thanks for reading The Healthy Scientist: Build Using AI With Healthy Habits 🌱 I’ve spent the last decade building projects on my GitHub. Check them out for inspiration and contribution. I’m preparing more content coming your way on my LinkedIn! This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.pierrehenry.dev

Ratings & Reviews

About

Speaking about software engineering, AI, productivity, happiness, and intentional living. 🚀 I enjoy exploring ideas, sharing what I learn, and building products that solve meaningful problems. Topics I regularly discuss include: * Software engineering and product development * AI and emerging technologies * Productivity and time management * Personal growth and lifelong learning * Building systems, habits, and processes that last * Creating a fulfilling and intentional life Through writing, building, and continuous learning, I aim to share practical insights that help people think more clearly, work more effectively, and live more intentionally. I’m always interested in connecting with curious people, exchanging ideas, and collaborating on projects that create a positive impact. www.pierrehenry.dev