Forem: 👨‍💻Pierre-Henry ✨

Taking a Break from Dev.to (This is Why)

👨‍💻Pierre-Henry ✨ — Sun, 18 Jan 2026 02:40:25 +0000

After sharing posts here about AI, best engineering practices, and building scalable products, I'm stepping back from content creation.

What's Happening?

— Pierre-Henry

Keep learning. Keep researching. Keep practicing. Keep growing! 🚀

🏁 Follow my Software Engineering Journey on PierreHenry.Dev

Zero-Downtime Deployment & Canary Release

👨‍💻Pierre-Henry ✨ — Sun, 28 Dec 2025 10:42:11 +0000

Let's speak about the Zero-Downtime Deployment, a crucial concept for modern applications! Zero-downtime deployment ensures to keep everything running smoothly without interrupting the service while releasing new major changes to the server.

Understanding Zero-Downtime Deployment

Zero-downtime deployment means deploying new application versions to production without any service interruption. Users continue using your application normally while updates roll out in the background.

The core principle is maintaining service availability throughout the entire deployment process. This approach represents the best possible deployment scenario since teams can introduce new features and fix bugs without causing outages.

Blue-Green Deployment

Blue-Green deployment is one of the most straightforward approaches to zero-downtime deployment. The concept is simple despite its colorful name.

How Blue-Green Deployment Works

The strategy involves running two identical production environments simultaneously:

Blue Environment: Currently serves live traffic with the existing version
Green Environment: Receives the new version deployment and testing

The deployment process follows these steps:

Preparation: Your blue environment serves production traffic
Deployment: Create an identical green environment and deploy the new version
Testing: Run comprehensive smoke tests and sanity checks on the green environment
Traffic Switching: Redirect traffic from blue to green once confident in the new version
Monitoring: Keep both environments running temporarily for quick rollback if needed
Cleanup: Decommission the blue environment after confirming stability

Traffic Migration Strategies

When transitioning from blue to green, you have two primary approaches:

Immediate Switch: Redirect all traffic at once to the new environment. This approach is faster but carries higher risk if issues arise.

Gradual Migration: Start by routing a small percentage of traffic to the green environment, gradually increasing the load as confidence grows. This method provides better risk mitigation and allows for real-world testing under production conditions.

Blue-Green Deployment Checklist

For successful blue-green deployments, maintain this checklist:

[ ] Both environments are operational and properly configured
[ ] Comprehensive testing completed on the new environment
[ ] Traffic routing mechanism is ready and tested
[ ] Monitoring and alerting systems are in place
[ ] Rollback procedures are documented and tested
[ ] Database migrations are compatible with both versions
[ ] Load balancer configuration is updated appropriately to adjust the traffic accordingly

Canary Releases: Risk-Controlled Deployment

Canary releases offer a more sophisticated approach to risk management during deployments than blue-green deployment alone.

The Canary Release Philosophy

Named after canaries used in coal mines to detect dangerous gases, canary releases expose new software versions to a small, controlled subset of users before full deployment. This strategy identifies potential issues early while minimizing the impact of any problems.

Implementing Canary Releases

The canary release process follows these stages:

Initial Deployment: Deploy the new version alongside the existing one, but route no user traffic to it
Selective Exposure: Begin routing a small percentage of users to the new version
Monitoring and Analysis: Carefully monitor both business metrics and operational indicators
Gradual Expansion: Progressively increase the user base exposed to the new version
Full Rollout: Migrate all users to the new version once confidence is established
Cleanup: Remove the old version after confirming stability

User Selection Strategies

Choosing which users see the new version is crucial for effective canary releases:

Random Sampling: Select users randomly, providing an unbiased sample of your user base.

Internal Users First: Deploy to employees and internal stakeholders before external users, allowing for thorough testing in a controlled environment.

Demographic-Based Selection: Choose users based on specific characteristics, geographic location, or usage patterns that align with your testing objectives.

Geographic Rollout: In distributed systems, deploy to specific regions or data centers before global rollout.

Advanced Canary Strategies

Large-scale organizations often employ sophisticated canary approaches:

Multi-Stage Canaries: Companies like Facebook use multiple canary stages, starting with internal employees who have feature flags enabled to detect issues early.

Partition-Based Deployment: Instead of user-based routing, deploy to specific service instances, geographic regions, or business units.

