DEV Community: Habeeb Abdullahi

Beyond the Syntax: Why Growth Matters More Than Tools

Habeeb Abdullahi — Sun, 12 Jul 2026 08:50:57 +0000

Every few months, a new technology dominates the conversation.

Yesterday it was Docker.

Then Kubernetes.

Today, it's AI.

Tomorrow, it will be something else.

The discussion usually sounds like this:

"Do I need to learn this to stay relevant?"

I think that's the wrong question.

The technology itself isn't what keeps engineers relevant.

Their ability to grow does.

The Misconception: Tools Make Great Engineers

It's easy to believe that learning every new framework, platform, or tool automatically makes you a better software engineer.

It doesn't.

Docker didn't create great engineers.

AWS didn't create great engineers.

Kubernetes didn't create great engineers.

AI won't either.

They're all tools.

Powerful tools.

But tools nonetheless.

The engineers who built these technologies started with the same computer science and engineering fundamentals every developer learns.

The difference wasn't access to better tools.

It was years of continuous learning, solving increasingly difficult problems, and building real systems.

Tools are the result of engineering.

They are not a substitute for it.

School Gives You the Foundation

One misconception I often hear is that universities should teach everything you'll use in industry.

They can't.

And they were never meant to.

Formal education introduces the fundamentals:

Programming
Data Structures and Algorithms
Operating Systems
Computer Networks
Databases
Software Engineering

Those principles don't become obsolete every year.

They're the foundation that allows engineers to understand new technologies much faster.

No university can realistically teach every cloud platform, framework, container technology, or AI model.

By the time a curriculum is updated, the industry has already evolved.

School gives you the fundamentals.

Growth is your responsibility.

Growth Is What Keeps Engineers Relevant

The engineers who remain relevant aren't necessarily the ones who know the most tools.

They're the ones who never stop learning.

Growth comes in many forms:

Building personal projects.
Participating in hackathons.
Contributing to open source.
Reading technical books.
Learning from experienced engineers.
Working on real-world systems.
Making mistakes and learning from them.

Every project teaches something.

Every challenge exposes another gap in your knowledge.

Every solved problem compounds your experience.

That's how engineering maturity develops.

AI Doesn't Replace Growth

AI has changed how we build software.

It hasn't changed how engineers grow.

AI can:

Explain concepts.
Generate boilerplate.
Review code.
Accelerate implementation.

What it can't do is replace curiosity.

It can't replace engineering judgment.

It can't replace the experience gained from solving real problems.

AI is a powerful accelerator.

But acceleration without direction only gets you lost faster.

The developers who will thrive in the AI era won't be those who rely on AI the most.

They'll be those who understand enough engineering to use AI effectively.

Principles Over Popularity

Technology trends will always change.

The principles underneath them rarely do.

Yesterday it was jQuery.

Then Angular.

Then React.

Today it's AI.

Tomorrow, it will be something else.

Engineers who chase every trend without understanding the fundamentals constantly start over.

Engineers who build strong principles simply adapt.

Learning the next tool becomes easier because they're standing on a stronger foundation.

Final Thoughts

Staying relevant isn't about predicting the next technology.

It's about becoming the kind of engineer who can learn whatever comes next.

That's why I no longer measure growth by the number of tools I know.

I measure it by my ability to understand new ideas, solve harder problems, and adapt when the industry changes.

Because technology will always evolve.

Great engineers evolve with it.

What has contributed the most to your growth as a software engineer?

Was it school, work experience, side projects, hackathons, open source, or something else?

Beyond the Syntax: Why the "Web Dev Is Dead" Debate Misses the Point

Habeeb Abdullahi — Sun, 28 Jun 2026 02:56:10 +0000

Every few months, the same debate resurfaces:

"Is web development still worth learning?"

Recently, I came across another discussion asking the same question. The consensus was that AI has changed the industry and that developers now need to combine coding with problem-solving, security, and business understanding.

I agree with that conclusion.

What I don't agree with is one underlying assumption.

The conversation often implies that web development used to be "just writing code" and that AI somehow changed that.

It didn't.

The Misconception: Web Development Was Never "Just Coding"

Long before LLMs and AI coding assistants existed, web development was never about simply writing lines of code.

