Ce que l’avènement du code m’a appris sur la science des données

dans le L’avènement du codeune série de défis de programmation quotidiens lancés pour la première fois tout au long du mois de décembre. Les défis quotidiens contiennent généralement deux énigmes basées sur un problème similaire. Même si ces défis et problèmes ne ressemblent pas aux flux de travail typiques de la science des données, j’ai réalisé que bon nombre des habitudes, façons de penser et d’approcher les problèmes qu’ils encouragent peuvent être étonnamment bien traduites dans un travail axé sur les données. Dans cet article, je réfléchis à cinq apprentissages que j’ai appris en suivant le L’avènement du code défi cette année et comment ils se traduisent en science des données.

Pour moi, L’avènement du code était plutôt un environnement de pratique contrôlée pour revoir les fondamentaux et travailler sur mes compétences en programmation. Vous vous concentrez sur l’essentiel car les distractions auxquelles vous seriez confronté dans un travail quotidien ne sont pas présentes ; vous n’avez pas de réunions, d’exigences changeantes, de communication avec les parties prenantes ou de frais généraux de coordination. Au lieu de cela, vous disposez d’une boucle de rétroaction simple et binaire : votre réponse est correcte ou elle ne l’est pas. Il n’existe pas de « presque correct », ni de moyen d’expliquer le résultat, ni de vendre votre solution. Dans le même temps, vous avez la liberté et la flexibilité de choisir n’importe quelle approche qui vous semble appropriée, à condition que vous parveniez à une solution correcte.

Travailler dans un tel environnement était assez difficile, mais très précieux car cela révélait également des habitudes. Étant donné que vous avez très peu de place pour l’ambiguïté et que vous ne pouvez pas cacher vos erreurs, tous les défauts de votre travail ont été immédiatement révélés. Au fil du temps, j’ai également réalisé que la plupart des échecs que j’ai rencontrés n’avaient pas grand-chose à voir avec la syntaxe, le choix de l’algorithme ou l’implémentation du codage, mais bien plus avec la façon dont j’avais abordé les problèmes avant de toucher au code. Ce qui suit sont mes principaux enseignements de cette expérience.

Leçon 1 : Esquissez la solution – Réfléchissez avant de coder

Un modèle qui a souvent fait surface au cours L’avènement du code C’était ma tendance à passer directement à la mise en œuvre. Face à un nouveau problème, j’étais généralement tenté de commencer à coder immédiatement et d’essayer de converger vers une solution le plus rapidement possible. Ironiquement, cette approche a souvent provoqué exactement le contraire. Par exemple, j’ai écrit du code profondément imbriqué pour gérer les cas extrêmes qui gonflaient le temps d’exécution du code sans me rendre compte qu’une solution beaucoup plus simple existait.

Ce qui m’a finalement aidé, c’est de prendre du recul avant de commencer le code. Au lieu de cela, j’ai commencé par noter les exigences, les entrées et les contraintes. Le processus de notation de cela m’a aidé à obtenir un niveau de clarté et de structure qui me manquait lorsque je me suis lancé directement dans le code. De plus, réfléchir aux approches possibles, esquisser une solution approximative ou travailler sur un pseudocode a permis de formaliser encore plus la logique nécessaire. Une fois cela fait, l’acte de l’implémenter via le code est devenu beaucoup plus facile.

Cet apprentissage peut être transposé à la science des données, car de nombreux problèmes peuvent être difficiles en raison de buts peu clairs, d’objectifs mal définis ou parce que les contraintes et les exigences ne sont pas connues suffisamment à l’avance. En définissant les résultats souhaités et en raisonnant sur la solution avant de commencer à écrire du code, vous pouvez éviter des efforts inutiles. Travailler en arrière à partir du résultat escompté au lieu d’avancer à partir d’une technologie préférée permet de rester concentré sur l’objectif réel qui doit être atteint.

Apprentissage 2 : Validation des entrées – Connaissez vos données

