After spending quite some time exploring various engineering topics and building impactful projects while keeping healthy habits, today I am taking a break to focus on a new chapter.

Taking a Break to Focus on What's Next

After quite some time writing about AI, research, and building with healthy habits, I'm stepping back from content creation.

What Changes

✓ All existing posts remain available

✗ No new posts will be published

✗ Comments won't be monitored

✗ Newsletter is paused

Why I'm Telling You This…

Everything I've written here was created on my own time, independently. I'm proud of this work and want to preserve it properly as I shift my focus elsewhere.

Keep Going

Don't wait for permission. Don't wait for perfect conditions. Keep learning. Keep building. Keep applying what you discover. That's where growth happens—in the doing, not the planning. Maybe I'll be back with new insights someday. Maybe not. Either way, thank you for being here.

What This Really Means to You…

• All existing posts remain available.

• No new posts will be published.

• I won’t be responding to comments.

• Newsletter is paused.

Thanks for being part of this journey!

Share The Healthy Scientist: Build Using AI With Healthy Habits 🔥

Keep learning, researching, practicing, and growing! 🚀

Spoiler Alert: We will also discuss about CouchDB, PouchDB, and other very exciting things! ⚡️

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!

I’ve got more content coming your way on my LinkedIn.

Subscribe now

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

Subscribe now

We’ve all been there. You see a trending framework on Twitter, get excited, start a new project, build for three days, then... it just sits there. Unfinished. Forgotten. Added to the graveyard of abandoned repositories with a README and nothing else.

Here’s what I’ve learned: projects built on hype die the moment the hype fades. You start because something looks cool or you think it’ll be impressive on your portfolio. But when the initial excitement wears off and you hit the boring middle part? There’s nothing left to keep you going.

Choosing meaning over hype changes everything. When you build something that solves a real problem you care about, the motivation is completely different. You’re not building because it’s trendy. You’re building because you genuinely want this thing to exist. That deeper purpose carries you through the hard parts where most people quit.

Well... staying consistent becomes natural when the project actually matters to you. It’s not about forcing yourself to work on it or setting arbitrary goals. You just... keep coming back to it. Because you want to see it finished. Because you’re excited about using it yourself or seeing others benefit from it.

And here’s what makes a project worth finishing: it solves something real. Not theoretical. Not “this might be useful someday.” Real problems that you or someone else faces right now. When you can picture the exact person who’ll benefit from what you’re building, finishing stops feeling like a chore and starts feeling necessary.

Subscribe now

I’ve built many projects on my GitHub over the years. Check them out for inspiration or contribution!

I’ve got plenty more content coming your way on my LinkedIn! Hit the ‘follow’ button so you won’t miss out!

Share

If you feel like you’re learning slower than others…, this one is for you! I’ll share the exact mindset and structure to develop a learning loop that accelerates your progress, project after project. I used to watch other engineers pick up new technologies seemingly overnight whilst I struggled for weeks with the same concepts. It felt rubbish, honestly. Like everyone had some secret learning ability I just didn’t have.

But here’s what I discovered: fast learners aren’t magically smarter. They’ve just built better learning loops. They extract more knowledge from each project, apply it to the next one, and compound their skills faster than people who treat every project like starting from scratch.

The mindset shift is huge. Instead of “I need to learn everything about React before I start”, it becomes “I’ll learn what I need for this specific feature, build it, see what breaks, and learn from there”.

Active learning through doing beats every single time passive learning through reading.

Well… here’s what a proper learning loop looks like: You build something. You encounter problems you don’t know how to solve. You figure them out (through docs, asking questions, experimenting). You reflect on what you learnt and why it works that way. You apply that knowledge to the next thing you build. That last step is what most people skip, and it’s where the acceleration happens.

The structure matters too, right? After finishing any project (even small ones), spend 10 minutes asking yourself the following:

• What did I learn?

• What would I do differently next time?

• What patterns or concepts clicked that I can use elsewhere?

