Reprise du message précédent :

 
Tu fais chier avec ta question, tu viens de me rappeller que jean rochefort était mort

 
Déjà 2 ans  

 
Les 4 sur tout. Un peu plus complexe à gérer au quotidien avec des gens qui ont tendance à se spécialiser (mais avec du mob ou du pair c'est moins un problème), mais quand y'en a un qui part, voire deux partent, ton projet part pas dans le mur.

 
C'est notre fonctionne actuel. Mais je trouve fatiguant de passer du front au back et du back au front. Quand je fais que l'un ou l'autre, j'avance super vite. Mais à chaque switch, y'a tout un temps d'adaptation. J'ai l'impression d'être moins productif.

Je suis pro fullstack avec simplification de la stack au maximum pour que ça se passe bien.
Quitte à avoir des gens un peu plus experts que d'autres dans certaines technos mais j'essaie de pas entretenir ça et au contraire de favoriser la diffusion de leur expertise aux autres.
Je ne comprends pas cette séparation front/back de ces dernières années. #vieuxCon
Et chez moi ils font même de l'infra

 
               
 
Pardon... c'est juste que je repense à notre stack actuelle...    

Hype Driven Stack, what else.

 
heu, y'a un truc pourri avec le management qui a décidé de ça. Ça sent les gens drivé par des KPIs genre # de gens recrutés, ou # de postes vacants vs plan < x, et qui du coup recrutent n'importe quoi parce que c'est finalement plus facile de gérer un remplacement que d'expliquer pourquoi t'as pas fait ton quota.
C'est un enorme smell de management pourave pour moi.

Ça en fait 2 en 3 semaines vis a vis des recruteurs parisiens.
Et ça va remonter, mais je sais pas si ça aura une influence.

Bordel, dès que je peux ne pas toucher à du front, j'évite. J'étais full stack en commençant à bosser, je n'ai quasi plus fait de front depuis 4 ans.
 
Ça me gave, l'éco-système me gave, les outils me gavent. Le seul challenge dans le dev front c'est de comprendre comment tes putains d'outils/framework fonctionnent.
 
Je préfère clairement le back ne serait-ce que pour concevoir le modèle de données, utiliser des vrais patterns POO, me creuser la tête sur des problématiques métiers, etc.

 
Macbook Pro 15" sans aucune option: CHF 2'699.  
400 balles les 16Go de RAM supplémentaires.    

 
Amen !  

L'architecture du projet sur lequel je bosse me laisse pantois... Ni Auguste Perret, ni Le Corbusier n'auraient pu pondre une archi aussi dégueulasse, c'est dire.

 
Intéressant ça, c'est quoi leur solution du coup ?

Google EST la doc

 
Mais t'étais pas dans une boite de stars avec un soin tout particulier attaché à la technique ?

 
Moi ça va vraiment dépendre du projet. Là la stack backend est tellement aux fraises, tellement complexe, que je prends largement plus de plaisir sur mon front en Vue JS.
 
Par contre le CSS me gave, bien que ce soit quand même devenu 100 fois moins chiant qu'à l'époque

   
c'est pourtant clair: faut savoir ce que tu veux faire avant de le faire. J'ai utilise Sagemaker ces dernières semaines, et c'est pareil: tu peux tout faire tellement simplement c'est facile de répondre a la mauvaise question.
 
 
aussi https://www.aaron-powell.com/posts/ [...] errifying/

Oui, cette librairie a l'air pas mal. Mais dans mon problème de classification, j'ai presque autant de catégories (non connu à l'avance) que de samples. Je ne sais pas si les algos sont faits pour ça. J'aurais tendance à penser qu'ils sont plutôt taillés pour le cas où le nombre de classes est très inférieur à celui des samples.

cf ci-dessus

Au début, je suis allé directement dans du deep learning, mais je m'en sors pas, il me faudrait un vrai cours, pas juste rester à la surface. Du coup je change mon fusil d'épaule et vais me contenter d'algos plus simples.

Plus de détails ici:
https://www.reddit.com/r/learnmachi [...] es_almost/

A noter que j'ai déjà implémenté une solution à ce problème avec un algo que j'ai inventé (j'en ai déjà parlé) et qui a l'air de fonctionner très bien, mais là j'essaye d'améliorer encore ses perfs.

Bon, ça faisait un moment que ça me démangeait, je viens de craquer pour une turbine à glace.
 
Si quelqu'un en a une ici, y'a des retours sur ce genre d'engin ?
 
Pour le rasoir, j'ai pris un Braun Serie 9

Pour cette taille d'équipe, clairement 4 dev fullstacks. Bus factor moins important, pas de problème de synchro si tes devs client ont besoin d'une info que l'API back envoie pas encore (ils font l'ajout eux même) etc....

Au passage, "The 100 pages machine learning book" a l'air pas mal du tout. On peut le télécharger par chapitres, le livre lui-même coûtant 40€ (pour 100 pages, ça fait cher).

 
La politique et les critères de recrutement ne sont pas les mêmes à Paris et à Bordeaux
 
Le fait que les recruteurs de Paris ne soient que très rarement confrontés aux projets "en vrai" (c'est à dire que tous les mecs sont en clientèle, donc ils sont pas au contact des gens qu'ils recrutent, et pas non plus au contact des gens capables de les qualifier), ne doit pas aider...
Mais là, vu les retours sur le mec, il y a effectivement un problème, et Jubi a probablement en partie raison.
 

La France est malade de son management.

ouais, moi chez Plamcorps je suis de plus en plus flemmard, à appeler les développeur front de plus en plus tôt. Mais je crois qu'ils ont aussi un peu assuré la sécurité de leur métier par l'organisation du code, le react est impossible à découvrir et le redux est impossible à lire ou à écrire.
 
Et pourtant j'ai écrit des trucs un peu complexes en front, compris en SVG et en webgl.

 
tu lis les headers, comme les vrais
 
Je déconne à peine, en general tu as un document qui explique en gros le concept, le design (souvent assez high level, et difficile à comprendre si t'es pas déjà hyper familier du sujet), mais la doc technique est littéralement dans les headers. Si t'as du cul, une ame sympathique a écrit un readme.
Yá pas vraiment de doc récapitulative d'un point de vue technique (y'a pour les commerciaux / supports, mais c'est high level, et souvent pas à jour)
 
Je suis ULTRA impressionné par un tas de trucs ici, mais la doc est vraiment pas un sujet de fierté à mon sens.

 
La doc est le parent pauvre de pratiquement toutes les organisations, grandes ou petites et c'est bien dommage AMHA.

Justement, il n'y a pas longtemps je suis auditer une boite de 4 devs, dont deux fraichement sortis d'école et les deux autres qui sont là quasi depuis le départ.
 
Le code n'est pas ce qui se fait de mieux on va dire (legacy d'une dizaine d'année, framework maison, aucun concept de POO ou presque, souvent 1k ligne par classe, etc). Du vrai bon legacy comme on les aime. C'est très dur à suivre, et en plus de ça ils ont des surcharges spécifiques par client. Et... zéro documentation. Si un des deux vieux dev se barre, c'est la quasi faillite assurée
 
J'ai du mal à comprendre ce genre de fonctionnement.

moi je suis extrêmement sceptique des docs. On sait jamais où elle est, si elle est à jour et si l'information qu'on cherche est écrite quelque part.
 
ça sert essentiellement à celui l'a écrite de dire : "je l'ai écrit là, tu lis jamais les docs?"

 
Le court-terme l'emporte toujours
     

 
Ben oué mais ça et le code c'est tout ce qui te reste quand le type est parti

Franchement, je suis en train de supporter des trucs que j'ai écrit y'a 2 ans, j'ai aucune idée de quoi ça parle, donc type là ou pas, ça change pas grand'chose.
 
et je crois pas que j'aurai écrit une doc avec toutes les erreurs que j'ai jamais vu au cours du dev.

 
ça c'est parce que les docs ne sont jamais bien faites et jamais mis à jour sans aucun process solide derrière. En réalité, la doc, c'est ce qui permet de gagner plusieurs mois de boulot par employé quand tu embauches par exemple de nouveaux employés. C'est aussi ce qui te permet de ne pas commettre d'erreurs qui peuvent coûter très cher quand tu pars, que tu meurs et que d'autres récupèrent le projet derrière toi.

 
Écrire des docs correctement, c'est un métier. Accessoirement, c'est aussi une partie de notre métier en théorie. Mais une doc vraiment bien faite, c'est une doc qui change au fur et à mesure, qui est connectée au support, qui prend en compte les incidents, les résolutions d'incidents, les patches etc...

Un des principaux problèmes c'est que le processus d'écrire du code et celui d'écrire de la doc sont complètement cloisonnés et éloignés. A mon sens la documentation technique doit vivre dans les répos, avec le code et faire partie des mêmes branches, des mêmes commits.
 
Je ne parle pas forcément de mettre des commentaires partout, notez, mais plus t'éloignes la doc technique du code, moins elle est rédigée, moins elle est maintenue, moins elle est à jour.

Hire the smartest engineers in the world.

T'as quand même certains headers qui sont vachement bien foutus. Je trouve pour ma part que la doc technique est assez bonne, et relativement simple à trouver (à côté du code, donc). C'est évidemment absolument pas le cas de tout le code applicatif (c'est pas ça qu'on dit?) mais bon c'est relativement attendu, plus on est dans le réutilisable, plus on documente.

Du coup la question initiale était plus au niveau de la documentation process so j'ai bien compris, et là pour le coup je crois qu'à l'université ils faisaient à peine moins bien. Mais bon je me plains pas parce que ça me gonfle autant de lire que d'écrire ces trucs là, je suppose que ça fait effectivement partie de la culture

... mais quand c'est bon, c'est vraiment bon !

Sérieusement quand c'est bien fait ça permet de mettre en lumière toute la structure d'un code, perso je pense que c'est en partie pour ça que les gens qui savent pas écrire correctement en anglais (pas juste grammaticalement correct, le style c'est essentiel) ne peuvent pas être de bons développeurs.

Y'a qu'à googler.

+1 tu versionnes la doc comme le code et la revue de doc pourrait aussi faire partie de la revue de code.

Concrètement faut bien admettre que le portail de recherche interne est hyper bien fichu, il cherche automatiquement dans tous les sites internes, les docs, Google Drive, les mails, et les forums. En général, on trouve.