DEV Community: Grant Riordan

TypeScript Fundamentals, Part 3: Reusable Types

Grant Riordan — Sat, 10 Oct 2026 19:17:15 +0000

📚 TypeScript Fundamentals series

Part 1: Describing Your Data: interfaces, type aliases, unions, tuples

Part 2: Writing Safer Code: inference, strict mode, unknown, narrowing

Part 3: Reusable Types: generics, utility types, enums vs literal unions (you are here)

Each part stands on its own. Read them in order, or jump straight to the one you need.

As your codebase grows you'll find yourself writing the same type over and over with small variations: a list of users, a list of orders, a "user but with every field optional". TypeScript has tools for exactly this, so you can write a type once and reuse it. This part covers generics, the built-in utility types, and the question of how to model a fixed set of values.

Who is this part for? Anyone comfortable reading basic TypeScript. If you haven't read the earlier parts, this is all you need to know:

Quick refresher. An interface or type describes the shape of an object. A union like string | number means "one of these types", and a literal type like 'admin' means exactly that one value. keyof T gives you a union of the property names of T. (Part 1 covers the first two in depth.)

We'll use this User shape throughout:

interface User {
    id: number;
    name: string;
    email: string;
    role: 'admin' | 'editor' | 'viewer';
}

Generics

The problem

Imagine a function that returns the first item of an array. How do you type it?

function firstNumber(items: number[]): number | undefined {
    return items[0];
}

function firstString(items: string[]): string | undefined {
    return items[0];
}

Writing one per type doesn't scale. You could use any, but then you lose all type information:

function first(items: any[]): any {
    return items[0];
}

const n = first([1, 2, 3]);   // n is any. TypeScript has forgotten it's a number

The solution

A generic is a type placeholder, written in angle brackets, that gets filled in when the function is used:

function first<T>(items: T[]): T | undefined {
    return items[0];
}

const n = first([1, 2, 3]);           // T is inferred as number, so n is number | undefined
const s = first(["a", "b"]);          // T is inferred as string
const u = first<User>([]);            // or specify it explicitly

Read <T> as "I don't know what type just yet - but I will when I call the function". The type goes in, and the same type comes out, with nothing lost along the way.

You've already used generics without realising: Array<T> (the same as T[]) and Promise<T> are both generic types.

Generic types and interfaces

Generics aren't just for functions. They're great for wrappers that look the same regardless of the data inside:

interface ApiResponse<T> {
    data: T;
    fetchedAt: Date;
}

const userResponse: ApiResponse<User> = { data: someUser, fetchedAt: new Date() };
const listResponse: ApiResponse<User[]> = { data: [someUser], fetchedAt: new Date() };

One definition, any payload type.

Constraints

Sometimes "any type" is too loose. Use extends to say "any type, as long as it has at least this shape":

function findById<T extends { id: number }>(items: T[], id: number): T | undefined {
    return items.find(item => item.id === id);
}

findById(users, 1);          // ✅ User has an id
findById([{ id: 1 }], 1);    // ✅
findById(["a", "b"], 1);     // ❌ string has no 'id'

A particularly useful constraint combines generics with keyof, to make sure a key actually exists on an object and that the return type matches it:

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
    return obj[key];
}

const email = getProperty(someUser, "email");    // type is string
const bad   = getProperty(someUser, "emial");    // ❌ not a key of User

Utility Types

TypeScript ships with a set of built-in generic types that transform other types. They save you from writing near-duplicate interfaces. These are the ones you'll reach for most:

Utility	What it does
`Partial<T>`	Makes every property optional
`Required<T>`	Makes every property required
`Readonly<T>`	Makes every property read-only
`Pick<T, K>`	Keeps only the listed properties
`Omit<T, K>`	Removes the listed properties
`Record<K, V>`	An object with keys `K` and values `V`

Here they are in practice:

// Partial: great for update functions where only some fields change
function updateUser(id: number, changes: Partial<User>) { /* ... */ }
updateUser(1, { name: "Sam" });                 // ✅ no need to pass every field

// Pick: a smaller view of a type
type UserPreview = Pick<User, 'id' | 'name'>;
// { id: number; name: string }

// Omit: everything except some fields
type NewUser = Omit<User, 'id'>;                // the shape before the database assigns an id
// { name: string; email: string; role: ... }

// Readonly: prevent accidental mutation
const config: Readonly<User> = someUser;
config.name = "Other";                          // ❌ cannot assign, it is read-only

// Record: a lookup table
type RoleLabels = Record<User['role'], string>;
const labels: RoleLabels = {
    admin: "Administrator",
    editor: "Editor",
    viewer: "Read-only",
};

The Record example has a nice bonus: if you add a new role to User, TypeScript will complain that labels is missing a key.

Two more worth knowing about:

ReturnType<typeof fn> gives you the type a function returns, which is handy when you don't want to write it out twice.
Awaited<T> unwraps a Promise, so Awaited<Promise<string>> is string.

The big idea is that you define a type once (here, User) and derive the others from it. When User changes, everything derived from it updates automatically, with no copies to keep in sync.

Enums vs Literal Unions

Often you need a fixed set of allowed values, like roles, statuses or directions. TypeScript offers a few ways to do it.

Enums

An enum is a TypeScript feature that creates a named set of constants:

enum Role {
    Admin = 'admin',
    Editor = 'editor',
    Viewer = 'viewer',
}

function canEdit(role: Role) {
    return role === Role.Admin || role === Role.Editor;
}

canEdit(Role.Admin);     // ✅
canEdit('admin');        // ❌ a plain string isn't assignable to the Role enum

Enums work, but they have some quirks. Unlike most TypeScript features, an enum isn't just a type: it generates real JavaScript code at runtime. Numeric enums (the default, when you don't assign string values) also allow some surprising assignments, and values must be referenced via the enum rather than as plain strings.

Literal unions

The lighter alternative is a union of literal types, which we met in Part 1:

type Role = 'admin' | 'editor' | 'viewer';

function canEdit(role: Role) {
    return role === 'admin' || role === 'editor';
}

canEdit('admin');        // ✅
canEdit('owner');        // ❌ not in the union

There's no runtime code at all, since it's purely a type, and the values are just ordinary strings, which makes them easy to serialise, log and compare with data from an API.

`as const` objects: when you need the values at runtime

A literal union is only a type, so you can't loop over it or reference Role.Admin as a value. If you want both, define a constant object and derive the type from it:

const Role = {
    Admin: 'admin',
    Editor: 'editor',
    Viewer: 'viewer',
} as const;

type Role = typeof Role[keyof typeof Role];   // 'admin' | 'editor' | 'viewer'

Role.Admin;                    // 'admin', usable as a value
Object.values(Role);           // loop over every role
function canEdit(role: Role) { /* ... */ }

as const tells TypeScript to treat the object's values as exact literals instead of widening them to string. Notice that the value Role and the type Role share a name, which is allowed because values and types live in separate namespaces.

Which should you use?

For most projects, start with a literal union. It's the simplest option and needs no runtime code. Reach for an as const object when you also need the values at runtime. Enums are still perfectly valid, and plenty of codebases use them, so if your team already does, consistency matters more than switching. As with interfaces vs types, the important thing is to pick one convention and stick to it.

