DEV Community: Josiah Nunemaker

There will still be art in software

Josiah Nunemaker — Tue, 05 May 2026 21:47:47 +0000

Originally published on josnun.com

Larger groups gaining access to tools and capabilities that were previously exclusive to the elite is no new phenomenon. Books and literacy, photography, manufacturing (eg, 3D printing), and computing are all examples of capabilities that used to be out of reach of the average person, but are now commonplace. With the advent of AI, the next capability to become democratized is seemingly software.

With each of these shifts, there have been some naysayers declaring that giving "commonfolk" these tools will destroy the craft, wipe out an entire category of jobs, spoil the capabilities, or otherwise lead to the destruction of society as we know it. To some extent, this holds true, but broadly speaking, the democratization has enabled new opportunities for the common man, while still making space for those who excel at their craft. Just because everyone has a phone with a camera doesn't mean there isn't a place for photographers. Their understanding of composition and what makes a good photo is what sets them apart. That's only learned through effort, practice, study, and more practice. One doesn't become an expert photographer just because they have a camera.

The same will hold true for software. AI makes building software seem easy. And that's great. I'm all for a whole army of people building software that meets their needs, and frees them up to do the work that sets them apart; whether that's getting better at their job, hobbies, or spending time with their families and communities. Quality software is hard to build, though. There's a difference between something that "works" and something that works well. The differentiator is quality and attention to detail. Good software is more than just some code slung on a page. There's design, UX, discovering what doesn't work, iteration. Using it, and discovering that what you thought you wanted isn't what you actually wanted; what doesn't "feel" right. On some level, there's an intuition that you build after doing the reps of building software. It's learning when to trust your intuition, and when you need to prove it.

Everyone having the capability to build software is a good thing. There are whole categories of software that would be nice to have, but aren't financially viable to build a business around. Let the people build it themselves. There may be some people out there whose expertise in other disciplines have made them masters of building good software, but the high barrier to entry has kept them away. People have ideas. Maybe their ability to execute on those ideas will unlock whole new categories of tools and software. I expect that, just like with books, software that has had heart and soul poured into it and is a cut above the rest will rise to the top, raising software quality for everyone.

When everyone can produce, quality becomes the differentiator. Great software makes you feel things; it's art. That's why I'm hopeful. There's a certain joy that I've been able to unlock by building what lives in my imagination, and I'm excited to see that joy come to others. Will this transition be smooth? I doubt it. I'm sure there will be rough spots and setbacks, but the promise of a new class of software and the potential for refined craft still leaves me optimistic.

You don't need TypeScript's index types (probably)

Josiah Nunemaker — Tue, 22 Oct 2019 00:27:03 +0000

Originally posted on JosNun.com

TypeScript's index types seem super useful when you first find out about them. If you aren't familiar with index types, here's a crash course example:

interface StringArray {
  [key: number]: string;
}

const arr: StringArray = {
  0: 0,
  1: 'one',
  2: 'two',
  [Math.PI]: Math.PI,
  // This isn't valid
  'three': 'three'
};

As you can see, StringArray in our example allows any number to be a property name (key), and any string to be a value.

Index types are really handy when you have an object that could have unknown keys. They're also handy when using an object as a dictionary or associative array. They do have some downsides, though. You can't specify what keys can be used, and the syntax is also a bit verbose, in my opinion. TypeScript provides a solution, however; the Record utility.

In it's simplest form, Record is very similar to an index type. Let's give it a look:

type StringArray = Record<number, string>;

const arr: StringArray = {
  0: 0,
  1: 'one',
  2: 'two',
  [Math.PI]: Math.PI,
  // This isn't valid
  'three': 'three'
};

Like with the index type, arr can have any number as a key, and any string as a value. For a simple example like this, Record merely does some cleanup. There are some things that Record can do, that index types can't very easily, however. One such example is specifying which keys are allowed with a union type.

// Ain't gonna work
interface TypedKeys {
    // An index signature parameter type must be 'string' or 'number'
    [key: 0 | 1]: string;
}