Capacity Testing: Use canary releases to validate performance characteristics under real production load without risking the entire user base.

Canary Releases vs. A/B Testing

While canary releases and A/B testing share similar technical implementations, they serve different purposes:

Canary Releases focus on risk mitigation and detecting regressions or operational issues with new software versions.

A/B Testing aims to validate hypotheses about user behavior and business metrics using different feature variants.

Mixing these concerns can interfere with results and create confusion. A/B tests typically require days or weeks to achieve statistical significance, while canary rollouts should complete within hours.

Managing Complexity and Challenges

Version Management

Both blue-green and canary deployments require managing multiple software versions simultaneously. While this increases operational complexity, the benefits typically outweigh the costs. Best practices include:

Minimizing the number of concurrent versions in production
Implementing robust version tracking and monitoring
Automating deployment and rollback procedures
Maintaining clear documentation for each version

Database Considerations

Database schema changes present unique challenges in zero-downtime deployments. The Parallel Change pattern offers an effective solution:

Expand: Modify the database to support both old and new application versions
Migrate: Deploy the new application version while maintaining backward compatibility
Contract: Remove support for the old version once migration is complete

This approach ensures database compatibility throughout the deployment process.

Client-Side Applications

Deploying client-side applications (mobile apps, desktop software) presents additional challenges since update timing is beyond your control. Strategies include:

Using feature flags to control functionality rollout
Maintaining backward compatibility for extended periods
Implementing graceful degradation for unsupported client versions
Monitoring client version distribution to inform deprecation decisions

Implementation Considerations

Infrastructure Requirements

Successful zero-downtime deployments require:

Load Balancing: Required for traffic routing between environments. Solutions include cloud-based load balancers, nginx, HAProxy, or service mesh technologies.

Monitoring and Observability: Comprehensive monitoring of both business and operational metrics is crucial for detecting issues early.

Automation: Manual processes are error-prone and slow. Invest in automation for deployments, testing, and rollbacks.

Infrastructure as Code: Ensure environments can be reliably reproduced and configured consistently.

Cloud vs. On-Premises

Cloud platforms offer managed services that simplify zero-downtime deployments:

AWS: Route 53 for DNS routing, Application Load Balancer for traffic distribution, and services like CodeDeploy for automated deployments.

Other Cloud Providers: Similar services are available across major cloud platforms.

On-Premises: Requires more manual setup but remains achievable with proper tooling and processes.

Best Practices and Recommendations

Planning and Preparation

Design applications with zero-downtime deployment in mind from the beginning
Implement comprehensive testing strategies including unit, integration, and end-to-end tests
Practice deployment procedures regularly in non-production environments
Maintain detailed runbooks for both deployment and rollback procedures

Monitoring and Metrics

Define clear success criteria for deployments
Monitor both technical metrics (error rates, response times) and business metrics (conversion rates, user engagement)
Set up automated alerting for anomalies
Establish baseline metrics before deployments for comparison

Risk Management

Start with smaller, less critical applications to build expertise
Always have a tested rollback plan
Communicate deployment schedules with stakeholders
Consider the timing of deployments to minimize business impact

Conclusion

Zero-downtime deployment strategies like blue-green deployment and canary releases have become standard practices for modern software delivery. These approaches enable organizations to ship features rapidly while preserving service reliability.

Blue-green deployment provides a solid foundation with its straightforward approach to maintaining two production environments. Canary releases build upon this concept by adding sophisticated risk management through gradual user exposure and comprehensive monitoring.

The choice between these strategies—or a combination of both—depends on your specific requirements, risk tolerance, and operational capabilities. Regardless of the chosen approach, investing in zero-downtime deployment practices improves user satisfaction, reduces business risk, and increases deployment confidence.

As software delivery continues to accelerate, mastering these deployment strategies becomes increasingly important for DevOps and FullStack engineers seeking to balance innovation speed with operational stability. Start with solid fundamentals, invest in proper tooling and automation, and more importantly, continuously refine your processes based on real-world experience.

Hopefully this helps! I wish you a wonderful happy deploying day! 🤠

⚡️ You can check out my open-source projects I'm working on at GitHub.com/pH-7

🏁 Follow my Software Engineering Journey on PierreHenry.Dev

What is Serverless? And why you should care about it?

👨‍💻Pierre-Henry ✨ — Sat, 13 Dec 2025 12:42:39 +0000

