DEV Community: Abdulmalik Muhammad

Advanced TypeScript Patterns Worth Actually Learning (Part 1)

Abdulmalik Muhammad — Sat, 11 Apr 2026 00:59:17 +0000

There's a point in every TypeScript developer's journey where you stop fighting the compiler and start working with it. These patterns are what got me there.

They're not just clever tricks. They solve real problems that come up when you're building production software.

Branded types for primitive safety

TypeScript treats string as string. So if you have a UserId and an OrderId, both strings, the compiler won't stop you from mixing them up. Branded types fix that.

type Brand<T, B> = T & { _brand: B };

type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;

function getUser(id: UserId) {}

const orderId = "123" as OrderId;
getUser(orderId); // error, as it should be

Once you start using this in a fintech or any domain-heavy codebase, you'll wonder how you lived without it.

Mapped types for transforming shapes

Instead of manually creating variations of a type, let TypeScript do it for you.


type Nullable<T> = {
  [K in keyof T]: T[K] | null;
};

type Readonly<T> = {
  readonly [K in keyof T]: T[K];
};

type Optional<T> = {
  [K in keyof T]?: T[K];
};

These are simple examples but the pattern scales. You can filter keys, remap them, add modifiers conditionally. Very useful when you're deriving API response types from your internal models.

Conditional types for smart generics

This is where TypeScript starts feeling like a programming language within a programming language.

type IsArray<T> = T extends any[] ? true : false;

type Flatten<T> = T extends Array<infer Item> ? Item : T;

// usage
type A = Flatten<string[]>; // string
type B = Flatten<number>;   // number

Flatten is a real pattern I use when dealing with API responses that sometimes return an array and sometimes return a single item. Handle it at the type level and the rest of the code stays clean.

That's part one. Part two covers function overloads, template literal types, recursive types, and as const maps. Coming soon.

Common Mistakes I See in Node.js Backends (And How to Fix Them)

Abdulmalik Muhammad — Sat, 11 Apr 2026 00:52:10 +0000

I've worked on enough Node.js backends at this point to start seeing the same problems come up over and over. Some of them are beginner mistakes. Some of them show up in codebases written by people who really should know better.

Here are the ones I see most often.

Not handling async errors properly

This one is everywhere. Someone writes an async function, forgets to wrap it in a try/catch, and now unhandled promise rejections are silently swallowing errors in production.

// this will swallow errors
app.get("/users", async (req, res) => {
  const users = await getUsers();
  res.json(users);
});

// this won't
app.get("/users", async (req, res, next) => {
  try {
    const users = await getUsers();
    res.json(users);
  } catch (err) {
    next(err);
  }
});

Better yet, use a wrapper utility or a library like express-async-errors so you don't have to repeat that pattern everywhere.

Putting everything in one file

I've opened Node.js projects where the entire app, routes, business logic, database calls, and middleware, lives in a single index.js. It works until it doesn't. Once the project grows it becomes impossible to navigate and a nightmare to test.

A simple structure goes a long way:

src/
  routes/
  controllers/
  services/
  middleware/
  utils/

Controllers handle the request and response. Services handle the business logic. Keep them separate and your codebase stays readable as it scales.

Blocking the event loop

Node.js is single threaded. If you run a heavy synchronous operation on the main thread, everything else waits. I've seen people do things like parse a large JSON file synchronously or run a CPU intensive calculation right in a route handler.

If you have heavy work to do, offload it. Use worker threads, a job queue, or move it out of the request cycle entirely.

No validation on incoming data

Trusting whatever comes in from the client is asking for trouble. I've seen backends that pass req.body directly into a database query with zero validation. That's how you get corrupted data and security issues.

Use a validation library like zod or joi. Define your schema, validate early, and reject bad input before it gets anywhere near your business logic.

const schema = z.object({
  email: z.string().email(),
  amount: z.number().positive(),
});

const result = schema.safeParse(req.body);
if (!result.success) return res.status(400).json(result.error);

No centralized error handling

Error handling scattered across every route is messy and inconsistent. Users end up getting different error shapes depending on which route blew up. Set up a single error handling middleware and funnel everything through it.

app.use((err, req, res, next) => {
  console.error(err);
  res.status(err.status || 500).json({
    message: err.message || "Something went wrong",
  });
});

One place to update, consistent responses everywhere.

Ignoring environment configuration

Hardcoded secrets, API keys sitting in the codebase, no .env setup. Still happens more than it should. Use dotenv, never commit secrets, and validate your environment variables at startup so the app fails loudly if something is missing rather than breaking mysteriously at runtime.

No logging worth reading

