IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

J'aime la programmation informatique, mais je déteste l'industrie de la programmation
Par deathbyabstraction

Le , par deathbyabstraction

95PARTAGES

7  1 
Je n'ai jamais vraiment trouvé ma place dans aucun des postes d'ingénieur logiciel que j'ai occupé. L'aspect technique des choses est devenu ennuyeux une fois que j'ai acquis une compréhension de base de la logique interne de la base de code et que je ne me suis plus sentie mise au défi, et j'ai alors voulu en faire plus, et plus important encore, le faire différemment.

Je me suis interrogé sur les décisions en matière de conception et sur leur objectif général : pourquoi faisons-nous cela et pourquoi le faisons-nous de cette manière spécifique ? Existe-t-il une meilleure façon de procéder ? Quelles mesures utilisons-nous pour déterminer le succès et pourquoi ? Même si ces questions n'étaient pas toujours posées à voix haute, on me disait que je « réfléchissais trop » et que je « me souciais trop », alors que je pourrais utiliser ce temps pour produire davantage de lignes de code.

Je n'étais pas à ma place, et j'étais trop jeune et peu sûr de moi pour comprendre qu'il ne s'agissait pas d'une simple inadéquation entre mon talent et mon poste. C'est que je n'étais pas du tout d'accord avec la façon dont ces endroits fonctionnent et que je voulais travailler pour les changer plutôt que de les perpétuer.

Si une partie de moi ne s'est jamais dite qu'il devait y avoir de meilleures choses ailleurs, le fait de consulter des offres d'emploi pendant quelques semaines en 2023 a suffi à mettre fin à cette illusion. 90 % du temps, lorsque je lis des descriptions, il est atrocement évident pour moi que le code que les candidats choisis finiront par écrire dans le cadre de ce travail sera complètement éloigné de tout problème important que non seulement l'humanité, mais même tout être humain individuel, n'a jamais eu.


La culture des startups est sans vergogne à l'avant-garde de la politique de ce secteur qui consiste à « produire plus de code et à poser moins de questions ». La plupart des startups ne font que déplacer l'argent des investisseurs tout en essayant d'acquérir des utilisateurs payants en les convainquant qu'ils ont besoin d'un produit qui, le plus souvent, n'est au mieux que marginalement utile.

Elles échouent généralement en laissant derrière elles des milliers de lignes de code spaghetti non maintenable que les ingénieurs ont été contraints d'écrire en quelques semaines au lieu de quelques mois en utilisant des technologies arbitraires à la mode. Personne ne regardera plus jamais cette horreur, sauf peut-être comme un exemple de mauvaises pratiques de codage, le temps des ingénieurs a été gaspillé et le capital-risque finit en grande partie dans les mains de ceux qui possèdent déjà un capital important - ils peuvent l'utiliser pour financer une autre startup, et ce cycle misérable continue.

Les offres d'emploi qui tentent de présenter cela comme une sorte d'entreprise passionnante et utile qui enrichira la vie des gens et stimulera ma croissance en tant qu'ingénieur sont une insulte à mon intelligence. Je ne veux pas faire partie de cela - pas seulement parce que c'est sans doute immoral, mais parce que c'est fondamentalement et exaspérément ennuyeux et inutile.

Si les entreprises technologiques établies diffèrent des startups sur le plan organisationnel et financier, elles ne s'opposent pas vraiment sur le plan culturel.

Certes, le code que vous écrivez chez un FAANG peut arriver jusqu'aux utilisateurs, mais ce que vous pensez, en tant qu'individu, de tout aspect de l'écriture du code sera plus que jamais sans importance. Vous êtes un rouage dans une machine, non seulement dans le sens où le produit que vous construisez est susceptible d'automatiser les pires aspects du capitalisme de manière de plus en plus sinistre, mais aussi dans un sens pratique, vous êtes un nombre : la taille de votre pile de backend, ou votre score aux entretiens techniques, ou votre score à l'évaluation des performances.

