Opinions are free: advice is expensive

Something interesting has been going on. In case you haven’t noticed, it’s becoming cheaper and easier for anyone to distribute content these days. This inconvenient truth is leading to the death of the newspaper industry, and the fantastically overeager power grab from media moguls is causing technical folk to openly declare war.

But with all the schadenfreude (go grab the popcorn!) that comes with us tech guys watching multiple industries flail around with their hair on fire, I think perhaps we’ve missed something.

You see, all this time, we programmers thought we were in the programming business. Sounds somewhat reasonable, doesn’t it?

But actually, we’re not. We’re in the advice business. It’s just that most of the time, the people we’re giving advice to happens to be ourselves.

If you are a programmer, think about how much time you spend actually thinking about programming things. How much time do you spend thinking about the syntax for a while loop or a for loop? I mean, I have days like anyone where the whole thing is spent on a hunt for an errant semicolon, but it’s the exception, not the rule.

Now imagine yourself as two different people in a single body. One person is the consultant, the person brought in to make architecture decisions. What does the class diagram look like? Which library should we use? The consultant is the side that reads e-mail and goes to meetings, who has flamewars with other developers. The consultant is the guy who sketches out pseudocode and works out the formulas, who draws funny diagrams on scratch paper.

Then there’s the other side, the actual programmer. The programmer takes whatever decisions were made by the consultant and implements them at the line-of-code level.

This distinction might seem arbitrary to you. Isn’t it all just part of the job? I hate these blog articles that ramble on and on defining a stupid bistable dichotomy when in fact there’s a whole spectrum. And it seemed like a very strange line to draw to me at first, too. But I was inspired by sent-hil to keep a programming journal (more on this in a future post), and what I have discovered is that I spend much more time in the journal than I do in front of an IDE. It was eye-opening to me how much faster I could work with chicken scratch on paper that I later translate to an IDE, than it was to start in the IDE to begin with. And suddenly the distinction became very clear to me: the person who writes in the journal is the consultant, and the person who reads it is the programmer. And calling what I do “programming” is completely inaccurate, because most of my world these days is writing notes in the little book. Seriously, you should try it. I’ll start. Here are the notes left by the consultant about this blog post, which I, the humble writer, have turned into the essay you are now reading:

I’m afraid that the first 5 times patio11 presented the case of not calling yourself a programmer, I wasn’t really on board. Aren’t “consultants” those salesey guys in suits who offer “solutions” and want you to call for a custom quote so they can fleece you, who show up teaching workshops uninvited about “synergy” and “scrum”? That’s what I used to think about consultants. Before I realized that there was a consultant I liked quite a lot: the guy who keeps writing helpful things in my programming journal. He’s kind of alright.

And the distinction is useful. For example, it explains, in a concise way, the particular failure mode of outsourcing. The trouble is not the quality of the for loops from the devs across the pond. It’s not that they don’t put spaces after commas, or that they use for-case (well, not usually). The problem is that they fail at being consultants. On the external side, they’re bad at meetings and e-mail. The fancypants expression for this is “cultural barriers”. And then on the internal side, they design a bad solution. The class diagram is wrong; the component-level design is wrong; they don’t understand the business problem, they don’t test well, they don’t understand the users–whatever. Whatever specific reproduction steps you describe in your circumstance, it’s the same root cause: they fail to be good at consulting.

The Atlantic had an article that really put the problem in focus for me:

“What we had wrong was the idea that anybody can screw together a dishwasher,” says Lenzi. “We thought, ‘We’ll do the engineering, we’ll do the marketing, and the manufacturing becomes a black box.’ But there is an inherent understanding that moves out when you move the manufacturing out. And you never get it back.” …

If the people who design dishwashers sit at their desks in one building, and the people who sell them to retailers and consumers sit at their desks in another building, and the people who make the dishwashers are in a different country and speak a different language—you never realize that the four screws should disappear, let alone come up with a way they can.

