Discussion :

[DevTroglodyte]

peut-être mais selon moi il devrait trouvé une boite où il serait respecté et aurait la reconnaissance de son travail plutôt que de larbiner pour des ingrats

Vu l'état du monde du travail actuellement, ça demande un minimum de réflexion et de préparation ce genre de manoeuvre, hein...

Certainement pas quand il va défendre le colonialisme en Indochine ou en Algérie et je je ne serais jamais content de la mort de quelqu'un, tout le monde n'est pas de ta trempe.

Vraiment ? Tout ce qui te vient a l'esprit, c'est la décolonialisation ? Par contre le Mali, la Yougoslavie, voire même la 2e guerre mondiale, on zappe ? Pourtant, dans ces conflits, les soldats, on n'était pas mécontents de les avoir...

[sqwaly]

Par contre le Mali, la Yougoslavie, voire même la 2e guerre mondiale, on zappe ? Pourtant, dans ces conflits, les soldats, on n'était pas mécontents de les avoir...

Je crois qu'il milite contre l'injustice et les guerres injustes. Toi t'as été content d'envoyer des jeunes gens en Yougoslavie qui n'avait pas le droit de riposter à l'arme quand les snipers les canardaient et que leurs camarades tombaient un par un à leurs pieds? S'ils avaient été moins formaté ils auraient combattus pour leurs survies.

[Matthieu Vergne]

Ton discours ne laisse aucune place à la stratégie, la tactique, l'analyse et l'adaptation, je ne suis pas sur que tu vivrais longtemps sur le terrain...

Pour la simple raison qu'on parle de formations, donc majoritairement de jeunes recrues avant tout.

De plus, la stratégie ne se décide pas quand on est sur le terrain, mais avant. Quand tu es en opération, il faut appliquer, pas réfléchir. Tu as aussi généralement un support, les soldats ne sont pas seuls sur le terrain. Ceux qui doivent réfléchir sont majoritairement dans les QG, pas sur le terrain.

Bien entendu, je parle du cas général, pas de commandos d'élites qui ont roulé leur bosse et on l'expérience suffisante pour juger. Quand tu as l'expérience, la formation ça fait longtemps que tu l'as oubliée (n'en reste que certains automatismes). Ce n'est donc pas ce qui nous intéresse ici.

Quand on définit un contexte il faut savoir si tenir pour tenir un raisonnement cohérent, tu seras donc gentil de ne pas utiliser des évidences qui ne s'y appliquent pas.

[negstek]

Vu l'état du monde du travail actuellement, ça demande un minimum de réflexion et de préparation ce genre de manoeuvre, hein...

ouhai effectivement faut bichonner un CV et se bouger le cul mais pas plus que pour trouver un travail quand on est au chômage et avec qui plus est un salaire pour se couvrir.

Vraiment ? Tout ce qui te vient a l'esprit, c'est la décolonialisation ? Par contre le Mali, la Yougoslavie, voire même la 2e guerre mondiale, on zappe ? Pourtant, dans ces conflits, les soldats, on n'était pas mécontents de les avoir...

Parles pour toi la deuxième guerre mondiale le peuple français a bien écarté les fesses et collaboré. Moi durant ce temps mon grand-père faisait de la résistance à Rennes et a été envoyé dans un camp de concentration où il a chopé le typhus pour ça. Il s'en est sorti de justesse. Et toi tes ancêtres il faisait quoi pdt ce tps là? Moi si c'était à faire je le ferais j'ai pas besoin de me cacher derrière des "robots bien programmés" en uniforme.

[negstek]

Ceux qui doivent réfléchir sont majoritairement dans les QG, pas sur le terrain.

ces mêmes gens qui n'ont pas conscience de l'état du terrain vu qu'ils sont planqués un peu comme ces commerciaux qu'acceptent tous les contrats pendant que le dev se tape galère sur galère si le chantier est pourri. Sans compter que si l'état major capitule et qu'on s'en tient au ordre on a vite fait de collaborer avec les boschs pour l'exemple de la 2nde guerre mondiale. Dslé mais pour moi un homme ça doit réfléchir par lui même et faire preuve d'intégrité. Dans ton schéma les ptis soldats à deux sous qu'obéissent systématiquement tueraient même des innocent si l'ordre venait dans haut et ça je ne peux pas le cautionner.

[Matthieu Vergne]

Amen.

On en est à débattre sur des jugements de valeurs qui, par nature, ne peuvent pas aboutir, parce qu'on ne peut faire plus subjectifs. Dans ce style de débat, chacun a ses raisons, qui sont toutes justifiables dans certains contextes et critiquables dans d'autres. Vous pouvez donc continuer longtemps comme ça si vous voulez, mais c'est pas le sujet ici.

Coder est-elle une tache ingrate ? Oui/non, qu'est ce qui la rendrait ingrate, qu'est-ce qui permettrait d'empêcher ça ?

[Matthieu Vergne]

ces mêmes gens qui n'ont pas conscience de l'état du terrain vu qu'ils sont planqués un peu comme ces commerciaux qu'acceptent tous les contrats pendant que le dev ce tape galère sur galère si le chantier est pourri. Sans compter que si l'état major capitule et qu'on s'en tient au ordre on a vite fait de collaborer avec les boschs pour l'exemple de la 2nde guerre mondiale. Dslé mais pour moi un homme ça doit réfléchir par lui même et faire preuve d'intégrité. Dans ton schéma les ptis soldats à deux sous qu'obéissent systématiquement tueraient même des innocent si l'ordre venait dans haut et ça je ne peux pas le cautionner.

Cautionner ou pas, libre à toi. Je suis aussi à vouloir que les gens pensent par eux-même, mais ça ne veut pas dire que je vais faire passer cette philosophie pour la meilleure. Tout dépend du contexte. On peut revenir au sujet ?

[DevTroglodyte]

Et toi tes ancêtres il faisait quoi pdt ce tps là? Moi si c'était à faire je le ferais j'ai pas besoin de me cacher derrière des "robots bien programmés" en uniforme.

Ils crevaient de faim dans la campagne bretonne / normande / espagnole. T'es bien gentil avec tes grandes paroles, mais faudrait voir à te calmer (et à éviter de nous sortir des "moi je sais ce que je ferais", personne ne sait de quoi il est réellement capable dans ce domaine avant d'y avoir été confronté...)

