Reprise du message précédent :

je pense, j'ai suffisament bossé avec des gens de Google pour voir comment c'est.  
Je suis pas naif, tout n'est pas tout rose non plus, mais je suis à un tel point ici que je vois pas comment ça pourrait etre pire.
ça me rappelle moi chez Volvo : je gueulais tant et plus quand j'y étais, et avec le recul je me dis souvent que c'était une boite tellement bien gérée comparé à ici. En fait si ma boite actuelle était gérée comme Volvo je pense qu'on doublerais la marge...
 
et je tombe déjà de ma chaise avec la qualité des RH et du process de recrutement...
 

ça c'est parce que t'habites un pays dérégulé mon ami, en Europe c'est interdit pour les laits destinés aux enfants de moins de 6 mois (ce qui de fait revient à interdire la pub, puisque la décision d'allaitement se fait toujours dans les 6 premiers mois). Autre point, environ 15% des femmes ne peuvent pas allaiter à la naissance, donc c'est ça ou tu trouves une nourrice (profession un peu disparue), soit tu laisses ton gosses creuver (fun fact historique : c'est pour lutter contre ça que Henri Nestlé a inventé le procédé pour faire du lait en poudre, ce qui a permis le lait maternisé, et le chocolat au lait).
Source : ma femme bossait pour une de nos marques de nutrition infantile, et elle a pas pu allaiter.
 

trouve moi une boite qui ait un process 100% fiable...
après pour avoir pas mal recruté moi même, je suis assez admiratif de leur process, qui cherche vraiment à contrer le maximum de biais possibles. Il n'est pas parfait et on peut y trouver des failles, mais c'est quand meme un truc super bien pensé.
 

ça c'est le gros point : à ce stade c'est incomparable avec des industries plus traditionnel.

y'a bien un truc que je déteste dans ce job c'est d'envoyer mon code dans une review.

pourquoi? C'est le meme principe qu'une PR au final non?

mon interne qui fait des suggestions pour notre process de deployment après avoir lu Accelerate & le DevOps Handbook, c'est beau de les voir grandir  

parce que c'est une collection d'erreur stupides qui sont relevées.
 
