En tant qu'employé d'une entreprise, lorsque vous écrivez du code, vous sentez-vous que vous y êtes attaché? Pensez-vous que vous avez une certaine propriété du code? Ou l'écrivez-vous complètement détaché de lui sans vous soucier de ce qui lui arrive après que vous êtes passé à autre chose?
EDIT: Je ne parle pas d'écrire un mauvais code, puis d'exécuter ...
Réponses:
Après 30 ans en tant qu'entrepreneur, c'est mélangé.
Tout est jetable. J'ai travaillé avec des centaines de clients. Je ne reverrai plus jamais le code. Pourquoi devenir attaché? Il n'y a aucun sentiment d'appartenance.
C'est très visible. Il est plus cher que le code interne, il fait donc l'objet d'un examen minutieux. Comme je ne serai pas là pour le maintenir, cela fait l'objet d'un examen minutieux. Les procédures pas à pas et les transferts de code sont très importants. Il y a une certaine fierté dans l'artisanat. Mais aucun sentiment d'appartenance.
Mon record est de 17 ans de production. 12 de ces années sans aucun entretien.
Je le sais parce que j'ai reçu un appel. Ils révisaient leurs systèmes comptables et voulaient savoir comment remplacer l'algorithme intelligent de répartition des coûts que j'avais construit il y a tant d'années. J'ai regardé le code et les fichiers sont restés inchangés depuis la dernière amélioration il y a 12 ans. (Pas un correctif de bogue, AFAIK.)
La prochaine course la plus longue - à ce que je sache - a été 7 ans de fonctionnement sans faille. Cependant, cela posait un grave problème pour l'an 2000 et nécessitait quelques retouches pour utiliser des noms de fichiers qui avaient des années à 4 chiffres. Les algorithmes internes étaient tous corrects, mais les fichiers journaux seraient apparus dans le mauvais ordre.
Encore une fois, je sais que c'était impeccable car les fichiers n'avaient pas été touchés depuis la dernière version que j'avais faite.
Donc, oui, il y a beaucoup de fierté dans l'artisanat.
Mais pas de "propriété". C'est leur code, pas le mien. Je ne fais que le construire.
En tant que développeur plus ou moins solo, la peur d'avoir à maintenir ce que j'écris est le principal moteur derrière moi pour essayer de ne pas écrire de code horrible.
Au travail, une partie du code m'appartient, dans un sens similaire à celui de la chaise dans laquelle je suis assis. Je l'ai écrit, je l'ai fait aussi bien que je le pouvais, je me sens possessif, les gens me poseront des questions sur les changements et les gens l'appelleront le mien. Et, comme ma chaise, une fois que je quitte l'entreprise, je ne la reverrai plus, et je n'aurai plus d'attachement émotionnel.
Le mot «mien» a beaucoup de variations sur sa signification. "Ma femme" et "ma brosse à dents" ne sont pas strictement parallèles.
Si vous écrivez du code pour vous-même, vous pouvez vous permettre d'avoir des sentiments à son égard. Si vous écrivez du code pour une entreprise, vous devez purger vicieusement ces sentiments chaque fois que possible. Je ne peux pas compter le nombre de fois où j'ai vu un bon programmeur se faire du mal en devenant émotif par rapport au code.
Dites-vous: "Je l'ai fait, c'est bien, mais ce n'est pas le mien et je peux en faire plus." Si vous le croyez , alors quand 6 mois de votre vie deviennent obsolètes parce qu'un représentant des ventes d'un produit inférieur a donné un patron à votre patron pendant le déjeuner, vous ne perdez pas votre travail pour devenir fou de lui.
N'oubliez pas qu'ils vous paient. Nous aimerions tous faire des choses sympas, mais s'ils nous paient pour creuser des trous, puis les remplir à nouveau, c'est leur privilège. Je viens d' avoir une situation où j'ai écrit une application Web, puis passé des mois incorporant des caractéristiques terribles, puis mois plus coder à l'état d' origine. Les deux dernières semaines de travail ont été retirées de mon dépôt SVN, puis je l'ai réengagé avec les nouveaux numéros de version. Et je suis d'accord avec ça.
Non, mais je déteste vraiment devoir corriger les bogues introduits par d'autres dans le code que j'ai écrit à l'origine. Je serais plus heureux si le changement m'avait été attribué en premier lieu. Je le déteste encore plus lorsque le correctif est complètement en dehors de la conception d'origine, par exemple en créant une dépendance circulaire avec un module de niveau supérieur.
Oui et non.
Oui - c'est quelque chose que vous avez créé et donc vous avez un attachement, tout comme un concepteur automobile est fier ou embarrassé lorsqu'il voit des voitures qu'il a conçues sur la route.
Non - En ce qui concerne la propriété, vous renoncez généralement à cela en échange d'être payé pour travailler dans une entreprise. Les employés d'usine qui construisent des voitures n'obtiennent aucune propriété dans chacun d'eux, car ils sont payés pour leur temps.
Je me sens très propriétaire du code que j'écris; il représente les décisions que j'ai prises sur la façon de résoudre un problème donné et reflète donc ma capacité à réfléchir à un problème de manière rationnelle et à concevoir une solution logique et, espérons-le, élégante. Cela dit, tout ce que j'écris sur le temps de l'entreprise appartient à l'entreprise. J'espère que rien ne revient me mordre, et je préférerais qu'on me demande de réparer mon propre code, mais sinon, alors non. (Et je pourrais ajouter que le gars qui écrivait du code il y a trois mois et y mettait mon nom en contrôle de source est un idiot).
Pas du tout. Une fois que je l'ai enregistré, ce n'est plus "le mien". Je serai le go-to guy pour la maintenance et le dépannage, bien sûr, mais je ne ressens aucun sentiment d'appartenance à ce sujet.
J'ai connu des gens qui se sentaient très propriétaires de leur code, au point où ils seraient irrités si quelqu'un d'autre corrigeait un bogue ou le modifiait d'une manière ou d'une autre sans l'exécuter par eux au préalable. Je n'ai jamais ressenti ça. Tout ce que je demande, c'est que si vous trouvez un problème dans mon code et que vous le résolvez, dites-moi quel était le problème et comment il a été résolu afin que je ne fasse pas la même erreur à l'avenir.
J'adore les codes que j'écris. Je les comprends et les adapte pour que les autres aussi. Quand les gens viennent me voir et me disent "Mec, nous utilisons toujours le script que tu as écrit pour nous. C'est tellement stable et portable", j'aime ce sentiment de fierté et de propriété.
Il n'y a aucun mal à s'attacher à votre code si vous pouvez voir où cela va se terminer, c'est-à-dire si tout est en interne et que vous savez pour qui ou pour quoi vous programmez, alors je dirais que c'est une bonne chose à obtenir attaché . Coz, vous adorerez créer plus d'éclat, encore plus.
D'un autre côté (pleinement conscient que je pourrais répéter ce que @ S.Lott a dit) si le code va finir comme la propriété d'un client, alors il n'y a aucun sens à devenir sentimental. C'est comme ... prendre soin du chiot de votre ami quand il est parti en vacances. : - /
Les entrepreneurs et les consultants qui pourraient ne jamais revoir leur code ne sont probablement pas le candidat idéal pour s'attacher émotionnellement à leur code. Devoir «l'abandonner» encore et encore paralyserait probablement la motivation créative des pauvres consultants après un certain temps.
Si nous le considérons du point de vue d'un employé et non d'un entrepreneur, je dirais que j'aimerais que tous les membres de mon équipe se sentent propriétaires du code qu'ils écrivent et de tout ce qu'ils créent. Cette appropriation et cette fierté devraient s'étendre à toute l'équipe. Le sentiment de fierté et d'appropriation crée un attachement au produit dans les questions et ajoute du sens et du sens au travail d'un membre de l'équipe. J'ai vu cela augmenter considérablement les performances dans les petites et grandes équipes.
Ce qui devrait être évité et ce que je n'aime pas, ce sont les gens qui semblent émotionnellement attachés aux lignes de code spécifiques qu'ils ont écrites et le défendent dans la tombe. Ils ne veulent pas de changements, ils regardent vers le bas et refusent toute idée de changement ou d'amélioration et essaient de le justifier avec quelque chose qui semble crédible. D'après ma propre expérience, cela se résume souvent à la peur du changement et à la peur de l'inconnu. Ce n'est pas réellement abandonner leurs anciennes lignes de code qui est le problème. Au lieu de cela, il faut prendre quelque chose de nouveau, parfois non écrit par vous-même, et la peur de l'échouer.
Ce type d'attachement «malade» au code est quelque chose que je travaille dur pour éviter. Mais j'encourage les connexions émotionnelles «saines» au produit et, par extension, au code écrit.
C'est une question intéressante et je suis d'accord avec l'un des messages ci-dessus: Oui et Non - mais pour différentes raisons.
Dois-je m'attacher au code? Définitivement oui. Mais je ne pense pas que ce soit le code lui-même mais l'architecture globale et l'application. Habituellement, vous devez faire beaucoup de recherches spécifiques à un domaine avant de pouvoir vraiment mettre en code ce que les gens d'affaires veulent (sauf si vous écrivez un IDE - alors vous êtes définitivement coincé dans la récursivité).
D'un autre côté: il n'y a pas beaucoup de choses que j'aime plus que de jeter des parties obsolètes de la base de code. Peu importe la difficulté de l'écriture. Le voyage importe beaucoup plus que le produit (au moins pour l'ego, bien sûr, le produit lui-même doit également fonctionner).
Y a-t-il un sentiment d'appartenance? Eh bien, cela dépend de la situation du projet. Quand vous ne reverrez plus jamais le code (parce que votre part dans le projet est terminée et que vous passez à autre chose), alors pourquoi devenir romantique avec ce truc? Cependant, si vous continuez à le soutenir (de quelque manière que ce soit), une sensation d'attachement est une bonne chose! Lorsque vous vous souciez du produit que vous construisez, les chances sont assez élevées que vous essayez de livrer des artefacts de haute qualité.
Donc, dans l'ensemble, j'essaie d'adopter une "relation" pragmatique avec le code que j'écris.
Bon sang, j'ai déjà battu un collègue parce qu'il était assez arrogant pour renommer quelques variables.
Non, pas vraiment. Je suis payé pour le développement de logiciels. Même si je l'admets, voir les corrections de bogues apportées à mon code par d'autres développeurs a un impact sur -l'ego-.