Discussion :

[Stéphane le calme]

Être bon dans les compétitions de programmation est en corrélation négative avec effectuer un bon travail,
d'après le directeur de la recherche de Google

Dans le domaine du développement logiciel, les compétitions de programmation sont nombreuses et disposent de leurs propres règles. Nous pouvons par exemple citer le « hackathon », un concept provenant d’une fusion des mots « hack » et « marathon », qui a su peu à peu se faire une place dans la culture de l’entreprise technologique, mais aussi des écoles d’ingénieurs.

Les hackathons peuvent se présenter sous plusieurs formes, par exemple :

• les hackathons en ligne : vous participez depuis le confort de votre propre maison, la présentation est faite en streaming, mais bien sûr vous vous occupez vous-même de votre nourriture (pizza ?) ;
• les hackathons à sponsor unique : ils sont organisés ou financés par une seule entreprise. La différence ici est que généralement le thème autour des activités est d'utiliser un produit déjà développé par l’entreprise (ou dont elle se sert activement). Dans les coulisses, il s'agit généralement d'espèces de grandes entrevues pour les participants et les meilleures équipes peuvent se voir offrir des emplois. Pour ce type de hackathon, il est normal d'avoir une limite de deux ou trois personnes par équipe ;
• le marathon Hackathon : ce type d’événement a une durée inhabituellement longue. Il peut aller d’une semaine à un mois. Les candidats pourront probablement apporter une version plus aboutie de leurs différents projets étant donné qu’ils disposent de plus de temps.

D’autres rendez-vous de programmation bénéficient d’une certaine popularité, à l’instar des compétitions comme la Pwn2Own, un concours annuel où des chercheurs en sécurité informatique essaient de pénétrer des ordinateurs équipés d'un système d'exploitation et de divers logiciels incluant un navigateur web entièrement mis à jour.

Si certains peuvent estimer que les compétitions en développement informatique participent à mieux armer l’individu dans le métier, et donc à être meilleur au travail, Peter Norvig, directeur de recherche pour le compte de Google, est de ceux qui pensent qu’être un gagnant dans les concours de programmation constitue un facteur négatif pour bien effectuer son travail.

Il reconnaît que sa conclusion est surprenante et insiste sur le fait que cela ne veut pas dire qu’il décourage les développeurs qui veulent remporter des compétitions. Pour lui, le problème réside dans le fait que les compétiteurs habitués à la victoire ont tendance à vouloir avoir la réponse très vite et passer à la prochaine étape. Toutefois, « vous avez de meilleures performances au boulot si vous êtes un peu plus réfléchi et que vous allez doucement et vous assurez que vous faites bien les choses ».

Source : YouTube

Et vous ?

Partagez-vous son avis ? Pourquoi ?

Voir aussi :

Trolldi : hackathon ! Qu'évoque ce concept pour vous ? Y avez-vous déjà participé ? Partagez votre expérience

[Marco46]

« vous avez de meilleurs performances au boulot si vous êtes un peu plus réfléchi et que vous allez doucement et vous assurez que vous faites bien les choses »

Ben ouai, software craftmanship quoi !

"We don't ship shit"

Le principe du hackaton est exactement l'inverse, on veut livrer un truc "qui marche" avec une date de livraison figée. Donc scope fonctionnel figé, date de livraison figée, c'est forcément la qualité qui morfle. C'est juste un des fondamentaux du génie logiciel, cf triangle qualité / cout / délai.

[kilroyFR]

Le resultat d'un hackathon c'est un proto qui tombe en marche, une maquette ameliorée, rien de plus. C'est plus un POC qu'autre chose.

[neuneutrinos]

C'est moi où corrélation=causalité ici ?
Bref... un peu de recul ne peut pas faire de mal.

[CodeurPlusPlus]

On a tendance à faire moins bien quand on est pressé ?
Non ? Sans blague ?

Cela n'empêche pas que certains feront mieux en étant pressés que d'autres en prenant leur temps... et tant mieux pour google, parce qu'on ne me fera pas croire qu'ils recrutent autre chose que des gagnants

[Ikknar]

Je pense que son idée est plutôt que ceux qui gagnent ces concours s'ils appliquent ces méthode là pour coder en entreprise, par esprit de compétition avec les autres développeurs, pour prouver sa valeur ou simplement car il veut finir son travail le plus vite possible ou tout autres raisons, seront moins performants qu'un développeur un peu plus lents mais n'ayant pas cette objectifs de vitesse.
En tout cas c'est comme ça que je le comprends ^^