Building production-ready software has always required much more than knowing a programming language.

It has always demanded:

Systems Architecture: Designing scalable, maintainable, and loosely coupled systems.
Data Integrity: Managing state and ensuring predictable application behavior.
Problem Solving: Translating business requirements into reliable software.
Trade-off Analysis: Understanding that every engineering decision comes with benefits and costs.

These have always been the skills that separate someone who writes code from someone who engineers software.

AI didn't invent that distinction.

It simply made it more obvious.

AI Is a Productivity Multiplier, Not a Substitute

I don't see AI as a threat to software engineering.

I see it as leverage.

AI handles boilerplate.

It generates repetitive code.

It explains unfamiliar APIs.

It speeds up implementation.

That gives engineers more time to focus on the things that actually matter:

System design.
Architecture.
Business logic.
Security.
Performance.
User experience.

The real conversation isn't whether AI will replace developers.

It's how developers can leverage AI to become more productive while continuing to make the engineering decisions AI cannot.

Why Fundamentals Matter More Than Ever

Ironically, AI makes strong engineering fundamentals even more important.

Without them, it's incredibly easy to generate a large amount of incorrect or poorly designed code.

You can absolutely build a bad system with AI.

In fact, you can build it much faster.

AI is an amplifier.

If it is given a flawed architectural idea, it will happily generate messy, tightly coupled, and unmaintainable code at five times the speed.

Without understanding software fundamentals, many developers won't even realize they're heading toward a structural dead end until the application becomes difficult to maintain, scale, or debug.

AI doesn't replace engineering judgment.

It magnifies it.

Principles Over Syntax

The question has never been whether web development is worth learning.

The real question is how you're learning it.

If your focus is only on memorizing syntax, AI will probably outperform you.

But if your focus is understanding software architecture, system design, trade-offs, business logic, and engineering principles, AI becomes one of the most powerful tools you'll ever use.

Languages will evolve.

Frameworks will change.

AI will continue to improve.

But thoughtful engineering remains timeless.

AI can generate code.

It can suggest implementations.

It can accelerate development.

But it still can't decide what should be built, why it should be built that way, or how the system should evolve over the next five years.

That's still engineering.

And that's why the question was never whether web development is worth learning.

The real question is whether you're learning syntax or learning engineering.

What are your thoughts? Has AI changed what it means to be a software engineer, or has it simply amplified the skills that have always mattered?

Beyond the Syntax: Why Software Engineering Is Not Just Writing Code

Habeeb Abdullahi — Fri, 26 Jun 2026 22:41:42 +0000

We've all seen the archetypes: the developer who boasts about knowing seven different programming languages, the interview prep champion who can solve a LeetCode Hard in their sleep, and the coding bootcamp graduate eager to write thousands of lines of code.

Early in a software engineering journey, it's easy to mistake these milestones for the destination.

I used to think that becoming a better engineer meant learning more languages, more frameworks, and solving more algorithmic problems.

Then I started building larger applications.

That's when I realized something that completely changed my perspective.

Building software is fundamentally not about writing code.

Code is simply the artifact of engineering decisions.

The real engineering happens long before a single keystroke hits the editor.

The Syntax Trap

Learning a programming language is largely a game of understanding syntax, keywords, standard libraries, and APIs.

It's an essential first step, but it's still a tool-level skill.

Knowing how to write a for loop in Go, Rust, and TypeScript doesn't mean you know how to build a scalable data pipeline.

It simply means you know how to express the same idea using different syntax.

The same applies to Data Structures and Algorithms.

DSA is incredibly valuable. It sharpens logical thinking and teaches you how to build efficient solutions.

But after spending time on real projects, I noticed something.

Very few production problems were caused by an inefficient sorting algorithm.

Most of them looked like this:

Tightly coupled modules.
Fragile dependencies.
Business logic scattered across the application.
Architectures that resisted change.
Development environments that didn't match production.

Those aren't syntax problems.

They're engineering problems.

Shift Your Focus: Principles Over Syntax

One of the biggest mindset shifts I experienced was realizing that languages and frameworks are temporary.

The developers who consistently build great software aren't valuable because they know every framework.

