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.

Subscribe now

I recently had the chance to speak with Narender Reddy, a Lead Software Engineer working in the insurance industry in the United States. With more than 17 years of experience across web development, mobile development, cloud hosting, DevOps, and software architecture, he has seen the industry evolve through many times.

During our chat, Narender described AI as a tool that helps engineers work faster while still relying on human judgement, experience, and responsibility. Instead, he spoke about it as another tool that helps teams move faster while still requiring judgment, experience, and responsibility.

We discussed how large organisations are introducing AI into their engineering teams. Rather than introducing AI everywhere at once, they are first preparing the engineering platform. That includes migrating repositories to GitHub, replacing Jenkins with GitHub Actions, strengthening governance, and improving security before expanding AI adoption across the company.

We also talked about what it actually means to be a Lead Engineer.

Many people imagine that a lead engineer spends most of the day in meetings. While management is certainly part of the role, Narender still enjoys being hands on. He likes working with the team, discussing solutions together, discussing solutions together, encouraging engineers to propose ideas, and helping the team decide on the best approach together.

One part of the discussion that resonated with me was estimating work. Unknowns always appear during software development. His approach is to focus on today’s priorities, organise work clearly, and delegate whenever the right expertise already exists within the team. His approach is simple. Prioritise today’s work, organise tasks clearly, and delegate when the team has the right expertise. It sounds straightforward, but doing it consistently makes a real difference.

Naturally, we spent a lot of time talking about AI.

Today, he relies on AI for a significant part of his daily work. Writing user stories, analysing repositories, understanding unfamiliar codebases, and generating implementation plans have all become significantly faster. At the same time, enterprise security policies still limit where AI can be used, especially while large codebases continue migrating to newer platforms.

We also explored a topic that every engineer is thinking about today: trust.

How much information should we really give to AI systems?

There is no simple answer. We both agreed that there are clear benefits, but also responsibilities. Sensitive information, credentials, customer data, and private documents all require careful thought. Local models have their place, cloud models are becoming incredibly capable, and every engineer has to balance convenience with privacy.

The conversation also moved into software architecture.

We also explored monorepos, microservices, enterprise migrations, and the complexity of maintaining systems built by hundreds of engineers over many years. One example was particularly interesting. Different insurance products had evolved separate login systems, each with its own users, databases, and authentication flow. Bringing those together into a single authentication platform became a multi year engineering effort involving databases, APIs, migrations, and collaboration across many teams.

It is a reminder that software engineering is rarely just about writing code. Much of the work happens long before implementation begins.

Towards the end of our conversation, Narender shared that he is also researching AI adoption in enterprise environments and publishing research papers and technical articles on the subject. Like many engineers, he has found that writing about what he learns helps him organise his thinking and deepen his understanding. And that’s something I strongly relate to!

Whether it is an article, a video, or simply explaining an idea to someone else, teaching remains one of the best ways to learn.

We also both agreed that modern software engineering is becoming increasingly product focused. As AI takes over more repetitive implementation work, engineers spend more time thinking about user experience, architecture, and solving the right problems.

Lastly, we discussed internal hackathons, where teams prototype new ideas over a couple of days. One project involved AWS Bedrock to automate parts of the insurance underwriting process, reducing work that previously took days down to around an hour.

Subscribe now

Mentioned Resources & Links

• AWS Bedrock

• Zeera AI Tools (Narender uses it for his meetings)

• GitHub Copilot

• Google Scholar

• Medium Publications

Share

Subscribe now

Subscribe now

By understanding the psychology behind performance and cultivating the right habits, you can move from uncertainty to clarity, and from hesitation to deliberate progress.

Creating a mindset like this lets you reach your real level—not the one you’re afraid you might be at.

I’ve developed numerous projects on my GitHub over the years. Feel free to look at them for inspiration or to contribute! And I’ve got more content coming your way on my LinkedIn.

Share