[redbullch]

C'est surtout qu'un individu qui pratique beaucoup de compétitions sera beaucoup plus à l'aise pour résoudre des problèmes similaires, posés lors d'un entretient d'embauche.

[Hhissen]

Moi je pense plutôt que ceux qui participent a ce genre de hackAton sont déjà bon ou cales dans leur domaine de prédilection (langage de programmation) et donc ont un sens un peu aiguisé quant a la façon de réfléchir de concevoir une solution ...
Bref participer aux challenges est pour moi une source d'inspiration et de motivation....

[jm_zz]

Voilà je possède mes 18 ans.d expérience IT et je ne suis absolument pas d 'accord. Et ce désaccord est profond. Il est d ailleurs symptômatique des divergences actuelles dans le monde de la IT.
Why ? Because of le beau geste.
De mes racines paysannes ( vivaces) je ne saurai dire combien le beau geste ... Sûr
Et bien plus appréciable que la longue monotimie du code conchie que je me coltine tous les jours.
Là il est peut être question du beau !
Respect pour tous les jeunes samouraï des temps modernes qui s ' oublient quel que temps vers le beau... Le go !
Et me font Rêver bien en dehors de ces conneries d un mauvais DSI ( cf l état des offres pro de Google mdr/)

[jm_zz]

Il a déjà code ou just debug ? Aih ?

[frecco]

Je partage entièrement son point de vue depuis de nombreuses années.
Le principe du hackathon est d'aller vite et de produire du code à l'arrache. C'est-à-dire à littéralement pisser du code et produire du code jetable.
Cela amène des mauvaises pratiques.

Un bon développeur en entreprise doit surtout veiller à la conception, et produire du code de qualité qui est par définition lisible, maintenable, évolutif et élégant. Bref c'est radicalement une approche opposée de la programmation.

[tartenpion32]

Bien que l'article soit un peu court, je ne suis pas surpris par la conclusion.
Il n'est pas précisé les critères d'évaluation d'un bon travail, mais intuitivement il est facile de comprendre que les "compétiteurs" ne soient pas les meilleurs.
Gagner une compétition, ça se fait au détriment des autres en compétition ce jour là, à cet instant donné. Ça suppose un état d'esprit de non collaboration avec les autres, puisqu'ils sont des concurrents, ce qui ne peut pas être de bon augure pour un "bon" travail.
L'idée même de ce genre de vanité (ces compétitions) me semble futile.
Vouloir y participer est selon moi un signe d'immaturité, et donc une perte de temps;
et que des DRH puissent se fier à ce genre d'enfantillage pour faire leur choix, je trouve cela inconséquent.

[Jaydes]

En effet ça me parait juste. Si on est DEV de tout poil ou Hacker on doit réfléchir et concevoir pour faire un truc qui fonctionne.
Le salaria c'est tout l'inverse on reçois des ordre de chef débile et incompétent donc oui en effet il jugera que nous sommes incompétents.

Mais bon quelque part quand un crétin dégénéré me dit que je suis un crétin ça me rassure plus que l'inverse

[gene69]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Un bon développeur en entreprise doit surtout veiller à la conception, et produire du code de qualité qui est par définition lisible, maintenable, évolutif et élégant. Bref c'est radicalement une approche opposée de la programmation.

De mon expérience, un bon developpeur c'est un nobody dont on entends jamais parler. Des qu'il travaille mal, on voit des crises, du mode pompier et là ça devient une start qui trouvera la solution parce qu'on lui mettra le nez dedans.

Tiens j'ai récuperé le résultat d'un hackathlon, euuuh a part dire que c'est inexploitable, point de vue qualité de code il y a toutes les mauvaises pratiques immaginables (et peut être plus) que ça va couter cher à tout réécrire et personne n'a les moyen de le faire... mais bon c'est réputé innovant.

[flapili]

Spoiler HS mais pas trop

personnellement je trouve que les développements de software poussés par des contrats et des dates sont très proches des "marathon Hackathon"
... et quand on voit les soft pondus sous la contrainte du temps c'est souvent du n'importe quoi, bugée, mal opti, ect ... et qu'il faille n patch.

heureusement que les jeux AAA ne sont jamais en "marathon Hackathon", ça se saurait