Every single developer, tech supporter, manager, project planner, tester, parent, teacher, and quality checker knows that question. And we all know that absolute feeling of dread that comes with it.
No, you don’t have one ‘small’ question, we think to ourselves, wishing we had a drink in hand, or maybe pondering how much money we’d have if we got a penny (yes, one cent) for every single time someone asked a ‘small’ question that worked out to be larger than the initial topic. It’s right next to one more small change, which is always inconvenient.
The questions are nearly never ‘small’ and they’re nearly never ‘quick.’ They’re born of a lack of understanding (hence question), which in and of itself is alright, but they seem to always come at the end, when we think we’re done. As a developer, I often feel these last minute ‘one more’ questions are because I didn’t ask all the right questions in the beginning of a project (which is why I’m not answering ‘Should I use multisite?’ anymore, too many questions). If I had a simple checklist to go down for my projects, it would be a lot easier.
But…
Therein lies the bane of most development setups. We don’t know what questions to ask much of the time, because we can’t know. We ask everything we can think up, and suffer from the failures of imagination later on. Or we end up in design hell (this is an Oatmeal link!).
And what if we’re not developing? Tech support is a nightmare when people have ‘one more question’ because it means they’ve asked for help before they’ve actually thought through everything. Hey, I’m guilty of this too, there’s a reason me and my friends will sometimes tweet a question with a tag of #lazyweb – Sometimes it is faster to ask a question of the masses (or one person) than it is to think hard about the context.
Here’s my challenge to everyone. Stop asking one small question, and try to ask one smart, simple, question.
Boy that probably sounds weird to a lot of people. A smart, simple, question, is a page shy of being asked by Captain Obvious. It may net you a reply of “Ask that again, would you?” so you slow down and think about what you just asked, clearly. Other times, the smart and simple is a clarification of something confusing in documentation (or missing from documentation entirely). Maybe it’s a link you can’t find. Maybe it’s that thing you know your wife will remember, like an actor’s name (“Honey, who was the guy who wasn’t a guy in the movie with the weird clothes? Tilda Swinton! Thank you!”)
They sound like they’re stupid questions, don’t they? The ones you ask and think “I was dumb.” They’re not. They’re really smart because you know the one thing, and the one person, who can help you pull an answer out of your own head.
The other great smart and simple questions are the one-offs. They’re short. “How do I start this car?” That’s generally smart and simple. But moreover, they’re specific! That’s the trick to a simple question, it’s to the point and direct. It means you’re not sending a novel to the CEO of the company, but a carefully thought out explanation of what you expected to happen and what actually happened. A good bug report is always simple, even when it’s complicated.
What it’s not is needlessly complex.
There are a lot of smart, complex, questions. You know the ones where it’s “How do I thread my new sewing machine?” Sounds relatively simple and easy, but it’s deceptive. I say this having had to read poor documentation, from 1920, on how you thread a sewing machine. I realized I was smart, but I was inexperienced, so I googled how to thread that specific machine. It was a smart question, but it wasn’t simple. In fact, it was insanely complex, and at a certain point someone in the house wailed “I just want to sew!”
A smart, complex, question is a great question, but it’s not one you should ask frivolously. What you really just asked is not ‘How do you…’ but ‘Teach me how to…’ And if you think teaching is quick and simple, you have a lot to learn. The complex questions are made worse when they’re asked with that novel. Oh, the novel. This is a novel, and if I saw a forum post or a ticket at work with all this in it from someone, I’d wince.
Smart and simple. Smart and short. My wife can teach someone to make cheese in five tweets. But I can’t debug (most) WordPress problems in that many. This is in part because tweeting code sucks, but it’s also because this isn’t a math question. I can probably explain Common Core in five tweets, but I can’t teach it in the same number. When you ask me a complex question, you don’t want me to explain, you want me to teach.
I know that easy is hard. The easy answers are hard, and they take a long time, which is why sometimes I tell people “Maybe” or “You can, but it will be complex.” I’m not brushing you off, I’m giving you the biggest hint in the world.
Your question is complex and complicated. But it sure ain’t simple.
It would slow your site down. You’ve probably heard me say something like “WordPress Multisite was intended to be multiple separate sites managed by one install of the WordPress files.” When I say that, I don’t mean ‘managed’ the way some people envision managed. When I say ‘managed’ what I mean is “You manage your network settings from the network dashboard, and you manage your per-site settings from the per-site dashboard.”
It’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’
So. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?