Putting It Together

Here's a small example that uses generics, a union and a discriminant, so you can see how the pieces combine. A generic result type that works for any payload:

type Result<T> =
    | { ok: true; value: T }
    | { ok: false; error: string };

function parseAge(input: string): Result<number> {
    const age = Number(input);
    if (Number.isNaN(age) || age < 0) {
        return { ok: false, error: `"${input}" is not a valid age` };
    }
    return { ok: true, value: age };
}

const result = parseAge("42");

if (result.ok) {
    console.log(result.value + 1);    // ✅ value is a number here
} else {
    console.log(result.error);        // ✅ error is a string here
}

Result<T> is reusable for any type (Result<User>, Result<string[]>), and the ok field narrows the union so you can only touch value on success and error on failure.

Wrapping Up

Generics are type placeholders that let you write a function or type once and use it with many types without losing type information.
Constraints (T extends ...) narrow what a generic accepts, and K extends keyof T ties a key to an object.
Utility types (Partial, Pick, Omit, Readonly, Record) let you derive new types from existing ones instead of copying them.
For a fixed set of values, start with a literal union, use an as const object if you also need runtime values, and treat enums as a valid option if your team prefers them.

Continue the Series

Part 1: Describing Your Data: interfaces, type aliases, unions and tuples.
Part 2: Writing Safer Code: inference, strict mode, unknown and narrowing.

TypeScript Fundamentals, Part 2: Writing Safer Code

Grant Riordan — Sat, 10 Oct 2026 16:56:15 +0000

📚 TypeScript Fundamentals series

Part 1: Describing Your Data: interfaces, type aliases, unions, tuples

Part 2: Writing Safer Code: inference, strict mode, unknown, narrowing (you are here)

Part 3: Reusable Types: generics, utility types, enums vs literal unions

Each part stands on its own. Read them in order, or jump straight to the one you need.

TypeScript only helps you if you let it. You can write code that looks typed but quietly opts out of the safety net, and the compiler won't stop you. This part is about the habits and settings that make TypeScript actually catch bugs.

Who is this part for? Anyone who has written some TypeScript, or who knows what an interface and a union type are. If you haven't, here's all you need:

Quick refresher. An interface or type describes the shape of an object. A union like string | number means "one of these types". A literal type like 'idle' means exactly that one value. That's it; the rest is explained below. (Part 1 goes deeper if you want it.)

Type Inference: Let TypeScript Do the Work

You don't need to annotate everything. TypeScript works out types from the values you give it:

let count = 5;            // inferred as number
let title = "Hello";      // inferred as string
const isDone = false;     // inferred as the literal type false

count = "five";           // ❌ Type 'string' is not assignable to type 'number'

Notice that let and const infer differently. A let variable can change, so TypeScript widens its type to number. A const can never change, so TypeScript keeps the narrowest type it can:

const maxRetries = 3;     // type is the literal 3
let retries = 3;          // type is number

Inference works for function return types too:

function double(n: number) {
    return n * 2;         // return type inferred as number
}

When to annotate

A good rule of thumb: annotate the boundaries, infer the middle.

Function parameters. TypeScript can't infer these, so you always annotate them.
Exported or public functions' return types. This documents the contract and catches accidental changes.
Variables that start empty. TypeScript can't guess what will go in later.

const names: string[] = [];          // without the annotation, this is hard to use
const lookup: Record<string, number> = {};

function getUserName(id: number): string {   // parameter + return type annotated
    // ...
    return "Sam";
}

For everything else, such as local variables and intermediate values, leave the annotations off. Redundant annotations add noise without adding safety.

Strict Mode and `tsconfig.json`

Most of TypeScript's safety comes from one setting. Every TypeScript project has a tsconfig.json file (generate one with npx tsc --init), and the most important line in it is:

{
  "compilerOptions": {
    "strict": true
  }
}

strict is a bundle of checks. Two of them do most of the heavy lifting:

noImplicitAny: stops TypeScript from quietly giving a parameter the type any when you forget to annotate it.
strictNullChecks: makes null and undefined distinct types instead of values that can sneak into anything.

Here's strictNullChecks in action:

function shout(message: string | null) {
    return message.toUpperCase();   // ❌ 'message' is possibly 'null'
}

function shoutSafely(message: string | null) {
    if (message === null) {
        return "";
    }
    return message.toUpperCase();   // ✅ TypeScript knows it's a string here
}

Without strict mode, the first version compiles happily and crashes at runtime with the classic "cannot read properties of null" error. With it, the compiler forces you to deal with the missing case up front.

Start new projects with "strict": true. Turning it on later in an existing codebase can produce a lot of errors at once, so many teams enable the individual flags one at a time.

`any`, `unknown` and `never`

These three special types look similar but do very different jobs.

`any`: switching the checker off

any means "anything goes, don't check this". It's contagious and it defeats the purpose of using TypeScript:

let value: any = "hello";
value.doesNotExist();     // ✅ compiles. -- crashes at runtime
value = 42;
value.toUpperCase();      // ✅ compiles. -- crashes at runtime

Treat any as an escape hatch of last resort.

`unknown`: the safe alternative

unknown also means "could be anything", but with a crucial difference: you must check what it is before you use it.

let value: unknown = "hello";

value.toUpperCase();              // ❌ 'value' is of type 'unknown'

if (typeof value === "string") {
    value.toUpperCase();          // ✅ narrowed to string
}

unknown is the right type for data you can't trust yet, such as parsed JSON, user input or API responses. Be aware that JSON.parse returns any, so annotating the result as unknown is a good habit:

const parsed: unknown = JSON.parse(text);   // now you must check it before using it

`never`: the type with no values

never represents something that can't happen: a function that always throws, or a branch the compiler knows is unreachable. That makes it very useful for exhaustiveness checking with unions:

type Shape =
    | { kind: 'circle'; radius: number }
    | { kind: 'square'; size: number };

function assertNever(x: never): never {
    throw new Error(`Unhandled case: ${JSON.stringify(x)}`);
}

function area(shape: Shape): number {
    switch (shape.kind) {
        case 'circle': return Math.PI * shape.radius ** 2;
        case 'square': return shape.size ** 2;
        default:       return assertNever(shape);  // compile error if a case is missing
    }
}

If you later add | { kind: 'triangle'; ... } to Shape, the assertNever(shape) line stops compiling until you handle the new case. Instead of a silent bug, you get a compile error pointing at exactly what to fix.

Narrowing and Type Guards

Narrowing is how TypeScript refines a broad type into a more specific one inside a block of code. You've already seen it with typeof above. Here are the main tools.

`typeof`: for primitives

function format(value: string | number) {
    if (typeof value === "string") {
        return value.toUpperCase();   // string
    }
    return value.toFixed(2);          // number
}

`instanceof`: for classes

function describe(err: Error | string) {
    if (err instanceof Error) {
        return err.message;           // Error
    }
    return err;                       // string
}

`in`: for checking a property exists

interface Dog { bark(): void }
interface Cat { meow(): void }

function speak(pet: Dog | Cat) {
    if ("bark" in pet) {
        pet.bark();                   // Dog
    } else {
        pet.meow();                   // Cat
    }
}

