DEV Community: Muhammad Bilal Khalid

[Boost]

Muhammad Bilal Khalid — Tue, 04 Nov 2025 11:14:57 +0000

Muhammad Bilal Khalid

Nov 3 '25

Mastering the ‘O’ in SOLID: Applying the Open/Closed Principle in Real-World Code

#programming #architecture #dotnet #computerscience

Comments

4 min read

Mastering the ‘O’ in SOLID: Applying the Open/Closed Principle in Real-World Code

Muhammad Bilal Khalid — Mon, 03 Nov 2025 07:45:00 +0000

Adding features shouldn’t feel like defusing a bomb. Here’s how the Open/Closed Principle (OCP) helps you extend your code without changing what already works.

You’ve probably done this before:

You needed to add a small feature so you end up opening a class and writing yet another if statement. A couple of weeks later, you had to add another one. And then another. And before you know it, the code that once felt clean turns into a mess of conditions.

That’s the kind of slow creep the Open/Closed Principle is meant to prevent.

(Side note: we explored the Single Responsibility Principle in the previous part of this series, worth checking out if you missed it!)

What is the Open/Closed Principle❓

The Open/Closed Principle (OCP) is one of the five core principles of SOLID design. It states:

Software should be open for extension but closed for modification.

In simpler terms: you should be able to add new behavior without changing the existing code.

That doesn’t mean your code never changes. It means the parts that already work shouldn’t have to be touched every time something new is added.

Let's exapand on this a bit. Why we need to have our code open for extension but close for modification?

🤔 Why Apply the Open/Closed Principle?

Because code that changes too often becomes risky, not just technically, but mentally too. You start avoiding updates, afraid of breaking something that already works. I’ve experienced this first-hand!

Even a small if in the wrong place can create bugs or unexpected behavior. That fear of touching code slows everything down.

OCP helps you avoid that by encouraging you to add new behavior without touching old logic. It keeps the stable parts of your code safe and untouched.

This leads to cleaner structure, easier testing, and a codebase that grows without becoming fragile.

Let's understand this with the help of a quick example.

📉 What Happens When You Don’t Apply OCP?

Let’s say you’re building a discount engine for an e-commerce platform. Initially, you just support a flat discount:

    public class DiscountCalculator  
    {  
        public decimal ApplyDiscount(string customerType, decimal amount)  
        {  
            if (customerType == "Regular")  
            {  
                return amount * 0.95m; // 5% off  
            }  
            return amount;  
        }  
    }

Now marketing wants loyalty discounts. Then seasonal promos. Then discounts based on cart value, customer tier, or coupon codes. You start stacking conditions:

    if (customerType == "Gold")  
    {  
        // 15% off  
    }  
    else if (amount > 1000)  
    {  
        // 10% off  
    }  
    else if (couponCode == "SUMMER2025")  
    {  
        // 20% off  
    }

Before you know it, logic starts overlapping. You need flags to apply or skip certain discounts. And the order of these conditions becomes critical. One bug, and you end up giving 3 discounts instead of 1.

All you wanted was a clean way to apply business rules. Instead, you built a tightly-coupled maze.

Let's now solve this maze by the power of Open Closed Principle!

🛠️ How to Apply the Open Closed Principle?

You make your code extensible by introducing abstractions.

Instead of hardcoding every rule into the DiscountCalculator with if statements, we shift the responsibility of applying individual discounts to their own dedicated classes.

Each rule implements a shared interface, IDiscountRule, which defines when the rule applies and how it calculates the discount.

    public interface IDiscountRule  
    {  
        bool IsMatch(Customer customer, Cart cart);  
        decimal Apply(decimal amount);  
    }

This means each rule is completely self-contained. It knows when it should run and how to apply its logic. The calculator doesn’t care about what the rules are, it just loops through them and applies what matches.

You want to give loyalty discount? Simple, add a new implementation for the IDiscountRule interface.

    public class LoyaltyDiscount : IDiscountRule  
    {  
        public bool IsMatch(Customer customer, Cart cart) => customer.Type == "Gold";  
        public decimal Apply(decimal amount) => amount * 0.85m;  
    }

A discount for cart with high value? Add another implementation.

    public class HighValueCartDiscount : IDiscountRule  
    {  
        public bool IsMatch(Customer customer, Cart cart) => cart.Total > 1000;  
        public decimal Apply(decimal amount) => amount * 0.9m;  
    }

