DEV Community: Mohsin Ali

Experience-First Portfolio: A New Approach to Showcasing Engineering Skills

Mohsin Ali — Thu, 01 Jan 2026 04:32:39 +0000

Why I Built a Portfolio Without Projects: The Experience-First Approach

After six years in the tech industry, I realized something was fundamentally broken about how we present ourselves as engineers. Every portfolio I saw followed the same tired formula: a grid of projects with screenshots, tech stacks, and GitHub links. But here's the thing, none of these portfolios told me what I actually wanted to know: What was it like to work with this person?

So I threw out the playbook and built something different.

The Problem with Project-Centric Portfolios

Traditional portfolios focus on what you built, but they miss the how and why. They showcase finished products but hide the messy, collaborative reality of software engineering. When I looked at my own work, the most valuable contributions weren't standalone projects but experiences:

Working with cross-functional teams to reduce manual processing time
Building EHR integration layers that connected multiple health systems
Establishing coding standards that improved team velocity
Designing error handling that made beyond 9-5 debugging bearable

These weren't "projects" in the traditional sense. They were experiences that shaped how I approach engineering challenges.

The Experience-First Portfolio Concept

Instead of showcasing projects, I built my portfolio around expertise pillars that represent different types of engineering experiences. I built an entire site around it.

The home page ditches the typical hero section with a generic tagline. Instead, it opens with eight rotating expertise cards in a horizontal marquee, each one telling a story about a different type of engineering challenge I've tackled. No screenshots, no GitHub links, just the human experience of building systems with teams.

Each card follows the same structure but tells a completely different story:

Enterprise Architecture & Team Collaboration: "In my current role, I work with cross-functional teams on architectural decisions for internal automation systems, helping reduce manual processing time through collaborative workflow analysis."
Frontend Systems & User Experience Engineering: "Building clinician-facing dashboards using React and Angular taught me how responsive interfaces can genuinely enhance user engagement across diverse device landscapes."

What makes this work is the specificity. Instead of saying "I built a React app," I explain the context, the collaboration, and the outcome. Each pillar includes proof, impact, tooling, and measurable outcomes.

Why This Approach Works Better

1. It Shows Operational Empathy

Traditional portfolios show polished demos. Experience-focused portfolios show you understand production realities, team dynamics, and business constraints.

2. It Demonstrates Long-Term Thinking

Anyone can build a todo app. Not everyone can maintain a system for six years, see it scale, and learn from architectural decisions over time.

3. It Highlights Collaboration

Software engineering is a team sport. By focusing on experiences, I can showcase how I work with teams rather than just what I built for them.

4. It's More Honest

Let's be real: most "personal projects" in portfolios are contrived examples that don't reflect real engineering challenges. Experiences are authentic.

The Four-Page Architecture That Tells a Complete Story

Here's where it gets interesting. Instead of the usual About/Projects/Contact structure, I designed four interconnected pages that each serve a specific purpose in understanding how I work:

Timeline - The Journey

This isn't your typical career timeline with job titles and dates. It's structured like a story with three distinct "eras," each with animated milestone nodes and detailed context about what I learned during each phase.

The visual design uses a dynamic scroll-animated line that fills as you read, connecting each era to show progression. But the real value is in how each era explains not just what I did, but how it shaped my approach to engineering. The healthcare technology section, for example, doesn't just list technologies but explains how six years at one company taught me lessons about architectural decisions that job hopping never could.

Articles - The Thinking Process

Rather than a blog grid, this page showcases four carefully selected technical articles that demonstrate different aspects of my problem-solving approach. Each article gets a custom abstract icon and a summary that explains the engineering insight, not just the technical topic.

The layout is clean and scannable, with hover states that reveal the cursor indicator (a simple ">" symbol) that appears throughout the site. What's clever here is that the articles aren't just technical tutorials but stories about decision-making, tool selection, and community building.

Mindset - The Philosophy

This is where most portfolios would have an "About" page with personal details. Instead, I created a deep dive into three core engineering principles that guide how I work:

The "Gold-Plating" Paradox: Knowing when code is "done" is harder than writing it
Operational Empathy: Design systems for the humans who maintain them
Long-Term Thinking: Six years at one company taught me what job hopping never could

Each principle gets a full section with examples, context, and practical applications. The layout uses a card-hover system where engagement reveals additional visual cues, making the philosophy feel interactive rather than preachy.

Home - The Integration Point

