Quel chapeau un programmeur ne devrait-il pas porter? [fermé]

D'après mon expérience, les développeurs de logiciels ont tendance à porter plusieurs chapeaux et à remplir plusieurs rôles avec différentes responsabilités. De non seulement le codage, mais parfois aussi l'écriture de SQL, la conception de l'interface utilisateur, la conception de la base de données, la manipulation graphique, voire les tests d'assurance qualité.

Si le rôle principal est d'écrire un logiciel / code, quels rôles le développeur ne devrait-il pas assumer? Y a-t-il?

L'intention de cette question n'est pas parce qu'un développeur est incapable de remplir un autre rôle - mais avoir le rôle supplémentaire fonctionne réellement contre le rôle principal , ou devrait vraiment être un rôle dédié de quelqu'un qui ne programme pas principalement.

Sysadmin. Le développement de logiciels et la gestion de l'infrastructure informatique sont deux compétences différentes qui ressemblent à un étranger. (Tout ne fait que cogner sur les ordinateurs, non?) Pour une petite entreprise, la tentation sera très forte de rendre The Computer Guy responsable de toutes les machines du bureau.

Si vous avez les compétences nécessaires pour porter les deux chapeaux, génial; mais c'est une de ces choses qui peut être beaucoup plus longue que les gens ne le pensent, et si vous vous auto-apprenez au fur et à mesure, vous ne le faites pas très bien.

Vous portez le chapeau que votre employeur vous demande. C'est ce qui fait de vous un joueur d'équipe. C'est ce qui fait de vous un résolveur de problèmes .

Les gens sont trop pris dans l'idée d'être un "développeur" ou un "architecte" ou un "analyste". Vis ça. Vous devriez être un résolveur de problèmes. Le code n'est qu'un outil dans votre ceinture.

La résolution de problèmes ne se démode jamais.

Si mon employeur veut que je fasse du support technique ou que je construise des ordinateurs, tant pis. Il pense qu'ils gaspillent leur argent, compte tenu du salaire d'un développeur, mais c'est leur affaire. Je suis ici pour résoudre des problèmes. Cependant, je peux le faire, je le ferai. Et si j'ai l'impression, après un certain temps, que mes talents sont gaspillés ou que ma satisfaction au travail n'est pas là où je veux qu'elle soit, alors j'ai juste le droit de passer à un autre travail.

Mais à la question fondamentale - il n'y a pas de chapeau que vous ne portiez pas. Heck, s'ils veulent que vous alliez chercher du café, faites-le. Résoudre leurs problèmes; sachez simplement que vous avez le droit de trouver un autre emploi si vous désirez un changement.

Testeur!

Veuillez nous envoyer des testeurs directement de l'école de testeurs si besoin est!

Sans testeurs, les gens s'attendent à ce que tout fonctionne au départ, car le programmeur est le testeur et ils sont très intelligents, donc cela devrait fonctionner.

Je ne dis pas que le dogfooding n'est pas une bonne idée. Je pense simplement que les testeurs sont très importants maintenant que je suis programmeur.

Vous devez faire attention à ne pas devenir le gars incontournable pour les problèmes de matériel de bureau . Cela peut inclure le dépannage du PC, l'administration du serveur, les sauvegardes et même le travail du système téléphonique. J'ai fait l'erreur de mentionner mon expérience matérielle précédente, et finalement mes tâches matérielles / de dépannage ont été gravement en conflit avec mes fonctions de programmation.

Un programmeur ne devrait pas être le seul testeur de son propre code .

Les développeurs écrivent du code avec un ensemble d'hypothèses. Si les testeurs ont le même ensemble d'hypothèses, ils n'exerceront pas la fonctionnalité inattendue en dehors de ces limites, et de nombreux problèmes resteront non détectés.

De plus, pour aller de l'avant, les développeurs ne sont pas très motivés pour essayer de casser les choses, contrairement aux testeurs (peut-être à un niveau subconscient).

Cela ne signifie pas que les tests de développement sont inutiles. Bien au contraire - de bons tests de développement permettent aux testeurs de se concentrer sur la recherche de problèmes plus profonds. Cependant, les tests de développement ne remplacent pas un testeur dédié.

Deux, je peux penser dès le départ.

1. Support technique. Je ne suis pas ici pour aider les clients à parcourir le nouveau site ou leur apprendre à utiliser les fonctionnalités.
2. Bien qu'il puisse être nécessaire d'interfacer avec les clients à différents moments du processus, à moins que vous ne soyez un programmeur gestionnaire, vous ne devriez vraiment pas communiquer directement avec eux sur les fonctionnalités et les implémentations de conception.

On pourrait dire que le développement CSS / UI serait en dehors du "domaine" de programmation mais d'après mon expérience, c'est une compétence nécessaire aujourd'hui. Vous ne pouvez pas vous contenter de tables et dépendre de quelqu'un d'autre pour l'implémenter correctement. Je n'aime peut-être pas implémenter la conception ou modifier le code pour gérer une nouvelle conception, mais cela fait partie du travail.