// Works, but is verbose
interface TypedKeys {
    0: string;
    1: string;
}

// Works, and is nice and concise
type TypedKeys = Record<0 | 1, string>;

const arr: TypedKeys = {
  0: '0',
  1: 'one',
  // Object literal may only specify known properties, and '2' does not exist in type 'Record<0 | 1, string>'
  2: 'two',
};

You could also use a more advanced type for the value of a Record as well. At first glance, there may be some downsides. It isn't immediately obvious how you could have some predefined keys, like with an index type. Nevertheless, it's still doable, though maybe not as elegant as with an index type.

interface TypedKeys {
    0: 'zero'
    [key: number]: string;
}

// Same as above
type TypedKeys = Record<number, string> & {
    0: 'zero';
};

const arr: TypedKeys = {
  0: '0',
  1: 'one',
  2: 'two',
  3: 'three'
};

So there you have it, that's TypeScript's Record utility! Hopefully you'll find new ways to use it to make your code more readable and concise.

Key takeaways

Maybe a bit of pun intended

Record is, in it's simplest form, an easier to read version of index types
It makes specifying the keys and values much easier when you have complex types
Fewer characters = quicker to type for most people
Record works well with intersection and union types

Thoughts? Questions? Let me know in the comments!

Also, I've been thinking about doing regular posts on handy TypeScript utilities or features. If you think you'd find that useful or interesting, let me know in the comments as well!

What is TypeScript's Exclude?

Josiah Nunemaker — Thu, 05 Sep 2019 00:24:40 +0000

Originally posted on JosNun.com

I'm going to be honest, here. I love TypeScript, but some of the docs for their utility methods aren't that great. Thankfully, they have examples, but sometimes, even those aren't that helpful. Exclude is one of those utility methods that always had an air of ambiguity around it for me, but recently I did some research, and what I found makes writing some types so much cleaner.

So what does exclude do? Well, here's what the docs say:

Exclude<T, U>: Constructs a type by excluding from T all properties that are assignable to U.'

Not terribly descriptive, but at least it points us in the right direction. In my opinion, the type definition of Exclude is much more helpful.

type Exclude<T, U> = T extends U ? never : T;

A simple way of putting it is that if TypeA is a subtype of TypeB, it gets removed. Here's an example:

interface Widget {
  doesStuff: boolean;
}

type Doodad = number | string | symbol | object | Widget;

type PropertyAccessor = Exclude<Doodad, object>; // string | number | symbol
type ExcludeWidget = Exclude<Doodad, Widget>; // string | number | symbol | object;

const string: PropertyAccessor = 'key';
const number: PropertyAccessor = 3;
const symbol: PropertyAccessor = Symbol();

const obj: PropertyAccessor = {}; // Type '{}' is not assignable to type 'symbol'
const widget: PropertyAccessor = {
  doesStuff: true,
}; // Type '{ doesStuff: boolean; }' is not assignable to type 'string | number | symbol'

const obj2: ExcludeWidget = {};
const widget2: PropertyAccessor = {
  doesStuff: true,
} as Widget;

As shown in the example, the Exclude, helper enables us to remove a type from a type union. Now, you may be surprised to see that the Widget interface is not included in the type PropertyAccessor. This is because an interface extends an object. The same would happen if the interface was declared as a type instead of an interface. On the flipside, however, if we were to exclude Widget from Doodad instead of object, both obj2 and widget2 would be perfectly valid. obj2 being allowed makes sense, since it's type is in the union. widget, though?! We excluded that type explicitely!

When Widget is excluded, object is still a valid type for ExcludeWidget. Widgets are subtypes of object however, so since object is valid, so are Widgets;

After my research and tinkering, I discovered that the name Exclude is very applicable for what the utility does. Hopefully now you have a better understanding of the way that Exclude works, and you'll be able to utilize it to write cleaner, simpler types without getting frustrated when that type you excluded is still perfectly valid ;).