The home page ties everything together with that expertise marquee, but also includes strategic CTAs that guide visitors to the most relevant next step based on what they're looking for.

The Technical Implementation

I built this using React and TypeScript with a focus on performance and accessibility. The key innovation isn't technical but conceptual: organizing content around expertise areas rather than project categories.

const expertisePillars = [
  {
    title: "Enterprise Architecture & Team Collaboration",
    proof: "In my current role, I work with cross-functional teams...",
    impact: "Technical Expertise & Business Impact",
    tooling: ["Node.js", "TypeScript", "Cross-functional Work"],
    measurableOutcome: "Reduced processing time, supported transaction growth"
  },
  // ... more pillars
];

The site architecture deliberately avoids:

Projects Section: Intentionally absent
Generic Hero Sections: No "I'm a developer who loves to code"
Technology Lists: Skills are embedded in context, not displayed as badges
Contact Forms: Direct links to LinkedIn and GitHub where conversations actually happen

The Broader Implications

This isn't just about portfolios. It's about how we think about career development in tech:

Focus on Experiences Over Achievements

Instead of collecting projects, collect experiences. Work on different types of problems, with different types of teams, in different contexts.

Develop Operational Empathy

The best engineers I know don't just write code, they understand the humans who maintain it, the business constraints that shape it, and the long-term implications of architectural decisions.

Embrace Long-Term Thinking

In today's fast-moving tech scene, there's pressure to job-hop for growth. But my six years in healthcare technology taught me lessons that shorter tenures never could. Sometimes staying and seeing the full lifecycle of your decisions is more valuable than chasing the next opportunity.

Building Your Own Experience-First Portfolio

If this resonates with you, here's how to start:

1. Audit Your Real Contributions

Look beyond code you wrote to systems you influenced, teams you helped, and processes you improved.

2. Focus on Context and Impact

For each experience, explain:

What was the business context?
Who did you work with?
What was the outcome?
What did you learn?

3. Show Your Thinking Process

Include technical writing, decision-making frameworks, or lessons learned. Show how you approach problems, not just solutions.

4. Be Honest About Collaboration

Use "we" more than "I". Show how you work with teams, handle disagreements, and contribute to collective success.

The Future of Technical Portfolios

I believe we're moving toward more authentic ways of showcasing engineering capabilities. The project-centric approach made sense when most developers were building standalone applications. But modern software engineering is collaborative, iterative, and context-dependent.

Experience-first portfolios better reflect this reality.

Try It Yourself

You don't need to rebuild your entire portfolio overnight. Start by rewriting one project description to focus on the experience:

Instead of: "Built a React dashboard with TypeScript and Material-UI"

Try: "Worked with the product team to design a clinician-facing dashboard that improved documentation efficiency by reducing click-through paths and providing contextual information at the point of care"

See the difference? The second version tells me about your collaboration skills, user empathy, and business impact.

Conclusion

After six years in the tech industry, I've learned that the most valuable engineers aren't just great coders, they're great collaborators who understand the human side of technology. An experience-first portfolio is a better way to showcase these skills.

The traditional project portfolio isn't wrong, it's just incomplete. By focusing on experiences, we can show not just what we've built, but how we think, how we collaborate, and how we grow.

And in an industry where soft skills often matter as much as technical skills, that's a much more complete picture of who we are as engineers.

What do you think about the experience-first approach? Have you tried something similar in your own portfolio? I'd love to hear your thoughts and experiences in the comments below.

Connect with me:

LinkedIn - Professional network and recommendations
GitHub - Code quality and contributions
Portfolio - See the experience-first approach in action

🚀 The Weird Story Behind “n8n”: Why It’s Spelled That Way (And What It Really Means)

Mohsin Ali — Thu, 25 Sep 2025 16:16:07 +0000

If you’ve ever stumbled across n8n and thought:
“Wait… is that n-eight-n? Or maybe ninety-eight-n?!”
You’re not alone.

But here’s the thing 👉 the name isn’t random at all.
In fact, it hides a clever story about automation, creativity, and branding.

🌱 The Birth of “n8n”

Back in the early days, founder Jan Oberhauser was building a new kind of workflow tool.
It wasn’t just another automation app. It was node-based. It was no-code. It was designed to make automation accessible to everyone.

So, naturally, he came up with the name:
“nodemation” → short for “Node.js” + “automation.”

Cool, right? Except… there was a problem.

😅 The Problem With “nodemation”

