Say No to ‘Ship It’ Culture: Slow and Steady Wins the Race
- Op-ed
In this post, I’d like to share my thoughts on “ship it” culture — which could be polarizing!
I’ve noticed the trend growing significantly in recent years and I can’t help but think it’s both damaging to developer growth, and the tech industry in general. Many folks who quote the mantra “ship it” do understand its true meaning, but many newcomers to the field appear to have misinterpreted this rather punchy marketing message as an actual directive.
Let me be clear, I’m not saying the counter argument here is “don’t ship it”. Quite the opposite, I’m saying you can be equally as productive, if not more so, if you take the time you need to learn. I’ve worked in and around web development and tech for ~20 years and I’ve never worked anywhere (including my own company), where I wasn’t afforded the time to develop my skills and become a more effective resource.
Ship It Culture
I don’t know where this all started, but I suspect San Francisco. You’ve no doubt encountered folks who live and breathe “ship it” culture, and if not in person, you may be familiar with some of the characters from HBO’s hit comedy series Silicon Valley, which is based on these people.
A huge audience understands that repeating the messages of tech marketing is a really funny joke, however, there are still a remarkable number of people operating within the tech industry that haven’t figured this out yet. And while for me, it is quite amusing (albeit tedious), I am now starting to see the “ship it” culture bleed over into developer education. Which is quite troubling.
Many SaaS companies and “startups” push the “ship it” narrative because, understandably, they need to make money; and by influencing developer culture using cleverly worded marketing messages promoting the importance of speed over everything else, they’re able to ensure that developers keep paying for products and services they might not need.
If you’re familiar with The Simpsons, you might recall the Wallet Inspector, and I think “ship it” culture — and the marketers who push that narrative — are the tech industry’s equivalent.
You probably aren’t even in a situation where shipping at all costs is important. Many of the newcomers influenced by “ship it” culture are building apps for zero users, so who are they even shipping to?
I’d like to see developers take a step back from shipping and invest more time in themselves, and who doesn’t have time for that?
Invest in Yourself
Back in ~2006, after spending a number of years learning and using ActionScript 2.0 (AS2), the programming language used by Flash developers, Adobe released ActionScript 3.0 (AS3). To learn AS3 I printed out the entire developer’s guide from a .pdf, and carried it with me in my bag. I’d often read sections while on the Tube (London Underground), on my lunch break, and during any planned learning slots during the working day or week. If you’re interested, this giant document is still available today: ActionScript 3.0 Developer’s Guide.
It took around three months to become proficient with AS3, and while it was difficult (I’m not that smart), some 15+ years later I’m still reaping the rewards of my efforts. Apple kind of killed Flash in ~2012 with the iPhone, so I had to switch from Flash development to HTML, CSS and JavaScript development; and I have to be honest, it was quite easy for me.
Moreover, when TypeScript started to become popular, I took to it like a duck to water because AS3 was statically typed, and I’d already learned about types via my giant .pdf. My point is, learning is always a good thing — you may never know when something you took the time to learn will benefit you, and that’s why I believe that “ship it” culture could be stunting your growth.
Quick Start False Economy
So it’s here where the “quick start” economy rears its ugly head. Because many developers have bought into “ship it” culture, they assume that everything they do needs to be done fast. Now, I’m not saying that CLI’s, starter templates and npx create commands, etc, aren’t useful — they are, but I don’t believe they should be your starting point when learning something new, and I don’t believe they should be the only options available to developers.
Every technology needs to be documented, and if you want to set developers up for success you should be thinking about the most effective way for them to learn, not the fastest way to get them using your product.
To give you an example, remember when you learned to drive, what did your instructor do? Enter you into a Formula 1 race? Or slowly and carefully explain how the car works, make sure you are familiar with the rules of the road, and give you time to build up your confidence? I’d wager every Formula 1 driver learned this way, and look at how fast they’re going now!
Complexities of Documentation
This subject is huge — too huge to cover in this article — but I have my suspicions about why some companies don’t, or can’t, concisely document how to use their product. So they often have no choice but to go the “quick start” route, claiming “it’s a strategy.”
Broadly speaking, I think the reasons fall into two categories.
1. Smoke and Mirrors
Some products are actually very complicated to install and use, and by documenting the steps to get started, it becomes clear to developers that the product is in fact complicated. In these circumstances, I’ve observed companies pushing developers towards CLI’s, starter templates, or npx create commands.
2. Skill Gap
It shouldn’t come as a surprise, but writing documentation is hard; in fact, writing anything in a clear and concise manner is hard.
And to those companies missing manual install guides… maybe you could consider hiring folks with technical writing abilities over folks who love to plaster their stupid face all over the internet with “crazy face” YouTube thumbnails? How’s that for a strategy?
Manual Install Benefits
If you do find yourself lucky enough to be using a product, tool or service that has been well-documented, soak it up. The slow and steady manual approach to learning almost anything will, in the long term, benefit you.
One advantage of going manual is that you’ll learn how to learn from reading. At some point in your career, you will have to figure something out by reading documentation alone. Another interesting angle is learning by osmosis; whereby spending time in the docs, you’ll notice new things. You might not need them right away, but you’ll probably remember seeing something that will help you later down the line.
And lastly, you might know this quote.
Tell Me and I Forget; Teach Me and I May Remember; Involve Me and I Learn.
Whilst there’s no evidence Benjamin Franklin ever said this, the sentiment aligns with Franklin’s emphasis on the importance of learning; and what better way to learn than by actually involving yourself in the process, regardless of the time it may take.
Manual Install Example
A tech company that has got this balance just right is Astro.
It has both a CLI and a manual install guide, and I love them for it. I’ve built many Astro sites, and every time I go manual. It’s to the point now that it’s so well rehearsed, I don’t even need the guide anymore! You might think this is a useless skill to have, but I’d challenge that for the following reason.
I fully understand what’s required to spin up an Astro site; and spoiler, not very much at all. For me, having a solid understanding of what I’ve installed — and more importantly, why — has greatly helped further develop my Astro knowledge. I don’t claim to know everything about Astro, but it has helped me incrementally learn more about Astro and develop a much deeper understanding.
Understandably, you might think doing everything manually takes longer — but only if you focus on one task. Zoom out a bit, and look at the bigger picture, there’s a ton more to learn. But because I have a solid foundational understanding of how I got to “stage one,” I can more easily progress to stage two, three and beyond.
The Tortoise and the Hare
“Ship it” culture folks are really gonna hate this but, are you familiar with Aesop’s The Tortoise and the Hare?
The tale speaks of a Hare challenging a Tortoise to a race. The Hare arrogantly assumes the slow-moving Tortoise is no match for his speed and takes a nap midway through the race. The Tortoise, happy in his lane, overtakes the Hare while he’s sleeping and wins the race.
And so it goes: to finish first, you have to first finish. So next time you’re learning something new, don’t sleep on the learning, channel your inner Tortoise and I’ll see you at the finish line!