En premier lieu, je tiens à noté que cela fait plaisir d'avoir le premier commentaire d'un article qui est allé lire les sources.
En second lieu, les deux articles ont deux problématiques différentes et donc deux points de vue différents. L'article de Sam Atkinson parle principalement des langages alternatifs et utilisations dans des projets professionnels sans bonne raison. Ce qui posera forcement des problèmes de maintenances (Si cela n'en pose pas pendant le projet en lui-même). L'article de Yegor Bugayenko, lui parle de la relation de l’apprentissage "des bases" dans une équipe de développement
pendant un projet.
Pour le détail, je vais commenté ce que j'ai lu :

Envoyé par
fatbob
Par ailleurs, il faudra m'expliquer comment faire une appli web sans utiliser au moins deux langages (sans compter html et css).
Ce n'est pas ce qu'explique Sam Atkinson, en particulier quand sa conclusion inclus :
I think being able to program in multiple languages is an absolute must and is something I look for on a CV."
L'idée du choix de l'apport d'un nouveau langage dans un projet devant suivre cette logique :
But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.

Envoyé par
fatbob
Quant à l'apprentissage au cours d'un projet... Je ne vois même pas comment on peut faire pour ne pas apprendre à chaque projet.
Chaque développement un peu trapu entraîne des choix et des expériences qui sont des apprentissages. Ceux qui ne fonctionnent pas bien entraineront d'autres choix la fois d'après qui nécessiteront sans doute également une part d'apprentissage.
Le plombier a des normes fixes (relativement) là où un développeur travaille sur des environnements mouvants. Un développement de deux ans et la base de donnée a de nouvelle fonctionnalités, le framework a changé de version majeure, le langage a évolué notablement et le contrat suivant est déjà signé... Où apprend-on dans ce cas ?
Cela soulève deux argument selon moi.
En premier lieu, il faut bien comprendre que l'argument de Yegor Bugayenko est de dire que si tu es sur un projet utilisant le langage X, et que tu es développeur en Y. C'est le manageur qui a fait une boulette et c'est à lui d'assumer la connerie et non à toi :
Ask the project manager to fix this. En second lieu, il ne pas confondre travail et projet. Un emploi ne se résume pas à un ou plusieurs projets. Si tu as un jour un manageur un minimum compétent, tu verra que celui-ci n'affecte pas directement une personne à un projet. En générale, celle-ci a un temps de formation.. En particulier quand une personne rejoins une entreprise.
D'ailleurs, cela est l'une des raisons qui fait qu'un projet ne finit pas "dans les temps", simplement parce que le temps de formation s'est retrouvé dans le temps du projet. Alors, que c'est bien autre chose...

Envoyé par
fatbob
Au contraire de l'article, je pense que le développeur DOIT se former en permanence, sur tous les projets qu'il fait. Ça fait partie intégrante de son boulot. Celui qui ne le fait pas ne peut pas tenir plus de dix ans avant d'être complètement dépassé sauf à considérer que l'apprentissage des techniques du métier sont un loisir. Je ne vois pas pourquoi un client ou un employeur n'aurait pas à se soucier de cette partie du travail. C'est un peu facile de demander des types de bon niveau, formé aux dernières technologies, sans prendre en compte la nécessité pour ces ressources d'une formation véritablement continue.
Au final, je dirai qu'il faut aussi bien comprendre le degré d'incompétence ciblé est "
Je n'ai pas la moindre idée de ce qu'il faut faire." et non "
Je ne suis pas sûr d'une chose."
Et encore, encore une fois,
ne pas confondre projet, travail et emploie.

Envoyé par
dfiad77pro
- comment fait-on pour se renouveler si l'entreprise nous
cloisonne dans un environnement. ( Je parle pour les dev qui ont des enfants et ne peuvent pas se renouveler chez eux au détriment de l'éducation

)
Il y a deux possibilités :
- changer d'entreprise
- Être payer plus et donc avoir la possibilité financier de se re-former

Envoyé par
dfiad77pro
Bref avec ce genre de considération , beaucoup de DEV quittent la technique pour passer dans le management, c'est une perte considérable !
Beaucoup de "dev" passent dans le management, simplement parce qu'il n'y a pas filière "management technique". La plus part des manageurs actuels sont des anciens développeurs.

Envoyé par
LSMetag
Bref, si ce mec là était mon chef de projet, je programmerais toujours en COBOL, parce que ça fonctionne. Quid ensuite de la maintenance et de "l'évolutivité" ? Une fois que tout le monde sera à la retraite, je leur souhaite bien du plaisir.
Vieux ne veux pas dire hors d’usage ou obsolète !
J'ai un ami qui est formateur sur COBOL... IBM maintient un plug-in eclipse pour développer en COBOL. Et oui, c'est pour du bancaire. L'évolutivité, il y a certains moment où tout le monde l'en veux pas. En particulier, quand tu apprends que l'une des versions de PHP avait un problème sur les calculs sur le nombre flottant.
Je ne te reprends pas sur la confusion général que tu réalise entre ton "chef de projet" et ton "supérieur hiérarchique"....

Envoyé par
LSMetag
La richesse dans le développement, quand tu y es autorisé, c'est de pouvoir prendre des décisions et faire des propositions pertinentes, en tant que personne sur le terrain, pour le bien-être de l'entreprise et ses clients.
Donc, tu n'as pas pris le temps de lire la source de l'article pour y voir cette partie :
But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.
Ce qui est basiquement ce que tu vient de dire... Visiblement, tu n'es pas une personne sur le terrain en ce qui concerne cette article !
Cordialement,
Patrick Kolodziejczyk.
5 |
0 |