Imagine typing nodemation into your terminal over and over again.
Kinda clunky, isn’t it?

Jan realized the name was way too long for real-world use.
He needed something short. Memorable. Terminal-friendly.

So, he turned “nodemation” into something much leaner: n8n.

🔢 Why the “8”?

Here’s the genius part:
The 8 isn’t just random.

It represents the eight letters between the two “n”s in “nodemation.”

n [eight letters] n → n8n

Once you see it, you can’t unsee it.

And just like that, the quirky, hacker-culture name was born.

🎯 The Perfect Fit

The name wasn’t just shorter.
It fit the project’s DNA:

Node-based (drag-and-drop workflow builder)

Automation-first (the core purpose)

No-code friendly (accessible for beginners, powerful for pros)

Even better? It stuck.
“n8n” is now a recognizable brand in the automation world, lean, memorable, and unmistakably unique.

💡 The Takeaway

Great product names aren’t always obvious.
Sometimes, they hide stories, clever shortcuts, or even inside jokes.

👉 Next time you see a brand with a “weird” name, ask yourself: what’s the story behind it?

Because more often than not, there’s a piece of creativity hiding in plain sight.

✅ Your turn: What’s the most unusual (or clever) product name you’ve come across in tech? Drop it in the comments. I’d love to see your list!

Sources:

Reddit discussion on n8n
n8n Press Kit
n8n GitHub Repo

First Star on My Repo. That Hit Different.

Mohsin Ali — Mon, 16 Jun 2025 18:18:48 +0000

I built WhisperTranscribe in a quiet weekend.

Drop in an MP3: get back plain text. No cloud calls, just a local model doing its job. It was a scratch-your-own-itch tool. Build it, use it, move on.

Weeks later, buried in GitHub notifications, I saw it: just one ⭐.

One stranger found the repo, used it, and thought, “Yeah, this is worth a click.”

No viral tweet. No launch. Just a silent nod from another builder. Funny how a single star feels louder than ten thousand views.

Why That One Star Mattered

1. I polished like someone might care.

Clear README, Docker wrapper, friction-free UI. Worth the effort.

2. I never shared it.

No blog, no post, no launch. That single star reminded me: clean code and clear docs still matter.

3. It nudged me to hit “publish” more.

I have a folder full of quiet scripts. That click pushed me to ship the rest.

What You Can Steal From This

→ Don’t just post the code.

Show how it works. Add a gif. Write one useful line. Give people a reason to click.

→ Leave signs for others.

Good README, helpful repo tags, a one-liner in a dev blog. Make it easy to stumble across.

→ Respect small signals.

A star, a fork, an issue. Each one means someone found value.

Try It Out

Need a fast local transcription tool? Grab the repo:

👉 https://github.com/mohsinalipro/whispertranscribe (feel free to ⭐ if it helps you too)

Automating Chrome with a Node.js API and Browser Extension

Mohsin Ali — Wed, 29 Jan 2025 16:27:08 +0000

Introduction

While many developers today focus on integrating AI into automation, this project takes a different approach. Instead of using AI to execute tasks, I leverage it to generate workflows, defining task sequences while leaving execution to a Node.js API and Chrome Extension.

This system enables programmatic control of Chrome, allowing users to open and close tabs, execute JavaScript, and maintain synchronization. Unlike Playwright or Puppeteer, which operate in isolated environments, this solution works directly with your personal browser, preserving sessions, authentication, and logins.

Why Automate Chrome?

✅ Automate repetitive web tasks like form-filling and clicking buttons.

✅ Manage tabs efficiently—open, close, switch, and find tabs instantly.

✅ Run JavaScript inside browser tabs for real-time automation.

✅ Sync browser state with a backend, ensuring accurate session tracking.

Real-time synchronization is achieved with Socket.IO, providing immediate task updates and reliable connection management.

How It Works

1️⃣ The Node.js API queues tasks, tracks browser state, and now broadcasts tasks in real time using Socket.IO.

2️⃣ The Chrome Extension listens for incoming tasks, executes them using a CSP-friendly JavaScript injection (with support for file uploads), and reports back the results.

~~⚠️ Current Issue: JavaScript execution was blocked due to Content Security Policy (CSP) restrictions in Chrome, preventing unsafe-eval. A fix was in progress.~~

Resolved: I have implemented a robust CSP JS workaround that executes scripts in the tab's main context using Blob URL injection, with the added flexibility of processing file uploads.

Why Not Playwright or Puppeteer?

