You Don’t Have to Be Great to Start, But You Do Have to Start to Be Great
First things first: if GitHub (or anything) feels intimidating, you’re not dumb. You’re just uninitiated. Many — if not most — operators have never had a compelling reason to use platforms like GitHub, and the UI can be daunting to any non-developer.
That said, most operators, marketers, PMs, founders, and general-purpose problem solvers are closer to shipping real work than they think. The gap isn’t intelligence. It’s exposure.
This post is not about turning you into an engineer.
It’s about helping you understand the terrain so you can move with confidence instead of fear.
What the Ship? (Defining “Everybody Ships” in Plain Language)
Gatekeeping and gatekeepers are a pox on humanity. Let’s de-mystify this whole thing and move beyond jargon (and my indefatigable commitment to #forever12 shit ship puns).
When people say they’re “shipping work,” here’s what they mean:
- Someone makes a change (code, content, configuration, etc.)
- That change gets reviewed
- It gets merged into the main project
- It gets deployed so the work is visible somewhere on the internet (e.g. via Vercel)
- Users can now see it
That’s it. That’s the entire game.
You’re not trying to become a programmer. You’re trying to understand the flow of work so you can participate in it instead of standing outside it.
Shipping Jargon
You do not need to memorize technical definitions. But metaphors can be memorable and helpful:
- Git → Version history (like Google Docs history, but more powerful)
- GitHub → The shared workspace where projects live
- Repo (Repository) → A project folder. This website has its own repo.
- Branch → A draft version of the project. You work in branches, test, and if everything works and builds on a platform like Vercel, you’re good to go.
- Pull Request (PR) → After you review the work on a branch, a PR is what you create to enable someone else (ideally) to check your work, and then confirm it successfully builds on your hosting platform.
- Main → The real, canonical version of the project. Branches are merged to main via PRs.
- Deploy → Putting the current version live on the internet. You’ll hear the term build sometimes — that refers to your branch being deployed on your hosting platform (e.g. Vercel, again.. I work there, so The MOPerator is very Vercel-pilled)
Once you understand those seven concepts, you’re pretty much ready to rock.
Best Practice Workflow
Regardless of what you’re trying to do, whether it’s update copy on a webpage or deploy a fully featured AI app, the best practice workflow almost always looks like this:
- Create a branch (a safe draft space)
- Make your change
- Open a Pull Request
- Someone reviews it (maybe you, ideally a teammate)
- Merge it into main
- It deploys
That’s the entire lifecycle of most work on the internet.
No wizardry required. Though for the D&D nerds, there’s a parallel between AI tokens and spell components…
What You Actually Need to Learn (and what you don’t)
You probably do need to learn:
- How to navigate a GitHub repo
- How to create a branch
- How to edit files safely
- How to open a PR
- How to read review comments
- How to tell whether something broke
You absolutely do not need to learn (yet):
- Algorithms
- Data structures
- Framework internals
- Complex terminal workflows
- Writing massive codebases
- Computer science theory
You’re not trying to become a staff engineer. Probably. You’re trying to stop being blocked by tooling. Very different goal. Perhaps the most important life lesson to remember when it comes to dev work:
With Code, all things are possible.
Common Mistakes (aka: everyone does at least one of these)
My dad has been trying to convince me my entire life that experience is the best teacher, but those experiences don’t have to be your own. LOLz. Shows what he knows.
Here’s a quick checklist of the most common no-nos:
- Editing directly on main for… reasons
- Being afraid to open PRs because you might “waste someone’s time”
- Thinking you’ll “break everything” if you click the wrong button
- Not understanding what reviewers want from you
- Waiting for permission instead of trying
Here’s the most beautiful truth about the CI/CD (continuous integration, continuous deployment, aka the entire workflow we’re talking about in this post):
You can’t fuck it up. I mean, you can, but platforms like Vercel enable you to instantly roll it back. My brothers and sisters in code, it’s 2-way doors all the way down.
Ship… You Keep Using That Word
By now you’d be right to wonder, “Where am I actually shipping all this code to?”
For that, you need a deployment platform.
I work at Vercel, so I’m obviously biased — but I’m also there because I genuinely believe it’s the best platform for this job. I’ve used our competitors, but Vercel is the one I trust and reach for by default.
So throughout this series, I’m going to use Vercel as the example. Not because you have to — but because it’s the clearest, most reliable path I know.
Regardless of whether you start in v0, Cursor, Claude Code, or just hand writing your own code in an IDE, you’ll need to:
- Create a Repo
- Create a Vercel Project
After you create a Vercel project, you can integrate it with your repo via the settings page. From here on out, any branches you deploy code to in your repo will build as staging branches (non-production links you can share), and after you merge a PR to your main branch, the primary domain will be updated with your code. We’ll deep dive Vercel itself separately in another post, but the video in this posts covers this workflow at a high level.
The Operator Advantage (Why this matters for our careers)
Operators who understand shipping:
- Unblock themselves instead of waiting
- Write better specs
- Collaborate more effectively with engineers
- Build internal tools
- Spot problems earlier
- Move faster with fewer dependencies
You don’t need to out-code engineers.
You need to understand the system well enough to build prototypes. I worked at AWS for 4 years, so I won’t (can’t) disparage the virtues of memo culture… but in a world where “cheap, fast, and good: but you can only pick two” exists and fast is already an organizational imperative, demos not memos, my dudes.
This is leverage. This is how we earn trust in the AI era. This is how we continue to drive business impact and cement our roles as essential personnel and value-adding resources.
Practical Next Steps (things you can do today)
No big leap required. Just small reps.
- Create a GitHub account (if you don’t have one)
- Open any public repo and click around
- Read a README
- Look at commits
- Open a Pull Request tab and skim comments
- Click “Edit” on a file (even if you never commit it)
If you’re feeling bold, fork the OSS Marketing Toolkit repo I shared in the video and try customizing it on your local machine. Ask ChatGPT to walk you through it. Increase speed with proficiency. Increase proficiency with practice.
If I can be so bold, I’m like 85% certain that’s the summary cheat code to all things in life. If that doesn’t work, try 42.
Closing: This is a Skill You Can Build
This post covered the basics of the shipping process, not mechanics.
The video in this post walks you through creating a GitHub account, navigating a repo, and making your first safe change without breaking production. In future posts, we’ll share repos you can fork and customize. Before you know it, you’ll be shipping S-tier work internally, winning hearts and blowing minds.
Like we said at the top… Everybody ships. Git happens.