You’ll see practical ways to automate processes, improve user experience, and make your apps genuinely smarter. Not the kind of “smart” that’s just a fancy loading spinner with GPT slapped on top. I’m talking about actual intelligence that solves real problems for your users.

We go through tools, methods, and frameworks that help save development time whilst delivering better results. Things like automating repetitive workflows, building intelligent recommendation systems, implementing smart data processing pipelines, and creating features that adapt to user behaviour over time.

However, here’s the thing: adding AI to your app isn’t about cramming every trendy model you can find into your codebase. It’s about identifying where AI genuinely adds value and implementing it in a way that’s maintainable, scalable, and doesn’t become a nightmare to debug six months from now.

Whether you’re building a new project or retrofitting AI into an existing application, this video breaks down the practical steps to make it happen without overcomplicating things. Let’s dive in!

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! 🔥​​​​​​​​​​​​​​​​

Share

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.

Subscribe now

🏁 Follow my Software Engineering Journey on PierreHenry.Dev.

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 🚀

Subscribe now

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 isn’t about working longer hours or grinding harder. It’s about working smarter with the right systems in place. Discover how the best engineers structure their days, protect their focus, and approach problems in ways that compound results over time. These are the patterns that actually move the needle.​​​​​

Subscribe now

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. Don’t forget to hit the ‘follow’ button so you won’t miss out! 🔥

Subscribe now

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.

Subscribe now

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 now

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!

Share

Subscribe now

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!

Subscribe now

I’ve built tons of product-centric projects on my GitHub over the years. Feel free to check them out for inspiration or jump in to contribute! And I’ve got more content coming your way on my LinkedIn! Stay tuned! 🔥

Share

Eenjoy your journey! 🏝️

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.

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!

Subscribe now

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.

Subscribe now

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.

Share

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.

Subscribe now

Subscribe now

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!

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.

Subscribe now

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! 🎯

Subscribe now

I’ve built tons of projects on my GitHub over the years. Check them out for inspiration or contribution. I’ve got more content coming your way on my LinkedIn! Hit that follow button so you don’t miss out! 🔥

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 learn 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.

Share

I built various projects on my GitHub over the years that might interest you. Feel free to browse them for inspiration or contribution.

And I’ve got more exciting content coming your way on my LinkedIn. Make sure to hit the follow button so you won’t miss anything.

Subscribe now

The way you start your day shapes everything that follows. In this video, I share the simple morning habits that help me show up sharper, think clearer, and code better. These aren’t complicated rituals or time-consuming routines. They’re small, deliberate actions that set the tone for deep work and consistent performance. Try them and see the difference yourself.

Subscribe now

You might be interested by this! Indeed, 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 that follow button so you don’t miss out!

Share

I have listed some of the most essential rules every software engineer should know. These principles are taken from The Pragmatic Programmer by Andy Hunt and Dave Thomas.

Algorithm speed 🚀

Although this is nothing new for any experienced engineer, you should always be careful when dealing with multiple loops.

The complexity of a simple loop is O(n). Now, if we introduce a function or method inside it that also loops over something, the complexity will immediately become O(m × n). Always consider the side effects of any change in your code to ensure there is no impact on the scalability of your application in the long term.

Best isn’t always best 💡

Be aware that premature optimisation is not always the appropriate decision at the start of any project or proof of concept (POC). At that stage, it is impossible to know the traffic or the eventual iterations and direction of your application. Instead, it is usually wiser to keep things simple and small.

Be pragmatic. Not a coincidental “Code Monkey” 💥

Coding is not a mechanical job. As a pragmatic programmer, you need to make the right decisions. You need to think critically about all code and the impact it could have, as well as how your code and software architecture will scale in the future.

On the other hand, a coincidence programmer will write code without planning or looking at the big picture. They tend to add mechanical code in an inefficient manner.

Automation 🤖

Automating things is an important concept in the lifecycle of an application. However, like optimisation, if you automate too early things that might not be repetitive, it will only add unnecessary extra hours of work.

Learn what you need 📝

