Coding is a Language

Yeah, I know, it sounds kin­da ob­vi­ous. Read on. That seem­ing­ly ob­vi­ous state­ment is not ac­tu­al­ly what I mean.

I’m not talk­ing about a spe­cif­ic pro­gram­ming lan­guage. I’m talk­ing about cod­ing as a prac­tice in gen­er­al. We’re used to un­der­stand­ing com­mon lan­guages, from in­for­mal ones (like hu­man lan­guages such as Eng­lish or Span­ish), to more for­mal or re­stric­tive ones (like math­).

But all in al­l, a lan­guage is any­thing you can use to ex­press ideas with. In that sense art is al­so a lan­guage: for a mu­si­cian mu­sic would be his/her lan­guage, paint­ing, and so on. For ex­pert chess play­er­s, the rules of chess would con­sti­tute a lan­guage.

And even when some­thing like this seems ob­vi­ous (as stat­ed at the be­gin­ning), some peo­ple in the soft­ware in­dus­try some­times fail to rec­og­nize the cod­ing ac­tiv­i­ty as a lan­guage on it­self.

To give an ex­am­ple: let’s say you have to com­mu­ni­cate an idea about some­thing you want to im­ple­men­t. You can write a per­fect­ly craft­ed de­sign doc­u­ment (with ar­chi­tec­ture di­a­gram­s, and such), and then send it for re­view. But is that re­al­ly the best way to com­mu­ni­cate a change? In or­der word­s, is it the best lan­guage to use when you want to get an idea across?

How about pub­lish­ing a code re­view in­stead? Some­times in­stead of just say­ing ‘it would be good for your tool to do X’, it’s way more ef­fi­cien­t, to just go ahead and im­ple­ment it.

In oth­er cas­es, a de­sign doc­u­ment might not even be the best suit­able lan­guage choice to com­mu­ni­cate your idea. In the case of a pro­to­type, I would be more con­fi­dent on see­ing ac­tu­al work­ing code. The same ap­plies for a proof-of-­con­cep­t. A text doc­u­men­t, or pre­sen­ta­tion slides would al­ways com­pile and make sense from a high­-lev­el per­spec­tive. But there are cer­tain things that you won’t find out un­til you dive deep in­to the task, and that’s when cod­ing be­comes a more ef­fec­tive com­mu­ni­ca­tion tool.

Af­ter al­l, the pur­pose of a pull re­quest is not to merge code in­to the main branch. It’s to com­mu­ni­cate an idea us­ing code. When you sub­mit a new pull re­quest you’re com­mu­ni­cat­ing some­thing. That some­thing, does­n’t nec­es­sar­i­ly need to get merged.

This changes the def­i­ni­tion of suc­cess for pull re­quest­s. Most would ar­gue that a code re­view is suc­cess­ful if it gets merged with­out caus­ing is­sues in pro­duc­tion. This makes sense, of course, but it’s al­so lim­it­ing. If in­stead we’d say that a pull re­quest is suc­cess­ful if it ef­fec­tive­ly com­mu­ni­cates an idea, this would bring more val­ue. You can have a first code re­view sub­mit­ted on­ly to present a proof of con­cep­t. The code could be scrap­py and by no means any­where near what the code base would con­sid­er ac­cept­able. But it will be some­thing more con­crete to com­mu­ni­cate what (and how!) is you’re try­ing to achieve. This can be ref­er­enced in mail­s, or oth­er doc­s, and then the team can go ahead with the re­al (and high­-qual­i­ty) im­ple­men­ta­tion. The orig­i­nal code re­view did­n’t get merged, not even se­ri­ous­ly scru­ti­nized (like a re­al pull re­quest would), but it still got the job done.