L'écriture de requêtes est très bien, les tests Q / A sont très bien (et IMO devrait être le travail du programmeur, avoir un département externe le fait, mais vous devez d'abord le tester). L'administration du serveur est un peu une zone grise. Selon la taille du projet ou si vous avez un administrateur de serveur dédié, il peut être nécessaire ou non.

En général, d'après mon expérience, la plupart des programmeurs ne devraient pas développer l'apparence de l'interface utilisateur - bien que je sois certainement capable de développer une interface utilisateur (et souvent en créer une lors de la construction d'un prototype ou d'une preuve de concept), c'est il vaut mieux laisser à une personne des facteurs humains (qui dans notre petite entreprise est un graphiste qui s'occupe également de la mise en page des écrans et crée la plupart des manuels et brochures).

De plus, les développeurs ne devraient pas faire de tests d'AQ - c'est le travail du département QA (la société dans laquelle je travaille fabrique des dispositifs médicaux intégrés, c'est donc une exigence que les tests soient effectués par un département séparé).

D'un autre côté, je ne vois aucune raison pour laquelle les développeurs ne peuvent pas concevoir de bases de données et écrire du SQL, s'ils ont les antécédents pour le faire - je l'ai fait plusieurs fois.

Support technique

Une grande partie de ma journée est perdue en prenant des appels au support technique ...

Certains populaires sont:

• "Mon compte est verrouillé" ou "J'ai oublié mon mot de passe"
• "Mon [téléphone | clavier | souris | ordinateur] ne fonctionne pas"
• "Mon ordinateur est lent, pouvez-vous vérifier s'il y a quelque chose d'inhabituel?"
• "Pourquoi X se produit-il lorsque je clique sur ce bouton? Il devrait faire Y"
• "Je continue à recevoir ces popups ...." ou "Je pense que j'ai un virus"
• "Cette personne n'est plus là, pouvez-vous désactiver toutes ses affaires?"
• "Nous avons un nouvel employé, pouvez-vous le configurer avec login, carte de sécurité, poste téléphonique, email, etc.?"

Tout rôle qui le fait se gérer lui-même. Dans les petites équipes, on a souvent tendance à faire de l'un des développeurs seniors le chef de projet, mais aussi à le garder dans l'équipe en tant que programmeur. Cela conduit à toutes sortes de problèmes, car ce type, en tant que programmeur, est fondamentalement non géré. Au lieu de déléguer toutes les tâches aux autres membres de l'équipe, il sera souvent tenté de s'en attribuer plusieurs, en particulier les tâches les plus difficiles. Ainsi, les tâches les plus difficiles, celles qui sont les plus susceptibles de causer des problèmes, sont confiées à une personne qui n'est disponible qu'à 50% en tant que programmeur et à ce titre ne rend compte à personne. Lorsque les autres membres de l'équipe sont incapables de livrer, au lieu de se botter le cul, il essaiera de faire leurs tâches, car, en tant que chef de projet, il est responsable du succès et le moyen le plus sûr de le faire est de le faire lui-même n'est-ce pas?

Support technique pour quelque chose que vous n'aviez aucune main dans le développement, le déploiement ou la maintenance, et qui n'a reçu aucune formation et n'est pas tenu au courant des changements majeurs. Une partie de mon travail consiste à répondre au téléphone pour les clients qui m'appellent pourquoi leur Internet ne fonctionne pas. Je ne m'occupe pas de cette moitié de l'entreprise, donc je ne peux rien leur dire d'utile.

Ce n'est pas d'avoir à faire du support technique, cela ne pose aucun problème. C'est être un secrétaire / support technique tout en essayant de développer des choses.

Cela devient assez éprouvant de devoir écouter les gens se plaindre toute la journée et de ne pouvoir rien leur dire. Je conseillerais d'éviter cela à tout prix.

Ventes .

Un pauvre bougre doit le faire, mais ce ne devrait pas être les développeurs.

En vieillissant, j'ai réalisé qu'il est préférable que les développeurs ne fassent pas leurs propres déploiements (je me suis battu bec et ongles). Ils ne devraient avoir aucun droit sur la base de données de production, à l'exception de certains droits. Notre code est devenu beaucoup moins bogué (et la même chose ne s'est pas reproduite plusieurs fois car le changement n'a été effectué qu'en prod et un déploiement de développement ultérieur l'a écrasé à nouveau puis fixé uniquement sur la prod en toute hâte, rincer et répéter) lorsque nous a dû commencer à le donner à d'autres personnes à déployer et ne pas être autorisé à apporter des modifications rapides à la production car le déploiement n'était pas tout à fait correct. De plus, nous avons cessé d'avoir ces mises à jour accidentelles sans que la clause where ne soit mise en évidence, ce qui modifiait chaque enregistrement du tableau.

Artiste et concepteur d'interface utilisateur .

La plupart des programmeurs sont très pauvres en œuvres d'art, mais les entreprises ne prennent pas la peine de payer pour qu'un artiste dessine des images et des icônes pour leurs produits, et utilisent simplement "l'art du programmeur" - avec des résultats hideux. (Jusqu'à Windows Vista, c'était le facteur de différenciation le plus évident entre les Mac et les PC - les Mac étaient beaux et conviviaux, les PC étaient une horreur)

De la même manière, beaucoup de programmeurs ne sont pas très intéressés par l'interface utilisateur - ils se soucient principalement de leur code. Ils exposent simplement le contenu de leurs variables membres directement dans certains champs modifiables, souvent sans se soucier de l'endroit où ils ont placé des boutons et des champs sur leurs formulaires, et supposent que cela est suffisant, ce qui entraîne un logiciel inutilisable. (Toute l'industrie du téléphone mobile était très coupable de cela jusqu'à ce que l'iPhone arrive pour leur montrer que vous pouvez réellement créer une interface utilisateur de téléphone agréable à utiliser)

Lotus Notes est un exemple brillant de la gravité de ces deux choses si vous n'obtenez pas de concepteur professionnel pour aider les programmeurs.

Rédaction de tests globaux et de plans de tests. Sérieusement, les gars, je peux écrire mes propres plans de test, mais cela signifie intégrer dans le produit les erreurs, les fausses hypothèses et les erreurs cognitives que j'ai commises lors de l'écriture. C'était la seule chose que je détestais à propos d'une entreprise dans laquelle je travaillais; où je suis maintenant, nous avons au moins des revues de code qui attraperont probablement ce genre de choses.

Ne portez jamais plus de "chapeaux" que ce que vous pouvez raisonnablement gérer et avec lequel vous êtes à l'aise, essayer de pigeonner les développeurs de trous en disant qu'ils ne devraient pas faire A ou B signifie qu'un grand concepteur d'interface utilisateur pourrait passer inaperçu parce que quelqu'un pense que les programmeurs devraient rester à l'écart de l'interface utilisateur.

À la fin de la journée, tout le monde aura des forces et des faiblesses différentes et un bon gestionnaire / superviseur / chef d'équipe devrait connaître la meilleure façon de diriger les personnes travaillant pour eux pour s'assurer que les talents sont utilisés de manière appropriée. De même, si vous n'êtes pas à l'aise avec la conception d'interfaces utilisateur ou avec les utilisateurs finaux, faites-le savoir à votre équipe afin de minimiser votre rôle dans ce domaine. Cependant, vous devez être prêt à reprendre des travaux supplémentaires dans un autre domaine.

De plus, si vous portez trop de chapeaux (par exemple, programmeur, concepteur d'interface utilisateur, testeur, analyste commercial, etc.), vous allez soit faire mal à certains d'entre eux, soit vous vous épuiserez. Assurez-vous que vous savez combien de chapeaux vous pouvez gérer et essayez de maintenir la charge de travail autour de ce niveau.

Au-delà de cela, il n'y a vraiment pas de "chapeaux" qu'un développeur ne devrait pas porter s'il a les compétences nécessaires pour exceller dans ce rôle.

J'ai tendance à accepter n'importe quel travail qui m'est lancé si et seulement si:

• Je préviens à l'avance de mon niveau de compétence et des implications possibles et mon patron décide qu'il est acceptable
• Il y a une personne de niveau gourou qui peut (et va probablement à un moment donné) m'aider à faire face à quelque chose d'inattendu
• Lisez la documentation, les questions posées en ligne, etc.

De cette façon, je suis principalement assuré contre mon patron et si quelqu'un se trompe, c'est au moins réparable.

Les développeurs sont des parties prenantes de la situation (comme les clients, les propriétaires, etc.), ils ont donc le droit de s'attendre à un travail significatif. À mon avis, cela signifie la possibilité de travailler avec vos forces .

Ainsi, un développeur ne doit pas porter un chapeau qui ne dynamise pas, ne contribue pas à la croissance personnelle et ne mène pas à des performances optimales - et ne vole pas le temps aux "chapeaux" qui font ces choses pour eux.

En plus d'être le seul à tester leur propre code, je pense que tout "chapeau" est correct si c'est un travail significatif pour le développeur qui porte le chapeau.

Le "designer" ou le "mec créatif". Vous passerez de la préparation innocente d'une maquette de l'interface d'une application à la rédaction d'un texte marketing pour la prochaine campagne publicitaire en ligne ou à des discussions sans fin sur la «bonne» nuance de bleu avant de la connaître x_x.

ce chapeau avec les canettes de bière sur le côté avec une paille. mauvaise idée si vous vous faites prendre.

modifier:

Voici le chapeau que je déteste mais qui a une grande récompense - c'est un grand signe sur moi qui dit que si cette chose casse c'est de ta faute .... ah, mais si c'est bon, alors toi mon fils est le bon garçon nous vous connaissons tous sont - maintenant retournez au sous-sol ... bon garçon ... c'est tout.

Le chapeau de blâme.