Equality and truthiness

function greet(name?: string) {
    if (name) {
        return `Hello, ${name}`;      // string (non-empty)
    }
    return "Hello, stranger";
}

Discriminated unions

If your union members share a literal property (like kind or status), checking that property narrows the whole type. We used this in area() above.

Custom type guards

For anything more complex, write your own guard. The special return type x is User tells TypeScript that if the function returns true, the argument is a User:

interface User {
    id: number;
    name: string;
}

function isUser(value: unknown): value is User {
    return (
        typeof value === "object" &&
        value !== null &&
        "id" in value &&
        "name" in value
    );
}

const data: unknown = JSON.parse('{"id": 1, "name": "Sam"}');

if (isUser(data)) {
    console.log(data.name);           // ✅ data is a User here
}

One honest caveat: TypeScript trusts your guard. The version above only checks that the properties exist, not that they have the right types. A more thorough guard would also check typeof value.id === "number".

Escape Hatches: `as` and `!`

Sometimes you know more than the compiler does. TypeScript gives you two ways to override it:

// Type assertion: "trust me, this is a string"
const input = document.getElementById("name") as HTMLInputElement;

// Non-null assertion: "trust me, this isn't null"
const el = document.getElementById("app")!;

These are sometimes necessary, but they are promises, not checks. If you're wrong, nothing stops the crash at runtime. Prefer narrowing whenever you can.

Types disappear at runtime

This is the most important thing to understand about TypeScript. Types are erased when your code is compiled to JavaScript. They help you while writing code, but they don't exist when it runs, so they can't validate data that arrives from outside your program:

interface User { id: number; name: string }

const res = await fetch("/api/users");
const users = (await res.json()) as User[];   // ⚠️ this checks nothing

If the API returns something different, TypeScript has no idea. For data from APIs, files or user input, validate it at runtime, either with a hand-written type guard like isUser above or with a validation library such as Zod, which lets you define a schema once and derive the TypeScript type from it.

Wrapping Up

Let inference work. Annotate function parameters and public return types; leave the rest.
Turn on "strict": true. It's where most of TypeScript's safety comes from, especially strictNullChecks.
Avoid any. Use unknown for untrusted data and narrow it before use.
Use never for exhaustiveness checks so the compiler tells you when you've missed a case.
Narrow with typeof, instanceof, in, discriminants and custom type guards.
Remember that types vanish at runtime. Assertions are promises; validate external data.

Continue the Series

Part 1: Describing Your Data: interfaces, type aliases, unions and tuples, if you want the foundations.
Part 3: Reusable Types: generics, utility types like Partial and Pick, and enums vs literal unions.

TypeScript Fundamentals, Part 1: Describing Your Data

Grant Riordan — Sat, 10 Oct 2026 16:50:12 +0000

TypeScript Fundamentals, Part 1: Describing Your Data

Welcome to my 3 part series on learning the fundamentals of Typescript.

📚 TypeScript Fundamentals series

Part 1: Describing Your Data: interfaces, type aliases, unions, tuples (you are here)

Part 2: Writing Safer Code: inference, strict mode, unknown, narrowing

Part 3: Reusable Types: generics, utility types, enums vs literal unions

Each part stands on its own. Read them in order, or jump straight to the one you need.

So you've decided to learn TypeScript. Maybe you've been writing JavaScript and want to level up your code, or maybe you've heard it's hugely popular and want to stay ahead of the trends 🤷‍♂️

Either way, this series walks through the key fundamentals of the language. This first part is about the most basic job TypeScript does: describing the shape of your data.

Who is this part for?
Anyone who knows basic JavaScript. No TypeScript experience needed.

What is TypeScript?

TypeScript is a superset of JavaScript: every valid JavaScript program is also a valid TypeScript program, and TypeScript adds a type system on top. On the surface it can look complicated, but in essence it's just JS with some extra syntax. In return you get:

Static typing and type annotations
Interfaces and type aliases
Advanced tooling and IntelliSense
Generics, enums and utility types (covered in Part 3)
Safer refactoring

Interfaces & Types

One of the biggest upgrades TypeScript brings is its type system. If you're coming from JavaScript, you'll know it's a dynamically typed language: a variable can hold a string one moment and a number the next.

Interfaces and types give your code structure and enforce static typing. Your objects and variables are assigned strict types, and if your code doesn't abide by them, it won't compile.

Let's look at some examples.

Interfaces

interface Animal {
    name: string;
    age: number;
    makeSound(): void;
}

class Dog implements Animal {
    name: string;
    age: number;

    constructor(name: string, age: number) {
        this.name = name;
        this.age = age;
    }

    makeSound(): void {
        console.log("Woof");
    }
}

class Cat implements Animal {
    name: string;
    age: number;

    constructor(name: string, age: number) {
        this.name = name;
        this.age = age;
    }

    makeSound(): void {
        console.log("Meow");
    }
}

The code above defines an interface called Animal, which is implemented by the Dog and Cat classes. If you're familiar with other typed or object-oriented languages, this concept will feel familiar. If not, in its simplest form it means that Dog and Cat must implement the properties and methods defined in Animal. If they don't, your editor will show errors, and the TypeScript compiler will complain when you try to build the application.

Interfaces can also be used to type plain objects:

interface HttpResponse {
    statusCode: number;
    data: string;
}

function handleHttpResponse(response: HttpResponse) {
    console.log(response.statusCode);
    console.log(response.data);
}

The handleHttpResponse() function accepts an HttpResponse object. Passing anything that doesn't match that shape won't satisfy the compiler.

To declare that a variable has a particular type, use a type annotation (a colon followed by the type):

const response: HttpResponse = {
    statusCode: 200,
    data: "The API request was successful"
};

Optional and readonly properties

Two small modifiers you'll use constantly. ? marks a property as optional, and readonly stops it being reassigned after creation:

interface Profile {
    readonly id: number;   // can be set once, never changed
    name: string;
    nickname?: string;     // may be missing
}

const profile: Profile = { id: 1, name: "Sam" };  // ✅ nickname is optional
profile.name = "Samantha";                         // ✅
profile.id = 2;                                    // ❌ cannot assign to 'id', it is read-only

Types

Type aliases are very similar to interfaces: they also describe the shape of an object. Here's the same Animal shape as a type:

type Animal = {
    name: string;
    age: number;
    makeSound: () => void;
};

const dog: Animal = {
    name: "Buddy",
    age: 5,
    makeSound: () => {
        console.log("Woof");
    }
};

const cat: Animal = {
    name: "Whiskers",
    age: 3,
    makeSound: () => {
        console.log("Meow");
    }
};

"Wait, that looks identical to an interface," I hear you say. You're right: for object shapes the two overlap significantly. So where do they differ?

A Quick Detour: Structural Typing

Before we compare them, there's one idea that explains a lot of TypeScript's behaviour. TypeScript uses structural typing: it checks the shape of a value, not the name of the type it was declared with. If a value has the right properties, it fits.

interface Point {
    x: number;
    y: number;
}

function logPoint(p: Point) {
    console.log(p.x, p.y);
}

const pixel = { x: 10, y: 20, color: "red" };
logPoint(pixel); // ✅ pixel was never declared as a Point, but it has the right shape