Let’s face it, the term “serverless” can be quite confusing at first. Despite its name, servers are still involved. You’re just not the one managing them anymore. And honestly? That’s the beauty of it.

Serverless is essentially a collection of endpoints and functions, each performing a single task. Unlike uploading a full-stack application on Lambda, you upload functions that act as endpoints. These endpoints can then be consumed on your frontend, just like any other regular REST API.

The architecture behind it 🏗️

Ideally, your frontend should be decoupled from your backend and hosted on services like Vercel or Netlify, or any other platform of your choice. This separation of concerns isn’t just a nice-to-have. It’s fundamental to understanding what serverless truly brings to the table.

While setting up serverless architecture on AWS can be slightly complex, numerous services abstract away this complexity, allowing you to focus solely on your code. And this is where the magic happens. You stop worrying about server maintenance, scaling, and infrastructure headaches, and instead spend your time writing the code that actually matters.

Why serverless makes sense 💡

Think about it. How many times have you spent hours configuring servers, setting up load balancers, or debugging deployment issues that had nothing to do with your actual application logic? With serverless, you write a function, deploy it, and it scales automatically based on demand.

Each function is stateless and independent. Need to add a new feature? Write a new function. Need to update something? Deploy just that function without touching the rest of your infrastructure. No downtime, no complicated orchestration, just pure simplicity.

The real benefits 🚀

The beauty of serverless goes beyond just “not managing servers.” You only pay for what you use. If your function isn’t being called, you’re not paying for idle server time. This makes it incredibly cost-effective, especially for applications with variable traffic patterns.

Additionally, scaling happens automatically. Whether you have 10 requests or 10,000 requests per second, the cloud provider handles it for you. No need to predict traffic spikes or overprovision resources “just in case.”

When serverless shines ✨

Serverless is particularly well-suited for event-driven architectures, microservices, APIs, and background processing tasks. If you’re building a REST API that needs to scale effortlessly, serverless is your friend. If you need to process files uploaded to S3 or respond to database changes, serverless fits perfectly.

However, it’s not always the right choice for every scenario. Long-running processes, applications requiring persistent connections, or workloads with very predictable and constant traffic might be better suited for traditional server architectures.

Getting started without the headache 🎯

AWS Lambda is the most popular serverless platform, but the initial setup can feel overwhelming. This is where frameworks and services come to the rescue. Tools like Serverless Framework, AWS SAM, or Vercel Functions abstract away much of the complexity, letting you focus on writing functions instead of wrestling with configuration files.

The key is to start small. Pick one endpoint from your existing application and convert it to a serverless function. See how it works, understand the patterns, and gradually expand from there. Don’t try to migrate everything at once. That’s a recipe for frustration and confusion.

The mindset shift 🧠

Moving to serverless requires a bit of a mindset shift. You’re no longer thinking about servers, you’re thinking about functions and events. Each function should do one thing and do it well. This aligns perfectly with good software engineering principles: single responsibility, loose coupling, and high cohesion.

Your application becomes a collection of small, independently deployable units. This makes debugging easier (you know exactly which function is failing), deployments safer (you’re not deploying a monolith), and development faster (teams can work on different functions without stepping on each other’s toes).

Final thoughts 🤔

Serverless isn’t just a buzzword or a passing trend. It’s a fundamental shift in how we build and deploy applications. Like any tool, it’s not perfect for every situation, but when used appropriately, it can significantly boost productivity and reduce operational overhead.

The best part? Well, you can start today without committing to a full migration. Pick a small piece of functionality, write it as a serverless function, and see how it feels. And you might actually find that managing servers was never something you needed to do in the first place! 😉

Why I moved to Neovim. And ditched VS Code/IntelliJ

👨‍💻Pierre-Henry ✨ — Sat, 06 Dec 2025 12:27:50 +0000

I've been using VS Code and IntelliJ as my main editors for quite a long time, moving from Sublime Text and Atom. VS Code/IntelliJ immediately remind me of the time when we didn't have better alternatives for modern development workflows.

Apart from being widely adopted and having massive plugin ecosystems, VS Code and IntelliJ have some issues that can be easily fixed with a "more modern" (or rather, "timeless") alternative.

I've recently started using Neovim (along with tmux), and it does have many advantages compared to traditional IDEs. And FYI, the amazing Linux distribution, Omacom, comes directly with Neovim.