Ce n'est pas tant cette réalité en elle-même qui est si atroce à mes yeux, mais plutôt le fait qu'en tant qu'ingénieurs, nous sommes censés trouver cette tâche vide et humiliante encore plus ambitieuse que beaucoup d'autres travailleurs, et que nous sommes encore plus découragés de remettre en question tout aspect de cette tâche.

Essentiellement, le concept de pensée critique a été rendu anathème pour l'ingénierie : en tant que programmeur, vous devez vous concentrer uniquement sur le comment, rarement sur le quoi, et certainement jamais sur le pourquoi. Pour le rare singe code qui se trouve capable et désireux de critiquer le système pour lequel il produit, le message est clair : laissez cette merde à la porte. Un code monkey ne peut même pas identifier le manque d'autonomie et de créativité inhérent à son poste - il ne peut que s'efforcer de construire plus, jamais de construire différemment, ou de construire des choses différentes et meilleures.

Ainsi, si cette mentalité du monde de la technologie, qui consiste à faire plus et à demander moins, peut produire plus de code, elle conduit aussi systématiquement à des logiciels de moins bonne qualité.

Même dans les cas où le capital et d'autres forces hors de notre contrôle immédiat nous permettent théoriquement de construire des logiciels d'une manière durable, ou qui ont un impact positif sur le monde en général, ou qui sont au moins utiles en pratique, nous ne le faisons toujours pas, à cause d'une simple inertie : il est plus facile et généralement plus viable de faire ce qui est à la mode et de reproduire le statu quo une fois de plus.

Pire encore, cette même inertie s'infiltre dans l'ensemble de la pile technologique sur laquelle ce produit sociétalement inutile est construit. Les technologies, jusqu'aux langages, aux bibliothèques, aux frameworks et même aux patterns de code, sont infectées par la même marque de nouveauté et de gadgets avant l'innovation réelle qui affecte l'industrie dans son ensemble. Après tout, si vous ne résolvez pas de problèmes non conventionnels, pourquoi auriez-vous besoin d'une ingénierie non conventionnelle ?

En vérité, les problèmes d'ingénierie les plus intéressants sont généralement ceux qui se posent naturellement dans notre société, par opposition à ceux pour lesquels le progrès technologique est une fin en soi, ou même à ceux qui tentent de créer artificiellement une demande de marché là où il n'y en a pas.

La nécessité sociétale est le meilleur moteur possible de l'innovation - rappelez-vous qu'historiquement, les réalisations les plus révolutionnaires des débuts de l'informatique se sont produites au service du bien commun. C'est ce que je veux vraiment faire : Je veux que chaque comment - depuis le langage et le paradigme de programmation, l'architecture, jusqu'à chaque ligne de code et morceau de syntaxe - soit informé par le pourquoi du système qui est en train d'être construit. Et je veux que ce pourquoi soit le reflet d'un véritable besoin existant, et non d'une mesure commerciale à la con qui n'existe que pour elle-même.

Jusqu'à présent, je n'ai pas eu la chance de rencontrer quelqu'un qui partagerait ces valeurs de manière significative et qui voudrait faire ce genre de travail d'ingénieur. Malgré l'isolement que je ressens souvent dans mes interactions avec cette industrie, je suis confiant dans la valeur de mon travail et dans l'importance des choses que j'ai à dire. Si vous êtes cette personne, n'hésitez pas à me contacter - il serait intéressant de savoir s'il existe déjà une place pour quelqu'un comme moi. Et si ce n'est pas le cas, je pense qu'il serait bénéfique pour nous de la créer.

Source : "I love programming but I hate the programming industry" (par deathbyabstraction)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Pourquoi il n'est pas possible d'échanger les programmeurs : la programmation en tant que construction de la théorie, par Peter Naur

Programmation : quelles sont les qualités essentielles pour être un acteur de la filière ? Quelles sont celles qui montrent qu'on est fait pour ce job avant d'entamer un programme d'études ?

« La programmation informatique est difficile » : mythe ou réalité ? « Cette idée manque de preuves suffisantes et peut impacter de façon négative sur de futurs postulants », selon un universitaire

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 07/10/2024 à 16:52
Citation Envoyé par deathbyabstraction Voir le message
J'aime la programmation informatique, mais je déteste l'industrie de la programmation, par deathbyabstraction

