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. -5 j

    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

    8 min
  2. 28 juin

    Interview with a Solo Engineer Who Builds Simple Software That Lasts

    Most software becomes more complex over time. More features, more abstractions, more layers. But what about taking the opposite path? I had the great pleasure of interviewing Herman Martinus, the founder of BearBlog. He has taken a very deliberate path: simplicity over growth, independence over scale, and a strong refusal to let feature requests dilute the core idea behind his product. That mindset alone makes his approach interesting to follow! Herman is a former video game developer based in Cape Town, South Africa, where the tech scene is real and active. Meetups happen regularly, and the community is small enough that you keep bumping into the same people, which builds genuine connections over time. And when it’s not cloudy, the majestic Table Mountain is right there outside his window (no need for a virtual background!). Definitely a nice backdrop. Cape Town also turns out to be a strong base for independent builders. The cost of living is relatively low, the time zone aligns well with Europe, and English is widely spoken. Many developers there work remotely for European companies, earning in pounds or euros while living on South African Rand, which creates a comfortable setup for independent work. We also go into building products that last, resisting overengineering, and why saying no is one of the most important skills for any founder. A recurring theme is focus: building for a specific kind of user instead of trying to serve everyone. What also caught my attention is how Herman manages his work rhythm. He does not rely on a rigid schedule. He follows what needs attention, stays mostly in maintenance mode when travelling, and recently spent a month in Japan doing just that: handling support, emails, and small fixes. No deep building, no pressure to ship. When he returned, he felt refreshed and ready to build again. He also noticed that mixing travel and deep work left him underwhelmed on both sides, so he now separates them more intentionally. We also discussed how he uses AI. It is not part of the product itself, but it plays a specific role in his workflow, mainly for security audits and content moderation. Not as a shortcut for building features, but as a targeted tool with a clear purpose. From a lockdown side project to a sustainable independent business, Herman shares a grounded perspective on software engineering, product design, and what it means to build something that stays useful long after launch. A lot is covered in this episode: Why simplicity is a real competitive advantage, the dangers of overengineering, growing without traditional marketing, the special ʕ•ᴥ•ʔ growth hack that drives most of the user acquisition, how constraints often lead to better products, and the philosophy behind Bear Blog’s Manifesto, which helps Herman stay focused on what actually really matters for Bear Blog and its core values. This episode is definitely a must-listen for all software engineers, indie entrepreneurs, founders, and anyone interested in building meaningful products with intention rather than complexity. Herman also hosts his own podcast, “The Idea Roastery”, co-hosted with his friend Jason Forte. 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! Thanks for passing by! 🌱 If you enjoyed this interview, I’ll make more like this. 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

    1 h 20 min
  3. 28 juin

    How to Keep Your Web Services PERFORMANT

    APIs and web applications can become complex very quickly, and performance issues usually come from multiple small inefficiencies stacked together. Improving load speed is less about one big fix and more about identifying bottlenecks and applying optimisations at the right layer of the system. In this tech session, we explore practical techniques to make web applications faster and more efficient across the full stack. We start with image optimisation, since it is often one of the biggest performance drains. This includes serving images at the correct size, compressing them properly, and removing unnecessary metadata. We also look at modern formats like WebP and AVIF, which significantly reduce file size compared to PNG or JPEG. On top of that, lazy loading using the native HTML loading attribute helps defer offscreen images and improves initial page render speed. Fonts also play a role in performance. Choosing lighter formats like WOFF2 instead of heavier TTF or OTF files can reduce load time noticeably, especially on content-heavy pages. From there, we move into frontend and network performance. CDNs (Content Delivery Networks) help reduce latency by serving assets from locations closer to users. Preloading critical resources can also improve perceived speed by prioritising what the browser needs first. For client-side applications such as React, avoiding synchronous blocking calls and using proper asynchronous API handling helps keep the UI responsive. We also look at how hosting location impacts performance. If your users are mostly in one region but your infrastructure is hosted far away, latency increases unnecessarily. Using multi-region deployments or edge-based services helps reduce this gap. A key part of debugging performance issues is using browser tools effectively. Chrome DevTools provides the Network and Performance tabs to inspect request timing, payload sizes, and rendering behaviour. Lighthouse adds a structured performance score and highlights specific areas for improvement, making it easier to prioritise fixes. On the backend, database optimisation is critical. Proper indexing in relational databases can drastically reduce query time. Tools like pgAnalyze (for Postgres) help identify slow queries and inefficient patterns. Caching is another major improvement area, using systems like Redis or Memcached to avoid repeated expensive database calls. A well-designed caching strategy can often tolerate 30–60 minute stale data windows depending on the use case. API design also matters. REST APIs are often easier to optimise with HTTP caching headers, while GraphQL requires more careful cache management due to flexible query structures. In both cases, avoiding unnecessary requests and reducing payload size improves overall performance. Other important techniques include pagination and limiting data transfer. Instead of loading everything at once, APIs should return only the required chunk of data. This works well alongside frontend lazy loading strategies. Finally, serverless architectures require attention to database connections. Opening too many connections can create overhead, so proper connection pooling and cleanup is essential. The goal of this video is to show that performance is not a single optimisation, but a collection of small improvements across images, fonts, frontend behaviour, APIs, caching, and backend systems. When combined, they produce a significantly faster and smoother user experience. 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 won’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

    10 min
  4. 26 juin

    Why Software Engineers Keep Choosing Complex Solutions Without Realizing It

    In this video, I break down why so many engineers default to complex solutions even when a simpler approach works better. And honestly? I’ve been guilty of this too. We all have. Here’s what’s really happening: ego, insecurity, and unclear thinking lead us straight into overengineering territory. You want to prove you’re smart, so you reach for the fancy design pattern. You’re worried the simple solution looks too basic, so you add layers of abstraction “just in case.” Or you haven’t actually clarified the problem, so you build something overly flexible to cover all possible scenarios. But here’s the truth… The best engineers aren’t the ones writing the most clever code. They’re the ones solving problems with the least amount of complexity necessary. Because simple code is easier to debug, faster to ship, and way more reliable in production. In this video, I’ll show you how to recognize when you’re overengineering, how to shift your mindset from “what’s the coolest solution?” to “what’s the right solution?”, and how to build cleaner, faster software that actually solves the problem at hand. Let’s talk about fighting the urge to be clever and learning to be effective instead. Psst! I’ve built tons of projects on my GitHub over the years. Check them out for inspiration or jump in to contribute! 🤠 I’ve got more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out! 🎯 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

    4 min
  5. 25 juin

    SSR vs CSR vs SPA: What Most Developers Get WRONG

    If you’ve worked with React, PHP, Django, Symfony, or modern SaaS products, you’ve probably heard terms like SSR, CSR, and SPA. They’re everywhere in web development, yet many developers use them without fully understanding the trade-offs behind each approach. In this article, I break down the differences between Server-Side Rendering (SSR), Client-Side Rendering (CSR), and Single-Page Applications (SPA) using practical examples from real-world software engineering. You will see how traditional server-rendered applications work, why frameworks such as Symfony, Rails, and Django have relied on SSR through Smarty, Twig, ERB, and Jinja2 for years, why SSR applications are (often) easier and simpler to build than CSR, and how modern frontend frameworks like React changed the way we build applications by moving much of the rendering logic to the browser. You’ll also learn why client-side rendering creates a clear separation between frontend and backend systems, what performance implications come with that choice, and when a single-page application can provide a smoother user experience for products such as dashboards, internal tools, and SaaS platforms. Whether you’re preparing for software engineering interviews, learning web architecture, or simply trying to better understand the technologies you use every day, this article provides a straightforward explanation of these core concepts without unnecessary complexity. By the end, you’ll understand: • What SSR, CSR, and SPA actually mean. • How data flows in each architecture. • The advantages and disadvantages of every approach • When to choose one over another. • Why modern applications often combine multiple rendering strategies. These concepts sit at the foundation of modern web development, and understanding them will help you make better architectural decisions for your next project. 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 min

Notes et avis

À propos

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