Discussion :

[Matthieu Vergne]

Comme toute activité de haut niveau.

[Jitou]

D'accord avec toi, le pessimisme en moins ^^. J'ai arrêté les SSII aussi parce que justement on décide tout à notre place, et nous on a juste à coder ça comme on nous a demandé pour que ça marche. La moindre remarque sur l'existant sera au mieux prise en compte et notée sur un calepin pour être ressortie s'il finit par y avoir une anomalie grave ou bloquante dans l'application concernant cette remarque.
Mais dans la grande partie des cas, tu n'as aucun pouvoir, car tout vient d'en haut, tout est lié aux coûts et à la facturation à la tâche.
Tu peux même te faire engueuler/virer si tu as le malheur d'améliorer l'application sans qu'on te le demande.
(...)
En SSII, il n'y a guère qu'au niveau d'Architecte (10 ans d'expérience) que tu as officiellement le droit de prendre des décisions (et encore t'as toujours le client qui n'y connait rien sur les bras pour te dire "non je veux du WebSphere Portal parce qu'on a été partenaire avec IBM", ce qui ensuite donne une mauvaise image des développeurs et une mauvaise communication car les utilisateurs ne sont pas contents (ça rame, c'est buggué, c'est pas user friendly,...)).

C'est pas faux mais de mon expérience de développeur je retiens que les 3/4 du temps l'archi ou les specs techniques décidées plus haut sont totalement à revoir dès la premières semaines du début du développement projet.

La cause ? Des chefs de projet ou des archis qui ne codent plus dans le monde réel depuis des années, passe leur temps à faire de la veille techno et qui sont alors totalement à côté de leurs pompes. Le drame c'est que ce sont des gens appréciés et reconnu par la direction qui leur donne une totale confiance pour prendre les "bonnes" décision de design technique. Ca m'est arrivé en tant que responsable tech. de projet de jeter à la poubelle une archi ou des specs tech. pour tout refaire en 5 jours (et ce après avoir perdu 3 jours à convaincre à ma direction que c'était complètement foireux).

Ou alors à l'inverse on trouve des archis codeurs fous qui codent au boulot, qui codent chez eux la nuit, car pour eux c'est une passion et du coup ils envisagent plus l'informatique comme une activité "artistique" ou l’élégance, la satisfaction d'avoir mis en place un schéma de construction complexe prime sur l’efficacité et la maintenabilité (et le rentabilité du coup !). J'en ai vu aussi des projets partir en sucette avec de tel "décideurs"

[r0d]

Je n'aurais qu'une seule chose à répondre: la description de ma méthode de travail et la raison pour laquelle je ne serai jamais CP:

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template <typename ProjectType, typename StatementType>
void Project::StartProject( ProjectType project )
{
   int project_state = work_in_progress;
   while ( project_state != finished )
   {
      HomeMadeThreadingAPI::Thread< TrollingOnDvp >( new StartTrolling() ).launch();
      ProjectIteration iteration = project.NextIteration();
      if ( iteration.WorksFine() )
         Project< SubProject, CanDoBetter > sub_project().Start( *this );
      else
         Project< ProjectType, FindAnotherSolution > sub_project().Start( StatementType::Policy() );
   }
}

[Matthieu Vergne]

J'apprécie particulièrement le thread de trolling. Un indispensable {^o^}.

[zepgm]

Je ne trouve pas cela ingrat de coder, au contraire, on sait exactement ce qui se passe contrairement au Chef de projet, et oui c'est typiquement Francais de vouloir etre "Chef de". Je travaille depuis quelques temps aux UK, ils recherchent a fond des developpeurs seniors, quand je vois les payes, rien a envier aux Chefs de projet c'est sur.

Et puis meme, entre un jeune "pisseur de code" et un gars vraiment experimente, c'est un plus pour l'entreprise. Faut pas oublier que c'est nous qui developpons les technologies d'aujourd'hui.

Je me considere comme un jeune programmeur ayant de bons reflexes, mais compare a un Senior ... voila, on sent deja qu'ils sont beaucoup plus a l'aise.

(Desole pour les manque d'accents, je suis sur un Qwerty xD)

[CocoDesBois]

Plus celui qui code est loin du métier-fonctionnel / de l'utilisateur / de l'archi logiciel - choix des technos , plus c'est ingrat.

A chacun de se situer par rapport à ces critères.

[Matthieu Vergne]

Je viens de noter :

Regarde n'importe quel étude sur le sujet, les projets échoues que dans une infime proportion pour des raisons techniques.

Depuis que je fais de la recherche en info, je vois toujours d'écris des trucs comme "une quantité importante de projets échoue", "trop de projets échouent", etc. Je serai curieux de voir quelle étude dit le contraire.

[rimram31]

Ben dites donc, thread bien révélateur des difficultés que rencontre l'informatique ... un process ça sert a rien, les CP ne sont que des incompétents qui n'y connaissent rien et se contentent de pousser des cases dans leur tableau Excel ... laissez moi m'en occuper, moi je sais, je vais sauver la planète avec mes 4 lignes de code !!!

Je force un peu le trait mais malheureusement le vrai souci des "développeurs" est leur étroitesse d'esprit, leur totale ignorance d'un semblant de processus industriel qui engage des hommes car vous oubliez que l'informatique, comme beaucoup d'autre activité, reste une activité faites par des hommes et pour des hommes et demande donc des compétences, des expertises bien loin de la seule technique.

Amusant car les process sont capables de fabriquer des voitures, des avions, des satellites, fusées ... et bien d'autres équipements mais ils sont toujours critiqués en informatique et c'est, a mon sens, une des raison du taux d'échec des projets dans ce domaine, taux d'échec sans commune mesure avec ce que l'on peut voir ailleurs. Le métier de développeur est déconsidéré? C'est que vous avez a faire a des managers incompétents (qui n'ont d'ailleurs généralement aucune compétences en management) L'architecte respecte l'ouvrier qui va monter les murs et il n'hésitera pas a lui demander son avis sur tel ou tel point particulier, tout comme l'ouvrier respectera l'architecte car il sait qu'il n'a pas toutes les données du problème, chacun son job.

Je l'ai déjà exprimé ici, le succès d'un projet informatique ne tiendra jamais a la technique mais a la qualité de la communication et on avancera un peu le jour ou "les développeurs" auront compris qu'ils ne pourront pas tout faire avec leur seule machine. Arrêtez de vous prendre pour Bruce Willis

Sur le fond du débat, j'ai bientôt 50 ans et je continue a coder, coder en informatique n'est jamais que le processus de fabrication qui permet de rendre réelle une idée avec probablement la frustration avec le temps de voir la quantité d'efforts nécessaires pour réaliser une idée (ou peut-être plus d'idées que de patience :-)). Parfois ingrat, certainement, mais aussi parfois passionnant, mais comme beaucoup d'autres activités.