These questions turn random experiences into structured knowledge that actually sticks.

I’ve developed numerous projects on my GitHub over the years. Feel free to browse them for inspiration or to contribute! And I’ve so much more to come on my LinkedIn as well! Don’t forget to follow and stay tuned!

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

Subscribe now

Look, I get it. You have an idea, you’re excited about it, and your fingers are itching to open your IDE and start hammering out code. I’ve done this countless times myself. But here’s the thing: that’s usually how you end up with a complete mess three weeks later, wondering why nothing works the way you imagined it would.

The best engineers? They begin with clear plans, simple sketches, and fast prototypes to understand what truly needs to be built. Not fancy over-engineered architecture diagrams or 50-page documentation that nobody will read. Just enough planning to avoid wasting weeks building completely the wrong thing.

This approach reduces wasted work massively. You catch obvious problems before writing a single line of code. You realise that feature X doesn’t actually solve the real problem when you sketch it out on paper. You see that the data flow you had in your head won’t work in practice. All of this happens before you’ve invested days into implementation that you’ll have to throw away.

It also improves product quality because you’re thinking through edge cases, user flows, and technical constraints upfront instead of discovering them when it’s too late. And it gives you a much clearer path from idea to final outcome. No more “I’ll figure it out as I go” coding sessions that lead absolutely nowhere.

In this video, I’ll break down how to plan effectively without overdoing it, how to sketch out ideas quickly (honestly, pen and paper works brilliantly for this), and how to build throwaway prototypes that answer your biggest questions before committing to a full implementation.

Because at the end of the day, the fastest way to ship something good isn’t to code first and think later. It’s to think just enough, then code with clarity and purpose. Your future self will thank you for it.

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.

Keep learning, researching, practicing, teaching, and growing! 🚀

The answer is usually the same: the code wasn’t designed with change in mind.

That’s where SOLID principles come in. They’re not fancy design patterns or cutting-edge frameworks. They’re five fundamental principles that, if you follow them, make your systems stable, maintainable, and actually pleasant to work with.

Let’s break them down, one by one.

S: Single Responsibility Principle

Every class should have one reason to change.

Here’s the idea: each object should do one thing and do it well. All its methods should be tightly focused on that single responsibility.

Think about it this way. Imagine you have a `User` class that handles:

- User authentication

- Sending email notifications

- Generating PDF reports

- Database operations

What happens when you need to change how emails are sent? You have to touch the `User` class. What about when the PDF library updates? Yep, `User` class again. What if you want to swap databases? Same thing.

This is a nightmare. Every change, no matter how small, risks breaking something else.

A better approach:

class User {

constructor(id, name, email) {

this.id = id;

this.name = name;

this.email = email;

}

isValid() {

return this.email && this.email.includes(’@’);

}

}

class UserAuthenticator {

authenticate(user, password) {

// Handle login logic

}

}

class EmailService {

sendWelcomeEmail(user) {

// Send email

}

}

class UserRepository {

save(user) {

// Database operations

}

}

Now each class has exactly one reason to change. Email logic changes? Touch `EmailService`. Authentication changes? Touch `UserAuthenticator`. The `User` class itself stays stable.

But here’s the thing: don’t over-engineer this. If your application isn’t changing in ways that cause different responsibilities to evolve independently, you don’t need to separate them yet. Start simple. Refactor when the pain becomes real.

This is important. I’ve seen developers create twenty tiny classes for what could be three, all in the name of SRP. That’s not helpful. The principle is about managing change, not about making everything as small as possible.

O: Open-Closed Principle

Open for extension, closed for modification.

This one sounds abstract, but the metaphor is perfect: open-chest surgery is not needed when putting on a coat.

In other words, you should be able to add new functionality without changing existing code. Why? Because every time you modify working code, you risk breaking it. And let’s face it, nobody wants to be the person who broke production on a Friday afternoon because they added “just one more feature.”

Let’s say you’re building a payment system:

// Bad approach