(et de tri des imports, mais je me sens pas coupable pour ça, je comprends rien à l'algo de tri)

Extrait de nos guidelines sur le tri des imports :

https://gist.github.com/olivierlamb [...] d00663623f

edit : c'est tout de même pratique d'avoir les même règles de tri, parce que quand on modifie un truc, on rate rien dans le diff et ça reste clair

Tient, j'casse les couilles de tout le monde au taff avec ça.

J'ai enfin reussi à mettre tout le monde au Linter et Prettier etc. Next step, que tout le monde ait le reflexe de bien trier.

mais c'est pas à moi de trier les imports, les IDE font ça très bien, quand les règles ont du sens.

Ça ressemble aux règles de tri Python, en globalement plus complexe.

En python t'aurais les groupes stdlib / dépendances / package courant, et dans chaque groupe import de module "import foo.bar", correspondant au défault? IDK) suivi d'import de symboles contenus ("from foo import bar" ). Imports null et wildcard c'est nÿet et pas de cas spécial pour le multiline (c'est rare, généralement t'importes le module).

ces règles sont insuffisantes au quotidien (en particulier il manque la clef de tri) et j'arrive jamais à les retenir.

Fait modifier les règles alors C'est pas gravé dans le marbre

https://www.youtube.com/watch?v=GG_PMF27tDE
ça devient vraiment bon.

Toi, t'as pas dû voir Black Mirror s4e5

non, je mate pas cette série, je suis déjà assez anxieux comme ça.

Je suis d'accord avec nraynaud : on fait les règles qu'on veut et on fournit les outils qui les suivent aveuglément.

La détection d'obstacle est bluffante

Au fait Jubi, tu vas y faire quoi chez G.oogle ?

 
Anéfé.

 
C'est pas super malin d'avoir un système de review sans fournir un coding style et (si c'est en interne) sans fournir des configurations d'IDE toutes faites.

 
Commander les cafés.

 
Et le lien que j'ai posté c'est du poulet ?
 
Quand à fournir les configurations d'IDE, c'est bien gentil mais on va fournir une conf pour lesquels exactement ? Tous ? On utilise Code/Atom/Sublime déjà.

Non mais vous utilisez des technos de gitan c'est pour ça. Du coup il vous faut 45 outils de plus pour complémenter votre éditeur de texte qui est un peu neuneu.
 
(ma remarque sur le coding style était plus générale, pas basée sur un cas spécifique)

Perso qu'on édite encore du code dans un simple éditeur de texte en 2018 me dépasse complètement, j'ai l'impression d'être un extra terrestre.
 
Le premier meetup hébergé dans notre filiale "devs juniors" qui vont principalement faire du Java ou du C#, c'est un truc sur Vim. Tuez moi.

T'es un extra-terrestre

L'assistance phénoménale que me fournit l'IDE, la sécurité dans les refactorings, l'infusion permanente de bonnes pratiques via les inspections, l'affichage des valeurs des variables à côté du code pendant le debugging, c'est inestimable et totalement hors de portée de la plupart des éditeurs de texte. Et je ne fais qu'effleurer le sujet.

La non compréhension des systèmes de build, de la gestion de dépendances, le faux sentiment de sécurité que te donne les inspections de l'IDE, la non portabilité sur les env de prod ..etc.. Ya vraiment que sur le debugging ou les IDE offre un vrai confort, mais c'est certainement parce que j'ai jamais fait l'effort de bien gérer GDB.

Perso jsuis passé d'intellij à vscode sans aucun soucis.

Le seul truc qui me manque c'est la gestion des BDD, et les 3 ecrans pour résoudre des conflits de merge.
Le reste je m'en passe très bien. Après je fais pas de Java ou de C#.

Les IDE c'est top pour naviguer efficacement dans le code, et pour débugger. Ce qui n'est pas rien.

http://editorconfig.org/

C'est une base, mais il manque des choses.

En gros tu files un IDE à un mec mauvais et t'es étonné que ça devienne pas un bon dev ? C'est un peu léger, non ?

 
Ouaip je sais bien, mais c'est mieux que rien dans un projet. Ça permet déjà de limiter certaines choses.
 
Après, effectivement l'idéal ça reste d'utiliser le même IDE pour tout le monde (ici on est sur PhpStorm), et de partager le code style en imposant un reformatage de code avant publication.
 
Mais c'est clair qu'EditorConfig est super limité quand je vois jusqu'où on peut aller dans la configuration des produits JetBrains.

emacs et bistro forever

je ne connais pas très bien vim mais il me semble qu'avec son système de plugin tu peux le transformer en IDE qui ,suivant le language, permet de faire tout ce que vous dites.
Après ça ne sera clairement pas un ide très user friendly pour un débutant, ni sexy au niveau de l'apparence

vim tu peux en faire un IDE pour ce que tu veux (bash, ton langage maison, etc), mais tu n'arriveras pas au niveau d'IntelliJ pour java, VS/QtCreator pour C++, etc. Et même si tu y arrives, tu auras passé un temps fou à rajouter des configs perso et des plugins. Ça reste mon éditeur préféré, je l'utilise souvent depuis Visual Studio pour les éditions un peu 'hardcore' de code.

De quoi, faut lire les liens ?    
 
Il faut un outil en ligne de commande pour que les rebelles puissent bosser sinon, vous avez ça ?

T'es pas complètement un extraterrestre tant que tu utilises une police monotype

 
Ouais c'est eclipse dans le terminal avec un editing model chelou quoi.

Je sais pas quel IDE en carton tu utilises, mais IntelliJ ne fait qu'appeler le système de build du projet (maven, gradle, sbt, ...), donc ça change strictement rien à la compréhension ou la portabilité de ton fichier de build ou la gestion des dépendances.
 
Et pour les inspections, avec un bon langage c'est le compilateur qui fait le gros du boulot, l'IDE ne fait que te présenter ça de manière plus interactive.

Eclipse a son propre compilateur qui est notamment capable de compiler du code avec des erreurs de compilation au milieu. Et le support Maven dans Eclipse est historiquement naze.
 
J'utilise IntelliJ et je build avec Maven.
Le sentiment de sécurité des inspections y est réel (évidemment il faut bien comprendre les inspections qu'on utilise, avoir un outil puissant ne veut pas dire qu'on arrête de réfléchir), la portabilité est un non-problème en Java pour la grosse majorité des applications développées. La gestion des dépendances via Maven est nettement meilleure avec certains outils visuels qu'à la main avec son éditeur de texte et la ligne de commande.

 
Je me posais une question, est ce que tu as eu l'occasion de de voir sur un projet non java ?