[dev14]

J'ai toujours eu plus d'admiration pour le développeur senior capable de réaliser de vraies prouesses techniques que pour son chef de projet qui bien souvent ne comprend plus rien au code. Le premier fait fonctionner son cerveau, le second beaucoup moins et oublie ses acquis. Bref, je préfère le joueur à l'entraîneur.

[Mr_Exal]

J'ai toujours eu plus d'admiration pour le développeur senior capable de réaliser de vraies prouesses techniques que pour son chef de projet qui bien souvent ne comprend plus rien au code. Le premier fait fonctionner son cerveau, le second beaucoup moins et oublie ses acquis. Bref, je préfère le joueur à l'entraîneur.

A comparer des poires et des bananes il est étonnant de voir des différences.

[pcaboche]

A comparer des poires et des bananes il est étonnant de voir des différences.

Y a-t-il un jeu de mots intentionnel ?

Parce que voici comment on peut le comprendre :

développeur = "bonne poire" (et tout le monde profite de lui)
chef de projet = "banane" (au sens péjoratif)

[Mr_Exal]

Y a-t-il un jeu de mots intentionnel ?

Parce que voici comment on peut le comprendre :

développeur = "bonne poire" (et tout le monde profite de lui)
chef de projet = "banane" (au sens péjoratif)

Ah non du tout. Enfin c'était peut être inconscient
Mais j'aurais aussi pu dire des chats et des chiens.

[marsupial]

A 10 ans, coder était mon rêve.

A la sortie de l'école qui ne disposait pas de filière et où un PC coûtait un bras, j'ai appris sur le tas. Puis la bulle est arrivée.


Aujourd'hui je vis 3 fois en dessous du seuil de pauvreté après avoir tout donné.

Demain, je serai à la rue. Une nouvelle fois.

Je vous souhaite une bonne journée.

[e-ric]

L'architecte respecte l'ouvrier qui va monter les murs et il n'hésitera pas a lui demander son avis sur tel ou tel point particulier

C'est assez théorique.

Vous connaissez mal les architectes... Même des dessinateurs, il n'ont rien à foutre.

Je force un peu le trait mais malheureusement le vrai souci des "développeurs" est leur étroitesse d'esprit, leur totale ignorance d'un semblant de processus industriel qui engage des hommes car vous oubliez que l'informatique, comme beaucoup d'autre activité, reste une activité faites par des hommes et pour des hommes et demande donc des compétences, des expertises bien loin de la seule technique.

Merci pour la généralisation
Quand on cessera de placer des chefs de projets (je ne généralise pas) qui ne connaissent rien au développement, cela améliorera certainement le taux de réussite des projets. J'espère que cette mode de CDP non issu du métier n'existe pas en dehors de l'informatique.
En tout cas, j'ai pas vu beaucoup de boîte qui avait un semblant de respect pour les développeurs si en plus ils sont prestataires...

[Invité]

