Comme dit plus haut, c'est malhonnête en soi et personne ne fonctionne au chantage. En plus, dans notre métier en particulier (pourvu que ça dure) les développeurs sont quasiment en situation de plein emploi. Donc, soit le dev est incompétent (il y en a beaucoup plus que l'on croit) au moins sur une techno donnée, soit la compagnie fait déjà des pieds et des mains pour tenter de retenir ses éléments.
Avec ça, il y a un phénomène dont toutes les petites et moyennes structures ont fait l'expérience si elles ont un jour mené un projet de développement : même avec la meilleure volonté du monde, le logiciel devient de toutes façons et de lui-même, soit obsolète soit impossible à maintenir. Même si le dev est un « full stack » et connaît toutes les technologies sur le bout des doigts, il faut toujours au moins 500 jours/homme pour produire quelque chose qui soit réellement abouti sur tous les plans. Même faire de l'intégration, ou être mainteneur de packages pour une distribution, est une activité extrêmement chronophage. Et l'ennui des petites structures, c'est que pour verser un salaire au développeur, il faut vendre vite et si possible beaucoup.
Donc, le dev n'a pas le temps de produire quelque chose d'exhaustif dès le départ. Ce n'est pas du mercantilisme, c'est juste que s'il n'y a pas rapidement une première vente, il n'y aura pas de fond pour poursuivre le développement.
Du coup, les logiciels qui deviennent vraiment pérennes dans le temps sont ceux dont l'équipe a pu atteindre une masse critique, justement parce qu'elle ne dépend pas d'un seul développeur. Donc soit les logiciels de grosses entreprises, avec des équipes et des processus métier bien rodés, soit des projets de logiciel libre qui, par nature, ne sont pas liés au départ à une contrainte de temps et que les personnes intéressées peuvent rejoindre au fur et à mesure de leur avancement.
Et enfin, lorsque l'on arrive à surmonter tout cela, dans le contexte actuel, c'est généralement le développeur qui part de lui-même. Du coup, toutes les sociétés sont déjà habituées à prévoir un plan de repli ou à mettre carrément un projet en sommeil le temps de former une autre équipe.
La meilleure façon, au contraire, de pérenniser son emploi est d'être rentable. Il ne s'agit pas de devenir volontairement une vache à lait bien sûr, mais le meilleur argument pour se rendre « indispensable » est d'être capable d'exhiber ce que ton travail rapporte à la compagnie par rapport à ce que tu lui coûtes. Fort de cela, et si ça marche bien, tu peux essayer de négocier une augmentation pour récupérer ta part du gâteau tout en restant « profitable ».
Et s'il s'avère que justement, « ce n'est pas la politique de la compagnie » ou que tu travailles dans une de ces SSII où le principe est de te payer le minimum en te promettant monts et merveilles jusqu'à ce que tu décides toi-même de mettre un terme à la mascarade, alors au contraire, il faut essayer de perdre le moins de temps possible et essayer rapidement une nouvelle structure. Et pour cela, tu auras besoin à la fois de faire une transmission de compétences pour être libéré rapidement et d'un portfolio pour intégrer facilement un autre poste. Et ça, ce sont deux très bonnes raisons d'écrire le code le plus propre et le plus accessible possible.
Pour finir, sache que la personne qui devra un jour faire face à ton code réellement « obfusqué » sera probablement... toi-même. Entre 20 et 35 ans, on retient en général tout de tête. Après, ça devient difficile. Mais malgré cela, imagine qu'on te place huit mois sur une mission secondaire, puis que tu prennes trois semaines de vacances avant de reprendre ton développement initial. Tu verras alors à quel point il est difficile de se ré-immerger dans son propre travail...
[^] # Re: Pas forcément commercial
Posté par Obsidian . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 10.
Comme dit plus haut, c'est malhonnête en soi et personne ne fonctionne au chantage. En plus, dans notre métier en particulier (pourvu que ça dure) les développeurs sont quasiment en situation de plein emploi. Donc, soit le dev est incompétent (il y en a beaucoup plus que l'on croit) au moins sur une techno donnée, soit la compagnie fait déjà des pieds et des mains pour tenter de retenir ses éléments.
Avec ça, il y a un phénomène dont toutes les petites et moyennes structures ont fait l'expérience si elles ont un jour mené un projet de développement : même avec la meilleure volonté du monde, le logiciel devient de toutes façons et de lui-même, soit obsolète soit impossible à maintenir. Même si le dev est un « full stack » et connaît toutes les technologies sur le bout des doigts, il faut toujours au moins 500 jours/homme pour produire quelque chose qui soit réellement abouti sur tous les plans. Même faire de l'intégration, ou être mainteneur de packages pour une distribution, est une activité extrêmement chronophage. Et l'ennui des petites structures, c'est que pour verser un salaire au développeur, il faut vendre vite et si possible beaucoup.
Donc, le dev n'a pas le temps de produire quelque chose d'exhaustif dès le départ. Ce n'est pas du mercantilisme, c'est juste que s'il n'y a pas rapidement une première vente, il n'y aura pas de fond pour poursuivre le développement.
Du coup, les logiciels qui deviennent vraiment pérennes dans le temps sont ceux dont l'équipe a pu atteindre une masse critique, justement parce qu'elle ne dépend pas d'un seul développeur. Donc soit les logiciels de grosses entreprises, avec des équipes et des processus métier bien rodés, soit des projets de logiciel libre qui, par nature, ne sont pas liés au départ à une contrainte de temps et que les personnes intéressées peuvent rejoindre au fur et à mesure de leur avancement.
Et enfin, lorsque l'on arrive à surmonter tout cela, dans le contexte actuel, c'est généralement le développeur qui part de lui-même. Du coup, toutes les sociétés sont déjà habituées à prévoir un plan de repli ou à mettre carrément un projet en sommeil le temps de former une autre équipe.
La meilleure façon, au contraire, de pérenniser son emploi est d'être rentable. Il ne s'agit pas de devenir volontairement une vache à lait bien sûr, mais le meilleur argument pour se rendre « indispensable » est d'être capable d'exhiber ce que ton travail rapporte à la compagnie par rapport à ce que tu lui coûtes. Fort de cela, et si ça marche bien, tu peux essayer de négocier une augmentation pour récupérer ta part du gâteau tout en restant « profitable ».
Et s'il s'avère que justement, « ce n'est pas la politique de la compagnie » ou que tu travailles dans une de ces SSII où le principe est de te payer le minimum en te promettant monts et merveilles jusqu'à ce que tu décides toi-même de mettre un terme à la mascarade, alors au contraire, il faut essayer de perdre le moins de temps possible et essayer rapidement une nouvelle structure. Et pour cela, tu auras besoin à la fois de faire une transmission de compétences pour être libéré rapidement et d'un portfolio pour intégrer facilement un autre poste. Et ça, ce sont deux très bonnes raisons d'écrire le code le plus propre et le plus accessible possible.
Pour finir, sache que la personne qui devra un jour faire face à ton code réellement « obfusqué » sera probablement... toi-même. Entre 20 et 35 ans, on retient en général tout de tête. Après, ça devient difficile. Mais malgré cela, imagine qu'on te place huit mois sur une mission secondaire, puis que tu prennes trois semaines de vacances avant de reprendre ton développement initial. Tu verras alors à quel point il est difficile de se ré-immerger dans son propre travail...