DEV Community: Tamara Jordan

I enjoy programming

Tamara Jordan — Sat, 14 Feb 2026 08:00:00 +0000

I vividly remember interviewing for my second software developer job and being asked "what technologies are you interested in right now?"

My answer was something like "I'm not really that interested in technology, I'm more interested in what can be done with it". With the rise of AI, I've realised I was wrong, or at least partially.

Going back many years, I was always interested in computers, fueled by the desire to bypass restrictions so I could play Runescape and other online games on our home computer. I infected it with malware and ransomware a handful of times trying to use "free coin generators" for Habbo Hotel, and so learned to clean things up quickly with the hope that no one would notice.

In secondary school, my IT teacher Mr Alam encouraged me to join CC4G (computer club for girls), and that's where I got my first exposure to programming. I remember being very excited after making my first website using Adobe Dreamweaver - a page with a vomit green background that's now lost to time.

Later, my interest drew me towards an IT support apprenticeship. It was a bleak experience in general, but I was also bothered by the repetitive nature of some of my tasks, like setting up new users and email accounts, and doing weekly checks on our remote servers. One day I asked if we could automate some of it and the response was a shocked and disapproving "you want to run scripts? on our production servers?!".

Safety first, amirite?

I took a couple of months off between my first and second IT support jobs and learned basic programming through the website "Automate the Boring Stuff with Python". I mostly wrote little scripts and my "biggest" project at the time was a Flappy Bird clone built using Kivy which I probably left unfinished.

However at my second IT job, I wrote my first program as a means to an end. During a quiet 2 week period at work, 3 of us were supposed to go through a list of a few hundred ex-customers and remove them from our ticketing system. Probably dreading the idea of spending such a significant time on that, I said I could automate it. And I did - not particularly well, but I got the job done. That's when I thought "maybe I can get paid to do this instead".

That was 10 years ago and since then I've been involved in automating processes, building and contributing to a number of websites and apps both greenfield and legacy alike. But strictly outside of work and work-adjacent purposes, I've never finished a project.

That may be a shock to some, and not to others. My partner is confused by it, given I spend at least a few hours each weekend programming. He'll ask "how's your game going?" and I'll respond "I haven't really been working on it", while he peers over my shoulder at code, trying to figure out what I'm actually working on, if not the game.

All along I thought I enjoyed being a software developer because it allowed me to solve my, and other peoples problems. But as it turns out, I actually enjoy being a software developer because I love programming.

I enjoy solving technical problems, and figuring out what strategies I can employ to make my solutions better. I like taking the time to understand how things work under the hood. For example, I wanted to experiment with different testing strategies for my game which has led me to spend months developing my own Property Based Testing library. I've been reading lots of documentation, books and even research papers about the subject. And I'm not doing it for the sake of completion, or open sourcing it (although if I get that far, I might). I'm just doing it because I want to understand the design choices and considerations that go into building such a thing.

If I cared about finishing my game, I wouldn't have created 5 different incomplete versions of it over the last 4 years. I don't care about finishing the game, I don't want to finish it - I'm using it as a vehicle to learn about the software engineering topics I'm interested in. I'm scratching the itch and getting better at my craft while doing so.

I am a bit fearful that AI is coming for the part of my job that I actually love, and that once it's gone I'll just be left with the bits I simply tolerate. Maybe it won't, or maybe I'll be able to cope in some way that still allows me to do the fun bits from time to time. Who knows what will happen. However it goes, I'm glad that I got paid to do something I enjoy for a pretty long time.

DTO - A typescript utility type

Tamara Jordan — Wed, 17 Feb 2021 09:23:19 +0000

Dto (Data Transfer Object) is a TypeScript utility type that can be used to represent an object that is going "over the wire". It's meant to be used at the boundaries of an application. You can find the code at https://github.com/tamj0rd2/dto and at the bottom of this post.

What problem does it try to solve?

In Javascript, sending objects via network requests is generally pretty easy, but a problem arises when making use of classes. Take the following example using a Date

Here's some client side code that tries to create a Post via the endpoint /api/posts:

interface Post {
  author: string
  title: string
  datePublished: Date
}

const post: Post = {
  author: 'tamj0rd2',
  title: 'Something about TypeScript',
  datePublished: new Date()
}

await fetch('/api/posts', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify(post)
})

Let's take a look at how we're handling this request on the server side:

import express from 'express'

const app = express()
app.use(express.json()) // parses our request body into JSON

app.post<unknown, unknown, Post>('/api/posts', (req, res) => {
  // if you were to hover your mouse over datePublished below, your IDE would say its type is Date
  console.log(`The type of datePublished is '${typeof req.body.datePublished}'`)
  res.writeHead(201).end()
})

app.use((_, res) => res.sendStatus(404))
app.listen(8080, () => console.log('server listening on http://localhost:8080'))

If you thought the output of that console log line might say the type of datePublished is object, you'd be wrong. The actual type is string. Remember, the post was stringified on the client side and then parsed back into an object on the server side. In Javascript, the stringified result of a Date is a string and the parsed result of a string is... a string.

Date isn't the only class whose stringified structure is different to what you might expect. Set and Map don't stringify in a way you'd expect at all.

JSON.stringify(new Set([1, 2, 3])) // outputs "{}" but what I actually want is "[1, 2, 3]"

const myMap = new Map<string, string>()
myMap.set('Hello', 'World')
JSON.stringify(myMap) // outputs "{}" but what I actually want is "{"Hello":"World"}"

So although we've told our request handler that the request body should be of type Post, it isn't actually true. This would be more accurate:

interface PostDto {
  author: string
  title: string
  datePublished: string
}

app.post<unknown, unknown, PostDto>('/api/posts', (req, res) => {
  console.log(`The type of datePublished is '${typeof req.body.datePublished}'`)
  res.writeHead(201).end()
})

Why do I care about the accuracy of these types? They've helped to catch bugs in multiple codebases I've contributed to. One common case is trying to call functions on something you think is a Date but is actually a string. I like these types to be accurate for the same reason that I like TypeScript. It helps me catch bugs sooner rather than later.

But I don't want to write and maintain two different versions of an interface >:(

Well that's what the Dto utility type attempts to solve! The examples I'm showing in this post are so small that you might be wondering why I'm bothered by it. I've faced the pain of rewriting interfaces with dozens of properties and/or nested objects. It's time consuming and I don't like doing it. Once you have two interfaces you also have to maintain them and keep them in sync whenever you add, remove or change the types of properties.

What the Dto utility type doesn't do is serialize or validate your data. It's just a type. It can't do serialization or validation for you because it doesn't exist at runtime. You're still responsible for getting your code from it's "initial" type to it's "Dto-ified" type.

Example usage

app.post<unknown, unknown, Dto<Post>>('/api/posts', (req, res) => {
  res.writeHead(201).end()
})

In this example, instead of having to write out another interface for our "over the wire" version of a Post, we're just using the Dto utility type. Dto<Post> is equivalent to the PostDto interface we wrote out earlier.

Show me the money

Here it is! Although the most up to date version can always be found here

type IsOptional<T> = Extract<T, undefined> extends never ? false : true
export type Func = (...args: any[]) => any
type IsFunction<T> = T extends Func ? true : false
type IsValueType<T> = T extends
  | string
  | number
  | boolean
  | null
  | undefined
  | Func
  | Set<any>
  | Map<any, any>
  | Date
  | Array<any>
  ? true
  : false

type ReplaceDate<T> = T extends Date ? string : T
type ReplaceSet<T> = T extends Set<infer X> ? X[] : T
type ReplaceMap<T> = T extends Map<infer K, infer I>
  ? Record<
      K extends string | number | symbol ? K : string,
      IsValueType<I> extends true ? I : { [K in keyof ExcludeFuncsFromObj<I>]: Dto<I[K]> }
    >
  : T
type ReplaceArray<T> = T extends Array<infer X> ? Dto<X>[] : T

type ExcludeFuncsFromObj<T> = Pick<T, { [K in keyof T]: IsFunction<T[K]> extends true ? never : K }[keyof T]>

type Dtoified<T> = IsValueType<T> extends true
  ? ReplaceDate<ReplaceMap<ReplaceSet<ReplaceArray<T>>>>
  : { [K in keyof ExcludeFuncsFromObj<T>]: Dto<T[K]> }

export type Dto<T> = IsFunction<T> extends true
  ? never
  : IsOptional<T> extends true
  ? Dtoified<Exclude<T, undefined>> | null
  : Dtoified<T>

export type Serializable<T> = T & { serialize(): Dto<T> }

Since I wrote this I've learned more about Typescript and there is definitely some room for improvement, but hopefully someone else will get some use out of this. I'm planning to follow this up with another post on how I wrote the utility type and how I made sure I didn't break it as I added more functionality. Types are fiddly!

In the meantime, you can learn more about a lot of the tools that went into creating this type using the TypeScript utility types documentation and this blog post on Conditional types. I can't recommend that post enough.

Why I've started using namespaces in Typescript

Tamara Jordan — Sat, 13 Feb 2021 15:15:13 +0000

Typescript has these things called namespaces. To cut to the chase, namespaces offer a way to group things up. You can find out some information about what they are and how to use them here.

I've known about their existence for quite some time but until recently, I didn't think I had a reason to use them. There are already so many other ways you can group things up.

You can group things up using objects:

export const CustomMath = {
  add(a: number, b: number) {},
  subtract(a: number, b: number) {},
}

You can group things up using classes:

export class CustomMath {
  public static add(a: number, b: number) {}

  public static subtract(a: number, b: number) {}
}

You can group things up using wildcard imports:

// customMath.ts
export function add(a: number, b: number): void {}

export function subtract(a: number, b: number): void {}

export type Range = { lower: number; upper: number }

// anotherFile.ts
import * as CustomMath from './customMath'

const myRange: CustomMath.range = { ... }

With this solution, you can also include types/interfaces within the grouping. As far as I'm aware that isn't possible with the previous 2 methods.

One thing I don't like about wildcard imports is that it's still possible to import each of those functions individually. There's nothing in place to stop people from doing this. Straggler functions (and types) that seem like they would be better off being logically grouped annoy me a bit.

Namespaces

// customMath.ts
export namespace CustomMath {
  export function add(a: number, b: number): void {}

  export function subtract(a: number, b: number): void {}

  export type Range = { lower: number; upper: number }
}

// anotherFile.ts
import { CustomMath } from './customMath'

const myRange: CustomMath.range = { ... }

You can still access functions, constants, types and interfaces that are exported from your namespace, but now they're grouped nicely under a single import. Bliss.

There are drawbacks to using namespaces, some of which have been mentioned here. There are also other ways to avoid the minor annoyances I've mentioned in this post. One way is to make better use of index files. This is something I've done in personal projects and it works well for me, however it seems like too much of a manual effort to convince my colleagues to try this. Namespaces will be my go-to in situations where objects or classes aren't more appropriate.