Just like that you can introduce as many discount rules as you'd like. And the great thing is no one implementation affects another one. They are all separate.

The DiscountCalculator now becomes a simple orchestrator. It doesn’t contain any discount rules itself. It just loops through all available rules and applies them if they match.

    public class DiscountCalculator  
    {  
        private readonly IEnumerable<IDiscountRule> _rules;  

        public DiscountCalculator(IEnumerable<IDiscountRule> rules)  
        {  
            _rules = rules;  
        }  

        public decimal ApplyDiscount(Customer customer, Cart cart)  
        {  
            var amount = cart.Total;  
            foreach (var rule in _rules)  
            {  
                if (rule.IsMatch(customer, cart))  
                {  
                    amount = rule.Apply(amount);  
                }  
            }  
            return amount;  
        }  
    }

Want to support a new type of discount next month? Just create a new class that implements IDiscountRule, register it with your dependency injection container, and you’re done. You never touch the DiscountCalculator class again.

⏩ When Is It Okay to Skip OCP?

Now here a very important thing to understand. Not every situation calls for this level of abstraction.

If the code is unlikely to change or grow, applying OCP too early might just create unnecessary layers. Why solve a problem you don’t have yet? Keep things simple when they genuinely are.

But when your code deals with rules, workflows, or business logic that could evolve, that’s when OCP shines. It helps you balance simplicity today with flexibility tomorrow.

Remember, OCP is just one tool in your design toolbox. It’s not a silver bullet. Use it when it makes sense . Not every problem needs it, and sometimes the problem doesn’t even exist yet.

Whenever in doubt follow this 3 Questions Test I always ask myself before adding any layer of abstraction. It helps me avoid over-engineering solutions and might help you too!

💭 What about you ? where have you seen the Open/Closed Principle make the biggest impact in your own codebase? Or maybe where you wish it had been applied?

Next up: Liskov Substitution Principle when polymorphism quietly breaks your code.

Hi, I’m Bilal 👋, a .NET developer sharing what I learn about building software, thinking in systems, and writing clean, practical code.

If you’re exploring similar ideas, let’s connect and learn together.

Single Responsibility Principle sounds very simple but most devs get it wrong. SRP was never about a class doing one thing only. It's about fulfilling a single responsibility. But what does a single responsibility actually stand for?

Muhammad Bilal Khalid — Sun, 02 Nov 2025 06:35:52 +0000

Stop Adding Unnecessary Abstractions: My 3-Question Kill-Switch for Over-Engineering

Muhammad Bilal Khalid ・ Oct 27

#softwaredevelopment #softwareengineering #dotnet #programming

Demystifying the Single Responsibility Principle: It’s Not What You Think

Muhammad Bilal Khalid — Wed, 29 Oct 2025 19:13:44 +0000

“Clean code is not overengineering. It’s making sure small changes actually feel small when the time comes.” — Me, after wrestling with my own code

Hi! Are you one of those people who just can’t stand SOLID principles?

Don't worry, I totally get you! They can be really confusing at first.

But once you grasp the main idea behind them, you’ll start to see where they fit in your code and spot the bottlenecks that appear when they’re ignored.

In this SOLID series, I’ll try to explain each principle in a simple, easy-to-understand way. No heavy jargon, no overcomplication, just practical stuff.

So, let’s kick things off with the first one: the Single Responsibility Principle (SRP).

The key to mastering SRP is understanding what “single responsibility” really means.

What counts as a single responsibility, and how you can tell if a class or component is handling more than one.

Let's have a look!

What Exactly is Meant by “Single Responsibility”?

A single responsibility simply means a single reason to change. In other words:

A class, function, or module should only have one reason to be modified.

Here’s what that really means in practice:

🧩 A “responsibility” is a role or purpose your code serves.

For example, fetching data from a database is one responsibility. Formatting that data for display is another. Sending it in an email is yet another.

🔄 If a change in one part of the system forces you to update that class/function, it means the class/function is responsible for that area of change.

So if you have a function that needs changes whenever the business logic changes and also when the report format changes, it has at least two responsibilities.

✂️ Single Responsibilities Principle makes sure that each reason to change should belong to a different class or function.

That way, when a requirement changes, you only touch one small, focused piece of code, not everything at once.

Let's understand this with the help of an example.