Je n'ai jamais vraiment trouvé ma place dans aucun des postes d'ingénieur logiciel que j'ai occupé. L'aspect technique des choses est devenu ennuyeux une fois que j'ai acquis une compréhension de base de la logique interne de la base de code et que je ne me suis plus sentie mise au défi, et j'ai alors voulu en faire plus, et plus important encore, le faire différemment.
Une entreprise veut rarement que l'on fasse les choses différemments. Elle préfère s'en tenir à l'expertise qu'elle ont, en minimisant les risques. Si tu propose des solutions que tes collègues ne peuvent comprendre ou utiliser, tu es plus un problème qu'une solution. Bienvenu dans la vraie vie.

Citation Envoyé par deathbyabstraction Voir le message
Je me suis interrogé sur les décisions en matière de conception et sur leur objectif général : pourquoi faisons-nous cela et pourquoi le faisons-nous de cette manière spécifique ? Existe-t-il une meilleure façon de procéder ? Quelles mesures utilisons-nous pour déterminer le succès et pourquoi ? Même si ces questions n'étaient pas toujours posées à voix haute, on me disait que je « réfléchissais trop » et que je « me souciais trop », alors que je pourrais utiliser ce temps pour produire davantage de lignes de code.
Encore une fois, sauf dans de rare cas, on demande à un employé (ou un collaborateur comme on dit maintenant) de produire, pas de réflèchir. Il faut une énergie énorme pour faire changer de direction ou la manière dont fonctionne une entreprise, et généralement, ce n'est pas du bas que peuvent venir les changements. Si tu veux "réfléchir" et/ou "te soucier plus", il faut trouver un poste de chercheur. Une entreprise, c'est un paquebot à qui il faut du temps pour changer de direction. Si tu viens tourner autours de ce paquebot avec ton jet-sky, tu ne pourra jamais devenir le commandant du paquebot...

Citation Envoyé par deathbyabstraction Voir le message
Je n'étais pas à ma place, et j'étais trop jeune et peu sûr de moi pour comprendre qu'il ne s'agissait pas d'une simple inadéquation entre mon talent et mon poste. C'est que je n'étais pas du tout d'accord avec la façon dont ces endroits fonctionnent et que je voulais travailler pour les changer plutôt que de les perpétuer.

Si une partie de moi ne s'est jamais dite qu'il devait y avoir de meilleures choses ailleurs, le fait de consulter des offres d'emploi pendant quelques semaines en 2023 a suffi à mettre fin à cette illusion. 90 % du temps, lorsque je lis des descriptions, il est atrocement évident pour moi que le code que les candidats choisis finiront par écrire dans le cadre de ce travail sera complètement éloigné de tout problème important que non seulement l'humanité, mais même tout être humain individuel, n'a jamais eu.
Oui, une entreprise n'est pas là pour faire plaisir à l'humain, mais pour gagner de l'argent. Si ton "talent" est trop éloigné de 90% de tes collègues, tu ne saura pas travailler en équipe. Ils étaient là avant toi, ont des habitudes, des compétences, et s'appuye avec l'expérience sur ce qui fonctionne le mieux pour leur équipe. Si tu déboules dans une équipe en voulant tout révolutionner, persuadé que tu as raison, et même si tu as raison, tu vas forcément te hurter à un mûr. Tu dois comprendre tes collègues comme eux doivent pouvoir te comprendre. Et tout changement dans une routine bien établie, même si elle n'est pas "optimum", fera d'abord perdre du temps à coups sur, avant d'éventuellement en faire gagner plus tard. Les entreprises prennent rarement ce genre de risque.

Citation Envoyé par deathbyabstraction Voir le message
La culture des startups est sans vergogne à l'avant-garde de la politique de ce secteur qui consiste à « produire plus de code et à poser moins de questions ». La plupart des startups ne font que déplacer l'argent des investisseurs tout en essayant d'acquérir des utilisateurs payants en les convainquant qu'ils ont besoin d'un produit qui, le plus souvent, n'est au mieux que marginalement utile.
Cela se nomme le consummérisme, et qu'on le veuille ou pas, c'est ainsi que tourne le monde depuis très longtemps.