They're valuable because they understand the principles underneath them.

When you prioritize mental models over framework-specific knowledge, moving between languages and technologies becomes much easier.

You're no longer memorizing APIs.

You're recognizing familiar ideas expressed through different tools.

Frameworks teach implementation. Principles teach engineering.

Three Things That Matter More Than Syntax

1. Architectural Decisions

The biggest difference between writing code and engineering software is thinking about how a system evolves.

Good architecture isn't about using the latest design pattern.

It's about making future change inexpensive.

That means asking questions like:

Can this component evolve independently?
Is my business logic isolated from infrastructure?
Can I replace my database without rewriting my application?
Will changing the UI affect my core domain?

Patterns like MVC, Clean Architecture, and Hexagonal Architecture aren't goals by themselves.

They're tools for reducing coupling and making systems easier to change.

2. Thinking Beyond the Current Feature

Every line of code becomes something that has to be maintained.

Before implementing a feature, I've learned to ask questions first.

What happens when the data grows tenfold?
Can this solution be tested independently?
Does my local environment accurately represent production?
Will another engineer understand why I made this decision two years from now?

Engineering is less about finding answers and more about asking better questions.

3. Technical Communication

One lesson I underestimated early on was how much communication influences software quality.

Readable code.

Meaningful commit messages.

Clear documentation.

Consistent naming.

These aren't soft skills.

They're engineering practices.

As Martin Fowler famously said:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Software is read far more often than it's written.

Making it understandable is part of the job.

The Engineer's Mindset

Looking back, I don't think learning programming languages or practicing DSA was the wrong approach.

Those skills gave me a solid foundation.

But they weren't the destination.

The real growth started when I stopped asking:

"How do I write this?"

And started asking:

"How should this system evolve?"

That single shift changed how I approach software engineering.

Final Thoughts

Languages will continue to evolve.

Frameworks will come and go.

Libraries will eventually be replaced.

But thoughtful engineering remains timeless.

Today, I measure progress differently.

Not by how many languages I know.

Not by how many frameworks I've used.

But by how maintainable my systems are, how well they adapt to change, and how easily another engineer can understand what I've built.

Because in the end, software engineering isn't about writing more code.

It's about making better decisions before writing any code at all.

What experience changed the way you think about software engineering? I'd love to hear your perspective in the comments.

The Trap of "Perfect" Architecture: What Building a Shopping Cart Taught Me

Habeeb Abdullahi — Sat, 30 May 2026 22:06:27 +0000

Early in my journey as a software engineer, I became fascinated with software architecture.

I spent hours learning about:

SOLID Principles
Clean Architecture
Hexagonal Architecture
Ports and Adapters
Dependency Inversion

The more I learned, the more I became convinced that every project should be highly decoupled, framework-agnostic, and future-proof.

Then I built a shopping cart application.

And that's when reality taught me a lesson that no book could.

Building It "The Right Way"

Instead of creating a straightforward React application, I decided to apply a strict layered architecture.

My project was structured like this:

UI
│
Controllers
│
Application
│
Domain
│
Adapters
│
Infrastructure

Every responsibility had its own layer.

Every dependency pointed inward.

Every interaction crossed carefully designed boundaries.

At first, I loved it.

The folder structure looked professional.

The separation of concerns looked clean.

The architecture looked impressive.

Then I started building features.

The Architectural Tax

A simple feature change often required updates across multiple layers.

Something that should have taken minutes turned into a journey through several directories and files.

I found myself spending more time maintaining architectural boundaries than solving actual problems.

That's when I realized something important:

Architecture isn't free.

Every layer comes with a cost.

Every abstraction comes with a cost.

Every boundary comes with a cost.

You pay for it with:

More files
More indirection
More cognitive load
More debugging effort
Slower development velocity

The architecture wasn't wrong.

The problem was that the complexity of the architecture was greater than the complexity of the application itself.

Architecture Is a Budget, Not a Rulebook

This realization completely changed how I think about software design.

The question is not:

"Is this architecture clean?"

The better question is:

"What problem is this architecture solving, and is that problem large enough to justify its cost?"

A shopping cart application with a handful of features does not face the same challenges as a large enterprise system.