class PaymentProcessor {

processPayment(amount, type) {

if (type === ‘credit_card’) {

// Credit card logic

} else if (type === ‘paypal’) {

// PayPal logic

} else if (type === ‘crypto’) {

// Crypto logic

}

}

}

Every time you add a new payment method, you have to modify `PaymentProcessor`. That’s risky. And it violates the open-closed principle.

What’s worse? You’re probably running this code in production. Every modification means retesting everything. That credit card logic that’s been working for two years? Now you have to verify it still works after you added crypto support. Exhausting.

Better approach:

class PaymentProcessor {

constructor(paymentMethod) {

this.paymentMethod = paymentMethod;

}

processPayment(amount) {

return this.paymentMethod.pay(amount);

}

}

class CreditCardPayment {

pay(amount) {

// Credit card logic

}

}

class PayPalPayment {

pay(amount) {

// PayPal logic

}

}

class CryptoPayment {

pay(amount) {

// Crypto logic

}

}

Now you can add new payment methods without touching `PaymentProcessor`. Just create a new class that implements the `pay` method. The system is open for extension, but closed for modification.

The existing payment methods keep working. No retesting needed. No risk of breaking production. You just plug in the new payment type and go. That’s the power of this principle.

L: Liskov Substitution Principle

Subtypes must be substitutable for their base types.

This is my favorite analogy: if it looks like a duck and quacks like a duck but needs batteries, you probably have the wrong abstraction.

In practice, this means if you have a base class and a derived class, you should be able to use the derived class anywhere the base class is expected without breaking things. Sounds reasonable, right? But it’s surprisingly easy to violate.

Here’s a classic violation:

class Bird {

fly() {

console.log(’Flying!’);

}

}

class Penguin extends Bird {

fly() {

throw new Error(’Penguins cannot fly!’);

}

}

This breaks LSP. If some code expects a `Bird` and calls `fly()`, it’ll crash if you pass in a `Penguin`. The subtype isn’t substitutable for the base type.

I’ve seen this pattern so many times in real codebases. Someone creates a nice abstraction, then realizes “wait, this special case doesn’t quite fit,” so they add a method that throws an error. Now every caller has to know about this special case and handle it differently. The abstraction becomes useless.

Better approach:

class Bird {

move() {

console.log(’Moving!’);

}

}

class FlyingBird extends Bird {

fly() {

console.log(’Flying!’);

}

}

class Penguin extends Bird {

swim() {

console.log(’Swimming!’);

}

}

Now “Penguin” doesn’t promise something it can’t deliver. The abstraction actually matches reality.

The key lesson? Don’t force inheritance where it doesn’t fit. Think carefully about what behaviors your base class promises, and make sure all subclasses can actually fulfill those promises. If they can’t, your abstraction is wrong. It’s that simple.

I: Interface Segregation Principle

Clients shouldn’t be forced to depend on methods they don’t use.

Remember: an interface with only one method is totally fine. In fact, it’s often ideal.

The opposite of this is called a “fat interface.” It’s when you have one massive interface that tries to do everything, and clients are forced to implement methods they don’t actually need. This creates friction everywhere.

Here’s an example:

// Bad: Fat interface

class Worker {

work() { }

eat() { }

sleep() { }

attendMeeting() { }

}

class Robot extends Worker {

work() {

console.log('Working...');

}

eat() {

throw new Error('Robots do not eat');

}

sleep() {

throw new Error('Robots do not sleep');

}

attendMeeting() {

throw new Error(’Robots do not attend meetings’);

}

}

This is absurd, right? The `Robot` is forced to implement methods that make no sense for it. And look at all those error throws. That’s a code smell. Any time you’re implementing a method just to throw an error, you’ve violated this principle.

Better approach:

class Workable {

work() { }

}

class Eatable {

eat() { }

}

class Sleepable {

sleep() { }

}

class Human extends Workable, Eatable, Sleepable {

// Implements all three

}

class Robot extends Workable {

// Only implements work

}