Citation Envoyé par deathbyabstraction Voir le message
Elles échouent généralement en laissant derrière elles des milliers de lignes de code spaghetti non maintenable que les ingénieurs ont été contraints d'écrire en quelques semaines au lieu de quelques mois en utilisant des technologies arbitraires à la mode. Personne ne regardera plus jamais cette horreur, sauf peut-être comme un exemple de mauvaises pratiques de codage, le temps des ingénieurs a été gaspillé et le capital-risque finit en grande partie dans les mains de ceux qui possèdent déjà un capital important - ils peuvent l'utiliser pour financer une autre startup, et ce cycle misérable continue.
C'est ainsi que cela fonctionne, un investisseur investit dans 10 petites startup, et si l'une d'elle décolle, ce sera le jackpot pour lui. Mais certainement pas pour les gens qui on fait le boulot, sauf si ce sont les mêmes qui font le boulot et qui investissent.

Citation Envoyé par deathbyabstraction Voir le message
Les offres d'emploi qui tentent de présenter cela comme une sorte d'entreprise passionnante et utile qui enrichira la vie des gens et stimulera ma croissance en tant qu'ingénieur sont une insulte à mon intelligence. Je ne veux pas faire partie de cela - pas seulement parce que c'est sans doute immoral, mais parce que c'est fondamentalement et exaspérément ennuyeux et inutile. Si les entreprises technologiques établies diffèrent des startups sur le plan organisationnel et financier, elles ne s'opposent pas vraiment sur le plan culturel.
Tu semble bien naif... Une offre d'emploi est là pour faire une sélection, par exemple en demandant des tonnes de compétences qu'il est impossible d'avoir en début de carrière. Seules ceux qui "osent" se présenter ont une certaine valeur. De plus, l'entreprise qui a un poste à pourvoir, noye cette offre dans un discour bien corporate, et bien souvent très éloigné du travail réel que tu auras à effectuer.

Certes, le code que vous écrivez chez un FAANG peut arriver jusqu'aux utilisateurs, mais ce que vous pensez, en tant qu'individu, de tout aspect de l'écriture du code sera plus que jamais sans importance. Vous êtes un rouage dans une machine, non seulement dans le sens où le produit que vous construisez est susceptible d'automatiser les pires aspects du capitalisme de manière de plus en plus sinistre, mais aussi dans un sens pratique, vous êtes un nombre : la taille de votre pile de backend, ou votre score aux entretiens techniques, ou votre score à l'évaluation des performances.
Si tu veux progresser dans une entreprise, les "relation sociales" sont bien plus importantes que ton "talent". C'est malheureux, certes, mais c'est ainsi depuis toujours, et cela n'est pas près de changer.

Citation Envoyé par deathbyabstraction Voir le message
Ce n'est pas tant cette réalité en elle-même qui est si atroce à mes yeux, mais plutôt le fait qu'en tant qu'ingénieurs, nous sommes censés trouver cette tâche vide et humiliante encore plus ambitieuse que beaucoup d'autres travailleurs, et que nous sommes encore plus découragés de remettre en question tout aspect de cette tâche. Essentiellement, le concept de pensée critique a été rendu anathème pour l'ingénierie : en tant que programmeur, vous devez vous concentrer uniquement sur le comment, rarement sur le quoi, et certainement jamais sur le pourquoi. Pour le rare singe code qui se trouve capable et désireux de critiquer le système pour lequel il produit, le message est clair : laissez cette merde à la porte. Un code monkey ne peut même pas identifier le manque d'autonomie et de créativité inhérent à son poste - il ne peut que s'efforcer de construire plus, jamais de construire différemment, ou de construire des choses différentes et meilleures.
Quelqu'un de trop talentueux pour une entreprise et aussi mauvais pour cette entreprise que quelqu'un de médiocre. Un entreprise n'est pas une démocratie. C'est au mieux un bateau à rame, où la synchronisation entre les rameurs est plus important que tout. Si tu ne rames pas à la même cadence que les autres, tu ne fait que perturber l'avancement du bateau.