First of all, it's very fast! (Neovim, with its terminal-based interface, starts instantly compared to VS Code/IntelliJ). Editing code has been a real pleasure. The startup time and file switching are considerably faster.

Then, it keeps you focused on the essential, whereas VS Code/IntelliJ don't do this at all. With traditional IDEs, each time you need to switch context, you're moving between windows, tabs, and panels. This leads to constant distraction and context switching. Furthermore, you will still need to use your mouse frequently for navigation. In addition, there is always the temptation to install "just one more extension" that slows everything down (Neovim keeps you in the terminal with keyboard-driven workflows).

Neovim (and a few others such as [Helix](https://github.com/helix-editor/helix) that can also be used as modern modal editors) handle this under the hood. This way, when you are dealing with multiple projects and terminal sessions, you won't have any bad surprises like slow startups or high CPU/memory usage, for instance.

For instance, here's my typical workflow:

# Terminal session with tmux
tmux new -s coding
nvim .
# Everything happens here (editing, git, terminals, all keyboard-driven)

With Neovim, I stay in the terminal where everything I need is right there. You can also (and very easily) start using Neovim in your existing projects without changing anything. At the end of the day, it's just a text editor that works with any codebase.

-- Example Neovim config (init.lua)
vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.tabstop = 2
vim.opt.shiftwidth = 2

-- Using lazy.nvim for plugin management
require("lazy").setup({
  "nvim-telescope/telescope.nvim",
  "neovim/nvim-lspconfig",
  "hrsh7th/nvim-cmp",
})

It's also good to mention that Neovim is fully compatible with Vim plugins while adding modern features like LSP support, tree-sitter, and Lua configuration.

Downsides

The only case where you should still use VS Code/IntelliJ is when you're just starting out in programming. This occurs either when you're learning to code or working in a team that requires specific IDE features. The problem is that Neovim has a steep learning curve initially. We need time to learn modal editing and configure everything, such as LSP servers, formatters, and keybindings that don't come pre-configured.

However, for experienced developers who value speed and efficiency, Neovim is the clear winner. Anyway, it's worth trying it for a week or two 😉

Now, it will give a significant boost to your productivity and focus, as well as better resource usage on your machine, which is the most important at the end of the day, right? 😊

Alternatives

Helix is another modal editor option (still relatively new and not very popular either), that provides a similar experience to Neovim. It also offers modern features out of the box, but it uses a different selection-first model and has fewer plugins available compared to Neovim's mature ecosystem.

When to still use VS Code/IntelliJ

Lastly (although you might not need this), it's good to mention that VS Code/IntelliJ are still perfectly valid for beginners, pair programming sessions (where screen sharing GUI is helpful), or teams with standardized IDE setups that require specific extensions and configurations.

👉 See my projects on GitHub, GitHub.com/pH-7 💡
☕️ Was this helpful? You could offer me one of my favorite coffees: Ko-fi.com/phenry 😋

[Boost]

👨‍💻Pierre-Henry ✨ — Sun, 09 Nov 2025 09:17:22 +0000

👨‍💻Pierre-Henry ✨

Nov 8 '25

Why it's time to ditch UUIDv4 and switch to UUIDv7!

#uuid #database #performance #node

Comments 4

3 min read

Why it's time to ditch UUIDv4 and switch to UUIDv7!

👨‍💻Pierre-Henry ✨ — Sat, 08 Nov 2025 02:29:13 +0000

I've been using UUIDv4 as my go-to identifier for database primary keys for quite a long time, moving from sequential integer IDs (auto-increment/SERIAL). UUIDv4 immediately reminds me of the time when we didn't have better alternatives for distributed systems.

Apart from being widely adopted and having massive usage, UUIDv4 has some issues that can be easily fixed with a "more modern" alternative.

I've recently started using UUIDv7 and it does offer many advantages in comparison with UUIDv4.

First of all, it's really fast (UUIDv7, with its time-ordered structure, claims to be 2-5x faster for inserts than UUIDv4). Writing records to the database has been a real pleasure. The insert performance and index maintenance are considerably faster.

Second, it naturally sorts by creation time, whereas UUIDv4 doesn't do this at all. With UUIDv4, each time you insert a record, it lands in a random position in your B-tree index, causing page splits and fragmentation. This leads to degraded performance over time. Furthermore, you will still need to add a separate created_at timestamp column if you want to sort records chronologically. In addition, there is always index fragmentation when inserting with UUIDv4 (UUIDv7 appends sequentially to the index, providing better cache locality for index operations).

UUIDv7 (and a few others such as ULID that can also be used as time-ordered identifiers) handle this under the hood. This way, when you are dealing with high-volume inserts and large databases, you won't have any bad surprises like severe performance degradation or bloated indexes, for instance.

For instance, here's how UUIDv7 structures its data:

018c8e8a-9d4e-7890-a123-456789abcdef
└─timestamp─┘ └───random bits────┘

The first 48 bits contain a Unix timestamp with millisecond precision, so UUIDs generated over time are naturally sequential. You can also (and very easily) start using UUIDv7 in your existing projects without migrating old UUIDv4 records, because both can coexist in the same column.

// Node.js usage
const { v7: uuidv7 } = require('uuid');
const id = uuidv7();
console.log(id); // 018c8e8a-9d4e-7890-a123-456789abcdef

// example database record
{
  "id": "018c8e8a-9d4e-7890-a123-456789abcdef",
  "user_id": "018c8e8a-9d50-7000-c345-6789abcdef01",
  "created_at": "2024-11-08T10:30:00Z"
}

It's also good to mention that UUIDv7 maintains the same 128-bit format as UUIDv4, so it works with all existing UUID columns in your database.

Benchmark

UUIDv4 database inserts: 2,847ms
UUIDv7 database inserts: 2,763ms

Note: My benchmark was run with Node v20.10.0

// Run: node benchmark-uuid-comparison.js

// UUIDv4 benchmark
const { randomUUID } = require("crypto");

console.time("UUIDv4 database inserts");
for (let time = 0; time < 10_000_000; time++) {
  randomUUID();
}
console.timeEnd("UUIDv4 database inserts");

// UUIDv7 benchmark
const { v7: uuidv7 } = require("uuid");

console.time("UUIDv7 database inserts");
for (let time = 0; time < 10_000_000; time++) {
  uuidv7();
}
console.timeEnd("UUIDv7 database inserts");

// note, I've used 10_000_000 with _ which are numeric separators
// https://github.com/pH-7/GoodJsCode#-clearreadable-numbers

The real performance difference shows up in actual database operations where UUIDv7's sequential nature prevents index fragmentation.

Downsides...

The only case where you still want to use UUIDv4 is when you explicitly don't want temporal ordering. This occurs either when you're building security tokens, API keys, or session IDs where predictability could be a security concern. The problem is that UUIDv7's timestamp-based structure reveals when the identifier was created. We need something completely unpredictable in these scenarios, such as pure random identifiers that don't leak any information about creation time.

However, for database primary keys and foreign keys, UUIDv7 is the clear winner. Anyway, it's worth trying it in your next new project 😉

Now, it will give a significant boost to performance for your database operations, as well as better index efficiency over time, which is the most important at the end of the day, right? 😊

Alternatives

UUIDv6 is another time-based UUID option (still relatively new and not very popular either), that is essentially a fixed version of UUIDv1. It also provides sequential ordering like UUIDv7, but it still includes MAC address information (or random node ID) in its structure, which UUIDv7 avoids entirely for privacy reasons.

Where to continue using UUIDv4

Lastly (although you might not need this), it's good to mention that UUIDv4 is still perfectly valid for security tokens, API keys, session IDs (where you don't want creation time leakage), or PostgreSQL databases (where the performance impact of random UUIDs is less severe for PostgreSQL since it appends new data to a heap rather than reordering it in a clustered index like MySQL).

👉 See my projects on GitHub, GitHub.com/pH-7 💡
☕️ Was this helpful? You could offer me one of my favorite coffees: Ko-fi.com/phenry 😋

Comparing Objects with PHP 🐘 Step-By-Step Guide

👨‍💻Pierre-Henry ✨ — Sat, 25 Oct 2025 02:53:14 +0000

In this screencast tutorial, I’m sharing how to compare objects and their instances with PHP. We are discussing the comparison operator, the strict identity comparison operator, etc. All in PHP!

🏁 Follow my AI Data Software Engineering Journey at PierreHenry.DEV
🤖 Get inspired by open-source GitHub projects I’ve built for the past years GitHub.com/pH-7
👋 Is this helpful? How about sending me a cup of coffee via Ko-Fi 😊

How to UNDO a GIT PUSH FORCE?

👨‍💻Pierre-Henry ✨ — Wed, 22 Oct 2025 07:42:05 +0000

In this session, you will see how you can use a git reset -f to restore a git push --force against a main or development branch. Thanks to git reset, you will be able to reset your branch to the desire commit hash.

You will understand how to undo an accidental git push --force and recover your lost commits! This tutorial covers:

Understanding the risks of force pushing
Using git reflog to find lost commits
Resetting your local branch
Restoring the remote repository
Best practices to avoid future accidents

Whether you're a beginner or experienced developer, this guide will help you recover from git push force mistakes. Don't panic, your code can be saved!

⏱️ Timestamps:
0:00 Introduction
1:15 What is git push --force?
3:30 Using git reflog
5:45 Resetting your branch
8:00 Pushing changes back
10:15 Prevention tips
📚 Resources:
Git documentation: https://git-scm.com/doc
Git reflog: https://git-scm.com/docs/git-reflog

🏁 Follow my Software Engineering Journey on PierreHenry.Dev

Set systems, rather than relying on goals or motivations

👨‍💻Pierre-Henry ✨ — Wed, 15 Oct 2025 09:00:15 +0000

Don't give up! Ever! And this is even more important as a software engineer. Set systems, rather than relying on goals or motivations. The most difficult part is starting to think in "systems" for everything you want to achieve efficiently. Once you have that mindset, you are on the right track.

Start breaking down problems into very small pieces, and draft a prototype before implementation.

🏁 Follow my Software Engineering Journey on PierreHenry.Dev

🇫🇷 Commencer en tant que Data Scientist. Démarrer une carrière fructueuse

👨‍💻Pierre-Henry ✨ — Wed, 24 Sep 2025 08:26:20 +0000

Aujourd'hui, dans cette courte vidéo, je te partager mes astuces pour démarrer ta carrière de Data Scientist, de la passion et des premiers challenges jusqu'aux missions et aux postes à haute responsabilité en science des données.

🤩 Mon GitHub: https://github.com/pH-7

🏁 Mon Dev.to https://dev.to/pierre

Clean Code: How to use NAMED PARAMETERS in JavaScript

👨‍💻Pierre-Henry ✨ — Tue, 24 Jun 2025 12:17:04 +0000

If you're familiar with named/keyword arguments in programming languages like Ruby, Python, and PHP 8, you might wonder if JavaScript offers the same functionality.
That's an excellent question. Named parameters, also known as named arguments, significantly enhance code readability. With named-parameter arguments, we can directly understand the purpose of each argument in a function call.

One way to achieve this is by using object destructuring on the function parameters.

Here’s an example:

const invertSentence = ({
  sentence,
  doesFormat = false
}) => {
  if (doesFormat) {
    return sentence;
  }

  // Logic…

  // Split the sentence into two segments
  const [stringOne, stringTwo] = sentence.split(“. “);

  // Rebuild the sentence
  const rebuiltString = `${stringTwo} ${stringOne}`;

  return rebuiltString;
};

Now, you can specify the required properties as “named arguments” when calling the function.

invertSentence({
  sentence: 'JS makes my job easier. Writing clean code avoid me from having a headache',
  doesFormat: false
});

Conclusion

In conclusion, JavaScript doesn't support keyword arguments natively, unlike PHP 8 and Python for instance. However, thanks to the power of object destructuring (introduced in ES6), we can structure our function signatures to accept arguments using their respective property names, thereby enhancing code readability.

And you, how often are you using this technique?

Happy JS Developing Day! 🤠 You can follow me on GitHub at GitHub.com/pH-7

Rubber Duck Debugging Method

👨‍💻Pierre-Henry ✨ — Tue, 11 Mar 2025 09:16:26 +0000

Today, I would like to share the Rubber Duck(y) Debugging Method. This efficient debugging approach in programming that can be used along with AI helps you to break down the situation of a given problem. This technique has helped me a lot as a software engineer.

And you? What is your favorite way to debug a problem/bug you are facing?

Reference: https://en.wikipedia.org/wiki/Rubber_duck_debugging

Happy problem-solving session! ⚡️

👉 You can follow me on GitHub - https://github.com/pH-7
☕️ Was this debugging technique helpful? What about offering me a cup of my favorite coffee? Ko-fi.com/phenry 😋