console.log("error:", err) is not a logging strategy. In production you need structured logs you can actually search and filter. Something like winston or pino gives you log levels, JSON output, and the ability to plug into whatever monitoring setup you're using.

If you can't tell what your backend was doing when something went wrong, that's a problem you'll feel at the worst possible time.

None of these are hard to fix. Most of them just require slowing down and being intentional about how the project is set up from the start. A backend that's easy to debug and maintain is worth more than one that was fast to throw together.

Things I Wish I Knew Before Building My First React Native App

Abdulmalik Muhammad — Thu, 09 Apr 2026 22:45:15 +0000

I remember the first time I opened a React Native project. I thought, I already know React, how different can this be?

Pretty different, it turns out.

Here's what I wish someone had told me before I wasted time figuring it out myself.

The bridge is not free

Early on I treated React Native like a browser. I passed big objects around, called native modules constantly, didn't think twice about it. Then I started noticing janky animations and sluggish interactions.

The JavaScript thread and the native thread are separate. Every time they talk to each other there's a cost. The more you understand that, the better decisions you make about where logic lives and how often you cross that bridge.

StyleSheet.create is not just for organization

I was using inline styles everywhere when I started because it felt easier. Turns out StyleSheet.create isn't just a pattern for keeping things tidy. It validates styles at compile time and optimizes them so they don't get recreated on every render.

Small thing but it adds up across a whole app.

FlatList will bite you if you ignore it

I made the mistake of rendering long lists with a plain ScrollView early on. It works, until it doesn't. FlatList exists for a reason. It only renders what's on screen. Once your list grows past a certain point, the difference is night and day.

Also, always set keyExtractor. Don't let React Native guess.

Navigation state is its own beast

Coming from web, I assumed routing would feel familiar. It doesn't, not really. React Navigation has its own mental model and the stack, tab, and drawer navigators each behave differently. I spent way too long fighting navigation bugs that were actually me misunderstanding how the navigator was managing state.

Read the docs properly before you build. It saves you a lot of pain later.

Test on a real device early

The simulator is convenient but it lies to you. Performance feels fine in the simulator and then you run it on a mid-range Android and everything falls apart. I learned to keep a physical device nearby from day one.

Also, Android and iOS behave differently more often than you'd expect. Don't assume something works on both just because it works on one.

Expo is not cheating

There was a phase where I thought using Expo meant I wasn't doing it properly. That's nonsense. Expo managed workflow is legitimate and handles a lot of the setup and tooling pain so you can focus on actually building. When you need bare metal access you can eject. But start simple until you have a reason not to.

The ecosystem moves fast

Libraries you depend on today might be unmaintained in a year. React Native itself ships breaking changes. I learned to be intentional about what I pull in and to keep an eye on the health of dependencies before committing to them in a production app.

React Native is genuinely great once you understand how it works under the hood. Most of the frustration early on comes from treating it like the web when it isn't. The sooner you accept that, the faster things click.

What Building Fintech Apps Taught Me About Writing Better Code

Abdulmalik Muhammad — Wed, 08 Apr 2026 23:34:26 +0000

Fintech is unforgiving. You're dealing with real money and real users. A glitch in a social app is a bad UX moment. A glitch in a payment flow means someone loses money or trust, sometimes both.

After spending years building across fintech and crypto products, here's what that environment actually drilled into me.

You start thinking about failure first

In most apps you can afford to be a little optimistic. In fintech you can't. What happens if the network drops mid-transaction? What if the user hits the button twice? What if the third party API returns a 200 with a broken body?

You stop treating edge cases as afterthoughts. That habit sticks with you even when you move to lower stakes projects.

Types stop being optional

When you're moving money around, a string where a number should be is not something you push to fix later. I became a much more deliberate TypeScript user building fintech than I ever was before. Strict mode on, no shortcuts, model your data properly from day one.

The compiler catching something before production feels different when what it caught could have caused a financial discrepancy.

Idempotency becomes second nature

This one trips up a lot of developers who haven't built payment systems. If a user submits a payment and the response never comes back, what happens when they retry? Does it charge twice?

Designing endpoints so the same request always produces the same result no matter how many times it's called is something you bake in from the start in fintech. Once you think that way, you start applying it everywhere.

Logging stops being an afterthought

In a regular app, a bug report comes in and you dig through the code. In fintech, you need to reconstruct exactly what happened, in what order, with what data, at what time. Structured logging and audit trails stop feeling like nice-to-haves really fast.

If you can't explain what your system did, that's a problem.

User trust is the actual product

The feature set matters. Performance matters. But the thing fintech taught me most is that users are trusting you with something real. The moment that trust breaks, it's very hard to get back.