Citation Envoyé par deathbyabstraction Voir le message
Ainsi, si cette mentalité du monde de la technologie, qui consiste à faire plus et à demander moins, peut produire plus de code, elle conduit aussi systématiquement à des logiciels de moins bonne qualité.
Une entreprise ne cherche pas a faire un produit parfait. Elle cherche a faire un produit suffisament bon pour qu'il soit vendable, et le tout à moindre coût. C'est un problème récurant avec les personnes "de talent". On peut toujours faire mieux, mais il faut savoir s'arrêter et pouvoir sortir un produit vendable. Une entreprise qui ne vend pas de produit, ne vit pas très longtemps...

Citation Envoyé par deathbyabstraction Voir le message
Même dans les cas où le capital et d'autres forces hors de notre contrôle immédiat nous permettent théoriquement de construire des logiciels d'une manière durable, ou qui ont un impact positif sur le monde en général, ou qui sont au moins utiles en pratique, nous ne le faisons toujours pas, à cause d'une simple inertie : il est plus facile et généralement plus viable de faire ce qui est à la mode et de reproduire le statu quo une fois de plus.
C'est pareil pour toutes les entreprises, technologique ou pas. Elles sont là pour vendre. Pas pour expérimenter des "nouvelles" manière de faire, mais en utilisant ce qui est maîtrisable par leurs équipes.

Citation Envoyé par deathbyabstraction Voir le message
Pire encore, cette même inertie s'infiltre dans l'ensemble de la pile technologique sur laquelle ce produit sociétalement inutile est construit. Les technologies, jusqu'aux langages, aux bibliothèques, aux frameworks et même aux patterns de code, sont infectées par la même marque de nouveauté et de gadgets avant l'innovation réelle qui affecte l'industrie dans son ensemble. Après tout, si vous ne résolvez pas de problèmes non conventionnels, pourquoi auriez-vous besoin d'une ingénierie non conventionnelle ?
Tu mélanges ton idéologie avec la vie réelle. Il y a pleins de choses "sociétalement inutile", et que tu as sans doute déjà acheté. Le monde n'est pas fait à ton image, c'est un mélange de tout et de son contraire.

Citation Envoyé par deathbyabstraction Voir le message
En vérité, les problèmes d'ingénierie les plus intéressants sont généralement ceux qui se posent naturellement dans notre société, par opposition à ceux pour lesquels le progrès technologique est une fin en soi, ou même à ceux qui tentent de créer artificiellement une demande de marché là où il n'y en a pas.
Il est vain de tenter de définir ce qui est "sociétalement utilie ou inutile". De plus, cette définition est à géométrie variable suivant l'endroit où tu vis, ton passé, ta projection dans l'avenir, et des chances que tu as eux (ou pas) au départ.

Citation Envoyé par deathbyabstraction Voir le message
La nécessité sociétale est le meilleur moteur possible de l'innovation - rappelez-vous qu'historiquement, les réalisations les plus révolutionnaires des débuts de l'informatique se sont produites au service du bien commun. C'est ce que je veux vraiment faire : Je veux que chaque comment - depuis le langage et le paradigme de programmation, l'architecture, jusqu'à chaque ligne de code et morceau de syntaxe - soit informé par le pourquoi du système qui est en train d'être construit. Et je veux que ce pourquoi soit le reflet d'un véritable besoin existant, et non d'une mesure commerciale à la con qui n'existe que pour elle-même.
Dans ce cas, ne cherche pas a te faire embaucher par une entreprise, crée la tienne avec tes valeurs et tes principes. Puis tu verras si en mettant 5 ans pour écrire le code parfait, alors qu'en 6 mois c'est possible de faire suffisament bien, tu arrives à vendre quelques chose à quelqu'un.