M'enfin j'adore ton mépris des militaires, vraiment... typique de nos bobos bien-pensants.

[negstek]

Coder est-elle une tache ingrate ? Oui/non

à voir selon l'état d'esprit des collègues

qu'est ce qui la rendrait ingrate

leurs divergences d'opinion sur des themes important

qu'est-ce qui permettrait d'empêcher ça ?

une discussion sans tabou


Je rigole mais coder c'est le pied, ça permet d’appréhender les couches hautes du fonctionnement des ordinateurs, c'est un gouffre sans fin d'un savoir qui est en perpétuel évolution, les technos sont variés, chacune d'entre elle permet de quasiment tout faire. Je trouve la technique vachement plus enrichissante et intéressante que la gestion de projet. Cependant les choix techniques des supérieurs peuvent pourrir cette état d'esprit, je me retrouve en permanence avec des vieux de la vielle qui code sans gestion des versions, sur des vielles technos et qui ne veulent pas faire évoluer les choses. Dur dur dans ces cas quand on sort de l'école et qu'on doit désapprendre toutes les bonnes pratiques modernes pour se plier au manque de méthodologie d'équipes en production, qui plus est quand on a quitté un premier taf à la pointe de la techno dans une grosse équipe agile mais où le salaire faisait défaut.

Cela dit il faut garder espoir et essayer de faire progresser son équipe en douceur et sur le long terme quand ses méthodes sont est un peu dépassées.

[Matthieu Vergne]

On peut aussi considérer la taille de l'entreprise.

En général, les petites boites font attention à chaque personne, vu que la moindre erreur peut avoir des conséquences notables sur l'ensemble de l'équipe. Dans ces conditions, il me semble qu'il est rare d'avoir cette idée d'ingratitude.

A contrario, c'est probablement souvent le cas dans les grosses, vu que l'ampleur de la structure implique une certaine inertie, on s'arrange donc pour avoir un fonctionnement régie par des règles censées bien marcher et les employés doivent s'y tenir. Par conséquent, si la politique de l'entreprise n'intègre pas ce qu'il faut pour rendre le travail attractif (ouverture aux nouvelles idées, temps suffisant pour expérimenter, etc.) alors on aura du mal à se sentir reconnu pour ce qu'on fait, vu qu'on ne peut faire que ce qu'on nous demande, comme n'importe qui. Et bien entendu, comme ce qui fait le plus de bruit c'est ce qui ne marche pas, c'est tout ce que les autres retiendront de ce que font les programmeurs en cas de coup dur : des trucs qui peuvent te sauter à la figure à n'importe quel moment.

[Aqualys]

On peut aussi considérer la taille de l'entreprise.

En général, les petites boites font attention à chaque personne, vu que la moindre erreur peut avoir des conséquences notables sur l'ensemble de l'équipe. Dans ces conditions, il me semble qu'il est rare d'avoir cette idée d'ingratitude.