Building a Report Generator

Imagine you just joined a logistics company as a .NET developer. Your first task is to Build a simple shipment report generator.

Let’s say you come up with this (very realistic) piece of code:

public void GenerateReport()
{
    // 1. Fetch data
    var shipments = new List<Shipment> 
    { 
        new Shipment { Id = 1, Description = "Cargo A" },
        new Shipment { Id = 2, Description = "Cargo B" }
    };

    // 2. Format as text
    var builder = new StringBuilder();
    foreach (var shipment in shipments)
    {
        builder.AppendLine($"ID: {shipment.Id}, Description: {shipment.Description}");
    }
    var report = builder.ToString();

    // 3. Save to disk
    var filename = "shipment_report.txt";
    File.WriteAllText(filename, report);

    // 4. Send email
    Console.WriteLine("Sending email to manager...");
    // (Pretend there’s real SMTP logic here)
}

Looks good, right? Everything’s working. It fetches data, formats it, saves a file, and even emails it.

But here's the thing.

This version technically has one function GenerateReport() but it’s still doing four different things:

Fetching data
Formatting data
Writing to disk
Sending an email

So even though it’s written as one function, it’s carrying multiple responsibilities.

That’s the key:

SRP isn’t about how many functions or classes you have. It’s about how many reasons to change exist in one place.

If the email logic changes, you’ll have to edit GenerateReport(). If the file output format changes, same function again. If the report data changes, again.

Each of those is a different reason to change (multiple responsibilities).

So let's fix this by following Single Responsibility Principle.

Rebuilding Report Generator following SRP

Let's start by listing down all the reasons to change aka responsibilities.

If the way we fetch data changes, that’s one reason.
If the way we format reports changes, second reason.
If we save somewhere else, third.
If we want to notify someone differently, fourth.

So, let’s split it up.

Step 1: Define the Responsibilities

So far we have identified four responsibilities. Let's create dedicated functions to serve each responsibility.

We'll have:

Data Fetcher → Responsible for fetching shipment data from database.
Report Formatter → Responsible for formatting the shipment report to the desired format.
File Saver → Responsible for saving the file to server, cloud storage, etc.
Email Sender → Responsible for sending the emails.

Step 2: Write Dedicated Functions for each Responsibility

Let's write functions for each of the defined responsibilities.

Data Fetcher

FetchShipmentsFromDb()
{
    // Simulated DB call
    return new List<Shipment> 
    { 
        new Shipment { Id = 1, Description = "Cargo A" },
        new Shipment { Id = 2, Description = "Cargo B" }
    };
}

Report Formatter

FormatAsTextReport(List<Shipment> shipments)
{
    var builder = new StringBuilder();
    foreach (var shipment in shipments)
    {
        builder.AppendLine($"ID: {shipment.Id}, Description: {shipment.Description}");
    }
    return builder.ToString();
}

File Saver

private void SaveToFile(string content, string filename)
{
    File.WriteAllText(filename, content);
}

Email Sender

private void SendEmail(string content)
{
    Console.WriteLine("Sending email to manager...");
    // Imagine SMTP logic here
}

Step 3: Bring it all together

Now let's rewrite the ReportGenerator(), this time, delegating the responsibilities to their respective functions.

public void GenerateReport()
{
    // 1. Fetch data from the database
    var shipments = FetchShipmentsFromDb();

    // 2. Convert to report format
    var report = FormatAsTextReport(shipments);

    // 3. Save report to disk
    SaveToFile(report, "shipment_report.txt");

    // 4. Send email to manager
    SendEmail(report);
}

That’s it! Our ReportGenerator is now only responsible for assembling the report, while all the individual tasks are delegated to their respective functions.

Want to format the report in Excel? Just update the ReportFormatter.
Need to save the file to the cloud instead of the local server? Modify the FileSaver.

Each function now has a single responsibility.

A change in report formatting doesn’t affect the File Saver, and a change in the Email Sender doesn’t require updates anywhere else.

And with that, you’ve successfully achieved the Single Responsibility Principle. 👏

Now, I get that it’s harder to see the consequences of not following SRP in a small example like this.

But in real-world applications, things rarely exist in isolation. Systems are made up of multiple components and modules that constantly interact with each other.

Having well-defined responsibilities, and making sure each component follows SRP, goes a long way toward keeping your codebase clean and maintainable.