Now each class only depends on the interfaces it actually needs. Tailor your interfaces to individual clients’ needs. Keep them small, focused, and specific.

Well… I’ll be honest. When I first learned this principle, I thought “isn’t this just common sense?” But then I started reviewing code and realized how often it’s violated. We love creating one big interface because it feels organized. “Everything a Worker needs is in one place!” But that convenience comes at a cost. Don’t fall into that trap.

D: Dependency Inversion Principle

It depend on abstractions, not concretions.

The metaphor here is perfect: would you solder a lamp directly to the electrical wiring in a wall? Of course not. You’d use a plug and socket. That way you can swap out the lamp without rewiring your house.

The same principle applies to code. High-level modules shouldn’t depend on low-level implementation details. Both should depend on abstractions. This is probably the most impactful of all five principles when you actually apply it.

Here’s what this looks like in practice:

// Bad: Direct dependency on implementation

class UserService {

constructor() {

this.database = new MySQLDatabase();

}

getUser(id) {

return this.database.query(`SELECT * FROM users WHERE id = ${id}`);

}

}

This is tightly coupled to MySQL. What if you want to switch to PostgreSQL? Or add a caching layer? You have to modify `UserService`. And probably every test that uses it. And probably a dozen other places in your codebase.

I’ve been on teams where switching databases took months because of this kind of coupling. It’s painful.

Better approach:

// Good: Depend on abstraction

class UserService {

constructor(database) {

this.database = database;

}

getUser(id) {

return this.database.findById(’users’, id);

}

}

class MySQLDatabase {

findById(table, id) {

// MySQL-specific implementation

}

}

class PostgreSQLDatabase {

findById(table, id) {

// PostgreSQL-specific implementation

}

}

// Usage

const db = new MySQLDatabase();

const userService = new UserService(db);

Now `UserService` doesn’t care what database you’re using. It just depends on something stable: the abstraction that any database provides a `findById` method.

This is dependency injection in action. And it makes your code incredibly flexible and testable. Want to test `UserService`? Just pass in a fake database object. No need to spin up a real database for every test. Beautiful 🎯

Putting It All Together

SOLID principles aren’t about making your code more complex. They’re about making it more stable and easier to change.

Here’s the thing: you don’t need to apply all five principles everywhere, all the time. That’s over-engineering. But when you feel pain in your codebase—when changes become risky, when bugs keep popping up, when adding features feels like playing Jenga—that’s when SOLID principles show their value.

I’ve worked on codebases that followed these principles religiously, and codebases that ignored them completely. The difference is night and day. The SOLID codebases? Features take hours, not weeks. Bugs are isolated and easy to fix. New team members can contribute confidently. The non-SOLID codebases? Every change is scary. Nobody wants to touch certain files. Technical debt compounds until eventually someone suggests a full rewrite.

Don’t be that team.

Key takeaways

Single Responsibility: One class, one reason to change. But don’t over-engineer it. Start simple, refactor when the pain appears.

Open-Closed: Add features without modifying existing code. Your production code will thank you.

Liskov Substitution: Subtypes should be drop-in replacements. If you’re throwing errors in overridden methods, your abstraction is wrong.

Interface Segregation: Keep interfaces small and focused. One method per interface is totally fine.

Dependency Inversion: Depend on stable abstractions, not concrete implementations. This makes testing easy and changes safe.

Start applying these when the pain appears. Your future self (and your teammates) will thank you ☺️

Share

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.

Share

As we know, AI is changing our industry faster than most people realise.

If your main skill is writing boilerplate code or implementing basic features, you’re in trouble. AI can do that stuff now, and it’s getting better every week.

Here’s what actually matters: the skills AI can’t replicate. Understanding what problem needs solving in the first place. Making architectural decisions with real trade-offs. Knowing when to ship simple versus when complexity is justified. These require human judgement, not pattern matching.

System thinking is absolutely crucial now. AI can write individual functions brilliantly. But can it design how an entire application should fit together? Can it understand the second and third-order effects of architectural choices? Can it balance competing priorities like performance, maintainability, and time to ship? Not really. That’s where you add value.

