Ciao 👋
Sei qui perché qualcuno ti ha indirizzato a questo post in risposta a un'idea che hai suggerito su come migliorare Exercism?
Prima che il nostro team investa tempo a esplorare la tua idea, spera che tu legga questo testo e valuti se la tua idea potrebbe essere già stata presa in considerazione e quali insidie potrebbe nascondere.
Se aggiungi queste considerazioni e le possibili insidie al tuo suggerimento, e ti chiedi perché la tua idea potrebbe non essere stata già messa in pratica, è probabile che otterrai una risposta più rapida e più positiva.
Quindi, cosa significa «la recinzione di Chesterton»?
La recinzione di Chesterton è un'idea ispirata a una citazione dal libro del 1929 dello scrittore G.K. Chesterton, The Thing.
È diventata famosa perché è stata citata da John F. Kennedy.
Questa è la citazione originale:
In un caso del genere esiste una certa istituzione o legge; diciamo, per semplicità, una recinzione o un cancello eretti attraverso una strada.
Il riformatore più moderno si avvicina allegramente e dice: «Non vedo l'utilità di questo; togliamolo di mezzo».
Al che il riformatore più intelligente farà bene a rispondere: «Se non ne vedi l'utilità, di certo non ti lascerò toglierlo di mezzo. Vai via e rifletti. Poi, quando potrai tornare e dirmi che ne vedi l'utilità, potrò permetterti di distruggerlo».
L'idea della recinzione di Chesterton è che se non capisci perché qualcosa è lì, probabilmente non capisci nemmeno perché dovrebbe essere rimosso.
Allo stesso modo, se non capisci perché qualcosa non è lì, probabilmente non capisci perché è stato lasciato fuori.
Una regola semplice da ricordare è: «Non rimuovere una recinzione finché non sai perché è stata messa lì in primo luogo.»
In che modo questa nozione riguarda Exercism?
Su Exercism siamo fortunati: tantissime persone si uniscono alla nostra comunità continuamente e pubblicano i loro pensieri e le loro idee.
Molte di queste idee sono nuove, innovative, entusiasmanti e sbloccano il nostro modo di pensare.
Quindi, se hai un'idea o un suggerimento, siamo felici di accoglierlo!
Tuttavia, spesso le persone pubblicano idee di cui si è già discusso molte volte.
Rispondere a queste idee, riesaminare o giustificare di nuovo le nostre decisioni può prosciugare le energie del nostro team.
Questo articolo vuole aiutare a proteggere quel tempo e quelle energie.
Exercism è stato progettato, ingegnerizzato e costruito da migliaia di persone di grande talento.
È un prodotto estremamente ragionato: le cose ci sono perché sono state progettate per esserci, e spesso altre cose sono lasciate fuori perché sono state progettate per essere lasciate fuori.
Quasi tutto su Exercism è stato dibattuto, discusso e riprogettato molte volte.
Quindi, prima di pubblicare la tua idea, chiediti se potremmo averla già presa in considerazione e perché potremmo aver fatto le cose diversamente da come stai suggerendo.
E ricorda: più la tua idea sembra ovvia, più è probabile che sia già stata discussa e dibattuta molte volte. Quindi, quando la presenti, presentala insieme alle possibili avvertenze e insidie.
Se hai l'istinto di dire «perché non semplicemente ...», allora rientra quasi certamente in questa categoria.
Non avere mai paura di pubblicare, ma per favore rifletti bene prima!
Hai un esempio?
Una frustrazione comune è che gli studenti inviano ai mentori codice che non supera i test.
Un suggerimento altrettanto comune è: «Perché non eseguire automaticamente i test nella CLI prima che qualcuno invii il proprio codice?»
Sembra un'ottima idea: la CLI può semplicemente chiamare un comando per eseguire i test e impedire allo studente di inviare se i test non passano.
Allora, prima di tutto: cosa significa «semplicemente chiamare un comando per eseguire i test»?
Significa scrivere uno script per ciascuno dei 52 linguaggi su Exercism in grado di eseguire i test e controllare il risultato.
È un po' di lavoro, ma fattibile.
Ma significa anche scrivere quello script in modo che funzioni su Windows, MacOSX e Linux, in tutte le versioni e configurazioni possibili. È una quantità di lavoro enorme (se non illimitata).
«Perché deve essere ogni configurazione?» potresti chiedere.
Beh, perché stai attivamente bloccando qualcuno dall'usare Exercism a meno che non riesca a eseguire questo script.
Questo significa anche che non può mai fallire.
Se per qualche motivo lo script non parte, lo studente è completamente bloccato.
Un bug in uno di quei 52*3*n script significa che uno studente non può più usare il track su quel sistema operativo.
Come faresti a testarlo?
Non puoi.
Ma, dirai, si potrebbe semplicemente aggiungere un flag --skip-tests.
È un buon suggerimento, ma ci riporta al punto di partenza: le persone possono scegliere di saltare i test quando vogliono.
Solo che ora ci troviamo in una situazione in cui è marginalmente meno probabile che vengano inviati test falliti, quindi i mentori se lo aspettano meno, il che rende più spiazzante e confuso quando i test sono effettivamente falliti.
«Ma le persone, in genere, non lo farebbero», potresti obiettare. Vero, per alcuni linguaggi in cui eseguire i test richiede 0,5s.
Ma per i linguaggi in cui eseguire i test richiede 20s, dover aspettare altri 20s per inviare è incredibilmente frustrante per gli studenti, quindi saltare i test finali diventerebbe la norma.
Indipendentemente da dove finirà questa conversazione, è chiaro che qui c'è molta più complessità di quanto sembri a prima vista. Ci sono sfide tecniche da considerare, problemi di flusso di lavoro a cui pensare e la consapevolezza che i track sono diversi al punto che qualcosa di rapido e semplice per uno è doloroso per un altro.
Quindi, invece di proporre il suggerimento «perché non eseguire i test prima dell'invio», facciamoci una domanda: «Perché le persone pubblicano soluzioni che non superano i test?»
E allora le cose si fanno interessanti.
La risposta generale è che sono bloccati o confusi.
E hanno bisogno di aiuto.
Il che significa che inviare test falliti è un'euristica davvero importante per i mentori: indica che questo studente ha bisogno di aiuto.
Sì, è frustrante perché i mentori non sanno subito se il codice è «corretto» o no. Tuttavia, possono scaricare il codice ed eseguirlo per verificarlo (cosa che la maggior parte dei mentori fa sulle soluzioni non banali) e poi sapere con certezza al 100% se è corretto o no.
E gli studenti bloccati che hanno bisogno di aiuto non finiscono ancora più bloccati, bisognosi di ancora più aiuto, ma arrivano a un mentore che può vedere e suggerire correzioni più rapidamente.
Nota: stiamo in realtà risolvendo questo problema eseguendo i test lato server: un'impresa grande e costosa, ma che vale lo sforzo per l'esperienza migliorata degli studenti e, cosa cruciale, per far risparmiare tempo ed energie ai nostri mentori.
Altro?
Tre cose:
-
Questo articolo su Second Order Thinking è una buona lettura. La citazione «Non rimuovere una recinzione finché non sai perché è stata messa lì in primo luogo» viene da questo post.
-
The Thing di G.K. Chesterton è disponibile qui https://archive.org/details/G.K.ChestertonTheThing.
- La tua idea potrebbe davvero essere nuova e valida. Non aver paura né vergogna di suggerirla!
