DEV Community: Nathan James

7 Graphic Tees for Developers (2025 edition)

Nathan James — Mon, 19 May 2025 21:33:50 +0000

If you’re a developer, programmer, coder, engineer, or whatever we’re calling ourselves these days, these will be the perfect shirts for you to wear while on Zoom calls, developer conferences, or just to show off your profession outside of work.

I guess also If you’re someone looking for a funny t shirt gift for a developer, then this is also a great list for you, though it might be harder for you to understand some of the inside-joke style humor.

I'm the CTO now.

When looking for a software developer shirt that gets a reaction, you won't have to go much further than this. If you're the CTO, it's funny.

If you're NOT the CTO, it's even funnier.

There are levels to this shirt, and different meanings. Maybe you're the guy the CTO always comes to to ask for advice. Or maybe you're the last dev left in a company and the defacto CTO. Maybe you're just the company clown that likes to stir the pot. In all cases, this one hits home every time.

It's dangerous to go alone

The intersection of gamer and developer is pretty high.

And one of the most iconic games is and will always be Zelda. It's also a personal favorite here at Miserably Employed. That sweet sweet golden cartridge from the original NES is a memory that brings back a lot of joy for us, and countless others.

As a homage to the game that started it all, and a lot of developers on that gaming journey which lead in a big way to the professions we have, we've created a shirt for developers like us who were inspired to quest endlessly against all odds and finish the tasks put before us. Which, is pretty much all software development.

AI is just fine

We have a love/hate relationship with AI. We use it in various portions of our workflows and even in some design elements here at Miserably Employed, and as developers it's helped us speed up and lower friction by becoming a better autocomplete for code we were already going to write in that specific way.

But, it's a dual edged sword in software engineering with broken vibe coded spaghetti everywhere, poor decisions based on faith instead of experience, and slews of laid off devs that will be replaced with code that will need twice as many in the years to come to fix.

This shirt is our answer, with an AI created background that mocks ourselves in the same way we satirically mock our entire industry.

I code naked

This shirt speaks for itself, there's not really much more to say. It's become a running joke that you never know if someone is wearing pants on a Zoom call, and developers are no exclusion.

Heck, I'm not even wearing pants as I write this.

I peaked at onboarding

We're all most excited within that early period of a new position at a company. The code is new, you're not sure if it's a microservice avro schema mess yet, you haven't learned about how your product manager and project manager hate each other, and you haven't been tricked 7 times by HR into clicking scam links that "gotcha".

All you have is hope because of the unknowns and you're as happy as you'll ever be there. There's a saying about boats: "the two happiest days of a boaters life is when you buy the boat and sell the boat" and while there's debate about the truth of that saying it's pretty applicable to software developers.

The two happiest days of a developer's life is the day you get hired, and the day you quit. Probably some nuance in there with promotions, bonuses and raises that aren't 2.7%. But we don't bring facts into things here.

I push to prod on Fridays

It's a meme, but it's a meme because there's truth to it. For some reason (spelled "marketing") there's this want to push things to production on Fridays.

Nothing spells out disaster more than slack messages about downed services at 9pm on a Saturday. Developers don't want to be on-call. The pay bonus for it isn't worth it when the salaries are already so high, the hours so long, and the stress so tangible.

This shirt wasn't made with love, it was made with spite. And that's how we wear it on calls with managment.

The de-velopment process

There's a famous principle (xkcd of course) called the Ballmer Peak. It's about how there's a sweet spot where when you've drunk just enough alcohol you become a super-human programmer.

Whether or not there's any truth to the theory, it seems that a large portion of developers have either taken this as a challenge and began drinking either while coding or pushing code (one of the bad decisions) and then having to fix their mistakes after the fact.

Though, it could just all be bad code, who knows. Looks the same.

Want to see more shirts like these for developers (and other professions)? Head over to MiserablyEmployed.com and enjoy!

How to use `npm create` to make your quickstart docs better

Nathan James — Fri, 26 Apr 2024 11:26:03 +0000

