Le travail, malade du chômage - Page 2

melbou (./28) :
euh tu délires vince avec ta chaine de commandement. Je fais de la recherche, chacun fait réellement ce qu'il veut. On va pas te recruter parce que tu connais du Fortran en particulier

je dis pas le contraire, si y'a que ton sujet d'études qui a besoin de ton programme, tu fais ce que tu veux et c'est normal... mais la recherche ne représentant pas 100% des embauches en informatique, il faut aussi prendre en compte ceux qui sont embauchés par des boites dont les logiciels sont maintenus par N personne et pour des utilisateurs nombreux...

(par ailleurs, le "chacun fait ce qu'il veut dans son coin", ça a beau être très cool, c'est en général pas du tout bon signe... et après on s'étonne que les enterprises se méfient des chercheurs )

()

On travaille à plusieurs sur le même logiciel, et on a mis en place des réunions mensuelles, un repo git commun, un forum pour archiver les questions-réponses, et une mailing-list. Plus les réunions improvisées "machine à café" On est loin de travailler chacun dans son coin là, c'est juste que chacun bosse sur des parties différentes du code avec des objectifs différents. Pour nous le code en lui-même c'est pas le but, limite on s'en fout en fait (du moins moi), le vrai but c'est utiliser le code pour faire de la recherche. Or chaque personne cherche sur un truc précis, donc on collabore beaucoup sur la partie code histoire de tous profiter du travail des autres mais après c'est chacun pour soi.

melbou (./34) :
On est loin de travailler chacun dans son coin là, c'est juste que chacun bosse sur des parties différentes du code avec des objectifs différents. Pour nous le code en lui-même c'est pas le but, limite on s'en fout en fait

Ben voilà, c'est typiquement le genre de trucs qui est pas sérieux

Ça peut très bien convenir pour faire du code jetable qui ne servira qu'à vous et qui prendra la poussière une fois que vous aurez fini vos recherches, mais en entreprise ça craint quand même

Mais c'est typique du fonctionnement de la recherche (essentiellement fondamentale, mais pas uniquement), hein... je vois comment ça fonctionne pour la chimie : dans les labos, au sein de chaque équipe, des individus ou des micro-équipes travaillent, souvent de façon assez bordélique et en tout cas de façon très libre, sur un sujet très spécifique. Une fois qu'une nouveauté est créée/modélisée et qu'il y a un "prototype", on travaille sur la semi-industrialisation en partenariat avec un pilote industriel, avant de passer le brevet à l'industrie qui devra, là encore, trouver des modèles pour une production de masse ou une exploitation "organisée" de l'invention/la découverte/l'amélioration... et je sais que c'est exactement la même chose en électronique, j'imagine que je ne t'apprends rien

Ah mais je dis pas le contraire, d'ailleurs c'est probablement un mode de fonctionnement normal pour une équipe de recherche (s'ils devaient se taper des réunions interminables pour décider comme organiser leur code, ils auraient encore moins de temps pour faire vraiment de la rercherche).

Mais il n'en reste pas moins que sur le plan du développement logiciel, c'est du bricolage ; tout comme les approximations utilisées pour l'industrie doivent hérisser les cheveux des chercheurs théoriciens rigoureux

En entreprise c'est plutôt le contraire qui est encouragé d'ailleurs, que chacun regarde ce que fait l'autre plus que lui-même, jusqu'à ce qu'on ait décidé de faire la même chose pour tout le monde sur le même sujet.

La répartition autonome des tâches est un concept plus que relatif dans ce domaine, ton autonomie étant (de mon expérience) limitée à "démerde-toi sur tel truc, mais je veux un rapport après et de toutes façons si y on revient dessus ça sera plus de ton ressort mais du mien".

Zerosquare (./35) :
Ça peut très bien convenir pour faire du code jetable qui ne servira qu'à vous et qui prendra la poussière une fois que vous aurez fini vos recherches, mais en entreprise ça craint quand même

Je croyais que le code réutilisable et mainteanble dans les entreprises, c'était une belle utopie ? ^^

Ca dépend pour quoi tu codes... s'il s'agit de la maintenance de la petite appli qui tient en 20 lignes qui sert à automatiser le calcul et l'impression des paies par exemple (je dis ça au pif), alors là oui, si c'est le code d'un truc qu'on vend au client, vaut ptet limite mieux un truc un peu sale pour facturer du support avancé...

Folco (./39) :
Je croyais que le code réutilisable et mainteanble dans les entreprises, c'était une belle utopie ? ^^

C'est une utopie de croire que ça respecte à la lettre les normes en tout genre, oui

Maintenant les entreprises essaient quand même de le faire un minimum, ne serait-ce que pour des raisons économiques (si le principal codeur d'un projet important donne sa démission et qu'il était le seul à savoir comment marchait le soft, l'entreprise est un peu dans la merde )

Zerosquare (./37) :
Ah mais je dis pas le contraire, d'ailleurs c'est probablement un mode de fonctionnement normal pour une équipe de recherche (s'ils devaient se taper des réunions interminables pour décider comme organiser leur code, ils auraient encore moins de temps pour faire vraiment de la rercherche).

Mais il n'en reste pas moins que sur le plan du développement logiciel, c'est du bricolage ; tout comme les approximations utilisées pour l'industrie doivent hérisser les cheveux des chercheurs théoriciens rigoureux

En effet, ça ne peut généralement pas vraiment fonctionner autrement dans la recherche « libre ». On te demande de trouver une solution à un problème donné ou juste comme ça dans un domaine (tu cherches le problème et sa solution) donc tu vas développer une procédure, un algorithme ou ce que tu veux (et ça n'a quelquefois rien à voir avec ce qu'on imaginait au début) et tu vas le tester un minimum avant de le présenter (ou pas, mais alors on va te le demander). Pouvoir exposer ton idée évasive pendant plus de quelques minutes en réunion, c'est exceptionnel, et ça finira systématiquement par une demande de test/simulation ou d'abandon. Après, ce qui compte c'est d'avoir les premiers indices de l'efficacité le plus rapidement possible pour savoir si on continue dans cette voie, donc tu fais ce que tu veux tant que c'est rapide. On ne peut pas perdre de temps en réunion pour bien architecturer le truc qui est encore vague. En fait, il faut juste accepter que la recherche, c'est pas du développement logiciel

Bon, tu as quand même quelques contraintes quelques fois, comme seulement du code en C et en Matlab. Ça a principalement pour but de permettre de relancer les simulations avec d'autres paramètres et pouvoir faire un partage élémentaire (mais dans ce cas, c'est le problème de celui qui récupère le code, on a autre chose à faire que de penser à la réutilisabilité ou la maintenabilité quand on cherche). Si malgré ces contraintes, tu leur dis voilà, j'ai des indices que ça va peut-être bien marcher, mais les simulations vont prendre 4 mois. Mais vous aurez les résultats dans deux semaines si on utilise ça, ça, ça et ça et ça coûtera tant, ils vont probablement accepter (si c'est raisonnable et que tu sembles savoir de quoi tu parles). Et même, si c'est gratuit, tu le fais directement, t'auras tout le temps de recoder comme ils veulent avec le temps gagné.

Il y a aussi la recherche sous contrat, où tu fais seulement ce que le type te dit de faire et exactement comme il veut le faire, mais c'est pas de la recherche

Oups, c'est trop long