Citation Envoyé par deathbyabstraction Voir le message
Jusqu'à présent, je n'ai pas eu la chance de rencontrer quelqu'un qui partagerait ces valeurs de manière significative et qui voudrait faire ce genre de travail d'ingénieur. Malgré l'isolement que je ressens souvent dans mes interactions avec cette industrie, je suis confiant dans la valeur de mon travail et dans l'importance des choses que j'ai à dire. Si vous êtes cette personne, n'hésitez pas à me contacter - il serait intéressant de savoir s'il existe déjà une place pour quelqu'un comme moi. Et si ce n'est pas le cas, je pense qu'il serait bénéfique pour nous de la créer.
Je ne pense pas qu'avec le discours que tu tiens, et j'en suis désolé, tu attires les gens vers toi... Ta seule porte de sortie, c'est de créer ta boite, essayer d'attirer des gens qui "pensent" comme toi, et vogue la galère...

BàT et Peace & Love.
5  0 
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 07/10/2024 à 2:46
Le problème est que l'IT est un secteur très fortement tertiarisé avec toutes les dérives que cela implique.
2  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 07/10/2024 à 15:07
C'est un discours généralisable à beaucoup de boîtes et de métiers du tertiaire et pas que...

Si elle veut du code sensé, peut être qu'il faut quitter les startups à l'arrache pour aller dans une industrie utile qui lance des projets sur 10-20 ans et qui aura besoin de fiabilité et de maintenance surtout. Le métro automatique écrit avec la méthode b ça plante moins qu'un appli écrite pour un congrès.
2  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 09/10/2024 à 16:12
et bonjour laloune

Citation Envoyé par laloune Voir le message
là je ne suis pas trop d'accord. L'innovation qui permet d'optimiser certaines choses, et faire la même chose à un coût inférieur sera sans doute quand même valorisée
Il y a biensur des exceptions à toute "règle". Mais il ne faut pas mélanger "innovation" et "optimisation". On peut innover sans optimiser et optimiser sans innover.

Avant de créer un produit, il y a une phase R&D.

Puis, une fois un "prototype" fonctionnel, on va tenter d'obtenir les mêmes "exigences" pour le produit, mais en tentant d'en réduire le coût (autres composants, autre technique, etc).

Une fois ce produit terminé, quand il entre en phase de production, on va dans un premier temps mettre en place la chaine de production la plus fiable possible, puis on va optimiser au maximum cette chaine de production, pour produire plus vite et donc à moindre coûts.

Du côté logiciel (ou firmware), ce que l'on va tenter, c'est de rendre le produit toujours meilleur. On arrive alors à une version "définitive" du produit.

Ensuite, ce produit pourra être (ou pas), avoir une évolution "Hardware" (et donc software également), pour segmenter le produit et pouvoir vendre ce produit.

Il y a un mélange d'innovations, d'optimisations, mais qui seront surtout bien "encadrée" pour ne pas devoir refaire une autre chaine de production. Une chose bien "encadrée", ce sont les modifications software. On ne peut pas laisser partir dans la nature un produit vendu par milliers, avec un bug, et/ou un "nouveau traitement" qui règle un défaut du produit, mais apporte d'autres contraintes. C'est un jeu d'équilibriste.

Si on s'en tient à du "software" pur et dur, il faut surtout que la base de code reste maintenable par tous les membres de l'équipe. Vouloir utiliser un nouveau langage ou même des évolutions de ce langage, mais qui n'offrent pas un "plus" au produit, n'a pas de sens. Si le "petit nouveau" viens avec l'intention de remplacer une librairie testée et validée (tant en labo, que sur le terrain), il devra vite revenir les pieds sur terre.

On innove quand c'est nécessaire, pas justement parce que c'est possible.
On optimise quand n'est nécessaire, pas justement parce que c'est possible.


On a tous vu passer des "logiciels" qui faisaient bien le "taf", mais qui sont ensuite devenu des "poids lourd", à force d'ajouter et/ou de modifier ce qui fonctionnait par une "nouvelle méthode", qui au final rendait les choses plus compliquées qu'avant.

Il faut une "force de frappe" pour se permettre de changer les habitudes d'un client. Et toute "nouveauté" qui ne lui apporte rien, est vu comme un handicap. Microsoft peux se permettre de faire et défaire puis refaire, mais une petite structure spécialisée ne peut se le permettre.