Nothing had to say implements Point. This is different from languages like Java or C#, where types are matched by name. It's also why interfaces and type aliases are so interchangeable: both just describe a shape.

One guard rail: if you pass a fresh object literal directly, TypeScript checks for extra properties too, because that's usually a typo:

logPoint({ x: 1, y: 2, color: "red" }); // ❌ 'color' does not exist in type 'Point'

Where Interfaces and Types Differ

Declaration merging

Interfaces with the same name in the same scope merge automatically. Type aliases can't be redeclared.

interface User { name: string }
interface User { age: number }   // merged: { name: string; age: number }

type Account = { id: string }
type Account = { email: string } // error: duplicate identifier

This is why library authors favour interfaces: consumers can augment them. A common example is extending the Request type from the popular Express library.

What they can describe

Interfaces can only describe object shapes (including callable and constructable ones). Type aliases can name almost anything:

type ID = string | number                    // union
type Pair = [string, number]                 // tuple
type Status = 'idle' | 'loading'             // literal union
type Keys = keyof User                       // computed from another type
type Partial2<T> = { [K in keyof T]?: T[K] } // mapped type

Extending

Interfaces use extends; types use intersections (&):

// Interface
interface Admin extends User { role: string }

// Type alias
type SuperAdmin = User & { role: string }

The two look similar, but they behave differently when properties conflict. With an interface, a conflicting property type between the base and the extension produces a clear error at the declaration. With an intersection, the conflicting property silently becomes never, and you only find out when you try to use it.

Interfaces also tend to give nicer error messages and are cached better by the compiler, which can matter in very large codebases.

Classes

A class can implement either one, as long as it describes an object shape (not a union).

Which Should You Use?

For consistency, pick one default and write down the exceptions. There are two common conventions:

1. Interface for object shapes, type for everything else.
This is the TypeScript team's long-standing guidance and what many style guides recommend. You get the compiler benefits of interfaces, while types handle unions, tuples and utility types, which interfaces can't express anyway.

2. Type everywhere.
A simpler rule with no judgement calls, and you never hit a case that can't be expressed as an interface. The downside is giving up declaration merging, which only matters if you're publishing a library or augmenting third-party types.

If you're building an application rather than a library, either works fine. I'd lean towards option 1 if you want to follow common community convention, and option 2 if you value a single rule that nobody has to think about.

Whichever you choose, enforce it with tooling rather than code review.

The ESLint rule @typescript-eslint/consistent-type-definitions can flag (and auto-fix) the other style.

Unions, Literal Types & Tuples

Unions

A union type describes a value that can be one of several possible types. Unions are written with the | operator:

type ID = string | number

const a: ID = "abc-123";  // ✅
const b: ID = 42;         // ✅
const c: ID = true;       // ❌ boolean isn't part of the union

Literal types

A literal type is a type whose only valid value is one specific value, such as 'idle' or 404. Combine several literals in a union and you get a precise, self-documenting set of allowed values:

type Status = 'idle' | 'loading' | 'success' | 'error'

Discriminated unions

Literal types really shine when they're used to tell the members of a union apart. Take the state of a page that loads some users from an API:

interface User {
    id: number;
    name: string;
    email: string;
}

type RequestState =
    | { status: 'idle' }
    | { status: 'loading' }
    | { status: 'success'; data: User[] }
    | { status: 'error'; error: Error; retryable: boolean }

RequestState is a union of four different object shapes. The first two have identical properties, but they aren't the same type, because the status property is a literal type: one allows only 'idle' and the other only 'loading'. That shared literal property is called the discriminant, and it's what lets TypeScript work out which variant you're dealing with.

It also means each variant must provide exactly the fields that make sense for it. A 'success' state must include data, and an 'error' state must include error and retryable. You can't have data on an error, or an error while loading.

Here's how you'd use it:

function render(state: RequestState): string {
    switch (state.status) {
        case 'idle':
            return 'Click to load';
        case 'loading':
            return 'Loading...';
        case 'success':
            return `Loaded ${state.data.length} users`;
        case 'error':
            return state.retryable
                ? `Failed: ${state.error.message}. Retrying...`
                : `Failed: ${state.error.message}`;
    }
}

Inside each case, TypeScript narrows the type of state to the matching variant. That's why state.data is available in the 'success' branch, while trying to read it in the 'error' branch would be a compile error. (Narrowing has a few more tricks, which we cover in Part 2.)

Tuples

A tuple is an array with a fixed length where each position has its own type. Use one when you have a small, ordered group of values that mean different things:

type Coordinates = [number, number]

const london: Coordinates = [51.5072, -0.1276]

const [lat, lng] = london  // destructuring works as you'd expect

Unlike a regular number[], TypeScript knows exactly what's at each position, and it will complain if you get the length or the order wrong:

const bad1: Coordinates = [51.5072]                // ❌ missing an element
const bad2: [string, number] = [200, "OK"]         // ❌ wrong order

You can also label the positions to make them self-documenting:

type HttpResult = [statusCode: number, body: string]

Tuples will look familiar if you've used React: the useState hook returns a [value, setter] pair, which is a tuple.

Wrapping Up

Interfaces and type aliases both describe object shapes, and for most everyday code they're interchangeable.
TypeScript is structurally typed: what matters is the shape of a value, not the name of its type.
Interfaces support declaration merging and give clear errors when extending.
Types can also describe unions, tuples and mapped types.
Discriminated unions let you model state so that impossible combinations can't be represented.
Pick one convention for your project, write it down, and enforce it with a linter.

Continue the Series

Part 2: Writing Safer Code: how type inference works, why strict mode matters, any vs unknown, and narrowing.
Part 3: Reusable Types: generics, utility types like Partial and Pick, and enums vs literal unions.

AI Can Not Be Left Unsupervised

Grant Riordan — Thu, 26 Mar 2026 23:42:34 +0000

"AI is dangerous" — is a phrase you may hear a lot, and I have to agree. But, the most dangerous words in tech right now aren't "AI is dangerous", they're "it'll probably be fine". In a society where the use of AI has become the norm, people have become almost complacent around the dangers of it.

This week I read an article on Dev.to here, telling a story where an employee had "trusted AI to organize my backlog." Two hours later, they returned to a development team's worst nightmare.

"The agent had silently deleted 47 tickets it labelled as duplicates — they weren't. It had reassigned half my team's tasks to people who had left the company months ago. It created 23 new tickets for features nobody had requested. And it marked three critical bugs as resolved, because it found similar-sounding issues elsewhere in the system."

A prime example of when AI is left to its own devices — no warning, no follow-up prompts. It was asked to organise a backlog, and so it did, in the only way it knew how.

Other Damaging Cases

This isn't an isolated incident. Amazon's own AI coding tool, Kiro, was handed a minor fix to a customer-facing system. Rather than patch it, the agent autonomously decided to delete and rebuild the entire environment from scratch. The resulting outage lasted 13 hours. Amazon's response? "Coincidence that AI was involved." That denial tells you everything.

In a similar case, an AI coding assistant from Replit went rogue and wiped the production database of startup SaaStr entirely — its founder took to social media to warn others after the assistant modified production code despite explicit instructions not to.