Product sense separates engineers who stay valuable from those who get replaced. AI doesn’t know what users actually need. It can’t tell you whether a feature solves a real problem or creates more confusion. It can’t prioritise what to build based on impact. You can. Develop that skill ruthlessly.

Communication becomes more important, not less. When AI can generate code, your ability to explain complex technical decisions to non-technical people matters more than ever. Your skill at writing clear documentation. Your talent for asking the right questions before building. These human skills compound your AI-amplified technical abilities.

Problem identification might now be the most valuable skill. AI is brilliant at solving well-defined problems. But spotting that a problem exists in the first place? Understanding the root cause versus symptoms? Knowing which problems are worth solving? That’s still very much a human game.

Knowing how to use AI effectively is also a skill. Not everyone uses it the same way.

Some engineers treat it like advanced autocomplete.

Others use it as a thinking partner that helps them explore approaches, spot edge cases, and prototype rapidly.

The gap between these two approaches is significantly massive.

Critical thinking about AI outputs is essential. AI confidently generates code that looks right but has subtle bugs. Can you spot when it’s wrong? Can you evaluate whether its suggested approach is actually the best one for your context? Or do you just accept whatever it generates and ship it without understanding?

In this video, I’ll break down each skill that matters in the AI era. System thinking and architecture (how to design robust systems that scale). Product sense (how to identify what’s worth building). Communication (how to influence decisions and explain technical choices). Problem identification (how to spot valuable problems before anyone asks). And AI fluency (how to use AI as a force multiplier without becoming dependent on it).

I’ve built many projects on my GitHub over the years. Take a look for inspiration or jump in to contribute! 🔥

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

Subscribe now

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 contribution! And so much more to come on my LinkedIn as well! Don’t forget to follow and stay tuned!

Subscribe now

Look, AI tools are brilliant. They speed up development, help you write boilerplate faster, and can even suggest solutions you hadn’t thought of. But there’s a trap here that too many engineers are falling into, and it’s worth talking about.

From over-trusting outputs to losing technical depth, this video explains what you must stay vigilant about to keep providing real value as a software engineer.

Here’s the thing: when you rely too heavily on AI-generated code without understanding what it’s doing, you’re essentially becoming a copy-paste engineer. You lose the ability to debug properly when things break. You stop questioning whether the solution is actually the right one for your use case. You miss edge cases because you didn’t write the code yourself and didn’t think through the problem deeply enough.

And over time? Your technical depth erodes. You become dependent on tools that might give you plausible-looking code that’s actually inefficient, insecure, or just plain wrong.

Don’t get me wrong, AI tools are fantastic when used correctly. They’re brilliant for speeding up repetitive tasks, exploring different approaches, or handling the boring stuff. But you need to stay in control. You need to understand the code you’re shipping. You need to verify outputs, question suggestions, and keep your problem-solving skills active.

In this video, I’ll break down the specific risks you should watch out for and how to use AI tools as a force multiplier rather than a crutch. Because at the end of the day, the engineers who thrive aren’t the ones who blindly trust AI outputs. They’re the ones who use AI strategically whilst maintaining their technical judgement and depth.

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 as well! Don’t forget to follow and stay tuned! 🔥

Share

Look, here’s what actually happens: if you tell yourself “I’m not good at systems design” or “I’ll never understand this codebase,” guess what? You won’t. The Pygmalion effect is real. Your expectations shape your performance in ways that are honestly kind of wild when you think about it.

But flip that script? When you approach problems with curiosity instead of fear, when you believe you can figure it out even if it takes time, something shifts. You start seeing solutions instead of roadblocks. You experiment more. You ask better questions.

In this video, I break down how your internal dialogue directly impacts your code quality, problem-solving ability, and career growth. And more importantly, I’ll show you practical ways to rewire those limiting beliefs so you can tackle challenges with the confidence they deserve. Because the difference between a stuck engineer and a thriving one often isn’t skill. It’s mindset.

