Archiv der Kategorie: programming

Source Code as an act of communication

Taking from the last lon­ger pie­ce and a very good idea that @codePrincess lin­ked to in a blog post: Code that says what it does. Of cour­se, source code also is a medi­um of com­mu­ni­ca­ti­on bet­ween human and human – but the per­son you are wri­ting for may just be the future you. And just as the user inter­face is an act of com­mu­ni­ca­ti­ons, so is your source code.

Do you want to impress the rea­der with your skills in opti­mi­zing, but pro­du­cing hard that is extre­me­ly hard to read? Do you want to be con­si­de­ra­te and share a lot of your thought pro­cess in your code, or is it bet­ter to have the rea­der gues­sing as to why you cho­se a par­ti­cu­lar road to imple­men­ta­ti­on? Try to be nice to some­bo­dy who will have to live with your code later on – it just may be yourself!

Icons from the future

Some­thing that I’d tru­ly like to see is smar­ter icons, both on iOS and the desktop.

What if your icon were a litt­le, con­stant­ly run­ning snip­pet of Java­Script code that had access to the files wit­hin the app­li­ca­ti­on that brought it along? That way, the app could store sta­te infor­ma­ti­on for various times the icon needs to chan­ge or visua­li­ze some­thing. Also, the icon would not just alter an image, it could actual­ly pro­gram­ma­ti­cal­ly visua­li­ze some­thing – an ana­log clock that dis­play­ed the cur­rent time would be an easy exer­cise for the reader.

I real­ly think the pro­gramming world is ripe for an inno­va­ti­on like that.

User Interfaces as an act of communication

Even though we tend to com­ple­te­ly for­get about that, soft­ware qui­te often is a means of com­mu­ni­ca­ti­on bet­ween humans. I am not refer­ring to the way the pro­duct gets used (and a lot of soft­ware nowa­days is used for direct human to human com­mu­ni­ca­ti­ons, be that one-to-one or one-to-many) but rather that the ent­i­re user inter­face of the app­li­ca­ti­on – is an act of com­mu­ni­ca­ti­on bet­ween the deve­lo­per or deve­lo­p­ment team and the user. 

The last few years have seen tre­men­dous pro­gress on under­stan­ding what fac­tors influ­ence the expe­ri­ence for the user, and what tech­ni­ques and tools make an app­li­ca­ti­on easier and bet­ter to use. Com­pu­ters as tools have cer­tain­ly evol­ved and can be more effec­tively used. But still, the ten­den­cy is to see the app­li­ca­ti­on as some­thing detached from the peop­le who design and make it. I do not think this posi­ti­on holds true, and we do our­sel­ves a dis­ser­vice if we, as pro­du­cers of soft­ware, do not look at the ent­i­re com­mu­ni­ca­ti­ons pro­cess in depth. 

Look at your own expe­ri­ence as a user of soft­ware; I’m sure you can come up with examp­les of soft­ware that tre­at you well: con­si­de­ra­te, poli­te, hel­pful, play­ful. But just as well, there’s bad examp­les I am sure you quick­ly find: obnoxious, arro­gant, dys­func­tio­n­al apps. Pro­bab­ly, the peop­le who autho­red the inter­face and their talent to inter­act with other humans are not so dif­fe­rent from their works.

User Expe­ri­ence desi­gners are using Per­so­nae as a tool alrea­dy; envi­sio­ning typi­cal users and how they would go about inter­ac­ting with the pro­duct. If you envi­si­on tho­se peop­le alrea­dy, think about how you would inter­act with them. Con­si­der yourself as sit­ting with them in a mee­ting or on a date, wan­ting to sol­ve a pro­blem tog­e­ther (and that could be the one that the app­li­ca­ti­on you are wri­ting is to sol­ve) or try­ing to have a good time with them. A good conversation. 

Con­ver­sa­ti­ons and com­mu­ni­ca­ti­ons as a para­digm for user inter­faces has ano­t­her inte­res­ting impli­ca­ti­on: that of cul­tu­ral bias and presump­ti­ons. This can be ever­ything from not being able to use lan­guage-spe­ci­fic diacri­ti­cal marks in for­eign soft­ware pro­ducts and lack of inter­na­liz­a­ti­on for date and money fiel­ds to a lack of sen­si­ti­vi­ty in pro­ble­ma­tic are­as (a clas­si­cal examp­le being coun­try flags used as a selec­tor for lan­guage loca­liz­a­ti­on). The­re are cer­tain­ly other ways that we can look at this, like gen­der or eth­ni­cal presump­ti­ons in soft­ware – most stuff we inter­act with still is desi­gned by white men. 