Otherwise, it doesn’t take long before everything becomes intertwined and your code turns into spaghetti.🍝

I hope this helped you grasp the concept without feeling overwhelmed.

💭 What’s your take on SRP? Do you see it as essential, or do you think it’s just over-engineering? I’d love to hear your thoughts.

Next Up: The “O” in SOLID — Open/Closed Principle. Where we’ll dive into how adding a new feature shouldn’t mean rewriting old code (but it often does).

Hi, I’m Bilal 👋, a .NET developer sharing what I learn about building software, thinking in systems, and writing clean, practical code.

If you’re exploring similar ideas, let’s connect and learn together.

Stop Adding Unnecessary Abstractions: My 3-Question Kill-Switch for Over-Engineering

Muhammad Bilal Khalid — Mon, 27 Oct 2025 17:26:41 +0000

Here’s something nobody tells you when you’re learning to code: more projects fail from overengineering than from bad code.

I learned this the hard way. Three years into my career, I was that developer who obsessed over abstractions, built elaborate design patterns, and could justify every architectural decision with textbook precision. I felt good about my work.

Then I started noticing the pattern. Features that should’ve taken days were taking weeks. All that “future-proofing” I’d built? Most of those future scenarios never happened.

I was shipping slower, building for problems that didn’t exist, while real user needs waited.

That’s when I realized: knowing when NOT to build something is just as critical as knowing how to build it well.

Why Smart Developers Overengineer

We do it because we care. We want scalable systems, clean architecture, code that won’t need rewrites six months from now. We’re following best practices, doing things “the right way.”

But here’s the uncomfortable truth I’ve discovered: most of the future we design for never actually arrives.

And here’s the thing: it doesn’t feel wrong while you’re doing it. You’re learning, applying solid principles, building professional-grade systems. Everyone’s happy.

But there’s a hidden cost accumulating beneath the surface.

The Real Cost Nobody Talks About

The problem with overengineering isn’t dramatic failure. It’s quiet inefficiency that compounds over time.

You spend more time maintaining abstractions than solving actual problems. That “flexible” system becomes rigid because changing it means updating five interconnected pieces.

You’re shipping slower than you need to. Every extra abstraction is another decision point, another layer to think through. That feature that could’ve taken two days now takes a week because you’re “doing it right.”

Technical debt accumulates in disguise. Those flexible abstractions? They become rigid constraints. You thought you were preventing technical debt, but you were creating a different kind.

Performance takes hidden hits. All those layers, all that flexibility, it’s not free. Your app is carrying weight it doesn’t need, running code for scenarios that will never happen.

And here’s the kicker: Most of the flexibility you build for? Those future use cases you’re preparing for? They never actually arrive.

Requirements change. The product pivots. That “definitely coming” feature gets canceled. You spent time and added complexity for a future that didn’t happen.

Meanwhile, you could’ve shipped faster, simpler, and been ready to adapt when you actually knew what was needed.

The Mindset Shift That Changed Everything

Good code solves today’s problems and leaves room to evolve tomorrow. That’s it.

It doesn’t try to predict every scenario. It doesn’t build for imaginary scale. It doesn’t create abstractions just because they’re “proper.”

Simplicity isn’t laziness, it’s discipline. Every line of code is a liability until it proves its value. Every abstraction is overhead until it earns its keep.

The best engineers I’ve worked with? They don’t build perfect systems. They build sensible ones. They know complexity is easy, simplicity takes thought.

My “Now / Later / Never” Filter

Over the years, I’ve developed a three-question sanity check I run before adding any new abstraction, pattern, or architectural layer. It’s saved me countless hours and kept my codebases actually maintainable.

🟢 Question 1: Does this solve a problem we have right now?

If yes — build it. If no — stop.

This is your primary filter. Be ruthlessly honest here.

Ask yourself:

What actually breaks if I don’t add this today?
Is anyone blocked by the current simple solution?
Am I solving a real pain point or an imaginary one?

If the answer is “nothing breaks”, it’s not a “now” problem. And “now” problems are the only ones worth solving today.

🟡 Question 2: If not now, will it definitely be needed later?

Sometimes you actually know what’s coming. A confirmed roadmap item. A pattern you’ve seen emerge three times already. A specific requirement from stakeholders with a hard deadline.

Notice the word “definitely.” Not “might.” Not “could.” Definitely.

The test:

Can you point to a concrete, scheduled future use case?
Has this exact need appeared multiple times already?
Do you have actual data suggesting this will matter?

If you’re building based on “what if” or “just in case”, you’re guessing. And engineering based on guesses is expensive.

Here’s what I’ve learned: You can’t future-proof what you don’t understand yet. The future becomes clear after you’ve lived it once. That’s when you know exactly what abstraction you need.

Until then? You’re probably building the wrong thing anyway.

🔴 Question 3: If neither, why am I really adding it?

This is your stop sign.

Be honest with yourself. If it’s not solving a current problem and not clearly needed soon, why are you building it?

Usually, it’s one of these:

Habit: “This is how we’re supposed to architect things”
Fear: “What if we need to change this later?”
Resume-driven development: “This pattern will look great in my portfolio”
Intellectual curiosity: “This would be fun to build”
All of these are valid feelings. None of them justify adding complexity to production code.

If your abstraction exists mainly to look smart or feel sophisticated, it’s already technical debt.

Delete it. Ship simpler. You’ll move faster, your team will thank you, and you’ll actually sleep better.

The Real Skill: Knowing When to Stop

After a few years in this industry, I’ve realized the most valuable developers aren’t the ones who can build the most complex systems. They’re the ones who know when not to.

They ship working code instead of perfect architecture. They write clear solutions instead of clever ones. They build for today’s problems while staying ready to evolve.

That’s not being lazy or short-sighted. That’s being efficient. That’s being practical.

You can always add complexity later when you actually need it. Removing unnecessary complexity costs many times more.

Your Challenge

Next time you’re about to add a new layer, abstraction, or pattern, pause. Run it through the filter:

Now? Build it.
Later? Prepare for it specifically.
Never? Delete it.

You’ll be amazed how much faster you move when you stop carrying weight you don’t need.

What’s your experience with overengineering? I’d love to hear your stories, both the times you got burned by too much architecture and the times you successfully kept things simple. Drop a comment below! 👇

Hi, I’m Bilal, a .NET developer sharing what I learn about building software, thinking in systems, and writing clean, practical code.

If you’re exploring similar ideas, let’s connect and learn together.

Understanding Clean Architecture: A Beginner's Guide

Muhammad Bilal Khalid — Fri, 26 Jan 2024 13:17:12 +0000

Clean Architecture is one of the most popular software architectures to help organize your source code.

Here is everything you need to get started with Clean Architecture!

Proposed by Robert C Martin, aka Uncle Bob, the Clean Architecture offers some significant advantages:

Independent of Frameworks: The architecture does not require some external libraries to work. It can stand on its own.
Testability: The business logic is independent of the web UI, Databases, and external sources so that it can be tested independently.
Separation of Concerns: Web UI, Databases, and Business logic are all separated into different layers, making the system modular and less interdependent.
High Cohesion and Low Coupling: All the layers specialize in their own domain and are not coupled to each other. Thus, any change in UI or databases will not affect the business logic and so on.

So, what is it that makes this architecture so powerful?

The answer to this question is the Dependency Inversion Principle.

The Dependency Inversion Principle is the main engine or the driving force behind any Layered Architecture.

Dependency Inversion Principle

The Dependency Inversion Principle basically states that:

High-level modules should not depend on low-level implementation details. Instead, they should depend on abstractions that are implemented by the low-level modules. Thus, inverting the direction of the dependencies.

Consider a traditional Asp.Net Webforms application. In such applications, business logic is strongly tied to the User Interface and Database.

Thus, any changes in the UI or database logic would force changes in the business logic as well.

However, with dependency inversion, we can separate the business logic from the user interface and database by separating them into individual layers.

These layers, instead of depending on each other, depend on abstractions. Thus, any change in one layer does not affect any other layer.

So far, there have been multiple implementations of Layered Architecture, including Hexagonal, Onion, Clean Architecture, and more.

Let’s dive deep into the Clean Architecture now.

Clean Architecture

If you google the term Clean Architecture, you will see a diagram somewhat like this one.

The diagram consists of concentric circles representing the different layers of the system.

As you get closer to the center, you will find high-level abstract details like the Domain Entities.

Moving outwards, you will encounter low-level implementation details like services, databases, etc.

Let’s have a look at what is inside each of these layers.

Domain Layer

At the heart of the system is the Domain Layer. The domain layer consists of the core business entities.