The #1 primary goal of developer-facing software and tooling is making it as easy as possible for developers to use them.

It's the reason that Quickstart sections in documentations are so important, and why the length of those sections matters a lot. Too long? Didn't read.

So how can you shorten those?

Enter npx

If you don't know about npx, it stands for "Node Package eXecute", and is a way to execute scripts on the package.json from command-line without first installing the packing manually. You could do something like this:

npx yourlib create myproject

That will run whatever you have in your create script in your package.json. For example:

{
  "name": "@your/lib",
  "version": "1.0.0",
  "scripts": {
      "create": "node index.js"
  }
}

This is great, but if you look at big modern projects like Svelte or Vite you'll notice they don't use npx.

They use npm create.

One possible reason is that new developers know they have npm installed, but they don't realize they also have npx. That gives them pause, and makes them reconsider whether to use the tech if they have to install something additional onto their OS.

So, how does that work?

npm create isn't magic

It's basically doing the same thing as npx lib create, but it uses a specifically named npm package, and the bin property in your package.json.

Package name format

In order for your package to be picked up by npm create its name needs to follow this exact format:

create-<whatever>

For instance, the package I created was create-eos, as it's a CLI for getting set up on the EOS Network quickly.

Bin files

Your package.json supports specifying a bin file, which is a way to tell tooling that there's an executable script in your package.

Edit your package.json and add the bin property that points to a file called bin.js.

{
  "bin": {
    "create-<whatever>": "./bin.js"
  }
}

Now create that file and put this at the top.

#!/usr/bin/env node
require("./index.js");

This will call your index.js script from the executable using the node shebang.

What you put inside of your index.js is up to you, but you can reference the CLI I created if you want a starting point.

That's it!

Now all you need to do is push that up to npm using npm publish and anyone can call npm create <whatever>@latest.

Use this in your quickstart guides to give developers using your software and tools a better and modern experience. The more work you do for them, the less docs you have to write.

Did you like what you read? Follow me on Twitter. I write about software development, developer relations, and buildinpublic.

How to compete with Google, Amazon, Microsoft and Apple using Web3

Nathan James — Thu, 31 Aug 2023 10:35:27 +0000

Spoiler alert: You don't.

There is a bad habit that kills 90% of web3 projects before they even launch. It's the mindset that it's a good idea to take something web2 and slap web3 on top of it. These projects are doomed to fail because they are trying to compete with the biggest companies in the world on their own turf without providing any additional value other than the perceived value of being decentralized.

Here are some wildly successful web3 projects:

Uniswap - Easy decentralized swaps
IPFS - Efficient decentralized file storage
ENS - Readable names for Ethereum addresses
MetaMask - A way to access web3 applications (dApps)
OpenSea - NFT marketplace
ChainLink - Decentralized oracle network

Every one has one thing in common.
They are web3 native.

Instead of trying to take something that is inherently web2 and make it web3, they are taking advantage of unique properties of web3 to create something that is impossible (or nonsensical) to do in web2. Each project relies on fundamental properties of web3 to provide value to their users.

They have made it practically improbable for tech giants to compete with them because to do so would require core changes to their tech stacks, methodologies and business models.

This is the key to competing with all varieties of the alphabet soup.

The mindset shift is to look at the web3 space itself and the properties that it provides and ask yourself "What can I do with this? What is the next obvious step?".

This isn't to say that you can't take inspiration from web2. In fact, you should. OpenSea is a great example of taking a web2 concept and making it web3. They took the concept of a marketplace for collectibles and made it decentralized.

However, they didn't try to make decentralize eBay, they wrapped a marketplace around an existing web3 concept (NFTs).

A common example of how to fail

Mark is fed up with Twitter. He's tired of the censorship, the shadow bans, not knowing why his content isn't reaching his audience.

He's tired of the centralized and dark nature of it all. He wants to build a decentralized Twitter. A Twitter killer.

He starts building. He uses blockchain for hashed data, IPFS for raw data, smart contracts for the logic, MetaMask for
logins, etc. It's a masterpiece of web3 technology.