Could your business afford that kind of downtime?

It isn't just agentic AI operating behind the scenes. Customer-facing AI is failing in equally public and embarrassing ways. DPD's AI chatbot, after a routine system update, began swearing at a customer, insulted itself, and wrote a poem about how terrible the company was, all because a frustrated user simply asked it to. The incident went viral.

Perhaps the most alarming example of AI complacency comes from a Chevrolet dealership, whose chatbot agreed to sell a 2024 Chevy Tahoe for $1 and declared it a legally binding offer after a user simply manipulated it with a clever prompt. The dealer pulled the bot, but the damage to their brand was already done.

In August 2025, security researchers used a single 400-character prompt to manipulate Lenovo's customer service chatbot into revealing sensitive company data including live session cookies from real support agents. Not a sophisticated hack. Just a simple prompt.

Outside of customer service, the professional world is sleepwalking into its own risks. A lawyer was caught citing entirely non-existent legal cases in a New York federal court filing he had used ChatGPT to conduct legal research, and simply trusted the output.

With the rapid adoption of AI across industries, has the world become complacent, siding with productivity over pragmatism? More often than not, users are blindly allowing AI to complete work for them, review sensitive documents outside the bounds of a secure environment, and make decisions without a single human checkpoint.

I know many developers who simply click "Accept" when prompted to approve terminal commands. I've spoken to professionals within my network who say "AI has evolved, it can be trusted." That ignorance and naivety is precisely what leads to the scenarios above.

The companies and individuals that will thrive in an AI-driven world aren't the ones adopting it the fastest. They're the ones adopting it the most responsibly.

Final Note

Before you click "Accept" on that next AI suggestion, ask yourself honestly: do you actually know what you're agreeing to? Don't simply outsource your thinking to something that doesn't think - it predicts.

AI isn't the danger. We are.

I’d love to hear your thoughts - comment below or drop me a follow on X/Twitter

Using Python To Merge Array of Ranges

Grant Riordan — Tue, 30 Dec 2025 22:16:48 +0000

So I was doing an Advent of Code 2025 challenge the other day, and had an issue where I needed to count all the unique numbers between multiple ranges. It reminded me of some code I'd written previously for a booking system.

The problem was that the ranges overlapped in many cases. Now, looping over all the numbers and using a set() was not feasible, nor performant as the ranges could be in the millions.

The Naïve Approach

unique_values = set()
for start, end in ranges:
    unique_values.update(range(start, end + 1))

For a range of say 1-100_000_000_000 you'd create 1 billion numbers in memory, that's huge! You're also materialising data that doesn't need to exist.

Solution - Merge First, Count Later

Instead of creating every number in memory (expensive), we merge overlapping ranges into fewer, larger ranges, then calculate the count mathematically.

Lets look at a smaller range for the purpose of this tutorial:

Let's say we have the following ranges:

3-5, 
10-14, 
16-20, 
12-18

some of them overlap or touch each other.
10-14 and 12-18 overlap (they share 12, 13, 14)

If merged, they become one range: 10-18. Without merging, you'd count numbers twice or waste memory storing every individual number.

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Sorting the arrays by their start position makes the merging a lot easier - we read from left-to-right on the number line.

sorted_ranges = sorted(fresh_ranges)
# Before: [(3,5), (10,14), (16,20), (12,18)]
# After:  [(3,5), (10,14), (12,18), (16,20)]

How does this help though? When you encounter a new range, you only need to check if it overlaps with the last merged range. There's no need to check all previous ranges. If ranges are sorted, overlaps always happen with the most recent range, saving time and effort checking other ranges.

Sorted number line view:
   3---5      10----14
              12------18
                  16----20

# You can see overlaps flow left-to-right!

Second - Merge the overlapping ranges

merged = []
for start, end in sorted_ranges:
    if merged and start <= merged[-1][1] + 1:
        # Overlaps or touches - merge!
        merged[-1] = (merged[-1][0], max(merged[-1][1], end))
    else:
        # Doesn't overlap - add as new range
        merged.append((start, end))

Why merged and start <= merged[-1][1] + 1?
This condition checks two things:

merged → Is there at least one range already merged?

First iteration: merged = [] → False, so add first range

Later: merged = [(3,5)] → True, check overlap
start <= merged[-1][1] + 1 → Does current range touch/overlap the last merged range?

Lets take a look at some examples:

# Case 1: Adjacent (touching)
Last merged: (10, 14)  # ends at 14
Current:     (15, 20)  # starts at 15
Check: 15 <= 14 + 1? → 15 <= 15? → YES! They touch

# Case 2: Gap between ranges
Last merged: (3, 5)    # ends at 5
Current:     (10, 14)  # starts at 10
Check: 10 <= 5 + 1? → 10 <= 6? → NO! Gap exists

Why + 1?

Ranges for example like (5,10) and (11,15) are adjacent. They shouldn't stay separate (gap at position 10.5). The + 1 is about merging adjacent ranges that touch, not just overlapping ones.

Example:

Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (10, 15) →  10, 11, 12, 13, 14, 15

Number line:
5--6--7--8--9--10--11--12--13--14--15
[======A======][========B========]
              ↑
          They TOUCH at position 9→10

Without +1:
Check: 10 <= 9? → NO ❌
Result: Keep separate [(5,9), (10,15)]
This is WRONG - there is no gap! They should be one range: (5,15)

With +1:
Check: 10 <= 9+1? → 10 <= 10? → YES ✅
Result: Merge to (5, 15)
This is CORRECT!

# Actual Gap
Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (11, 15) →  11, 12, 13, 14, 15

Number line:
5--6--7--8--9--(10)--11--12--13--14--15
[======A======]  GAP  [=======B=======]
              ↑      ↑
          Ends at 9  Starts at 11
          10 is missing!

With +1:
Check: 11 <= 9+1? → 11 <= 10? → NO ✅
Result: Keep separate [(5,9), (11,15)]
This is CORRECT - there's a gap at position 10

Simply, sum each range to get the total number of items within the ranges.

total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Final Code:


# Sort ranges by start position
    sorted_ranges = sorted(fresh_ranges)

    # Merge overlapping ranges
    merged = []
    for start, end in sorted_ranges:
        print(merged)
        if merged and start <= merged[-1][1] + 1:
            # Overlapping or adjacent - merge with last range
            merged[-1] = (merged[-1][0], max(merged[-1][1], end))
        else:
            # No overlap - add new range
            merged.append((start, end))

    # Calculate total count from merged ranges
    total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Real Life Usages:

There are many scenarios in real life where you may need to handle multiple ranges needing merged, or to be counted;

For example:

Appointment Booking Systems:

Meeting A: 9:00 AM - 10:30 AM
Meeting B: 10:15 AM - 11:00 AM  
Meeting C: 2:00 PM - 3:30 PM
Meeting D: 3:30 PM - 5:00 PM

Sorted: [(9:00, 10:30), (10:15, 11:00), (2:00, 3:30), (3:30, 5:00)]

Merged: [(9:00, 11:00), (2:00, 5:00)]
         ↑               ↑
   Meetings A+B overlap  Meetings C+D touch (adjacent)

Free times: Before 9:00, 11:00-2:00, After 5:00