All the other layers in the system depend on the Domain layer and are there to support the Domain Layer.

Domain Layer itself does not depend on any other Layer.

Application Layer

Neighboring the Domain Layer is the Application Layer.

The Application layer is where all the magic happens. This is where your business logic resides.

Based on the business rules and regulations, this layer controls the flow of data to and from your business entities.

Generally, this layer consists of all your services, commands, queries, exceptions, logs, etc.

Infrastructure Layer

Next, we have the Infrastructure Layer. This is where all your external services and database logic are located.

All your external services, like email service, storage solutions, message queues, third-party API calls, etc., are handled by this layer.

Besides, it is also a common practice to separate database logic into its own Persistence Layer. This is where your DbContext and migrations, etc., will go.

Presentation Layer

Lastly, we have the presentation layer. This is the gateway or the entry point to your application.

This layer is responsible for presenting data to the end user in an easily understandable manner.

You will probably implement this layer as a Web or API project consisting of controllers defining the Action Methods or API endpoints.

So, these are the four layers in the Clean Architecture. But, now the question is:

Will there always be 4 layers?

The answer to that question is “No”.

You can always add more layers according to your requirements. The point of the layers is to organize and manage the source code.

For example, you may add a Common Layer at the center for storing static data like enums, magic strings, etc.

Or add a Storage Layer at the outermost to manage your storage in case you are using multiple storage solutions.

In short, there is no restriction on the number of layers you can add.

However, there is one principle that you must always follow. That is the Rule of Dependencies.

Rule of Dependencies

The rule of dependencies gives clear instructions about the direction of dependencies. It states:

Source code dependencies can only point from outside towards inside of the circle.

That means that no inner layer can know anything about the outer layers. Anything defined in an outer layer should not be visible to any inner layer.

So, how do the layers interact then?

It's simple. An inner layer defines an abstraction or an interface. The implementation of this interface is then provided by an outer layer.

That way, the inner layer doesn’t have to know about the outer layer and thus becomes independent of the implementation details.

Sounds good. But there is one more question remaining.

How do we transfer data between the layers?

Remember, we can not violate the Rule of Dependencies.

This implies we cannot directly pass data to and from layers using our domain entities.

Doing so would require the inner layer (Domain Layer) to know about the outer layers, violating the Rule of Dependencies.

So, instead of domain entities, we can create special Data Transfer Objects called DTOs to transfer the data between different layers.

DTOs must be simple data structures or objects containing the data required for an inner layer. You can also use immutable types like records for DTOs.

In the end, remember that software architectures are opinionated and very subjective. They are not a set of hard rules that must be followed.

Therefore, experiment with different architectures and feel free to make modifications to best suit your application.

After all, the goal of any architecture is to make clean, maintainable, testable, and scalable applications.

I hope you enjoyed this article. Let me know how you would structure your project for Clean Architecture. Feel free to share any insights!

PS: Check out my implementation of the Clean Architecture on my Github repo.

For now, it’s just the basic structure. Over the next few weeks, I will add different services and features to this project, like logging, dependency Injection, Authentication, CQRS, Emails, and more.

My goal is to make it into a starter template that is configured with all the necessary features that are a must in any modern application.

Feel free to follow along and share your suggestions.

Why I Switched from Engineering to Computer Science

Muhammad Bilal Khalid — Mon, 04 Apr 2022 19:28:13 +0000

Let me begin with a quick overview.

So basically, I completed my bachelor's in Electrical Engineering in 2018. Back when I got admission in Electrical Engineering, it was of the most in-demand fields. There were a lot of opportunities, and the field, in general, promised a great career.

However, the demand started to go down gradually while I was still studying. By the time I graduated, there were only a handful of opportunities open for freshers.

Anyhow, I decided to give it some time and kept preparing for any opportunities that may come. However, the demand never went up, and not enough opportunities were created.

So, long story short. After giving my best for nearly 3 years, I realized it's not going to work. So, after re-evaluating my options, I finally decided to switch to Computer Science. And here I am today, sharing my journey with you!

So, let's address the first question first. Why did I leave Engineering?

Why did I leave Engineering?

During my 3 years of job hunt, I observed a number of things that eventually brought me to my decision. I'll break it down into three main reasons.

Reason# 1: Not Enough Opportunities

