Prêt pour le daily de demain les pisseurs de code ?

Le 20 février 2021 à 17:34:35 UnaryOperator a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Pour une boite, avoir des technos à jour et "sexy" ça permet aussi d'intéresser les bons développeurs qui cherchent une mission.

En réalité, le métier s’en branle de la techno.
Côté IT, on en utilise partiellement, mais en interne on ne pousse pas vers ça en ajoutant de la formation interne, ...
En gros c’est forme toi de ton côté et viens le mettre en place pour ta boîte.

Je vais prendre tout ce que je peux et me barrer dans 6 mois max car sinon je vais vite finir obsolète sur le marché.
J’ai pas les mots clés à la mode dans mon CV : Docker, TDD,... car jamais utilisé ni même de connaissances

Le 20 février 2021 à 17:38:10 moishemea a écrit :

Le 20 février 2021 à 17:34:35 UnaryOperator a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Pour une boite, avoir des technos à jour et "sexy" ça permet aussi d'intéresser les bons développeurs qui cherchent une mission.

En réalité, le métier s’en branle de la techno.
Côté IT, on en utilise partiellement, mais en interne on ne pousse pas vers ça en ajoutant de la formation interne, ...
En gros c’est forme toi de ton côté et viens le mettre en place pour ta boîte.

Je vais prendre tout ce que je peux et me barrer dans 6 mois max car sinon je vais vite finir obsolète sur le marché.
J’ai pas les mots clés à la mode dans mon CV : Docker, TDD,... car jamais utilisé ni même de connaissances

C'est parce que tu es soit dans une boite qui voit l'IT comme un milieu d'esclave, soit qui ne repose pas sur l'IT.
Dans les deux cas, c'est pas forcément l'environnement idéal dans lequel évoluer en tant que dev.

Les éditeurs de logiciels ont une culture IT bien meilleure.

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Le 20 février 2021 à 17:36:56 UnaryOperator a écrit :

Le 20 février 2021 à 17:30:55 alpachinois69 a écrit :

Je suis pas ton manager, je pense pas que celui-ci soit certifié Microsoft azure ou soit dba à ces heures perdus ?

Juste comme ça, les certif on s'en branle.
J'ai fait passer un entretien récemment à un mec triplement certifié (spring, java et AWS). Le mec était nul et quand j'ai vu son code... il était pas à jour dans ses pratiques.
A côté j'ai fait passer un entretien à qqn pas certifié mais qui a bossé dans plein de boites reconnues de mon milieu et qui fait de la veille... c'était bien plus intéressant.

Je préfère mille fois un mec qui fait de la veille, qui va à des conférences tech, qu'un bulshiter qui a farmé une semaine pour être certifié

Sauf que je suis pas un bullshiter donc me comparer à son manager

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Le 20 février 2021 à 17:56:06 moishemea a écrit :

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Les produits avec une dette technique c'est du à quoi? La techno en elle-même ou que c'est architecturé comme de la merde? Les dettes techniques que j'ai pu voir si on regarde bien c'était surtout à cause de l'archi et de la conception plus que la techno en elle-même?

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Le 20 février 2021 à 18:05:48 alpachinois69 a écrit :

Le 20 février 2021 à 17:56:06 moishemea a écrit :

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Les produits avec une dette technique c'est du à quoi? La techno en elle-même ou que c'est architecturé comme de la merde? Les dettes techniques que j'ai pu voir si on regarde bien c'était surtout à cause de l'archi et de la conception plus que la techno en elle-même?

Architecture qui pue la défaite oui.
Mais au début ils partent d’une bonne intention, mais à force de rajouter des briques dans le projet, ils ne scalent pas le projet en //
Et chez nous aucun (même le CTO) n’a d’Xp sur des projets avec des grosses architectures, donc tous nos projets se retrouvent à être bancale tôt ou tard

Les techno en général c’est toujours des versions supportées donc pas trop de pb dessus

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Le 20 février 2021 à 18:12:54 moishemea a écrit :

Le 20 février 2021 à 18:05:48 alpachinois69 a écrit :

Le 20 février 2021 à 17:56:06 moishemea a écrit :

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Les produits avec une dette technique c'est du à quoi? La techno en elle-même ou que c'est architecturé comme de la merde? Les dettes techniques que j'ai pu voir si on regarde bien c'était surtout à cause de l'archi et de la conception plus que la techno en elle-même?

Architecture qui pue la défaite oui.
Mais au début ils partent d’une bonne intention, mais à force de rajouter des briques dans le projet, ils ne scalent pas le projet en //
Et chez nous aucun (même le CTO) n’a d’Xp sur des projets avec des grosses architectures, donc tous nos projets se retrouvent à être bancale tôt ou tard

Les techno en général c’est toujours des versions supportées donc pas trop de pb dessus

C'est ce que je dis. Les recruteurs veulent du key words genre docker et CO.Mais je préfère largement un dev sur des technos moins sexy mais qui connaît et a implémenté de bonnes architectures.