When is the room actually free?

IP Address Blocking

Block: 192.168.1.0 - 192.168.1.50
Block: 192.168.1.45 - 192.168.1.100
Block: 192.168.1.200 - 192.168.1.255

Without merging, check 3 rules for every connection.
With merging -
[(192.168.1.0, 192.168.1.100), (192.168.1.200, 192.168.1.255)]

Only 2 rules to check = Faster firewall!

Maintenance Downtime

Server or Machine scheduled for maintenance:

Maintenance A: Hour 0-5
Maintenance B: Hour 4-8
Maintenance C: Hour 20-24

Merged downtime: [(0, 8), (20, 24)]
Total downtime: 8 + 4 = 12 hours (not 17 if counted individually)

Why This Matters in All Cases:

Avoid double-counting overlapping periods
Optimise checks - fewer ranges to search
Find gaps - available time slots
Accurate reporting - real busy vs. free time
Performance - checking fewer merged ranges vs. many overlapping ones

Conclusion

The above pattern / method is used by multiple companies around the globe, handling calendar invites, database indexing, network traffic analysis and much more.

Go ahead, use the above code to increase your applications performance.

If you want to chat, or reach out don't hesitate to comment below, or drop me a follow on x/twitter.

Spread Operator and Chaining in JS/TS

Grant Riordan — Tue, 30 Sep 2025 13:39:09 +0000

Hey, so I’m sometimes asked how the spread operator works in JS especially when working with chained statements.

Some confuse the ... (spread) operator as applying to the first element of the chain, spreading the variable before applying chained functions.

This isn’t correct; it applies to the result of the chain.

Take this code:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length)
  );
};

Some may think it spreads the sentence variable first then applies the other chained functions, which you would be right in thinking would throw an error.

However, due to the way that JS works the . operator is seen as what's called a primary expression, meaning it takes *precedence * over every other operator.

This would be the same as if you wrote your code like this, wrapping your statement in brackets:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...(sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length))
  );
};

But fortunately for us these extra brackets aren't needed due to the . expression precedence.

So in fact what the code is doing is:

Replace all . in a string.
Split the result on spaces.
Return the length of each word.
Spread the lengths array to Math.max()

Code is read left to right, treating the chain as a single variable / element - so no need to wrap our statement in extra brackets.

Hope this helps 😁 - did you know this?

C# LeetCode 268: Missing Number - (Easy)

Grant Riordan — Thu, 25 Sep 2025 20:46:18 +0000

LeetCode 268: Missing Number

This problem gives you an array of distinct numbers ranging from 0 to n, with one number missing. Your task is to find that missing number.
At first, I misread the instructions — I assumed the highest number would be the array's maximum value, not realizing that n is both the length of the array and the upper bound of the range [0, n]. That realisation changed everything for me.

Solution

To solve this, we can use a well-known mathematical formula known as Gauss's formula. It calculates the sum of the first n natural numbers:

Sum = n * (n + 1) / 2

This works because you can pair numbers in the sequence so that each pair adds up to the same value, take the numbers between 1 and 100:

1 + 100 = 101  
2 + 99  = 101  
3 + 98  = 101  
...

n is multiplied by the number of possible pairings (n + 1). Then as we're doing pairings we need to half this number.

So, if the array had no missing number, its sum would match this formula. But since one number is missing, the actual sum of the array will be less than the expected sum.

Thus, the missing number is simply:
Missing = Expected Sum - Actual Sum

Code

public int MissingNumber(int[] nums)
{
    int n = nums.Length;
    int expectedSum = n * (n + 1) / 2;
    int actualSum = 0;

    foreach (int num in nums)
    {
        actualSum += num;
    }

    return expectedSum - actualSum;
}

Example Walkthrough


var numbers = [0, 3, 1];

# sum of all numbers
0 + 3 + 1 = 4

## all numbers added up using Gauss
# 0 -> 3
n = 3
3 * (3 + 1) / 2 = 6

So we can then subtract 6 (Gauss sum) - 4 (actual sum) = 2

So the missing number would be 2.

LeetCode 8: String to Integer (atoi) - Medium

Grant Riordan — Sun, 21 Sep 2025 20:58:52 +0000

Mastering LeetCode 8: String to Integer (atoi)

A Simple and Efficient Solution

LeetCode's String to Integer (atoi) is a classic medium-difficulty coding problem that challenges you to convert a string representation of a number into an actual integer. While it sounds straightforward, the problem comes with a few twists: you need to handle leading whitespace, account for positive or negative signs, and ensure the result stays within the 32-bit signed integer range.

In this post, I'll walk you through a highly efficient solution that achieves:

0ms runtime (beating 100% of submissions)
41.85MB of memory (better than 50% of submissions)

Understanding the Problem

The goal is to take a string, such as " -42", "4193 with words", or "+123", and convert it into an integer, like -42, 4193, or 123. Here are the key requirements

Ignore leading whitespace: Skip any spaces at the start of the string.
Handle signs: Recognise + or - to determine if the number is positive or negative.
Stop at invalid characters: If you encounter a non-digit (other than the initial sign), stop processing.
Respect 32-bit integer bounds: If the result exceeds the 32-bit signed integer range (-2^31 to 2^31 - 1), return the appropriate boundary value (-2^31 or 2^31 - 1).
Default to 0: If the string is empty or contains no valid digits, return 0.

My Approach: Simple and Fast

I designed a solution that prioritises efficiency by working directly with the string's characters and using indexing to avoid unnecessary operations. Here's the step-by-step approach:

Check for Empty Input: If the string is null or empty, return 0.
Skip Whitespace: Loop through the string to bypass leading spaces, avoiding methods like .Trim() to reduce overhead.
Handle the Sign: Assume the number is positive by default (sign = 1). If a + or - is found, update the sign variable and move to the next character.
Build the Number: Process each digit character, converting it to its numeric value and building the result incrementally. Stop if a non-digit is encountered.
Check Bounds: As the number is built, ensure it stays within the 32-bit integer limits, clamping to int.MaxValue or int.MinValue if necessary.
Apply the Sign: Multiply the result by the sign to get the correct positive or negative value.

This approach is clean, avoids heavy string operations, and handles all edge cases efficiently.

The Code

class Solution
{
    public int MyAtoi(string s)
    {
        // Handle null or empty string
        if (string.IsNullOrEmpty(s)) return 0;

        int idx = 0, end = s.Length;

        // Skip leading whitespace
        while (idx < end && s[idx] == ' ') idx++;
        if (idx == end) return 0; // Return 0 if only whitespace

        // Check for sign
        int sign = 1; // Default to positive
        if (s[idx] == '+' || s[idx] == '-')
        {
            sign = (s[idx] == '-') ? -1 : 1; // Set sign based on + or -
            idx++;
        }

        int result = 0;
        // Process digits
        while (idx < end && char.IsDigit(s[idx]))
        {
            // Convert character to digit (e.g., '5' -> 5)
            int digit = s[idx] - '0';

            // Check for overflow before adding digit
            if (result > (int.MaxValue - digit) / 10)
            {
                return sign == 1 ? int.MaxValue : int.MinValue;
            }

            // Build number: multiply by 10 and add new digit
            result = result * 10 + digit;
            idx++;
        }

        // Apply sign to get final positive or negative result
        return result * sign;
    }
}

