Un buon modo per capire se un programmatore è davvero valido è osservarne le azioni ed i risultati, ossia codice e programmi.
E’ indubbio che ogni linguaggio di programmazione, framework o tecnologia in genere o altro tendano ad avere proprie best practices, favorire un certo stile di programmazione, ma il bravo programmatore sostanzialmente opera sempre nello stesso modo, deterministicamente ripetitivo.
Di tanto in tanto capita di dover accettare decisioni altrui e di cui si conosce già anzitempo l’esito negativo: si accetta lo status quo per evitare problemi di qualunque tipo.
Tuttavia c’è di peggio: accettare qualcosa o non reagire affatto, che poi è la stessa cosa, a qualcosa di negativo che accade accanto a noi.
Si chiama apatia e si manifesta in molte forme. Una forma abbastanza comune è quella che gli anglofili chiamano “bystander effect” e che Wikipedia definisce così:
“The ‘bystander effect’ or ‘Genovese syndrome’ is a social psychological phenomenon that refers to cases where individuals do not offer any means of help in an emergency situation to the victim when other people are present.
The probability of help has in the past been thought to be inversely related to the number of bystanders; in other words, the greater the number of bystanders, the less likely it is that any one of them will help.”
Non immischiarsi, evitare di finire invischiati. Non a caso viene definita come l’opposto della parabola del Buon Samaritano.
Taaanto tempo fa fa mi sono ritrovato a riflettere se aggiungere o meno una certa funzionalità ad un progetto che stavo sviluppando per lavoro. Nulla di trascendentale ma piuttosto secondario rispetto agli obiettivi del progetto.
Che fare in questi casi?
In un post di qualche giorno fa su Coding Horror viene riportata per l’ennesima volta una frase di Joel Spolsky. La riporto in forma estesa:
The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage.
By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.
By writing clear technical documentation for end users, they allow people to figure out what their code is supposed to do, which is the only way those users can see the value in their code. There’s a lot of wonderful, useful code buried on sourceforge somewhere that nobody uses because it was created by programmers who don’t write very well (or don’t write at all), and so nobody knows what they’ve done and their brilliant code languishes.
I won’t hire a programmer unless they can write, and write well, in English. If you can write, wherever you get hired, you’ll soon find that you’re getting asked to write the specifications and that means you’re already leveraging your influence and getting noticed by management.
Beh, che dire, questa è l’essenza del vero programmatore.
