Just do the things
I saw an exchange on LinkedIn recently between Arek Dryer and Anthony Young that perfectly captures something Iâve been thinking about:
Arek Dreyer: Whatâs a piece of advice for someone whoâd like to get involved like youâve done?
Anthony Young: âJust do itâ đ but no, in all honesty, the one thing I have to tell myself over and over and over again is just do the things. My 2025 goal was to grow âmeâ. Grow my personal brand, grow my knowledge, grow my involvement. There are a million different things one can get involved in - pick just a few to go at it and be uncomfortable getting started in it. The community itself, specifically the Mac Admins community, has been great to me to allow me to take up space and participate and my participation is a way of giving back to that very same community - so everybody ultimately wins. Just start, and keep just starting and soon youâd be doing a year in review like âwhereâd the time go??â
Heâs right. Nobodyâs going to tap you on the shoulder and say âyouâre ready now.â
Hereâs what that looked like for me
I use AutoPkg to automate software packaging. Fleet has package management built in. But there was no way to add packages to Fleet directly from AutoPkg runs. I had to manually upload them through the UI.
Thatâs a gap. Not a catastrophic one. Not something that was blocking my work completely. Just an annoying friction point that wasted time and broke my workflow.
Nobody at Fleet asked me to solve this. The AutoPkg project wasnât waiting for someone to build a Fleet processor. But the problem was real, and I knew other Fleet users wanting to use AutoPkg would hit the same friction.
So I built FleetImporter, a custom AutoPkg processor that adds packages directly to Fleet.
Start before youâre ready
Hereâs what I didnât do: wait until I knew how to build an AutoPkg processor.
Iâd never written one before. I had to read through AutoPkgâs processor documentation, look at how other processors were structured, figure out Fleetâs API endpoints, and debug why my first several attempts didnât work.
I asked questions in the AutoPkg Slack when I got stuck. I shared early versions with colleagues at Fleet to get feedback on the API implementation. I pushed code that wasnât perfect because getting it working mattered more than getting it flawless.
Thatâs what starting uncomfortable actually means. Not âI felt a bit nervous but I was actually totally prepared.â More like âI genuinely didnât know what I was doing and had to figure it out as I went.â
Hereâs the thing: I still donât feel like I really know how to build an AutoPkg processor. But I know more about it than I did when I started. And thatâs all that matters.
You donât need to master something to contribute value. You just need to be curious enough to solve the problem in front of you. Everything else you learn along the way.
Discomfort is the point
If youâre comfortable, youâre not growing. Youâre just doing things you already know how to do.
Your comfort zone only expands when you push past its edges. If you stay inside it, doing the same things youâve always done, you stagnate. Your skills plateau. Your knowledge stops growing. You become really good at the things you already know, but you never learn anything new.
This isnât a bug. Itâs a feature.
That feeling of âI have no idea what Iâm doingâ when you start building something new? Thatâs exactly where you should be. That discomfort means youâre learning. It means youâre expanding what youâre capable of.
When I started writing FleetImporter, I was uncomfortable because I didnât know how AutoPkg processors worked. Now I kind of do. My comfort zone expanded. The next processor I write wonât feel as hard.
When we started the Mac Admins Slack, we didnât know how to moderate a community at all, let alone at scale. We learned by doing it. By making mistakes.
The pattern is always the same: start uncomfortable, push through it, end up capable of something you couldnât do before. Then find the next uncomfortable thing.
If youâre never uncomfortable, youâre never growing.
Failure is always an option
Adam Savage used to say this on Mythbusters, and I took it as a valuable life lesson.
Failure isnât really failure if you learn something from it. If you walk away from every attempt with a lesson about what doesnât work, or why something broke, or how to approach it differently next time, then that time wasnât wasted. Youâre smarter than you were before you started.
My first few attempts at FleetImporter didnât work. I had to debug API calls, figure out why packages werenât uploading correctly, and rewrite large chunks of code when I realized my approach was wrong.
I threw the whole thing out and started completely over at least three times. Not ârefactored a few functionsâ - scrapped everything and rebuilt from scratch. Each time I thought I understood how it should work, Iâd hit a wall that made it clear my mental model was wrong. Eventually I got to something that actually worked.
Every failure taught me something about how AutoPkg processors work or how Fleetâs API expects data to be structured. The time I spent on versions that didnât work wasnât wasted - each failed attempt made the next one better.
The Mac Admins Slack made plenty of mistakes in the early days. We had to figure out moderation policies after situations came up that we hadnât anticipated. We learned what worked and what didnât by trying things and adjusting when they failed.
Time spent failing is still time well spent if youâre learning. The only real failure is not trying at all.
Why we wait (and why we shouldnât)
The impulse to wait for permission comes from somewhere real:
âIâm not expert enough.â You donât need to be the worldâs foremost expert. You just need to know more than the person whoâs struggling with the problem youâre solving. If you figured something out that took you three hours of trial and error, writing it down saves the next person those three hours.
âSomeone else is probably already working on this.â Maybe. But if you havenât found their solution, neither has anyone else. And even if someone is working on it, two approaches to the same problem often surface different insights.
âWhat if I do it wrong?â Iâve done plenty of things wrong. For every thing Iâve gotten right, Iâve probably done ten things wrong. My first few attempts at FleetImporter didnât work. Iâve written blog posts that needed corrections. Iâve given conference talks where I stumbled over explanations or realized later I could have explained something better. We made moderation decisions in the MacAdmins Slack that we had to walk back.
None of that stopped the work from being valuable. People still use FleetImporter. The blog posts still help people even after Iâve updated them. The talks still landed even if they werenât perfect. The Slack community still grew.
Version two is always better than version one. But version one has to exist first.
âI donât want to step on anyoneâs toes.â Most people in open communities are happy when someone steps up to solve a problem. If youâre genuinely worried about overlap, ask early. Share your work-in-progress and see what feedback you get. But donât let theoretical toe-stepping stop you from starting.
What starting actually looks like
When we started the Mac Admins Slack in 2015, we didnât have a detailed plan for running a community that size. We just knew that the existing forums and mailing lists werenât meeting our needs for real-time discussion and quick answers.
We set up a Slack workspace. We invited people we knew. Those people invited others. We figured out moderation policies as situations came up. We made mistakes and adjusted. Now itâs over 80,000 members.
Starting doesnât require a perfect plan. It requires noticing a problem and taking the first step toward solving it.
For FleetImporter, that first step was opening the AutoPkg documentation and reading how processors work. For the Mac Admins Slack, it was creating the workspace and inviting the first 20 people.
Pick the smallest possible first step. Do that. Then do the next one.
Donât wait for permission
Nobodyâs going to email you and say âyou are now authorized to contribute to this communityâ or âyou have been granted permission to build this tool.â
You already have permission. You have permission because you noticed the problem. You have permission because youâre willing to work on solving it. You have permission because open source and open communities are built by people who just show up and start contributing.
The things youâre dealing with right now - the workflow friction, the missing documentation, the tool that doesnât quite exist yet - those are gaps. Someone else is hitting the same problems.
Pick one. Start there. Donât wait for permission.
The time will pass either way. You can spend it waiting for someone to tell you youâre ready, or you can spend it doing the things.
Just do the things.