He launches it and... nothing happens. He gets a few users, but it's not taking off. He can't figure out why. He has everything that Twitter has, but he's decentralized. Why aren't people using it?

The answer is simple. It's just Twitter.

The only users he will ever get are the ones with ideological alignment. The ones that care about decentralization. Though these people are passionate, they are a small minority. The vast majority of people don't care about decentralization.

What they care about is the value and functionalities that only decentralization can provide.

Novelty is not to be ignored

First look at TikTok. It became a global phenomenon in less than a year. It didn't try to copy YouTube, or Instagram, or Twitter. It created a novel experience that was native to the platform. It was a new way to consume content, create content, interact with content and creators.

Next, look at Threads. With a huge company behind it that has experience with social networks, it still failed. Why? Because
it was just a copy of Twitter. It didn't provide any value that Twitter didn't already provide. It was just Twitter, but with the ability to log in with Instagram.

You want to replicate the success of TikTok, not the failure of Threads. You want to create something that is novel and native to web3, not just a copy of something that already exists.

So how do we come up with a good idea?

The first step is to look at the web3 space itself. What are the properties that it provides? What are the things that are impossible (or impractical) to do in web2?

The second step is to look at web2. What are the things that people love about web2? What are the things that people hate about web2? What are the things that people want to do in web2, but can't?

Find the intersection of these two things and jot down some ideas. Test out the waters, but always be asking the question:

"What makes this web3 native?"

The answer to this question is what will make your project successful, not the fact that you've branded a web2 idea as web3.

What are some web3 native concepts?

This is by no means an exhaustive list, but it should give you some ideas.

Tokenization - The ability to make anything tradable / ownable / sellable
Peer to peer payments - Payments directly from one user to another
Governance - Immutable, decentralized, community driven governance
Real Ownership - Your keys, your content
Immutability - No more deletions, everything is permanent
Transparency - No more black box algorithms, everything is public
Decentralized - Distributed by nature
Censorship resistant - No more shadow bans, no more deplatforming
Permissionless - No gatekeepers or walled gardens
Unrestricted APIs - No way to prevent third parties from building on top of your contracts

Just looking at the list above it is much easier to come up with a web3 native social network.

Want more thought-provoking content that will help you build a successful web3 project?

My name is Nathan James, and I'm a web3 developer, educator, and entrepreneur.

I've been building web3 projects since 2017 and have helped hundreds of developers build web3 projects.

If you want to learn more about building successful web3 projects follow me on Twitter
and check out the EOS Network Documentation

Getting funding - Understanding what Grant Programs are looking for and how you can fund your Open-Source Web3 projects

Nathan James — Thu, 29 Jun 2023 12:14:38 +0000

I've been investigating, participating, and running grant programs for a while now.
There are a few things that I've learned along the way that I want to share with you.

What is Grant Program?

A grant program is a process that provides a way to fund initiatives that are aligned with the
mission and vision of the organization that is running the grant program.

Grant programs are usually run by companies or foundations that want to support a specific cause,
or have specific goals that they want to achieve. It allows participants to submit proposals
that are aligned with the goals of the grant program, and if the proposal is accepted, the
participant receives funding to work on the project.

Why do Grant Programs exist?

Grant programs are usually run by a company or a foundation that wants to support a specific cause
which is aligned with their mission and vision.

For example, the EOS Network Foundation's Grant Program
is focused on supporting projects that are building on the EOS Network. The alignment with the
foundation's mission and vision is clear, they want to support the EOS Network ecosystem.

Another example is the Web3 Foundation's Grants Program
which is focused on supporting projects that are building on a variety of networks (Polkadot, Kusama, etc.),
but the alignment with the foundation's mission and vision is also clear, they want to support
the Web3 ecosystem.

What does the process look like?

The process of applying for a grant program is usually the same across all grant programs.

You submit a proposal
The proposal is reviewed
The proposal is accepted or rejected
If accepted, you start working on milestones