In other words, the value in US manufacturing isn’t people who speak English and know how to use a screwdriver. It’s having in-house people who have an intuitive knowledge from using screwdrivers to butt into your meeting and say “This design with sixty screws? It’s a bad idea.” It’s consulting that’s the valuable part of this. The whole technical part of this–actually handling the screwdrivers–is just a prerequisite for developing the consulting knowledge. A critical prerequisite, certainly, in the sense that your car having wheels is a critical prerequisite. But you do not buy wheels; you buy a car.

And now we return to our original quandry, that bit about the gatekeepers going out of business. Whatever inflated notions of their own importance they may have developed, and however badly they went about it, at some point they were at least a little useful, by standing against the idea that “my ignorance is just as good as your knowledge“. To appear in print, you needed expertise. To write an article or a book about software, at minimum you had to have software experience.

But anyone who’s perused an open source mailing list knows that there are many more opinions than there are cooks in the kitchen. I actually snorted coffee when I read this StackExchange question that wanted to know the “canonical retort” when a person who wants a feature is invited to submit a patch instead of starting Yet Another Flamewar requesting the feature. One person responds dryly: “The canonical retort is to submit a patch.” The problem that faces software is not a lack of opinions: it is a lack of patches. And the thing that causes lack of patches is not lack of programmers so much as lack of consultants. (“Consultants”, if you are just joining us, being a specific technical term that I’ve defined very carefully earlier in this essay.) And so one can say that there are too many opinions and not enough qualified advice. Too much empty talk and not enough design document.

The thing that got me thinking about this is remembering the old spat between svbtle and obtvse.

“This is the blogging platform for creative, intelligent, and witty people. Membership by invitation only.”
Am I the only person that laughed out loud at this? – devinfoley

I didn’t laugh but I found that incredibly arrogant and pathetic. – patrickaljord

Say what you want about Dustin Curtis being a jerk, but I think with hindsight it’s clear that svbtle succeeded in creating a high-quality site with content worth reading. And as best as I can tell, I don’t read anyone who uses obtvse. The whole gatekeeper idea has turned into a parody of itself to us developers, but there seems to be something to it after all.

And there’s another thing. Marco Arment, one of the smartest developers out there, has for some reason gotten himself into the publishing business. That’s gotta be a typo, right? And quite rightly, the pundits on HN tear him a new one for being a step back from the web in nearly every conceivable way: it’s hard to search, it requires a special app, it’s only available for iOS, only iOS 6 no less, blah blah. And they’re right, it is worse than the web in all the ways but one: the content. The content is some of the best I have ever read; it’s like HN used to be before it went to hell in a handbasket, it’s like watching the news back before 24 hour news shows. Did you know that there is such a thing as a good, well-written and imaginative fluff piece; you’ve just forgotten because you can’t find it in the sea of click-grabbing headline top 10 lists any more? You can find it in The Magazine. Remember those days when you would read an article and the response isn’t to get into a flamewar but to start a new repository? You can find that there too.

In a world where everybody has a keyboard, the editor is king. This gatekeeper idea has legs. The “social” filter, the facebooks and instagrams and tumblrs and whatever else the kids are doing these days promotes bite-sized, easily-digestible content. It produces things that fill time, but not things that use it. And I want to use it.

And we programmers are in danger of killing the goose. Have you spent your time today dispensing opinions or providing advice? Are you the consultant working on the patch, or are you standing outside yelling complaints into the kitchen?

I think a lot of it is the pervasive idea that programming is a meritocracy; that the best ideas win. But it’s not true. There’s basically no value in merely being right. Nobody likes the “I told you so” guy even when he is right. If you are that guy, then you have to either convince everyone you are right (which is usually a fool’s errand), build the thing yourself, or find another group of people who don’t need convincing. There’s no credit for knowing the right answer, there’s only credit for building the right thing.

And yet if you go on HN or to [arbitrary programmer gathering], you always see the first strategy: convince the other person that you are right. Essentially the predominant purpose of programmer gatherings is to practice the first strategy. When an article about “PHP sucks” appears, you will see articles and counter-articles and comments and counter-comments, does it suck, doesn’t it suck, but you will never see any proposal to actually improve any language, or any particular software project, or any particular community, or anything at all, really. You will not see any consulting. You’ll just see people typing at keyboards. Because in the end, that’s how we see ourselves.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.