So if we app­ly con­cepts that we know about human com­mu­ni­ca­ti­ons to soft­ware pro­ducts, can we gain new insights or deve­lop even bet­ter app­li­ca­ti­ons? Hope­ful­ly. We cer­tain­ly have a new tool chest avail­ab­le: a lot of rese­arch has been done on inter­per­so­nal com­mu­ni­ca­ti­ons and rela­ti­ons­hips. We would do well to take that to heart and app­ly it to our work. 

Lazy loading in PHP

In more pro­jects than I care to think about, I’ve seen a pat­tern that I dis­li­ke the more I see it. It appears qui­te inno­cent, but it brings about cost with no dis­cer­ni­ble benefit. 

Inclu­ding all of the application’s source code on each and every call being made to a page. It may be that one file is inclu­ded that lists all files the app brings along; it may be a list of require_once state­ments in every ent­ry page it has. But what is the bene­fit? Even if the page loads only tho­se files that it might even­tual­ly need, it pro­bab­ly inclu­des more than is war­ran­ted given the task it is cur­r­ent­ly given.

One solu­ti­on is to get into using an auto­loa­der; let the inter­pre­ter figu­re out by its­elf whe­ther it has alrea­dy seen all that it needs to exe­cu­te a given pie­ce of code. The other opti­on is to requi­re exter­nal files only at the point that you’­re cer­tain that you need them. Does your code do input saniti­zing and vali­da­ti­on befo­re it loads the clas­ses that then work with the saniti­zed values? Pro­bab­ly not – it’s much more com­mon to first load all the code, and only then start to work with what you are given. 

Lazy loading means that the inter­pre­ter only runs on tho­se code parts it needs, hel­ping to con­tri­bu­te to bet­ter app­li­ca­ti­on per­for­mance (becau­se we’­re not spen­ding time on code we don’t real­ly need, any­way). This also means using less resour­ces on the ser­ver, which means bet­ter use of resour­ces – ulti­mate­ly, having your code use less electric power. But the­re is even more bene­fits: code that has not been loa­ded can­not be causing any kind of inter­fe­rence; you’­re cer­tain that you don’t have to look into tho­se files when you’­re debug­ging. And then, code that has not been loa­ded also can­not be used for secu­ri­ty exploits–so you have less side effects the­re as well. 

It’s not that this is a par­ti­cu­lar­ly com­plex intel­lec­tu­al chal­len­ge, it’s more a mat­ter of per­spec­ti­ve and may­be wri­ting infra­st­ruc­tu­re code for your app. But to me, the bene­fits are worth the few more minu­tes spent whilst thin­king about your code.

Fluency in programming languages

I recent­ly had a con­ver­sa­ti­on with a friend who is cur­r­ent­ly job hun­ting for a pro­gramming job. He is a smart guy who holds a PhD in phy­sics, has spent a good num­ber of years in rese­arch and – as part of the life of a modern phy­si­cist – had to wri­te code as part of his day job alrea­dy. But he said some­thing that got me thin­king: he said that once you mas­ter the basic con­cepts of pro­gramming, you can pro­gram in just about any lan­guage you’­re put in front of. 

I stron­gly dis­agree. I feel that in many ways, Lud­wig Wittgenstein’s “The limits of my lan­guage mean the limits of my world.” holds even more true for pro­gramming lan­guages than it holds for natu­ral lan­guages. Of cour­se, given a good enough intro­duc­tion to a lan­guage and some time, you can wri­te pro­grams in many languages–provided they’­re simi­lar enough to what you know alrea­dy. But to reach a cer­tain level of mas­te­ry in any lan­guage, to be able to wri­te idio­ma­tic code, you have to immer­se yourself qui­te deeply and prac­ti­ce qui­te a bit. To my mind, most peop­le take a sizab­le num­ber of years to reach that level of exper­ti­se – and not reco­gni­zing that indi­ca­tes that this level has­n’t been attai­ned yet. 

To be a good pro­grammer, you should be able to know your lan­guage insi­de out. Can you give a list of short­co­mings of your lan­guage that goes bey­ond “It sucks?” Do you under­stand whe­re the limits of your lan­guage lie, what design decisi­ons were made with what pur­po­se in mind?

And to be an excel­lent pro­grammer, in how many dif­fe­rent lan­guages have you attai­ned that sta­tus? In how many dif­fe­rent types of lan­guages? If you’­re given a spe­ci­fic pro­blem, how do you deci­de which lan­guage is the appro­pria­te tool for the job?