A contrario, c'est probablement souvent le cas dans les grosses, vu que l'ampleur de la structure implique une certaine inertie, on s'arrange donc pour avoir un fonctionnement régie par des règles censées bien marcher et les employés doivent s'y tenir. Par conséquent, si la politique de l'entreprise n'intègre pas ce qu'il faut pour rendre le travail attractif (ouverture aux nouvelles idées, temps suffisant pour expérimenter, etc.) alors on aura du mal à se sentir reconnu pour ce qu'on fait, vu qu'on ne peut faire que ce qu'on nous demande, comme n'importe qui. Et bien entendu, comme ce qui fait le plus de bruit c'est ce qui ne marche pas, c'est tout ce que les autres retiendront de ce que font les programmeurs en cas de coup dur : des trucs qui peuvent te sauter à la figure à n'importe quel moment.

Pas tout à fait d'accord en ce qui concerne ta conclusion : les autres ne sont pas des crétins mais des utilisateurs de l'informatique souvent au quotidien ( je sais utilisateurs quotidien et crétins ne sont pas incompatibles ), et ce qu'ils retiendront c'est le programmeur qui va rester la soirée pour corriger le bug pour que le lendemain ces mêmes utilisateurs puissent travailler normalement.

Dans les petites structures on va travailler en mode stress et quasiment au file de l'eau ( je me demande si 'Agile' n'a pas été inventé pour donner l'impression qu'il y a un semblant d'organisation dans les petites structures ... je me lâche c'est friday ! ), alors que dans des structures importantes, l'inertie permet non seulement une conception poussée mais aussi une intégration dans l'existant plus rassurante pour les dirigeants.

De toute façon, il n'y a pas de structure idéale, l'important c'est de s'amuser !

[Matthieu Vergne]

De toute façon, il n'y a pas de structure idéale, l'important c'est de s'amuser !

[troll]Mais ça ça marche pas dans les grande structures. Sinon les comptables joueraient au yoyo avec les bénéfices... Ah mais ils le font déjà.[/troll]

Nan j'ai pas parlé de crétin. Mais le fait est que dans les grosses structures, le dév qui va corriger le bug tu le vois pas forcément. Si tu as un système du style "en cas de problème, envoyez un mail à mailing-list-dev@boite.com", ou si les dev sont en fait sur un autre site, ça n'aide pas.

[Aqualys]

Nan j'ai pas parlé de crétin. Mais le fait est que dans les grosses structures, le dév qui va corriger le bug tu le vois pas forcément. Si tu as un système du style "en cas de problème, envoyez un mail à mailing-list-dev@boite.com", ou si les dev sont en fait sur un autre site, ça n'aide pas.

La correction est plus longue dans de grosses structures, évidement ( et encore pour des applis critiques, les temps de réaction sont des indicateurs de performance ), mais quelle est la valeur ajoutée d'un contact utilisateur/dev ?

Une plus grande description ne nécessite pas de se voir, il y a d'excellentes applis de suivi de bugs.
Beaucoup de Dev n'aiment pas avoir quelqu'un dans leur dos qui attend la correction. ; trop stressant !
Des corrections à la volée ( en prod encore plus ), peuvent générer plus d'instabilité que le bug corrigé...

[Matthieu Vergne]

Sauf qu'une description textuelle, ou même accompagnée de screenshots, n'est pas aussi informative qu'un dev qui peut voir la personne refaire le processus qui mène au bug. L'utilisateur ne sait pas ce qui se passe sous le capot, et donc il ne sait pas ce qui est important de faire savoir. Il donne que ce qu'il pense être important (et l'exprime de la manière qui lui semble être la meilleure, ce qui n'est pas toujours vrai). Si derrière le dev ne peut pas contacter la personne facilement, faut espérer que l'info donnée suffira. S'il peut la contacter, il doit avoir l'abstraction et la "pédagogie" nécessaire pour arriver à obtenir les informations manquantes. Un dev qui assiste directement l'utilisateur peut voir tout de suite quelles sont les actions faites et les points clés qui peuvent mener au bug (ou les points clés qui font que ce bug ne devrait pas arriver, et donc quoi regarder après pour voir si ça fonctionne correctement), voire demander en live les points importants (e.g. comment est configuré le module X). Si on n'a pas d'outils avancé de discussion de bugs avec un bon moyen de logger les erreurs (ce qui demande déjà pas mal d'efforts), le suivi perso reste franchement plus efficace.