There might be some back and forth at step 3, but not always. In a lot of cases you might get rejected with
some feedback, and you can re-submit the proposal with the feedback in mind.

When do you get paid?

This differs between grant programs, but there are generally two ways you get paid.

You get paid upfront
You get paid after you complete a milestone

It's important to understand how the grant program you're applying for works.

If you need funding upfront, and don't realize that the grant program pays after you complete a milestone,
you'll be in for a surprise, and possibly suffer reputation damage which will prevent you from ever being
able to complete your proposal, or get further funding from that grant program (and possibly others).

What qualifies for Grant Programs?

Grant programs are open to anyone who wants to participate (within legal requirements). However, there are some
things you need to keep in mind to be able to take advantage of them.

Most grant programs require that the project is open-source, aims to solve a problem that
is aligned with their mission, and has a clear roadmap of milestones and timeline.

The two hidden types of proposals

Okay, here's some alpha for you.

Though this is never talked about or stated on any grant programs, there are two types of proposals.

The business proposal
The tech proposal

Both of these types of grants are common, and sometimes there is overlap, but it's important to understand
how evaluators look at these proposals and what they are looking for in each of them.

The business proposal

These kinds of proposals are centered around projects that are focused on building a business. They want to
build a product that will be used by users, and build their own community. These are always crucial for the
success of any grant program, as they are the ones that will bring users to the network, and help it grow.

However, in a lot of cases, these projects do not focus on the business model, and instead focus entirely on features.
This is a mistake, as no grant program wants to become a substitute for a business model. The aim of a grant program
is to help you get started, not to fund your business.

It is crucial that you outline how you will reach self-sufficiency in your proposal.

The tech proposal

These kinds of proposals are centered around proposals that do not benefit from a business model.

For example, a proposal to build a new command-line tool that will help developers build a specific type of application
should not have a business model, as that would negatively impact the adoption of the tool; and the goal of the
grant program is to help the tool get funded and then adopted.

These types of proposals should focus on the technical aspects of the project, and how it will benefit the growth of
the ecosystem, improvement of the network, or other technical aspects.

How to write a winning proposal?

There are a few secrets to writing a winning proposal. Some of them are obvious, and some of them are not.

Follow directions

This one is obvious, but it's not always followed. Actually, it's rarely followed 😂.

If the grant program asks you to submit a proposal in a specific format, do it. There are often automated
tools that will help evaluators review your proposal, and if you don't follow the format, you'll just have to
do the work later on, and you'll be wasting everyone's time. It also reflects poorly on you at the very first stage
of evaluation.

Be clear & specific

I see way too many proposals that are vague. There is no clear roadmap, no clear milestones, and no clear timeline.

These never get accepted.

You want the reader to be able to understand what you're proposing in as little time as possible. If they have to
spend an hour reading your proposal, it often shows that you don't know what you're doing, and you're just trying
to fluff up your proposal.

These aren't whitepapers, they are grant proposals. They should be short, concise, and to the point. You need to
explain the technicals of what you want to accomplish, but you don't need to (for example) dig into the details of
how you will implement a specific feature.

Singular focus

This is a big one. Scatterbrained proposals are much harder to accept, as they are often too ambitious, and don't
make the evaluator feel confident that you will be able to deliver on your promises. You don't want to do
15 things in one proposal, you want to do 1-3 things, and do them well.

You will always have the chance to create a new proposal in the future to add new functionality, but you need to
focus on the core that you want to build for each proposal.

This makes it very easy for the evaluator to understand what you're proposing, and how you will accomplish it.

Be realistic

Look, I know you have big plans, and you want to build the next big thing. But you need to be realistic about what
you can accomplish in the time that you have, and within the parameters of the grant program.

You're not going to build a AAA FPS game in 2 months with a $20k grant. It's just not going to happen.

This is a sure-fire way to get instantly rejected, and that first impression on the evaluators is going to be hard
to shake off.

Thanks for reading!

I hope this was helpful, and I hope you learned something new. If you have any questions, feel free to reach out
to me on Twitter @nsjames_.