Share

You can get inspired by the open-source projects I’ve built over the past several years, available on my GitHub 🔥

And there are so much more to come on my LinkedIn. Don’t forget to follow so you won’t miss out!

You can get inspired by the open-source projects I’ve built over the past several years, available on my GitHub.

Look, we’ve all been there. You’re stuck on a bug for hours, grinding away at your desk, convinced that if you just push a little harder, the solution will click. But here’s the thing: your brain doesn’t work that way. Real breakthroughs happen when you step away, reset, and let your mind process in the background. In this video, I’ll show you why taking breaks isn’t lazy. It’s actually one of the smartest things you can do for your code quality and career longevity.

Share

Repetition slows developers down. As a software engineer or data scientist, templates help you cut out the busywork, reduce errors, and boost your coding/prompt speed. In this video, I’ll walk you through how to set up and use templates that streamline your daily workflow so you can focus on solving problems that really matter.

Subscribe now

🏆 Get inspired by open-source projects I’ve built over the past years on my GitHub. And I’ve also plenty more content coming soon on my LinkedIn!Don’t forget to follow and stay tuned! 👀

No fluff, no theory you’ll never use. Just practical strategies you can implement today to write better code, think more clearly, and work more effectively in an industry that’s evolving faster than ever. Whether you’re junior or senior, these principles will help you stay ahead.

You can get inspired by the open-source projects I’ve built over the past several years, available on my GitHub. And there are so much more to come on my LinkedIn!

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

You will learn every practical step to organise your routines, boost focus, and make lasting improvements without relying on sheer willpower.

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 content coming your way on my LinkedIn!

The problem is that most developers don’t think about folder organization until they have 50+ repositories in random locations. Then, every time you need to jump into a project, you’re playing the guessing game of where you put it.

What if we could have a simple, consistent structure that makes navigating between projects effortless?

Here’s the thing: your folder structure should mirror how you actually work. The most common convention is to keep all repositories under ~/Code or ~/Projects. Personally, my favorite one is ~/Code (and I’d recommend you stick with it too). Then group by organization or client first, then by project. Something like ~/Code/company-name/project-name or ~/Code/client-name/repo-name.

Key principles:

• One main development folder for everything (~/Code is the way to go ✅)

• Clear, consistent naming conventions

• Group by organization/client, then by project

• Avoid nesting too deep - two or three levels max

The beauty of this approach? When you need to quickly jump into a project, you know the pattern, you follow it, and you’re in. Simple as that.

No more time wasted hunting for repositories. No more confusion about which version you’re working on. Just a clean, organized workspace that lets you focus on what actually matters: writing code 🚀

I’ve developed numerous projects on my GitHub over the years. Feel free to browse them for inspiration or to contribute!

Share

In this video, I share the proven strategies and real-world habits that senior engineers actually use to tackle massive codebases without burning out. You’ll learn how to break down complexity, maintain quality under pressure, and develop the mental models that make even huge projects feel manageable.

Whether you’re joining a large project or watching your own codebase grow, these practical techniques will help you work smarter.

You can get inspired by the open-source projects I’ve built over the past several years, available on my GitHub. And there are so much more to come on my LinkedIn!

You can get inspired by the open-source projects I’ve built over the past several years, available on my GitHub. And there are so much more to come on my LinkedIn!

AI now performs almost as well as a disciplined, pragmatic programmer when it comes to writing code.

Although knowing how to write maintainable and scalable code remains valuable, it is not where you should spend most of your time. What matters most is your ability to create efficient systems that rely heavily on AI agents and leverage them effectively to solve complex problems faster at scale.

While you focus on solving the major problems that truly matter, your role is to design and build proper solutions that enhance productivity and address the company’s most pressing challenges. The goal is to leverage AI to overcome these problems, superpower what you can do, and continuously challenge yourself with new problems that have not yet been solved.

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!

The New Definition of “Great Engineer” in the AI Era.

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!