Même après avoir adopté cette approche consistant à esquisser des solutions et à définir dès le départ la solution souhaitée, un autre obstacle récurrent est apparu : les données d’entrée. Certains échecs que j’ai rencontrés n’avaient rien à voir avec un code défectueux mais avec des hypothèses sur les données que j’avais formulées et qui ne tenaient pas dans la pratique. Dans un cas, j’ai supposé que les données avaient une certaine limite minimale et maximale qui s’est avérée erronée, conduisant à une solution incorrecte. Après tout, le code peut être correct lorsqu’il est vu isolément, mais échouer complètement lorsqu’il travaille avec des données pour lesquelles il n’a jamais été conçu.

Cela montre une fois de plus pourquoi la vérification des données d’entrée est si cruciale. Souvent, ma solution n’avait pas besoin d’être entièrement remaniée, de petits ajustements tels que l’introduction de conditions supplémentaires ou de contrôles de limites suffisaient pour obtenir une solution correcte et robuste. En outre, l’enquête initiale sur les données peut donner des indications sur l’ampleur des données et indiquer quelles approches sont réalisables. Face à de grandes plages, des valeurs extrêmes ou une cardinalité élevée, il est très probable que les méthodes de force brute, les boucles imbriquées ou les approches combinatoires atteignent rapidement une limite.

Naturellement, cela est tout aussi important dans les projets de science des données où les hypothèses sur les données (implicites ou explicites) peuvent entraîner de graves problèmes si elles ne sont pas vérifiées. L’analyse précoce des données est une étape essentielle pour éviter que les problèmes ne se propagent en aval, où ils peuvent devenir beaucoup plus difficiles à résoudre par la suite. L’essentiel à retenir n’est pas d’éviter du tout les hypothèses sur les données, mais plutôt de les rendre explicites, de les documenter et de les tester dès le début du processus.

Apprentissage 3 : Itérer rapidement – Progresser plutôt que perfection

Les énigmes dans L’avènement du code sont généralement divisés en deux parties. Même si la seconde s’appuie souvent sur la première, elle introduit une nouvelle contrainte, un nouveau défi ou une nouvelle tournure, telle qu’une augmentation de la taille du problème. L’augmentation de la complexité invalidait souvent la solution initiale pour la première partie. Néanmoins, cela ne signifie pas que la solution de la première partie est inutile car elle fournit une base de référence précieuse.

Disposer d’une telle base de référence permet de clarifier le comportement du problème, la manière dont il peut être résolu et les résultats déjà obtenus par la solution. À partir de là, les améliorations peuvent être abordées de manière plus structurée, car on sait quelles hypothèses ne sont plus valables et quelles parties doivent être modifiées pour parvenir à une solution réussie. Il est donc beaucoup plus facile d’affiner une solution de base concrète que de concevoir dès le départ une solution abstraite « parfaite ».

Dans L’avènement du codela deuxième partie n’apparaît qu’une fois la première résolue, rendant ainsi inutiles les premières tentatives visant à trouver une solution qui fonctionne pour les deux parties. Cette structure reflète une contrainte couramment rencontrée dans la pratique, car on ne connaît généralement pas toutes les exigences à l’avance. Essayer d’anticiper toutes les extensions possibles qui pourraient être nécessaires est non seulement largement spéculatif mais également inefficace.

En science des données, des principes similaires peuvent être observés. À mesure que les exigences évoluent, les sources de données évoluent et les parties prenantes affinent leurs besoins et demandes, les projets et les solutions doivent également évoluer. En tant que tel, commencer par des solutions simples et itérer sur la base de retours réels est bien plus efficace que de tenter de proposer dès le départ un système entièrement général. Une solution aussi « parfaite » est rarement visible au début et c’est l’itération qui permet aux solutions de converger vers quelque chose d’utile.

Apprentissage 4 : Concevoir à grande échelle – Connaître les limites

Alors que l’itération met l’accent sur le fait de commencer par des solutions simples, L’avènement du code souligne également à plusieurs reprises l’importance de comprendre l’échelle et la façon dont elle affecte l’approche à utiliser. Dans de nombreuses énigmes, la deuxième partie n’ajoute pas simplement de la complexité logique, mais augmente également considérablement la taille du problème. Ainsi, une solution avec une complexité exponentielle ou factorielle peut être suffisante pour la première partie mais commence à devenir peu pratique lorsque la taille du problème augmente dans la deuxième partie.