En bref, "un petit dessin vaut mieux qu'une longue explication". On peut étendre à "une petite vidéo vaut mieux qu'une grosse pile de dessins". Si l'utilisateur utilise le soft d'une manière non prévue, c'est pas avec une description du style "J'ai mis 3.5 dans le champs X et ça m'a planté à la gueule." et un screenshot du message d'erreur "Valeur invalide" qu'on va trouver le vrai problème. Grosse structure ne veut pas forcément dire capacités de débogage avancées.

[Aqualys]

Si derrière le dev ne peut pas contacter la personne facilement, faut espérer que l'info donnée suffira.

C'est à 90% la situation dans la pratique.

S'il peut la contacter, il doit avoir l'abstraction et la "pédagogie" nécessaire pour arriver à obtenir les informations manquantes.

Un Dev 'pédagogue'....c'est un peu comme un politique vertueux ; une exception

le suivi perso reste franchement plus efficace.

Bien sûr, mais c'est tellement rare dans la vie professionnelle, qu'il faut savoir faire avec le moins possible... c'est le piment du débogage

Grosse structure ne veut pas forcément dire capacités de débogage avancées.

Tout à fait d'accord, le débogage c'est une affaire de capacité du Dev, pas de structure d'entreprise. La grosse entreprise ne fait qu'organiser le travail, ce qui peut s'apparenter à des contraintes parfois.

[federb.do]

La meilleure façon pour connaitre les machines reste encore le codage.

Indispensable à l'Analyse : le Débogage, car il permet de connaître machines et outils par l'intérieur, vertus et travers, écueils et raccourcis.

HAsoft.fr

[Matthieu Vergne]

T'as pas besoin de te jeter du haut de la tour montparnasse pour savoir que ça te serait fatal {'^_^}. Les programmes c'est pareil, t'as pas besoin d'avoir des bogues pour savoir qu'il vaut mieux en corriger un maximum.

[poolpie]

Perso j'adore faire de l'optimisation, trouver des solutions élégantes aux problèmes, évaluer des middlewares/outils, prendre des décisions d'architecture et les implémenter etc... Mais à côté de cela, coder des trucs de base comme des formulaires CRUD, ça m'éclate pas trop! C'est même pas que je me trouve trop bien pour faire ça mais c'est du boulot un peu rébarbatif et pas très enrichissant.

Donc je pense qu'un développeur, il sera épanoui ou non selon qu'il ait la possibilité dans son cadre de travail de faire des choix techniques, de chercher des solutions et d'apporter sa touche personnelle et d'amener son expertise et sa valeur au projet. Dans le cas contraire (et il y a des entreprises comme ça!) où on me demandrait de coder strictement des specs établies par d'autres, sans la moindre autonomie, oui je trouverai que programmeur est un boulot naze et j'aurai envie de me spécialiser dans autre chose.

Je partage entièrement. Malheureusement, je n'ai pas l'impression que beaucoup d'employeurs voient les choses ainsi.

[federb.do]

Oui, moi aussi je partage, mais c'est le quotidien.
Grater pour les autres dans leur modèle.

Et puis il y a l'expertise.
"Expert programmeur". ça c'est un truc qui parait naze ! mais comme c'est le coeur de métier c'est lui qui permet de perdurer dans la profession.

Grater sans invention ça permet de s'améliorer. ça permet de trouver d'autres techniques d'écritures rapides, de controles plus efficaces, de débogage astucieux.
Parce que la conception c'est très beau, mais il faut compter (en temps ça fait beaucoup) sur les bogues systèmes et logiques.
Non ?

HAsoft.fr

[horaT]

Coder est-elle une tâche ingrate ?
Pourquoi les ingénieurs s’orientent-ils vers des profils autres que programmeur

Si le terme ''Ingrate'' signifie ici ''Mal rémunéré et mal considéré'', alors oui, un programmeur moyen peut le dire. Mais pas un développeur chevronné de haut niveau, qui fait office de Coach ou de développeur en chef. Au contraire les développeurs de haut niveau sont recherchés, richement payé et très honorés, sur de grands projets de développement d'application les plus critiques. L'essentiel est donc d'être extrêmement bon et de savoir se vendre.

D'autre part, les ingénieurs, - ou disons plutôt certains ingénieurs - s'orientent vers des profils autres que programmer, parce que soit ils n'ont pas la passion de la chose, soit ils n'ont pas dans leur entourage immédiat un modèle ou une idole qui les inspire, ou simplement parce qu'ils ne sont pas prêts à travailler aussi dur qu'un programmeur se doit de faire pour arriver au haut niveau avant de s'épanouir pleinement en tant que programmeur, car il faut le reconnaître, programmer exige du programmeur beaucoup de travail, de sacrifice, de rigueur, de passion, et j'en passe.