Unlike Playwright or Puppeteer, which create isolated browser instances, this system works within your personal browser:

Preserves login sessions – No need to re-authenticate.
Works with real browsing data – Automates everyday workflows.
No separate headless instance – Uses your existing Chrome profile.
Real-time communication – With Socket.IO, tasks are delivered instantly, even if queued before the extension is activated.

Takeaways

🚀 Personal browser automation unlocks new possibilities, from monitoring dashboards to auto-refreshing web apps.

🔄 Synchronization is key—ensuring browser and backend states remain in sync prevents task failures.

My new Socket.IO integration guarantees immediate task delivery and robust reconnection if the Node API goes down.

🛠 Strategic automation improves productivity while maintaining security and performance.

Enhanced with a CSP-friendly JS execution workaround (supporting file uploads) and real-time task management, my system now offers greater flexibility and reliability.

Conclusion

This Node.js-powered automation system provides full control over Chrome, preserving sessions and real-world data. If you need automation that integrates with your personal browsing, this approach is for you.

🔗 Check out the full source code here: GitHub Repository

What would you automate? Let’s discuss! 🚀

Building Robust Backend APIs with State Machines: A Comprehensive Guide

Mohsin Ali — Tue, 04 Apr 2023 00:40:09 +0000

Introduction

As a backend developer, I have come to appreciate the importance of state machines in building robust and scalable systems. State machines are a powerful tool for modeling complex business logic and automating transitions between states. In this blog post, I will explain what state machines are, their benefits for backend development, and how to use them to solve common problems.

What are State Machines?

A state machine is a mathematical model used to describe the behavior of a system. It consists of a set of states, transitions between these states, and actions associated with these transitions. At any given time, the system is in one of the defined states, and transitions are triggered by specific events or conditions.

State machines are often used in software development to model complex workflows or business logic. They provide a clear and structured way of defining the behavior of a system, making it easier to reason about, debug, and maintain.

Benefits of Using State Machines for Backend Development

There are several benefits of using state machines for backend development:

Simplicity: State machines simplify the design and implementation of complex workflows. They provide a clear and structured way of defining the behavior of a system, making it easier to understand and maintain.
Scalability: State machines are highly scalable and can handle large amounts of data and complex logic. They can also be easily integrated with other systems and services.
Reliability: State machines help ensure the reliability of a system by enforcing constraints and ensuring that only valid transitions are allowed. This can prevent errors and reduce the risk of system failures.
Flexibility: State machines are flexible and can adapt to changing business requirements. They can be easily updated or modified without affecting the rest of the system.

Overview of What Will Be Covered in the Post

In the rest of this post, I will explain how to use state machines to solve common backend development problems. Specifically, We will cover the following topics:

Defining states and transitions
Actions associated with transitions
Validating transitions
Persisting state machine data
Testing state machines

By the end of this post, you should have a good understanding of how to use state machines to build robust and scalable backend systems.

Designing the State Machine

As I mentioned earlier, state machines are made up of states, transitions, and events. When designing a state machine for our backend system, We need to first identify all the different states that our system can be in. For example, in a user authentication system, we might have states such as "logged out," "logged in," and "forgot password."

Once we have identified all the states, we need to define the events that will trigger transitions between those states. In our authentication system, events could include "user submits login credentials," "user clicks logout button," or "user requests password reset."

With states and events defined, we can now diagram our state machine. This is typically done using a visual representation, such as a flowchart or state diagram. This diagram will show all the states, transitions, and events in a clear and organized manner, making it easier for us to understand and implement our state machine in code.

When designing a state machine, it's important to keep in mind the specific needs and requirements of our backend system. By carefully considering all the states, transitions, and events, we can create a state machine that accurately reflects the behavior of our system and provides the necessary functionality for our users.

Designing the State Machine with Visual Editor

To further simplify the process of designing and diagramming state machines, there are visual editors available that allow us to create and modify state machines using a graphical interface. One popular tool is the XState Visualizer, which provides an easy-to-use interface for designing state machines.

With XState Visualizer, we can create and edit states and transitions using a drag-and-drop interface. We can also define events and actions for each state and transition, making it easier to test and debug our state machine.

Using a visual editor can be especially useful for complex state machines, where the diagram can quickly become difficult to manage and understand. By using a visual editor, we can ensure that our state machine is well-designed and meets the specific needs of our backend system.

Implementing the State Machine

