Welcome to The Rosetecha Stone
Hello and welcome to the handbook for non-developers and non-technicals to get inside the hearts and minds of developers.
I've noticed that it is often difficult to be a visitor to this headspace. It's an awkward hat to put on when you don't know what it's like to write code every day.
I want to create a place for non-technicals to be able to understand technicals. To speak our language, to walk and talk like us enough to empathize, to know why we care about the things that we care about.
Okay, or just to have a convenient reference that cuts through everything else so you can sell/market/understand products. Either way.
Why I Care
There are so many amazing products and tools out there that deserve more attention, more money, more usage, more love, all of it. Big and small.
But developers are a particularly persnickety bunch. I personally think we as devs get a little bitter when we have an electric piece of sand yell at us all day like ERROR: YOU DID A BAD THING AND YOU NEED TO FIX IT RIGHT NOW OR I WILL NOT COOPERATE ANYMORE. I AM COMPUTER. DO MY BIDDING MORTAL FOOL.
They make snap decisions about tools and their first impressions of things can ruin their intepretation of a tool, service, or company for excruciatingly bad reasons.
If only they had been able to get past the fact that the first sentence of the marketing page incorrectly said "Use the CDN today" instead of "Use a CDN today".
Yes, developers really will not use a tool because of things like this. They will assume that the company doesn't know their stuff and shy away. Really it was just that Jimmy from Accounting thought he would be helpful and update some copy and nobody happened to catch it.
The problem is: Developers miss out on great tools because of this.
What This App Solves
I don't want that to happen anymore.
Marketer, I want you to write an ad about headless components and genuinely know what you are talking about. That copy is going to be materially correct the first time now.
Sales, when you tell a company that you'll cut down their compile times by 37%, I want you to actually know what that means beyond the fact that it's a good thing. Maybe you'll even a little bit of how it works.
Designer, I want your pretty picture to truly capture the essence of what that technology is for and why we (re: developers) care about it. Empathy and relatability make a great design if that's its purpose, right?
Less mistakes.
Less toil.
More understanding.
More production.
What This App Doesn't Solve
Developers love to get into spirited debates about even the most simple things. It's like if you took the "Is a hot dog a sandwich?" debate and turned it into an entire industry.
We're not going to do that here. We're only going to get familiar with the basics, provide a talking point or two about why a dev is supposed to want/like this thing, and then let you get back to work on your business tasks.
I won't be going into deep dives on why developers make certain decisions in certain situations too much (unless this app turns into that by popular demand). There is way too much to go into there.
I'll stick to telling you what things are and giving you a topical explanation of why developers use/like that thing. Plain and simple.
Want a new article?
You can send a message to anthony.shew@vercel.com, ping Anthony Shew on slack, or submit a Github issue on the repository for this project.