That changes how you approach everything, from how errors show up in the UI to how you write copy for a failed transaction screen.

I've worked across a few domains now and fintech sharpened me more than any of them. Not because the code was harder, but because the cost of carelessness was real.

If you get a chance to build in a high stakes environment, take it. You'll write better software everywhere else because of it.

TypeScript Tricks I Actually Use Day to Day

Abdulmalik Muhammad — Tue, 07 Apr 2026 23:42:05 +0000

I've been writing TypeScript for a few years now across React Native, Node.js, and a bunch of different product types. And there's a gap between what the docs teach you and what you actually end up reaching for every day.
Here are the patterns I keep coming back to.

Discriminated unions for state management
This one changed how I model data. Instead of a bunch of optional fields that may or may not exist, you define each state explicitly.

type RequestState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: User }
  | { status: "error"; message: string };

Now TypeScript knows exactly what's available in each case. No more data might be undefined checks scattered everywhere.

satisfies instead of direct type annotation

This one's newer but I use it a lot now. The difference is subtle but useful.

const config = {
  theme: "dark",
  language: "en",
} satisfies Record<string, string>;

With satisfies, you get type checking without losing the literal types. If you annotate directly with Record, you lose the specific values. Small thing, big difference when you're chaining or inferring from it.

Utility types you actually need

Everyone knows Partial and Required. These are the ones I reach for more often:

// Pick only what you need
type Preview = Pick<Article, "title" | "slug" | "createdAt">;

// Exclude what you don't
type PublicUser = Omit<User, "password" | "token">;

// Make specific fields optional
type UpdateInput = Partial<Pick<User, "name" | "bio">> & Pick<User, "id">;

That last one is something I use constantly for update/patch endpoints.

Template literal types for string contracts
Useful when you're dealing with event names, routes, or anything string-based that needs structure.

type HttpMethod = "GET" | "POST" | "PUT" | "DELETE";
type Endpoint = `/${string}`;
type Route = `${HttpMethod} ${Endpoint}`;

const route: Route = "GET /users"; // valid
const bad: Route = "FETCH /users"; // error

Catches a whole class of bugs at compile time instead of runtime.

infer for extracting types from generics

Looks scary at first but once it clicks, you use it everywhere.

type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;

type UnpackPromise<T> = T extends Promise<infer U> ? U : T;

I use UnpackPromise constantly when working with async functions and I need the resolved type without awaiting.

Const assertions for config objects

Stop widening your types when you don't need to.

const ROLES = ["admin", "user", "guest"] as const;
type Role = typeof ROLES[number]; // "admin" | "user" | "guest"

Clean, no manual duplication, and the type stays in sync automatically.

None of these are exotic. They're just the things that come up over and over when you're building real products. The more you use them the more the TypeScript compiler starts feeling like a teammate rather than something you're fighting against.

That's the shift worth chasing.

How I Stay Sharp as a Senior Dev (Without Burning Out)

Abdulmalik Muhammad — Mon, 06 Apr 2026 23:28:37 +0000

Five years in and honestly, the thing I didn't expect to fight against is comfort.

You get to a point where things just... work. You know the patterns. You've seen the bugs. You can set up a project without thinking. That's great until you realize you haven't actually been challenged in months.

Here's what's been working for me.

Build something you don't understand yet
Not at work. On the side. Pick something that's slightly outside your zone and just start poking at it. I've been messing around with VoIP and SIP stuff lately, nowhere near my usual React Native and Node.js world. It's uncomfortable. That's kind of the whole point.

You don't have to finish it. Just stay curious.

Read more code than you write
Not tutorials. Actual source code of libraries you use every day. Open it up and read it like a book. You'll find things that surprise you, and occasionally things that make you go "wait, why did they do it like that?" Both are useful.

Explain things regularly
Write a post. Walk a junior through something. Do a quick internal talk. It doesn't matter. The moment you try to explain something clearly, you find out fast where your understanding actually has holes. Happens to me every time.

Ship the ugly version first
This one took me a while. Senior devs tend to want to get it right from the start. But sometimes the right move is to ship something rough, see how it actually gets used, then fix it. Real usage teaches you things no amount of upfront thinking will.

Switch contexts when you can
New domain, new stack, new team, whatever you can manage. Every time I've moved into a new space (fintech, crypto, AI products) I've hit problems I wasn't ready for. That friction is where most of my actual growth has happened.

Staying sharp isn't really about doing more. It's about not going numb. The best senior devs I know aren't the ones working the hardest, they're the ones who are still genuinely interested after years of doing this.

That's what I'm chasing anyway.