Learning the right tools well (such as Jenkins, Docker, a framework, shortcuts, your favourite IDE, or a benchmarking tool) will be one of your greatest strengths in your career.

Don’t write Dodo-Code 🦤

Writing dodo code implies that your code will not adapt well over time. The dodo did not adapt to the presence of humans. They were once abundant on the island of Mauritius before going extinct. Do not give the same future to your code. Keep your codebase agile and well maintained, using good design patterns that make new changes and feature implementations easy.

Testing before production 🍳

Although this can seem obvious, too often I see last-minute “important” changes that need to be shipped to production as soon as possible. And since the software engineers do not have the time or necessary resources, they proceed with shipping the changes right away to please their manager or C-level stakeholders.

This can end up quite badly. It is always easy to underestimate what can go wrong until you wake up one morning and the entire online service is down because of a missing assignment operator or a missing semicolon or comma causing incorrect behaviour. No matter how much you trust the release, you are never 100% sure of the consequences of each change in your code. Integration and acceptance tests can be very useful here.

A good practice is also the use of the “chaos monkey” technique in your application to make sure there are no obvious issues with it.

The boy-scout rule 🧹

The Boy Scout rule says: “Always leave the campground cleaner than you found it.”

It means you should clean up even when others leave things messy, no matter the excuses. It does not matter whether you created the mess or not. The rule aims to make the codebase incrementally better, step by step, every time you touch a legacy or outdated part of the code.

So, every time you need to add or change something in an existing function or class, identify a small improvement you can also make. A tiny improvement will not introduce new problems or make the code review harder, but those small improvements, applied consistently, will make the entire codebase much cleaner over time.

Debugging mindset 🧠

Before debugging, it is important to adopt the right mindset. Debugging can be tricky and time-consuming.

Here are some rules of thumb that make this “mental digging” more pleasant 🤠:

1. Immediately think about which tier or layer of your code the problem could come from.

2. Failing early will tell you more directly where something is not working. Always fail early instead of quietly moving to the next function when something is not supposed to happen.

3. Use breakpoints and exception tracing.

4. Speaking to your rubber duck, an AI chat, or a colleague will help you see the bigger picture of what you are working on. Very often, you will have an “aha” moment when you explain what is not working, what has changed, and where you looked in the code.

5. Step back and consider the overall architecture and infrastructure to locate the problem more easily.

Rubber Duck debugging technique 🐥

Happy Debugging Day! 🤠 Enjoy solving and tackling your technical challenges! 🎯

Subscribe now

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. So, make sure to hit that follow button so you don’t miss out!

Share

Look, this might sound controversial, but hear me out. The actual act of writing code? That’s becoming less and less of the differentiator. AI can handle everything now. What it can’t do (at least not yet) is understand the whybehind what you’re building.

The engineers who are genuinely valuable are definitely no longer the ones who can write the most maintainable lines of code in a day. They’re the ones who can look at a feature request and ask: “Wait, does this actually solve the user’s problem? Is this the right approach? What are we missing here?”

Product-oriented thinking means you’re not just executing tasks. You’re questioning requirements. You’re thinking about edge cases before you write a single function. You’re considering the long-term maintenance burden of your decisions. You’re thinking like someone who owns the outcome, not just the implementation.

And here’s the thing: this requires clear thinking. Not clever thinking. Clear thinking. The ability to break down a complex problem into simple parts, spot what actually matters, and communicate your reasoning to others. That’s the skill that separates strong engineers from everyone else.

In this video (which is quite long because I’m walking and thinking out loud), I’ll break down what this actually looks like in practice. How to shift from “just tell me what to build” to “let me understand the problem first.” How to evaluate trade-offs. How to think through second and third-order effects of your decisions. And why this mindset matters more than any specific technology you know.

Share

I’ve been building several projects on my GitHub over the years that might interest you. Feel free to check them out for inspiration or jump in with contributions!

There are so much more to come on my LinkedIn! Don’t forget to follow and stay tuned! 🔥