BàT et Peace & Love.
1  0 
Avatar de Zeeraptor
Membre régulier https://www.developpez.com
Le 15/10/2024 à 21:43
https://codetapper.com/amiga/comedy/final-fight/

C'est le programmeur qui a fait la conversion Amiga de 'final fight' a l’époque

Un 'one_man project'

Peu conventionnel mais géniale
1  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 07/11/2024 à 9:46
Définition de "ingénieur" (Larousse):
Personne que ses connaissances rendent apte à occuper des fonctions scientifiques ou techniques actives en vue de prévoir, créer, organiser, diriger, contrôler les travaux qui en découlent, ainsi qu'à y tenir un rôle de cadre.
J'en conclue que l'auteur n'était pas ingénieur, mais juste développeur/programmeur/codeur (au choix).
Personnellement, dans tous les postes que j'ai occupés, j'ai toujours pu plus ou moins orienter les décisions techniques dans les projets sur lesquels j'étais. Quant à la qualité du code, d'abord, le client s'en fout, et c'est à chacun d'apporter son expertise. Pour les équipes constituées de juniors ou mauvais, il existe des solutions pour améliorer la partie technique (pair-programming et autres).
1  0 
Avatar de laloune
Membre éclairé https://www.developpez.com
Le 09/10/2024 à 15:39
C'est pareil pour toutes les entreprises, technologique ou pas. Elles sont là pour vendre. Pas pour expérimenter des "nouvelles" manière de faire, mais en utilisant ce qui est maîtrisable par leurs équipes.
là je ne suis pas trop d'accord. L'innovation qui permet d'optimiser certaines choses, et faire la même chose à un coût inférieur sera sans doute quand même valorisée
0  0 
Avatar de Zeeraptor
Membre régulier https://www.developpez.com
Le 12/10/2024 à 21:51
En gros,il y aurait tout a gagner en remunérant un programmeur de l'ombre peu conventionnel...Dans le but de développer une 'library' innovante
0  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 07/11/2024 à 10:39
Il n'y a que trois fois que j'ai fait des trucs réellement innovants. Dans les trois cas, j'ai outrepassé le cadre qu'on m'avait donné. Dans les trois cas, si je ne le faisais pas, le projet allait dans le mur.

La grosse différence, c'est comment les gens ont réagi.

  1. gloups...tu est sur de ton coup?
  2. bon, on a jamais vu ça, mais ça peut marcher - juste corrige tel point mineur pour respecter nos normes. Et prouves nous que ça marche, merci.
  3. tu as volé la banque!!! tu as dépensé de la charge sur des fonctions non demandées!!! (dans une banque, faut-il le préciser)


Ca a marché les trois fois. Les trois fois c'était un risque. Risque pris parce que l'alternative était une certitude d'échec. Dans tous les autres cas, j'ai respecté les instructions, parce que les instructions étaient respectables - même si pas souvent optimales.

On peut avoir une opinion exagérée de son propre talent. De sa propre compréhension de la situation. C'est pourquoi, à mon sens, il ne faut chercher à sauver le monde que celui-ci semble foutu. Et il y a toujours une part de chance - j'en ai eu, clairement, pour faire un 3/3 - quel que soit le niveau de talent, il ne suffit pas toujours (et j'aurais bien du mal à me situer). Toutes les autres fois ou je me suis posé la question, je me suis refreiné parce que le risque me semblait dépasser le gain escompté. Et aussi qu'avoir un système d'information médiocre mais où tout est standard, ces souvent plus facile à maintenir qu'un système qui mélange des styles géniaux mais incompatibles entre eux. Je ne me suis donc permis de sortir du standard que quand je ne pouvais pas faire autrement.

Je comprends la frustration de l'auteur, mais dans une grosse structure (je n'ai pas fait de startup, seulement des grosses structures), il faut aussi penser que parfois passent des médiocres, et que eux aussi doivent avoir des conditions pour être un minimum productif. Si on s'amuse à faire du génial pour les génies, on aura été contre productif. Dans ce cadre, du médiocre qui marche, c'est respectable. Et je l'ai toujours respecté.
0  0