Ca dépend :
Moi je code depuis 16 ans (j'en ai 26 là) et j'ai commencé sur calculette graphique.

Personnellement le boulot de développeur est bien à partir du moment ou tu peux améliorer un truc déjà existant ou bien créer quelque chose.

A partir du moment ou t'a des chefs de projets qui n'y connaissent rien et t'impose de travailler avec tel ou tel outil pour faire du travail finalement rébarbatif et de mauvaise qualité, ça devient plus une tâche ingrate en effet.

[jean_kevin_musclor]

Pour les grosses boîtes je sais pas trop comment ça marche j'ai surtout bossé dans les petites structures et c'est plutôt côté management que c'est dévalorisant car d'utilité hautement discutable.

Tant que les développeurs se débrouillaient eux-mêmes pour gérer la barque ça se passait bien parce qu'ils savent à peu près ce qu'ils font.

Là où ça a été la catastrophe c'est quand on a nous a encombrés avec des "chefs de projet" "consultants" et autres parasites dont les compétences relevaient plutôt de la magouille que de la technique. Des gars qui non seulement étaient payés à occuper une chaise et taper trois emails, mais qui en plus se prenaient pour des génies de l'efficacité révolutionnaires en annonçant un délai de deux semaines pour un développement qui demande 6 mois, faisaient des choix techniques délirants qui relevaient du sabotage pur (par exemple développer de la vidéo en java parce que ça connait pas d'autre langage), appliquaient des méthodes de gestion à la légalité discutable (genre déléguer le design à leur beau-frère engagé bénévolement, ou encore laisser le développement en plan une fois que le client a envoyé les ronds parce que pour des petits projets ça passe ça leur coûte moins cher de pleurer la thune que d'engager des poursuites juridiques), qui parfois nous offraient des moments de rire jaune genre au bout de deux semaines à baratiner qu'il s'y connait mieux que tout le monde le gars te demande c'est quoi une classe d'objet. Et qui bien évidemment avaient dès le départ l'intention d'accuser les développeurs à la moindre embrouille.

Bref impossible de travailler avec des types pareils. Au lieu de gaspiller des sous à payer un saboteur on pourrait embaucher deux développeurs de plus pour faire le boulot plus vite et sans parasite pour tout foutre en l'air.


Sinon l'expression pisse-code il ne me semble pas qu'elle ait été inventée pour dénigrer les développeurs mais plutôt pour évoquer ceux qui s'intéressent pas à ce qu'ils font et bâclent le travail en pondant à l'arrache du code buggé pas optimisé crade inutilisable et qui se foutent pas mal de savoir si le programme fonctionne sans ramer faire des leaks et planter dans tous les sens. C'est souvent ceux là qu'on déplace aux postes de "manager" "chef de projet" "consultant" etc ils font moins de dégâts à la paperasse qu'à la technique.

Je ne sais pas comment ça marche dans le reste du monde, peut-être qu'aux us les gars qui dirigent une équipe de dev sont des codeur expérimentés, mais chez nous c'est plutôt des codeurs incompétents reconvertis dans le management, et je ne crois pas qu'ils dénigrent réellement le métier de développeur, je crois surtout qu'ils n'y comprennent pas grand chose et qu'ils s'en foutent.

[Invité]

Ouais c'est aussi l'impression que j'ai. (pour les petites boîtes tout du moins) les grosses boîtes je ne sais pas non plus je n'ai jamais eu l'occasion de travailler dans l'une d'entre elles)

Mais pour un projet plus conséquent en groupe de 2-3 il faut en effet au moins compter 6 mois. (Par projet plus conséquent j'entends par là le développement d'un erp par exemple)

Dans des petites boîtes il te demande de faire ce genre de projet en 2 semaines en général..., sous prétexte que se sont des petites boîtes et qu'ils ont besoin d'une solution très rapidement, donc, qu'ils ont besoin de prendre des risques et donc, de bâcler le travail.

Ce qui est bien sûr totalement absurde, je vois très mal comment un développeur pourrez faire ça sans magouiller.

Bref c'est à ce moment là que coder devient vraiment une tâche ingrate en effet.
Difficile de trouver la bonne boîte, je pense que dans les grosses boîtes finalement ça irait peut être mieux surtout si les chef de projets sont des développeurs très expérimenté.

Mais je ne sais pas comment ça se passe dans les grosses boîtes exactement, si quelqu'un pouvait en témoigner ça serait sympa.

PS : mais m'étant un peu informé sur la structure de certaines boîtes il y a au 1er rang les développeurs, ensuite après plusieurs années ils deviennent chefs de projets. Ca parait déjà mieux mais dans les grosse boîtes j'ai peur de n'être considéré que comme un robot. (Je pense que il doit y avoir des inconvénients dans les 2 types de structure l'idéal se serait une grosse boîte mais pas trop grosse avec des chefs de projets qui étaient des développeur autrefois et qui ont une certains ancienneté.)

[Matthieu Vergne]

L'idéal c'est une petite team hétérogène d'expérimentés.

[Invité]

Oui se serait bien mais faut avoir la chance d'en trouver moi jusqu'à présent j'ai du presque tout me taper seul.

[Matthieu Vergne]

Pour ma part, je pense plutôt qu'il faut continuer de chercher jusqu'à les avoir trouvé. Mais bon, on a toujours des deadlines... perso je trouve ça contre-productif, les deadlines. Ou plutôt ça favorise la productivité sur le court-terme au dépend de celle sur le long-terme. Mais c'est un autre débat. {^_^}