Treating both projects the same way can actually make the smaller project harder to maintain.

The Framework-Agnostic Illusion

One of my goals was to make the application completely independent of React.

I wanted to be able to swap React for another framework in the future.

In theory, that sounded like great engineering.

In practice, I realized I was optimizing for a scenario that might never happen.

The changes that are almost guaranteed to happen are:

New features
Requirement changes
UI updates
Bug fixes
Refactoring

A complete framework migration is usually much less likely.

Today, I still keep business logic isolated, but I no longer try to abstract every single framework detail away.

What I Prefer Now

My current frontend architecture is much simpler:

Domain

Pure business logic.

No React.

No API calls.

No UI concerns.

Infrastructure

External systems such as:

API clients
Storage
Third-party services

Hooks

State management and orchestration.

The bridge between the domain and the UI.

UI

Presentation components.

Focused on rendering and user interaction.

Nothing more.

This gives me most of the benefits I care about without introducing unnecessary complexity.

The Biggest Lesson

The lesson wasn't that Hexagonal Architecture is bad.

The lesson wasn't that Clean Architecture is wrong.

The lesson was this:

Architecture should solve real problems, not hypothetical ones.

Sometimes adding a boundary is the right decision.

Sometimes removing a boundary is the right decision.

The difficult part is knowing the difference.

And that's not something you learn from reading alone.

You learn it by building software, experiencing the friction, and understanding the trade-offs firsthand.

Final Thoughts

Engineering maturity isn't about applying every design pattern you've learned.

It's about understanding the cost and value of each decision.

The goal isn't perfect architecture.

The goal is reducing the cost of future change.

Build.

Ship.

Learn.

Then simplify.

Have you ever realized you were over-engineering a project? What lesson did it teach you?

JavaScript vs TypeScript? Maybe We’ve Been Asking the Wrong Question.

Habeeb Abdullahi — Thu, 30 Apr 2026 12:23:08 +0000

A lot of developers frame JavaScript vs TypeScript as a debate about which one is better or more professional.

But in real-world systems, that question often misses the real issue.

The difference between good and bad developers is rarely about the language. It is about understanding software design, data flow, and runtime behavior.

Let’s look at a practical example.

Bad TypeScript (Type Safety Without Real Safety)

This is a common pattern

type User = {
  id: string;
  name: string;
  email: string;
};

async function getUser(id: string): Promise<User> {
  const res = await fetch(`/api/user/${id}`);
  return res.json();
}


async function showUser(id) {
  const user = await getUser(id);
  console.log(user.email.toUpperCase())
  }

showUser("123");

What is wrong here

On the surface this looks clean and type safe

But in reality

• The API response is not validated
• The server could return null or incomplete data
• TypeScript is being trusted blindly
• Runtime errors are still possible

This is what happens when TypeScript is used as a replacement for validation instead of a supplement

✅ Better JavaScript (Safer Through Design)

Now compare this approach

function isUser(data) {
  return (
    data &&
    typeof data.id === "string" &&
    typeof data.name === "string" &&
    typeof data.email === "string"
  );
}

async function getUser(id) {
  const res = await fetch(`/api/user/${id}`);
  const data = await res.json();

  if (!isUser(data)) {
    throw new Error("Invalid user data received from API");
  }

  return data;
}

async function showUser(id) {
  try {
    const user = await getUser(id);
    console.log(user.email.toUpperCase());
  } catch (err) {
    console.error("Failed to load user:", err.message);
  }
}
showUser("123");

Why this JavaScript approach can actually be safer

• It validates real runtime data instead of assumptions
• It fails explicitly when something is wrong
• It separates concerns between fetching, validation, and usage
• It scales naturally into schema based systems like Zod or Joi

The real takeaway

TypeScript improves developer experience and static safety.

But:

real world safety comes from architecture, validation, and understanding runtime behavior, not types alone.

You can write unsafe TypeScript and safe JavaScript.

The difference is not the language.

It is the engineering discipline behind it.

If you are serious about frontend engineering, the real question is not:

JavaScript or TypeScript

It is:

Do I understand what actually happens when my code runs?

What’s your take? Does TypeScript make better developers or do fundamentals matter more?