How It Works

Whitespace Handling: The while (idx < end && s[idx] == ' ') loop skips leading spaces. If the string contains only whitespace, we return 0.

Sign Detection: We default to sign = 1 (positive). If a + or - is found, we set sign to 1 or -1 and advance the index (so the index will be at the first character).

Number Building: For each digit, we convert the character to its numeric value (e.g., '5' - '0' = 5). We build the number by multiplying the current result by 10 and adding the new digit (e.g., for "123", we do 0*10 + 1 = 1, 1*10 + 2 = 12, 12*10 + 3 = 123).

Overflow Check: Before adding a digit, we check if result * 10 + digit would exceed int.MaxValue. If so, we return int.MaxValue or int.MinValue based on the sign.

Final Sign Application: Multiplying result by sign ensures the correct positive or negative output (e.g., 123 * -1 = -123).

Hope this has helped, as always give me a follow, or drop me a line on twitter/x

LeetCode 206: Reverse Linked List - (Easy)

Grant Riordan — Tue, 16 Sep 2025 13:37:28 +0000

Given the head of a singly linked list, reverse the list, and return the reversed list.

Approach & Solution

We reverse a linked list by keeping track of two pointers: prev (the previous node) and curr (the current node). At each step, we:

Save the next node so we don’t lose track of the list.
Reverse the current node’s pointer to point to prev.
Move prev forward to curr.
Move curr forward to the saved next node.

We continue until curr is null, meaning we’ve processed all nodes. At that point, prev will be the new head of the reversed list.

Code

ListNode ReverseList(ListNode head)
{
ListNode prev = null;
ListNode curr = head;

while (curr != null)
{
    ListNode nextNode = curr.next;
    curr.next = prev;
    prev = curr;
    curr = nextNode;
}

return prev; // new head

}

Extension Members: My New Favourite Feature in C# 14

Grant Riordan — Fri, 12 Sep 2025 18:49:31 +0000

The release candidate of .Net10 was released on the 9th September [2025], which comes with C# 14, and with that comes one of my favourite features, Extension Members

The Concept

The new extension keyword defines an extension scope; a block where you declare which type your extension methods apply to. All methods inside that scope automatically extend the specified type.

Before and After

Current Implementation

So up until C# 14 you would declare an extension method like this:

public static class StringExtensions
{
    public static string ToTitleCase(this string input) =>
         CultureInfo.CurrentCulture.TextInfo.ToTitleCase(input.ToLower());
}

It can be cumbersome, and to some junior developers it may not be obvious that the method is an extension method. You would have to know that static + this = extension.

The New Way

Firstly you declare your extensions scope using the new extension keyword:

public static class StringExtensions
{
   extension(string text)
   {
      // extension methods go here
   }
}

This replaces the (this string text) syntax, now all methods within this block apply to this type. The new syntax makes declaring all your extensions for this type much cleaner and tidier.

Let's add some basic extensions to show you the concepts:

public static class StringExtensions
{

    extension(string text)
    {
        public string ToTitleCase() =>
            CultureInfo.CurrentCulture.TextInfo.ToTitleCase(text.ToLower());

        public bool IsPalindrome() =>
            text.SequenceEqual(text.Reverse());
    }

}

The examples above show just how easy it is to now declare multiple extension methods on the same type, because we can just use the scoped variable text , rather than having to redefine it each time with this.

Shorter Method Declarations:

// before
public static class DateTimeExtensions
{
    public static bool IsWeekend(this DateTime date) =>
        date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

//after
public static class DateTimeExtensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() =>
            date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;

        public bool IsBusinessHours() =>
            date.Hour is >= 9 and < 17 && !date.IsWeekend();
    }
}

Extensions Can Easily Be Grouped

Before C# 14, you might see a single Helpers class like this:

public static class Extensions
{
    // for DateTime
    public static bool IsWeekend(this DateTime date) { … }

    // for collections
    public static bool HasDuplicates<T>(this IEnumerable<T> items) { … }

    // for strings
    public static string ToTitleCase(this string text) { … }

    // and so on...
}

The problem with this approach:

Hard to maintain– Over time, these Helpers classes can balloon to 500–1,000+ lines of mixed methods, making it difficult for developers to find what they need. – One file can contain extensions for multiple unrelated types.

Before C# 14	After C# 14
Helpers.cs (mixed types)	Extensions.cs (type-scoped)
- DateTime extensions	- extension(DateTime date) { … }
- IEnumerable extensions	- extension(IEnumerable items) { … }
- string extensions	- extension(string text) { … }
- Random other methods	… neatly grouped per type

Let's take a look how the code may look with the new groupings:

public static class Extensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() {...}

        public bool IsBankHoliday() {...}

        public bool FormatIsoDate() {...}
    }

    extension(IEnumerable<T> items)
    {
        public bool HasDuplicates() {...}
    }

    extension(string text)
    {
        public string ToTitleCase() {...}
    }
}

That means:

*Natural grouping by type *– all string extensions must sit inside the extension(string) scope, all DateTime ones inside extension(DateTime).

Prevents mixing unrelated stuff– you literally cannot write a string extension in the DateTime scope. The compiler enforces it.

Cleaner discoverability– IDEs and developers now know exactly where to look. If you collapse your editor, you’ll see one extension(string) block, one extension(DateTime) block, instead of a 500+ line god like class of random extensions.

Before, people dumped everything into Helpers.cs.

Now, even if your team of developers decides to keep a single file called Extensions.cs, the syntax itself enforces organisation by type, so it’s much less likely to create a “misc soup” of extensions scattered around the file.

We Now Have Extension Properties !

New in C#14 we no longer just have to have extension methods, we can now utilise extension properties. Meaning without huge refactors, or updating multiple places you can easily add Extension properties, to compute results.

For example:

extension<T>(IEnumerable<T> source)
{
    public bool IsNullOrEmpty => source == null || !source.Any();
}

You now have a IsNullOrEmpty property which will be attached to every IEnumerable type within your code base.

So you can do things like:

    List<string> names = ["Grant Green", "Roger Red", "Bianca Blue"];

    // Before (method style)
    if (names.IsNullOrEmpty())
    {
        Console.WriteLine("No names found!");
    }

    // After C# 14 (property style)
    if (names.IsNullOrEmpty)
    {
        Console.WriteLine("No names found!");
    }

I think you'll agree using a property instead of a method makes the code read like it's part of the type itself. It's cleaner, easier to read, and removes the mental overhead of remembering parentheses for simple checks.

Final thoughts

C# 14’s extension members are a small language change with a big impact!

They enforce better organisation by type, reducing the mess of “miscellaneous helpers” spread across static classes.

Extension properties make your APIs feel more natural, allowing boolean checks and computed values to read like first-class members of the type.

Overall, your code becomes cleaner, more discoverable, and easier for teams to maintain.

While the compiler doesn’t stop you from scattering extensions across multiple classes, using a consistent type-scoped approach helps keep your codebase tidy and readable.

In short: if you frequently write helper methods or utilities, C# 14 extension members are worth adopting — they make your codebase feel more structured and your extensions feel like they belong.