Apparemment je suis pas majoritaire dans cette vision

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Le 20 février 2021 à 18:19:56 alpachinois69 a écrit :

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Toads tu peux l'utiliser en pro ? Il me semblait qu'il y avait une licence non ?

Le 20 février 2021 à 17:38:10 moishemea a écrit :

Le 20 février 2021 à 17:34:35 UnaryOperator a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Pour une boite, avoir des technos à jour et "sexy" ça permet aussi d'intéresser les bons développeurs qui cherchent une mission.

En réalité, le métier s’en branle de la techno.
Côté IT, on en utilise partiellement, mais en interne on ne pousse pas vers ça en ajoutant de la formation interne, ...
En gros c’est forme toi de ton côté et viens le mettre en place pour ta boîte.

Je vais prendre tout ce que je peux et me barrer dans 6 mois max car sinon je vais vite finir obsolète sur le marché.
J’ai pas les mots clés à la mode dans mon CV : Docker, TDD,... car jamais utilisé ni même de connaissances

Tu es dans une boucle.
Mais bonne chance car je sais que c'est pas évident et on est beaucoup dans ton cas
Il faut refuser de se former en dehors de son travail car ne t'inquietes pas que les gens qui te conseillent ça mangent des petits four pendant leurs formations.
Si tu prends la décision de te former en dehors, c'est seulement pour fuir ta position actuelle et pour tenter de trouver mieux

Le 20 février 2021 à 17:54:00 alpachinois69 a écrit :

Le 20 février 2021 à 17:36:56 UnaryOperator a écrit :

Le 20 février 2021 à 17:30:55 alpachinois69 a écrit :

Je suis pas ton manager, je pense pas que celui-ci soit certifié Microsoft azure ou soit dba à ces heures perdus ?

Juste comme ça, les certif on s'en branle.
J'ai fait passer un entretien récemment à un mec triplement certifié (spring, java et AWS). Le mec était nul et quand j'ai vu son code... il était pas à jour dans ses pratiques.
A côté j'ai fait passer un entretien à qqn pas certifié mais qui a bossé dans plein de boites reconnues de mon milieu et qui fait de la veille... c'était bien plus intéressant.

Je préfère mille fois un mec qui fait de la veille, qui va à des conférences tech, qu'un bulshiter qui a farmé une semaine pour être certifié

Sauf que je suis pas un bullshiter donc me comparer à son manager

Je ne voulais pas te blesser m'enfin soit.

Le 20 février 2021 à 18:17:59 alpachinois69 a écrit :

Le 20 février 2021 à 18:12:54 moishemea a écrit :

Le 20 février 2021 à 18:05:48 alpachinois69 a écrit :

Le 20 février 2021 à 17:56:06 moishemea a écrit :

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Les produits avec une dette technique c'est du à quoi? La techno en elle-même ou que c'est architecturé comme de la merde? Les dettes techniques que j'ai pu voir si on regarde bien c'était surtout à cause de l'archi et de la conception plus que la techno en elle-même?

Architecture qui pue la défaite oui.
Mais au début ils partent d’une bonne intention, mais à force de rajouter des briques dans le projet, ils ne scalent pas le projet en //
Et chez nous aucun (même le CTO) n’a d’Xp sur des projets avec des grosses architectures, donc tous nos projets se retrouvent à être bancale tôt ou tard

Les techno en général c’est toujours des versions supportées donc pas trop de pb dessus

C'est ce que je dis. Les recruteurs veulent du key words genre docker et CO.Mais je préfère largement un dev sur des technos moins sexy mais qui connaît et a implémenté de bonnes architectures.

Apparemment je suis pas majoritaire dans cette vision

Oui enfin docker c'est quand même pas du buzzword aujourd'hui. Ca fait plusieurs années que c'est largement utilisé

Le 20 février 2021 à 18:38:19 UnaryOperator a écrit :

Le 20 février 2021 à 18:19:56 alpachinois69 a écrit :

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Toads tu peux l'utiliser en pro ? Il me semblait qu'il y avait une licence non ?

Ben en entreprise la boîte paie s'il le faut non?

Le 20 février 2021 à 18:43:05 alpachinois69 a écrit :

Le 20 février 2021 à 18:38:19 UnaryOperator a écrit :

Le 20 février 2021 à 18:19:56 alpachinois69 a écrit :

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Toads tu peux l'utiliser en pro ? Il me semblait qu'il y avait une licence non ?

Ben en entreprise la boîte paie s'il le faut non?

Les licences pour les dev et les entreprises
Oui en indépendant je le fais, mais les entreprises si ça touche pas à la prod... elles seraient prêtes à laisser leurs dev se démerder avec vi

Le 20 février 2021 à 18:41:03 UnaryOperator a écrit :

Le 20 février 2021 à 18:17:59 alpachinois69 a écrit :

Le 20 février 2021 à 18:12:54 moishemea a écrit :

Le 20 février 2021 à 18:05:48 alpachinois69 a écrit :

Le 20 février 2021 à 17:56:06 moishemea a écrit :