Now that we have designed the state machine, it's time to implement it. Choosing the right framework for state machines is crucial for the success of your project. There are several frameworks available in different programming languages that can be used for implementing state machines. Some of the popular ones include:

Python: PyTransitions, Automat
Java: StateMachineFramework, EasyFlow
C#: Stateless, Automatonymous
JavaScript: xstate, javascript-state-machine

For the purpose of this post, we will be using the xstate library for implementing our state machine in Node.js.

We'll start by installing xstate using npm:

npm install xstate

Once we have xstate installed. The first step is to set up the state machine by defining the initial state and the state transitions. Xstate provides a simple syntax for defining state machines using a JSON object. Here's an example:

const signUpStateMachine = {
  id: 'signup',
  initial: 'idle',
  states: {
    idle: {
      on: { SIGNUP: 'pendingVerification' }
    },
    pendingVerification: {
      on: {
        VERIFICATION_SUCCESS: 'active',
        VERIFICATION_FAILURE: 'verificationFailed'
      }
    },
    verificationFailed: {
      on: { SIGNUP: 'pendingVerification' }
    },
    active: {
      type: 'final'
    }
  }
};

The id property is a unique identifier for the state machine. The initial property specifies the initial state of the machine, which in this case is idle. The states property contains all the possible states of the machine and their corresponding transitions.

Once the state machine is set up, we can write code to handle state transitions. Xstate provides a Machine function that creates an instance of the state machine. Here's an example:

const { Machine } = require('xstate');
const signUpMachine = Machine(signUpStateMachine);

We can now use this signUpMachine instance to transition between different states. Xstate provides a send function that can be used to trigger events and transition between states. Here's an example:

const result = signUpMachine.send('SIGNUP');
console.log(result.value); // 'pendingVerification'

In this example, we have triggered the SIGNUP event, which transitions the machine from the idle state to the pendingVerification state. The send function returns an object that contains the current state of the machine (result.value).

Testing the State Machine

Testing is a critical part of software development, and the state machine is no exception. In this section, We will discuss the different types of testing that can be performed on a state machine to ensure its correctness and reliability.

Unit Testing: Unit tests are designed to test individual functions or methods of the state machine in isolation. These tests are important for ensuring that each function of the state machine works as intended and that the state transitions occur as expected.
Integration Testing: Integration testing is performed to ensure that the state machine works correctly with other parts of the backend system. This type of testing is important for ensuring that the state machine interacts properly with the database, messaging queues, or other systems that the backend relies on.
Performance Testing: Performance testing is done to determine how well the state machine performs under various conditions, such as high traffic or a large number of concurrent users. This type of testing can help identify potential bottlenecks or issues with the state machine that may need to be addressed.
Automated Testing: Automated testing can help streamline the testing process by automatically running tests and checking for errors. This type of testing is particularly useful for regression testing, where changes to the state machine are checked against existing test cases to ensure that they do not introduce new bugs.

By performing a combination of these tests, we can ensure that the state machine is working as intended and that any issues are caught early on in the development process.

Advanced Techniques for State Machines in Backend Development

As state machines become more complex, there are several techniques to handle concurrency and multiple requests. One approach is to use optimistic locking, which allows multiple requests to access the state machine at the same time, but only one request can update the state at a time. This technique prevents data inconsistency and race conditions.

Another advanced technique is using state machines for complex workflows. In a workflow, there are multiple states and transitions that must be tracked, and state machines provide a clear and organized way to handle these states and transitions. State machines can also be used to enforce business rules and ensure that the workflow progresses as intended.

Incorporating error handling in the state machine is another advanced technique. When an error occurs, the state machine should handle it gracefully and transition to an appropriate state. Error handling can also involve logging errors, notifying users or developers, and retrying failed actions.

Conclusion

In this blog post, we've discussed the benefits of using state machines in backend development, and explored how to design, implement, and test a state machine in the backend. We've also looked at some advanced techniques for using state machines in complex scenarios.

State machines provide a powerful way to model complex systems and workflows in a clear and concise way. By using state machines, we can avoid the pitfalls of spaghetti code and ensure that our backend services are scalable, reliable, and maintainable.

In the future, we expect to see even more possibilities for using state machines in backend development. As systems become more complex and distributed, state machines can help us to manage the complexity and ensure that our systems are robust and resilient.

If you're working on a backend system or service, we highly recommend considering the use of state machines to simplify and streamline your code. With the right tools and techniques, state machines can help you to build better software and deliver more value to your users.