Which types do you most often extend in your projects? I’d love to hear your thoughts in the comments or drop me a follow on twitter/x to hear when I post more articles like this on DevTo and FreeCodeCamp.

C# LeetCode 1792: Maximum Average Pass Ratio - (Medium)

Grant Riordan — Thu, 04 Sep 2025 18:14:59 +0000

LeetCode 1792: Maximum Average Pass Ratio - (Medium Difficulty)

Intuition

Needed a way to determine which class would yield the best return on adding the extra students.

Best way to track this in my mind would be tracking a Priority, so a PriorityQueue would be ideal for this scenario. A PriorityQueue lets us always select the class with the current highest gain efficiently in O(log n) time per operation.

Approach

Populate the queue with initial values and the gain in pass ratio from adding one student to each class.
For each student, take the class with the highest gain from adding one more passing student.
Loop over the priority queue adding up all the ratios and divide by number of classes to get the average ratio.

Example

Let's say you have two classes:

Class	Pass	Total	Initial Gain from 1 Student
A	1	2	0.1667
B	3	5	0.0667

First assignment:

Class A has higher gain → gets 1 student → now A = [2,3]

Next round:

New gain for A:
(3/4) - (2/3) = 0.75 - 0.6667 = 0.0833

Class B still has gain:
(4/6) - (3/5) = 0.6667 - 0.6 = 0.0667

→ A still has higher gain (0.0833 vs 0.0667), so gets another student.

Now A = [3,4]

Third round:

Gain for A now:
(4/5) - (3/4) = 0.8 - 0.75 = 0.05

Class B gain is still 0.0667

✅ Now B has higher gain — it gets the next student.

When solving this problem, you might wonder:

“Aren’t we already adding one extra student when we calculate the initial gain? Then adding more? Isn’t that overcounting?”

The answer is no — and here’s why.

The iniital gain is just a prediction. When we calculate the gain for a class:

Gain(pass, total) = Ratio(pass + 1, total + 1) - Ratio(pass, total)

We're not actually adding a student.
We're just asking a "what if" question:

“If I gave one extra passing student to this class, how much would its pass ratio improve?”

This helps us prioritize which class would benefit the most if it were chosen next.

Code

public class Solution {
    public double MaxAverageRatio(int[][] classes, int extraStudents)
    {
        var pq = new PriorityQueue<(int pass, int total), double>(
            Comparer<double>.Create((a, b) => b.CompareTo(a))
        );

        // Populate the queue with initial values
        foreach (var cls in classes)
        {
            var pass = cls[0];
            var total = cls[1];
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // Distribute extra students
        for (var i = 0; i < extraStudents; i++)
        {
            var (pass, total) = pq.Dequeue();
            pass++;
            total++;
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // After distribution, calculate final average
        double sum = 0;
        while (pq.Count > 0)
        {
            var (pass, total) = pq.Dequeue();
            sum += CalculateRatio(pass, total);
        }

        return sum / classes.Length;
    }

    double CalculateRatio(int pass, int total)
    {
        return (double)pass / total;
    }

    double Gain(int pass, int total)
    {
        var current = CalculateRatio(pass, total);
        var after = CalculateRatio(pass + 1, total + 1);
        return after - current;
    }
}

LeetCode 168: Excel Sheet Column Title (Easy)

Grant Riordan — Sat, 30 Aug 2025 17:00:11 +0000

Approach

This problem is essentially a base-26 conversion, where the "digits" are the 26 letters of the alphabet (A–Z).

Like any base conversion, we process the least significant digit first — meaning we figure out the last letter of the result before the first.

Use the modulo operator (% 26) to find the remainder, which tells us the current character.
Insert each character at the front of the string (or reverse later), since we’re building the result from right → left.
After each step, divide columnNumber by 26 to move on to the next "digit."
Important: decrement columnNumber at the start of each loop (columnNumber--) because Excel columns are 1-based, while our alphabet mapping is 0-based.

Example Flow (columnNumber = 28)

Iteration 1

Input: 28
columnNumber-- → 27
Remainder: 27 % 26 = 1
Character: 'A' + 1 = 'B'
Result: "B"
Update columnNumber: 27 / 26 = 1

Iteration 2

columnNumber-- → 0
Remainder: 0 % 26 = 0
Character: 'A' + 0 = 'A'
Result: "AB"
Update columnNumber: 0 / 26 = 0 → stop

✅ Final result = "AB"

We can verify manually:

27 = 1 full cycle (A → Z) + 2 more columns (AA, AB).

Code


csharp
public class Solution {
    public string ConvertToTitle(int columnNumber) {
        var result = new StringBuilder();

        while (columnNumber > 0) {
            columnNumber--; // shift into 0-based
            int remainder = columnNumber % 26;
            result.Insert(0, (char)('A' + remainder));
            columnNumber /= 26;
        }

        return result.ToString();
    }
}

DEV Community: Grant Riordan

TypeScript Fundamentals, Part 3: Reusable Types

Generics

The problem

The solution

Generic types and interfaces

Constraints

Utility Types

Enums vs Literal Unions

Enums

Literal unions

as const objects: when you need the values at runtime

Which should you use?

Putting It Together

Wrapping Up

Continue the Series

TypeScript Fundamentals, Part 2: Writing Safer Code

Type Inference: Let TypeScript Do the Work

When to annotate

Strict Mode and tsconfig.json

any, unknown and never

any: switching the checker off

unknown: the safe alternative

never: the type with no values

Narrowing and Type Guards

typeof: for primitives

instanceof: for classes

in: for checking a property exists

Equality and truthiness

Discriminated unions

Custom type guards

Escape Hatches: as and !

Types disappear at runtime

Wrapping Up

Continue the Series

TypeScript Fundamentals, Part 1: Describing Your Data

TypeScript Fundamentals, Part 1: Describing Your Data

What is TypeScript?

Interfaces & Types

Interfaces

Optional and readonly properties

Types

A Quick Detour: Structural Typing

Where Interfaces and Types Differ

Declaration merging

What they can describe

Extending

Classes

Which Should You Use?

Unions, Literal Types & Tuples

Unions

Literal types

Discriminated unions

Tuples

Wrapping Up

Continue the Series

AI Can Not Be Left Unsupervised

Other Damaging Cases

Final Note

Using Python To Merge Array of Ranges

The Naïve Approach

Solution - Merge First, Count Later

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Second - Merge the overlapping ranges

Lets take a look at some examples:

Final Code:

Real Life Usages:

Appointment Booking Systems:

IP Address Blocking

Maintenance Downtime

Why This Matters in All Cases:

Conclusion

Spread Operator and Chaining in JS/TS

C# LeetCode 268: Missing Number - (Easy)

Solution

Code

Example Walkthrough

LeetCode 8: String to Integer (atoi) - Medium

A Simple and Efficient Solution

`as const` objects: when you need the values at runtime

Strict Mode and `tsconfig.json`

`any`, `unknown` and `never`

`any`: switching the checker off

`unknown`: the safe alternative

`never`: the type with no values

`typeof`: for primitives

`instanceof`: for classes

`in`: for checking a property exists

Escape Hatches: `as` and `!`