I was unable to land a job for almost 3 years. There were simply not enough opportunities for freshers.

Even among the few available opportunities, most were internal hirings. So, they never even got to me. On this point, I agree my networking wasn't that strong either. But still, the opportunities were scarce.

On top of that, the influx of graduating engineers further saturated the job market, which made the competition really tough.

Reason# 2: Uncertainty in the Job Market

The job market for Electrical Engineering had been quite uncertain. Those of us who did get a job had no certainty about their future. And in case one gets laid off, hunting for a job again will be a pain.

Besides uncertainty, salaries were also lower in comparison to other fields with equivalent qualifications. Because the competition was very high, people were willing to work at lower pay. After all, it is still better than being jobless.

Reason# 3: COVID-19!

Since the breakout of the pandemic, there was a complete lockdown in place. The industrial sector remained close for a significant share of time. This situation resulted in a huge number of layoffs.

For a field already facing saturation, this was a big blow. And with it, my hopes of making a career in Electrical Engineering went low.

PS: It is important to note that the job market varies significantly from region to region. Everything I have shared is within my radius. Your experiences in another part of the world might be completely different.

So, this was my journey of Electrical Engineering which came to an end half a year ago. Let's talk about the future now. So, why Computer Science?

Why I Decided to Go for Computer Science

Choosing Computer Science was a pretty straightforward decision for me. I'll break it down into three reasons.

Reason# 1: Familiarity

Since Electrical Engineering is closely related to CS, I was already familiar with the programming concepts. I had studied the core concepts of programming and data structures during my course of study.

Moreover, I did a number of projects that involved the programming of microcontrollers and Arduino boards. So, I already had some experience with programming.

Reason# 2: Better Opportunities.

Computer Science, in the foreseeable future, is only expected to grow. There are already a huge number of opportunities in the field, and the demand for IT professionals is growing continually.

Besides, you get so many options within the field. You can go for Software Development, Cloud Computing, Data Science, AI, Blockchain, etc. And the best thing is all are in high demand.

Reason# 3: Sustainability and Better Career Growth

If there is one industry that continued to grow even during the pandemic, it is definitely the IT industry.

Moreover, the demand for IT professionals is high. And in case you leave a job or get laid off, you can easily find another job, of course, with a bit of effort.

On top of that, IT professionals are getting competitive salaries and the field, in general, offers much better career growth as well.

To sum up, it made perfect sense for me to go with something I am already familiar with, that has decent opportunities and offers better growth. So, that's what I did!

Going Forward . . .

I actually decided to switch my career back in mid-2021. It took me some time to figure out my way forward. So, after some evaluation, here are the goals I've set for myself.

Goal# 1: Complete my Master's in Computer Science

So, currently, I am enrolled in a Master's program in Computer Science at FAST. However, since I did not come from a CS background, I had to take deficiency courses to make up for it.

Hopefully, I will clear the deficiency courses by June 2022. And after the summer break, My actual Master's degree will begin in Sep 2022.

It's a two-year program, so if everything goes well, I will graduate in mid-2024, InShaaAllah.

Goal# 2: Become a Self-Taught Developer

Besides the MS degree, I intend to learn web development using online resources. My aim is to go full-stack. However, for now, I am only focusing on front-end development.

Once I am well versed in front-end development, I plan to go for an entry-level web developer role. After that, I can continue to learn backend development alongside.

I haven't decided on a full-stack yet. Both MERN stack and .NET are in high demand in my region. So, I'll go with one of these, but that's a decision I will wait on for now.

Online Resources for Learning Web Development

If you are looking for online resources, do check out the Odin Project. It's a free online resource. I like it because the content is well structured and focuses more on the practical aspect.

Besides the Odin Project, we have other great resources like freecodecamp, Codecademy, Udemy, etc. So feel free to check them out as well. Find the one that best suits your learning style.

Please note that they are all great resources, and you can't go wrong with any of them. What's important is to just pick one and then stick with it. You'll make more progress that way. Wish you all the best!

What's next?

Moving on, I have decided to document my web development journey. So, I will be writing about all the things that I learn along the way.

So far, I have covered the HTML and CSS foundations section of the Odin Project. I will be writing shortly about that. So, feel free to follow along. After all, it's fun learning together!

In the end, I must say I have heard great things about the hashnode community. So, my expectations are high. Please feel free to share your valuable suggestions in the comments section. Cheers!