Même en partant d’une base de référence simple, il est crucial d’avoir une idée générale de la manière dont cette solution évoluera. Les boucles imbriquées, l’énumération par force brute ou les recherches exhaustives de combinaisons signalent que la solution cessera de fonctionner aussi efficacement lorsque la taille du problème augmente. Connaître le point de rupture (approximatif) permet donc de mieux évaluer si ou quand une réécriture est nécessaire.

Cela ne contredit pas l’idée d’éviter une optimisation prématurée. Cela indique plutôt qu’il faut comprendre les compromis qu’une solution implique sans avoir à mettre en œuvre immédiatement l’approche la plus efficace ou la plus évolutive. Concevoir à grande échelle signifie avoir conscience de l’évolutivité et de la complexité, sans avoir à optimiser aveuglément dès le départ.

Le parallèle avec la science des données est également présenté ici, car les solutions peuvent bien fonctionner sur des échantillons de données ou des ensembles de données limités, mais sont susceptibles d’échouer lorsqu’elles sont confrontées à des tailles de « niveau de production ». Être conscient de ces goulots d’étranglement, reconnaître les limites probables et garder à l’esprit des approches alternatives rend ces systèmes plus résilients. Savoir où une solution pourrait cesser de fonctionner peut éviter des refontes et des réécritures coûteuses ultérieurement, même si elles ne sont pas mises en œuvre immédiatement.

Apprentissage 5 : Soyez cohérent – ​​L’élan bat la motivation

L’un des enseignements les moins évidents de la participation à l’Avènement du Code était moins lié à la résolution de problèmes qu’à la « présentation ». Résoudre un casse-tête chaque jour semble gérable en théorie, mais en pratique, c’était un défi, surtout lorsqu’il se heurtait à la fatigue, au manque de temps ou à une baisse de motivation, surtout après une journée de travail complète. Espérer que la motivation réapparaisse comme par magie n’était donc pas une stratégie viable.

Les véritables progrès sont venus du travail quotidien sur les problèmes, et non de poussées d’inspiration occasionnelles. La répétition a renforcé les façons de penser et de démêler les problèmes, ce qui a créé une dynamique. Une fois cet élan créé, les progrès ont commencé à s’accumuler et la cohérence comptait plus que l’intensité.

Le développement des compétences en science des données provient rarement de projets ponctuels ou d’études approfondies isolées. Au lieu de cela, cela résulte d’une pratique répétée, d’une lecture attentive des données, de la conception de solutions, d’itérations sur des modèles et de débogage d’hypothèses effectuées de manière cohérente au fil du temps. S’appuyer sur la motivation n’est pas viable, mais avoir des routines fixes rend cela durable. L’avènement du code illustre cette distinction : alors que la motivation fluctue, la cohérence augmente. Avoir une telle structure quotidienne a contribué à faire de la résolution d’énigmes une habitude plutôt qu’une aspiration.

Pensées finales

En y repensant, la valeur réelle que j’ai tirée de ma participation à L’avènement du code Il ne s’agissait pas de résoudre des énigmes simples, d’apprendre de nouvelles astuces de codage, mais plutôt de rendre visibles mes habitudes. Cela a mis en évidence les domaines dans lesquels j’ai tendance à me précipiter vers des solutions, ceux où j’ai tendance à trop compliquer et ceux où ralentir et prendre du recul m’auraient fait gagner beaucoup de temps. Les énigmes en tant que telles n’étaient qu’un moyen pour parvenir à une fin, les enseignements que j’en ai tirés étaient la vraie valeur.

L’avènement du code cela a mieux fonctionné pour moi lorsqu’il est considéré comme une pratique délibérée plutôt que comme une compétition. Se présenter de manière cohérente, se concentrer sur la clarté plutôt que sur l’intelligence et affiner les solutions au lieu de rechercher des solutions parfaites dès le départ s’est avéré bien plus précieux que de trouver une solution unique.

Si vous ne l’avez pas encore essayé vous-même, je vous recommande de tenter votre chance, soit lors de l’événement de l’année prochaine, soit en résolvant des énigmes passées. Le processus fait rapidement apparaître des habitudes qui se prolongent au-delà des énigmes elles-mêmes. Et si vous aimez relever des défis, vous trouverez probablement cela une expérience véritablement amusante et enrichissante.