Le 20 février 2021 à 17:52:19 alpachinois69 a écrit :

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Faut mieux partir à l'avanture sur une nouvelle techno ou faire un truc où tu maîtrises bien tes ressources donc plus propre ?

Je pense qu’il faudrait stabiliser nos produits existants... ceux ayant une dette technique KOLOSAL.
Ajouter une partie R&D 0.5j/semaine pour pousser à la veille, à tester de nouvelles choses, moteur de la montée en compte ces de son équipe pour ensuite faire une transition vers de nouvelles technos si ça s’y prête bien.

Après dans notre Web, c’est assez « restreint » : Symfony, React/Vue, PgSQL/BigQuery et autres API.

Les produits avec une dette technique c'est du à quoi? La techno en elle-même ou que c'est architecturé comme de la merde? Les dettes techniques que j'ai pu voir si on regarde bien c'était surtout à cause de l'archi et de la conception plus que la techno en elle-même?

Architecture qui pue la défaite oui.
Mais au début ils partent d’une bonne intention, mais à force de rajouter des briques dans le projet, ils ne scalent pas le projet en //
Et chez nous aucun (même le CTO) n’a d’Xp sur des projets avec des grosses architectures, donc tous nos projets se retrouvent à être bancale tôt ou tard

Les techno en général c’est toujours des versions supportées donc pas trop de pb dessus

C'est ce que je dis. Les recruteurs veulent du key words genre docker et CO.Mais je préfère largement un dev sur des technos moins sexy mais qui connaît et a implémenté de bonnes architectures.

Apparemment je suis pas majoritaire dans cette vision

Oui enfin docker c'est quand même pas du buzzword aujourd'hui. Ca fait plusieurs années que c'est largement utilisé

De là à en faire un critère de sélection ? Les RH qui ne connaissent rien trient souvient les CV avec des buzzword surtout chez les juniors.

Le 20 février 2021 à 18:44:17 UnaryOperator a écrit :

Le 20 février 2021 à 18:43:05 alpachinois69 a écrit :

Le 20 février 2021 à 18:38:19 UnaryOperator a écrit :

Le 20 février 2021 à 18:19:56 alpachinois69 a écrit :

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Toads tu peux l'utiliser en pro ? Il me semblait qu'il y avait une licence non ?

Ben en entreprise la boîte paie s'il le faut non?

Les licences pour les dev et les entreprises
Oui en indépendant je le fais, mais les entreprises si ça touche pas à la prod... elles seraient prêtes à laisser leurs dev se démerder avec vi

Ah non moi ils paient sinon ils embauchent quelqu'un d'autre car paie ta productivité si je devais sur des trucs genre SQL plus . Cette argument marche tout le temps

Le 20 février 2021 à 18:49:27 alpachinois69 a écrit :

Le 20 février 2021 à 18:44:17 UnaryOperator a écrit :

Le 20 février 2021 à 18:43:05 alpachinois69 a écrit :

Le 20 février 2021 à 18:38:19 UnaryOperator a écrit :

Le 20 février 2021 à 18:19:56 alpachinois69 a écrit :

Le 20 février 2021 à 18:17:54 moishemea a écrit :

Le 20 février 2021 à 18:14:12 alpachinois69 a écrit :

Le 20 février 2021 à 18:08:35 lEo07a a écrit :

Le 18 février 2021 à 12:45:13 alpachinois69 a écrit :
Ah oui j'oubliais, avec l'achat d'une autre boite, on gérait aussi des data provenant d'un autre système avec du code métier cette fois en SQL pour augmenter les perfs. Tu te retrouves aussi à gérer des procédures stockées PL/SQL de 3000 lignes

C'était LE truc qui faisait qu'ils arrivaient pas à recruter, le boss disait que 80% des dév passaient pas les entretiens à cause de leur test en SQL

c'est quoi le souci avec PL/SQL ?
C'est pas un langage très utilisé sur le marché ?
C'est pas une expertise très demandée ?

Pour entretenir le bordel sur des legacy.Mais comme toujours t'as des gens qui détournent l'utilisation première du langage.

Mettre plein de code métier en pl c'est se foutre de la maintenance

J’espère que personne utilise pgAdmin ce truc est bourré de bug et plante 1/2.

Toads for the win

Toads tu peux l'utiliser en pro ? Il me semblait qu'il y avait une licence non ?

Ben en entreprise la boîte paie s'il le faut non?

Les licences pour les dev et les entreprises
Oui en indépendant je le fais, mais les entreprises si ça touche pas à la prod... elles seraient prêtes à laisser leurs dev se démerder avec vi

Ah non moi ils paient sinon ils embauchent quelqu'un d'autre car paie ta productivité si je devais sur des trucs genre SQL plus . Cette argument marche tout le temps

Je suis pas sûr que toutes les entreprises soient inquiétées par la productivité.. quand tu vois que beaucoup sont obligés de développer sur un vm et de lancer le serveur de façon distante.... au lieu d'avoir tout en local