Question:
Dois-je faire mon travail comme le dit mon patron, si je connais un meilleur moyen?
quest
2017-04-27 22:43:20 UTC
view on stackexchange narkive permalink

Je suis programmeur de niveau junior dans une entreprise. Mon patron m'a confié la tâche de faire un travail d'une manière particulière, mais je pense que c'est trop compliqué et qu'il faut aussi étudier. Je peux faire la tâche à ma manière, ce qui nécessite l'utilisation d'un programme open source particulier.

Dois-je simplement faire la tâche comme le dit mon patron, ou le faire à ma manière?

N'utilisez aucun logiciel extérieur sans que votre patron vérifie les conditions de licence.
vous pouvez essayer de le suggérer et vous assurer que vous êtes en mesure de le justifier
Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/57921/discussion-on-question-by-quest-do-i-need-to-do-things-the-way-patron-demande).
J'ai l'impression que cette question est une mauvaise question telle qu'elle est écrite.D'où la prolifération de réponses de mauvaise qualité et de flammes sur les projets open source dans les commentaires.Il faut beaucoup plus de détails dans les domaines clés pour pouvoir fournir une réponse utile.
@Coxy Je ne suis pas d'accord.Il y a quelques réponses très utiles (fournissant des opinions différentes).Toute question avec ce niveau de popularité attirera des réponses de mauvaise qualité.
La blague serait sur vous si «à votre façon» reconstruisait essentiellement le composant qu'ils voulaient que vous remplaciez!
Cette question était trompeuse en surface.L'ajout de "qui nécessite l'utilisation d'un programme open source particulier" change tout dans la situation et change radicalement les réponses appropriées.Il semble que cette question soit en fait "En tant que développeur, dois-je intégrer un programme open source dans le logiciel de mon entreprise sans le dire à mon patron?"
Malgré mon autre commentaire ci-dessus, je rencontre cette situation plus souvent que je ne le souhaite.Une fois, j'ai fait quelque chose de contraire à la manière de conduire sans demander la permission parce que j'étais sûr à 90% qu'il dirait non à l'avance, mais j'ai pris le risque parce que mon chemin était non seulement meilleur, cela a pris littéralement 2 ou 3 jours au lieu de plusieurs semaines,alors je savais que je ne nous mettrais pas derrièreJ'ai attendu qu'après que Lead utilise mon travail et après qu'il ait loué le temps et la qualité, * puis * je lui ai fait savoir comment je le faisais avant qu'il examine le code, et j'ai dit que je pouvais toujours le faire à sa manière s'il le voulait.Je me suis préparé à l'impact, craignant un contrecoup, mais (1/2)
(2/2) ... mais il a admis que ce que j'ai fait était génial - il est même allé jusqu'à m'appeler un "génie" pour la façon dont j'ai mis en œuvre ma voie.Il a convenu qu'il aurait dit «non» si j'avais demandé à l'avance, mais maintenant il m'a demandé d'utiliser la même technique plusieurs fois depuis lors au lieu de sa manière.Remarquez!: Je ne vous suggère pas de prendre ce risque;c'est * EST * un risque, dont j'ai heureusement profité.Cela pourrait tout aussi bien conduire à un avis dans votre dossier RH vous rapprochant d'être renvoyé pour insubordination.Mon cas était quelque peu unique et j'ai jugé que j'allais probablement bien.
@Coxy Vous pouvez blâmer la mauvaise qualité sur le HNQ.La question ici est vraiment: "Mon patron m'a demandé de faire une tâche en utilisant la méthode X. J'ai une méthode Y qui, je pense, est meilleure. Devrais-je faire X comme mon patron le dit de toute façon?"La partie programme open source n'est pertinente que pour ce scénario particulier, mais la question générale s'applique même en dehors du développement logiciel.
@Aaron Je souhaite que vous puissiez étoffer cela dans une réponse, mais je vois que la protection de la question vous empêche de faire cela pour le moment, ce qui est un peu dommage.Néanmoins, alors que le PO précisera les détails relatifs à son scénario spécifique, nous pouvons toujours essayer de rendre la question aussi générale que possible, puis fournir une réponse qui s'applique non seulement à la situation du PO mais aussi à plusieurs autres.Pour cette raison, j'ai délibérément évité de mentionner le programme open source dans ma réponse.Votre commentaire / réponse et la plupart des autres réponses le font également!
Peut-être que `` l'étude requise '' est tout le but de la tâche ...
Treize réponses:
#1
+203
Masked Man
2017-04-27 23:01:28 UTC
view on stackexchange narkive permalink

Discutez de votre approche avec le patron. Ne donnez pas l'impression que votre approche est meilleure et que vous ne tenez pas compte de son approche.

Patron, j'ai analysé cette tâche et je me posais des questions sur l'approche alternative suivante. Qu'en pensez-vous?

Il y a deux résultats principaux, qui peuvent tous deux vous être bénéfiques:

  • Patron vous explique 1 pourquoi l'approche qu'il a suggérée est meilleure

    Cela vous montre une partie de la situation dans son ensemble et un aperçu gratuit de ce qui se passe dans les coulisses lorsque les patrons prennent ces décisions. En gravissant les échelons de l'entreprise, vous serez responsable de prendre ces décisions vous-même, de sorte que ces informations vous aideront plus tard.

    Votre entreprise fait des affaires et le développement de logiciels n'est qu'une partie de cette activité. Par conséquent, les considérations commerciales prévalent sur vos préférences personnelles . En tant que développeur junior, vous pouvez vous concentrer presque entièrement sur la partie développement logiciel, mais votre patron est responsable de prendre la bonne décision commerciale.

  • Le patron se rend compte que votre l'approche est meilleure

    C'est moins probable, mais pas impossible. Dans ce cas, non seulement vous accomplissez la tâche à votre façon, mais vous créez également une impression positive. La prochaine fois que cette tâche ou quelque chose de similaire devra être effectuée, votre patron se souviendra de vous comme de la personne qui a trouvé une meilleure façon de le faire 2 .

Ensuite, vous devez faire ce que le patron dit , dans les deux cas. Cependant, avec l'approche ci-dessus, votre patron verra que vous pensez réellement au travail que vous faites . C'est aussi souvent une considération importante au moment de décider des promotions aux niveaux juniors. Un développeur junior qui ne fait que ce qu'on lui dit a besoin d'une supervision constante et ne sera pas promu, tandis que quelqu'un qui essaie constamment de contribuer et de comprendre comment les choses fonctionnent peut se voir confier une plus grande responsabilité.


1 Si le patron refuse de vous expliquer, vous pouvez lui demander poliment, mais ne le harcelez pas. Parfois, le patron décide que faire le travail est de la plus haute importance et convaincre un employé junior est très bas sur sa liste de priorités. Dans ce cas, faites simplement le travail comme il le dit, et peut-être posez des questions plus tard quand il sera plus disposé à consacrer du temps à l'explication.

2 À moins que votre patron ne soit un crétin qui s'en offense, auquel cas vous avez un problème beaucoup plus important, qui est hors de portée de cette question.

#2
+104
Neo
2017-04-27 22:45:48 UTC
view on stackexchange narkive permalink

Dois-je simplement faire les choses comme le dit le patron, ce qui nécessite quelques études, ou faire la tâche à ma façon, ce qui nécessite l'utilisation d'un programme open source particulier?

I vous conseille vivement d'utiliser la méthodologie et la technologie décrites par votre patron. Il est plus expérimenté que vous et possède plus d'expertise dans le domaine commercial et technique.

Une fois que vous avez quelques projets à votre actif, n'hésitez pas à proposer des suggestions qui pourraient accélérer la réalisation d'une tâche. Ne soyez pas surpris que lorsque vous le faites, vous pourriez être mis au défi de justifier votre suggestion en fonction du délai de commercialisation, du coût initial et de la propriété totale.

J'envisage un vote défavorable simplement pour «Une fois que vous avez quelques projets à votre actif» en raison de la façon dont il est appliqué.Si OP devait simplement offrir des suggestions, alors quelques projets à votre actif sont totalement inutiles.Je grince des dents aux groupes qui rabaissent si mal les nouveaux développeurs qu'ils ne peuvent même pas faire de suggestions.Laissez-les suggérer;une suggestion n'est pas une décision.Ne les laissez pas passer le temps de tout le monde à suggérer de mauvaises idées tout le temps, mais laissez-les suggérer.
Il y a un peu une fausse dichotomie ici.Souvent, dans des situations comme celle-ci, une approche plus simple peut être utilisée comme outil de test.Lorsque cette implémentation produit des résultats différents, le développeur cherche à comprendre pourquoi.C'est un excellent exercice d'apprentissage pour le développeur.Il offre également l'occasion de démontrer l'alternative et de discuter des avantages et des inconvénients.Discuter d'une approche de travail est différent de discuter d'une idée.De toute évidence, le temps est une préoccupation.Si vous vous enlisez dans votre idée «facile», elle devrait être abandonnée, du moins à court terme.
@Aaron totalement d'accord.Nouvelle paire d'yeux, nouveau cerveau, nouvelles idées sont toujours agréables.Les suggestions sont bonnes.Ce type a été embauché pour une raison.Discuter du comment et du pourquoi des projets est un excellent exercice mental.Vous aide à prouver que vous connaissez votre domaine.Je dois parfois écourter les discussions, mais je préfère toujours demander des discussions plutôt que de marmonner grincheux sur «mon chemin est meilleur».Cela aide à la fois le patron et le nouvel employé.Cela ne fonctionne pas dans un fast-food, c'est de la programmation.
#3
+22
leigero
2017-04-27 23:22:29 UTC
view on stackexchange narkive permalink

Quand devriez-vous suivre votre patron
Lorsque votre patron vous donne des instructions explicites sur la façon dont quelque chose doit être fait, vous devez faire le travail comme il le décrit. En général, ils ne font pas tout leur possible pour expliquer comment quelque chose doit être fait à moins qu'ils ne se soucient du comment.

Vous ne devriez surtout pas «devenir voyou» en faisant votre propre truc après que le patron vous donne des instructions si cela implique l'utilisation de bibliothèques tierces. De nombreux problèmes peuvent généralement découler de l'utilisation de logiciels tiers, et en tant que nouveau développeur, ce n'est pas une bonne idée. L'utilisation d'un logiciel tiers (en particulier sans approbation) peut entraîner un ou plusieurs des problèmes suivants:

  • Problèmes de stabilité
  • Ramifications juridiques
  • Violation de l'entreprise politique relative au processus d'approbation d'ajout de nouvelles bibliothèques au système.
  • Vulnérabilités ou risques de sécurité
  • Nécessité de refaire le travail car l'un des éléments ci-dessus posait problème

Si vous avez des problèmes avec la façon dont le patron vous demande de faire le travail et que vous êtes convaincu qu'il existe un meilleur moyen, vous devez présenter vos conclusions à votre patron et obtenir son approbation avant de faire votre propre travail façon. Il est généralement mal vu lorsque les nouveaux développeurs démontrent qu’ils pensent être mieux informés que les ingénieurs seniors et qu’ils ne suivent pas d’instruction.

Quand devriez-vous prendre des initiatives
comprendre pleinement le système et les besoins de l'entreprise derrière un projet et avoir la liberté de mener à bien un projet sans instruction supplémentaire ni supervision sur la façon dont le projet doit être réalisé, vous pouvez vous sentir libre de le faire comme vous l'entendez. En général, les développeurs plus récents devraient subir des revues de code afin que les ingénieurs supérieurs et intermédiaires puissent examiner le travail jusqu'à ce que tout le monde soit à l'aise avec la qualité du travail effectué. (Les révisions de code devraient vraiment continuer et impliquer tout le monde, mais c'est beaucoup moins souvent suivi et c'est une autre discussion pour un autre forum).

En effet.J'ai laissé un certain nombre de développeurs partir après plusieurs fois sans avoir suivi mes demandes.Et je n'ai normalement pas le temps d'expliquer la situation dans son ensemble avec suffisamment de détails pour permettre à ces développeurs de voir et de comprendre la lumière.Un rapide "quel est le problème avec cette solution open source?"devrait obtenir (d'un bon manager) une explication de 20 secondes comme "cela nous empêchera d'intégrer efficacement l'authentification unique dans le sprint 15"
@BrianLeeming n'explique pas la vue d'ensemble aux développeurs 50% de votre travail en tant que manager?Les 50% restants s'assurant que personne ne les dérange en travaillant dessus?
Pour être juste, Erik a raison.L'équipe doit au moins avoir une visibilité de la vue d'ensemble, si vous vous attendez à ce qu'elle obtienne une satisfaction réelle de son travail.Essayez de les garder dans la boucle, @Brian, au moins à un certain niveau.Et, qui sait, vous constaterez peut-être que l'un d'eux a une idée brillante qui peut faciliter les choses pour tout le monde.N'est-ce pas pour ça qu'ils sont là?
@Erik Cela ressemble à quelque chose qui pourrait varier énormément en fonction de la structure et de la hiérarchie de l'équipe.Selon les rôles des managers, ils peuvent être occupés à autre chose.Ne pas dire que c'est une bonne ou une mauvaise façon d'organiser l'entreprise, mais simplement dire que toutes les entreprises n'auront pas la même structure.
@Erik Le travail d'un gestionnaire est de faire correspondre le pouvoir des employés aux objectifs de l'entreprise.Certains développeurs répondront bien à la situation dans son ensemble et d'autres s'en moqueront.Les développeurs juniors doivent se sentir habilités à s'enquérir et les managers décents expérimentés doivent tirer parti de la capacité des développeurs à utiliser ces informations
@BrianLeeming pourquoi embaucheriez-vous des personnes qui ne se soucient pas des objectifs de l'entreprise?Ils ne semblent pas très productifs.
@erik, si l'embauche était si simple ...
#4
+16
Xavier J
2017-04-28 00:22:21 UTC
view on stackexchange narkive permalink

Écoutez votre patron

Les développeurs juniors ne voient souvent pas l'aspect maintenabilité des solutions proposées. Oui, vous avez peut-être une approche open source pour résoudre le problème, mais cela n'aide pas votre patron (ou l'entreprise) à long terme si vous êtes la seule personne de l'équipe à savoir comment le soutenir. Pensez à ce qui se passe si vous partez en vacances, tombez malade ou partez. Que se passe-t-il alors? Ce n'est pas votre problème, mais votre patron peut s'en prendre à l'enfer.

Ce n'est pas pour tuer votre esprit d'innovation, mais il y a une réalité plus grande à considérer chaque fois que vous introduisez quelque chose de nouveau.

Oui.Et se rendre même irremplaçable par friction n'est pas une chose favorable à faire tant qu'il y a encore un «junior» et que vous ne pouvez probablement pas encore supporter le poids de vos décisions.
C'est * complètement * l'inverse dans mon expérience.Si vous écrivez quelque chose de propriétaire, vous êtes beaucoup plus susceptible de perdre la connaissance de son fonctionnement lorsque quelqu'un part.Les projets open source ont une communauté, aussi petite soit-elle, sur laquelle vous pouvez compter.
@Michael En tant que personne chargée de * réécrire * un module entier laissé par quelqu'un qui est parti, je suis entièrement d'accord avec vous.Il avait même laissé une documentation décente.Nous pouvions comprendre comment le code fonctionnait, mais quelques corrections de bugs ont suffi pour que le paquet de cartes s'effondre.Il avait probablement un meilleur moyen dans son esprit de faire ces correctifs, mais nous avons compris que réécrire à partir de zéro (avec une réutilisation généreuse de certaines méthodes de son code) serait moins cher à long terme.Nous l'avons même appelé en plaisantant le dernier module de Fermat.
#5
+11
xDaizu
2017-04-28 13:12:12 UTC
view on stackexchange narkive permalink

Dois-je faire les choses comme le demande le patron?

OUI

Vous toujours doit le faire comme le demande votre patron.

Si vous avez une alternative solide et que votre patron est ouvert à vos commentaires, vous pouvez le convaincre de vous demander de le faire différemment, mais vous le feriez toujours comme votre patron l'a demandé .

Supposons que je sois votre patron. Si je vous dis de faire A ...

  1. ... et que vous faites B, vous êtes un mauvais employé et je serai probablement en colère ou déçu de vous. Je te ferai moins confiance, puisque tu fais ce que tu veux.

  2. ... et tu me convainques que B est meilleur, alors je te demanderai de faire B et tu le feras faites ce qu'on vous dit. Je vous tiendrai en haute estime. Vous avez (trouvé une meilleure façon de faire quelque chose) et (fait ce qu'on vous a dit) .

  3. .. .et vous ne parvenez pas à me convaincre que B est meilleur, et vous faites A, je vous tiendrai en meilleure estime. Vous avez proposé une alternative, qui aurait pu être meilleure, mais vous avez accepté les commandes plus élevées. J'apprécie les deux.

  4. ... et vous ne parvenez pas à me convaincre que B est meilleur, et vous faites B ... voir (1) . Probablement pire: vous ne pouvez pas prétendre à l'ignorance ou à la bonne volonté, puisque je vous ai dit explicitement de ne pas faire B.

  5. ... et vous ne parvenez pas à me convaincre que B est meilleur , et vous faites les deux pour "me le prouver" que c'est mieux ... c'est un geste risqué. Vous passeriez plus de temps, peut-être inutilement, et même si vous aviez raison, je pourrais en vouloir à votre défi. Cela dépend VRAIMENT de ma personnalité, de mon humeur actuelle et de votre relation avec moi. C'est risqué et je ne le conseillerais que si vous CONNAISSEZ votre patron et que vous PENSEZ VRAIMENT que cela fonctionnera bien. Même dans ce cas, c'est risqué.

Donc, si vous pensez vraiment que votre chemin (B) est meilleur, vous devriez en faire un très bon argument, suffisamment pour que votre patron dise "Ok, vas-y et essaie-le". Ne soyez pas ennuyeux ou trop insistant. Si vous n'obtenez pas son approbation, laissez-la simplement. Faites-le comme on dit. Gagnez leur confiance et leur respect grâce à un travail solide et probablement la prochaine fois, ils seront plus ouverts à vos suggestions.

J'aime vraiment cette réponse.J'ai eu un responsable qui m'a dit explicitement et de toute urgence de faire quelque chose de dommageable.Je l'ai fait sans y penser aux effets néfastes.Je me suis alors excusé car avec mon expertise j'aurais dû l'avertir immédiatement mais j'ai été pris dans l'urgence.À ma grande surprise, il s'est retourné et s'est excusé auprès de moi et m'a dit que c'était sa faute.Ce fut la première et peut-être la seule fois où je l’ai entendu dire qu’il avait tort sur quoi que ce soit.En d'autres termes, il a apprécié mon suivi de ses ordres directs même si j'aurais dû le savoir mieux.
Ce conseil est assez terrible.La raison pour laquelle vous devriez écouter votre patron est qu'il a plus de connaissances ou une meilleure vue / un meilleur contexte d'une situation.Si vous connaissez une meilleure façon de faire quelque chose que votre patron, alors soit vous savez quelque chose que votre patron ne sait pas, soit votre patron sait quelque chose que vous ne connaissez pas, et il est de votre responsabilité en tant qu'employé de combler le fossé.En tant que manager, les pires employés que j'ai jamais eues étaient des drones stupides qui faisaient exactement ce que je leur avais dit.Je préfère engager quelqu'un pour penser de manière indépendante, tout en vérifiant avec moi une vision plus large.
Si vous avez un travail où vous n'avez pas à réfléchir, alors très bien, suivez ce que dit votre patron afin de pouvoir conserver votre emploi.Si vous voulez vraiment être heureux dans votre travail tout en contribuant à quelque chose de plus grand que votre travail immédiat, repoussez les limites et efforcez-vous toujours de vous améliorer.Si votre patron est irrationnel et ne veut pas que vous fassiez cela, faites ce que vous devez pour vous en sortir jusqu'à ce que vous trouviez un meilleur emploi.
@user1234567890abcdef "Si vous connaissez une meilleure façon de faire quelque chose que votre patron ... c'est votre responsabilité en tant qu'employé de combler le fossé."Pour moi, cette réponse semble dire la même chose.Je suis désolé de ne pas comprendre votre inquiétude ici.
#6
+10
Lightness Races in Orbit
2017-04-28 05:38:51 UTC
view on stackexchange narkive permalink

Votre patron est, eh bien, votre patron.

Ils sont littéralement responsables de ce que vous faites. C'est leur travail. C'est leur raison d'être. Ils sont là pour vous dire quoi faire.

Parfois, ils peuvent décider qu'ils veulent écouter vos conseils, et parfois ils peuvent même décider de suivre vos conseils. Mais ils ne sont pas obligés de le faire, car ils sont votre patron.

C'est leur décision.

Ce n'est pas difficile.

Oui et non.Aucun patron décent ne veut être un microgestionnaire.Le patron engage le cerveau et l'initiative de l'employé ainsi que ses mains.
@superluminary: Oui, j'ai dit que le patron peut vous écouter et faire ce que vous recommandez.Mais le fait est qu'ils sont le patron.Vous faites ce qu'ils demandent finalement.Le PO se demande si cela est facultatif;ce n'est pas.
Et si vous en tant que patron n'aimez pas leurs conseils, vous lâchez vos dragons sur eux et faites fondre leur visage.Droite?Facile.:)
@Wildcard: Cela _pourrait_ fonctionner.
#7
+2
X0r
2017-04-28 17:58:38 UTC
view on stackexchange narkive permalink

En un mot, oui.

Bien que l'utilisation d'un programme open source pour résoudre le problème puisse fonctionner à court terme, il n'y a aucun moyen de savoir quel sera son statut dans le futur. Les entreprises passeront un peu plus de temps à fabriquer elles-mêmes quelque chose afin que la maintenance de ce logiciel soit assurée, car il est géré en interne.

De plus, vous pouvez considérer que votre patron vous présente cette tâche comme une expérience d'apprentissage. Il n'y a rien de mal à perfectionner les compétences :)

#8
+2
Christos Hayward
2017-04-28 19:08:03 UTC
view on stackexchange narkive permalink

Considérez-vous avoir un certain budget de capital social qui peut être utilisé par un comportement «provocateur». Même une nouvelle recrue junior a une partie de ce budget.

Cependant, considérez-vous comme un maigre approvisionnement de ce budget dans un avenir prévisible. Si vous dépensez trop, des conséquences peuvent survenir, pouvant aller jusqu'au licenciement.

Dans une situation comme celle-ci, la question centrale est: "Cela vaut-il la peine de pousser mon patron encore plus près de me renvoyer?"

Si le problème est simplement que votre patron vous a dit de faire quelque chose d'une manière particulière sans utiliser d'outils open source, vous ne voulez vraiment pas gaspiller votre budget de capital social à ce sujet. Cela peut prendre plus de temps et nécessiter un débogage que le projet open source a déjà effectué, mais la bonne réponse, pour un employé qui souhaite occuper le même poste un an plus tard, est " Non "

#9
+1
Gautam Rai
2017-04-28 00:44:00 UTC
view on stackexchange narkive permalink

Ce sera mieux si vous écoutez correctement votre patron et exécutez le programme selon les instructions.

  • La raison principale est que vous n'êtes peut-être pas le seul programmeur pour le projet, donc si vous suivez les directives, ce sera bon pour les autres programmeurs et les programmeurs qui travailleront après vous.

  • Chaque entreprise a une structure / culture de travail particulière, ici Je veux dire le modèle de logiciel. Si tous les programmeurs suivent la même directive, alors il sera facile pour tous de comprendre le code des autres.

#10
+1
Tim Woods
2017-04-28 03:47:53 UTC
view on stackexchange narkive permalink

En tant que développeur de niveau junior (ou en tant que niveau junior quoi que ce soit), ce n'est pas votre travail de réinventer la roue ou d'être "créatif" - votre travail consiste à vous établir comme une ressource digne de confiance et crédible.

Bien que vous puissiez certainement demander pourquoi votre patron veut que cela soit fait d'une certaine manière, mais ne soyez pas surpris si vous n'obtenez pas de réponse satisfaisante (à votre avis).

Il n'y a rien de plus ennuyeux pour un manager qu'un employé qui pense qu'il est plus intelligent que son manager. Défier votre patron à plusieurs reprises est ce que les experts appellent un «mouvement limitant la carrière» et croyez-moi, les gens s'en souviennent beaucoup plus longtemps que vous ne pouvez l'imaginer.

* "Il n'y a rien de plus ennuyeux ..." *.Je suis complètement en désaccord.En tant que manager, c'est ** votre travail ** d'embaucher des personnes plus intelligentes que vous.Les compétences de gestion et techniques sont différentes et, comme indiqué dans d'autres réponses, les développeurs ont souvent plus de connaissances que leurs gestionnaires.
@adelphus C'est vrai mais il n'est pas sage pour un développeur junior de supposer qu'il est plus intelligent que son manager.Il dit lui-même que la méthode du manager nécessiterait quelques études pour être mise en œuvre, donc évidemment il n'est pas familier avec elle, et en tant que tel, je dirais qu'il n'est pas en mesure de décider si sa voie est meilleure.
Il n'y a rien de plus stupide que celui qui se délecte de sa stupide croyance que tout le monde doit être plus intelligent.
@UpAllNight, Je souhaite que vous implémentiez un serveur Web en langage d'assemblage.Si la mise en œuvre de cela nécessiterait une étude de votre part, vous n'êtes évidemment pas en mesure de décider qu'une autre solution est préférable.
Le fait est que cela n'a ** rien ** à voir avec «être plus intelligent».Cela a à voir avec la responsabilité de * chacun * de * comprendre * ses devoirs et ses tâches.Et, [** un membre du groupe doit insister sur son droit à l'initiative. **] (http://www.scientologyreligion.org/background-and-beliefs/the-credo-of-a-true-group-member.html) S'il voit ce qui lui semble être une meilleure façon d'accomplir les buts du groupe, mais que cela ne doit * pas * être fait de cette façon, il a le droit de comprendre pourquoi.
@Wildcard Je fais ça tout le temps
#11
+1
Chris Pratt
2017-04-29 00:38:45 UTC
view on stackexchange narkive permalink

Si vous êtes un développeur junior , alors oui. Votre rôle est intégré à votre titre. Les développeurs juniors sont amenés à faire un travail difficile. Cela peut sembler un peu exploiteur, mais en même temps, faire le gros travail aide les développeurs à comprendre le code et à se familiariser avec les modèles et les processus, en particulier en ce qui concerne la façon dont votre organisation particulière les utilise.

les choses comme votre patron dit de les faire, mais vous pouvez toujours faire preuve de créativité tout en coloriant dans les lignes. Recherchez des moyens innovants d'améliorer l'efficacité, la lisibilité et la stabilité de votre code. Assurez-vous qu'il est soigneusement testé et pensez à des scénarios de cas extrêmes à tester. À peu près n'importe quel code de développeur junior sera examiné à un moment donné, et si le réviseur voit constamment du code solide, efficace, entièrement testé et bien documenté, alors votre opinion aura beaucoup plus de poids. À terme, vous pourrez peut-être suggérer de nouvelles façons de faire, car vous avez ensuite démontré une bonne éthique de travail et de solides pratiques de codage. Vous êtes également plus susceptible d'être promu à un poste avec plus d'autonomie à ce stade.

Rappelez-vous également que pour le meilleur ou pour le pire, la communauté de programmation est très basée sur la caste. Les développeurs seniors n'apprécient pas toujours les développeurs juniors en pensant qu'ils savent mieux, même s'ils le savent. En fin de compte, vous devez faire preuve de respect dans tout ce que vous faites. Même si vous connaissez un développeur en particulier, votre patron, etc. est tout simplement faux, ne vous contentez pas de le dire. Au lieu de cela, abordez les conflits dans une perspective d'apprentissage. Demandez à votre patron ou à quiconque (gentiment) d'expliquer pourquoi une chose doit être faite comme il le dit, afin que vous puissiez vraiment comprendre. Vous pouvez souvent entamer des conversations de cette manière et éventuellement présenter vos idées d'une manière plus détendue, où votre patron n'entend pas autant "vous avez tort" que "travaillons ensemble pour trouver la meilleure façon".

Enfin, ne soyez pas arrogant. Tous les développeurs de tous les niveaux d'expérience pensent toujours qu'ils sont des rockstars. C'est un effet secondaire de ce que nous faisons, car l'acte de création fait que l'on se sent comme un dieu. La simple vérité, cependant, est qu'il y a toujours quelque chose de nouveau à apprendre et toujours des domaines où vous pouvez vous améliorer. J'ai programmé la majeure partie de ma vie et j'apprends encore de nouvelles choses chaque jour, j'ai encore des moments de stupidité à couper le souffle tous les jours. C'est très bien. C'est normal. Le danger survient lorsque vous pensez tout savoir, car vous êtes alors intouchable.

#12
  0
philbranigan
2017-04-29 01:25:18 UTC
view on stackexchange narkive permalink

Oui, j'ai été dans cette voie tellement de fois, votre patron aura, espérons-le, la surveillance de la situation dans son ensemble. J'ai perdu le compte des fois où je pouvais faire les choses plus rapidement et plus efficacement pour être informé plus tard d'une dépendance / fonctionnalité qui change complètement la donne. Suivez la procédure décrite et, le cas échéant, suggérez des améliorations / commentaires.

#13
  0
bubba
2017-05-01 09:55:19 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont dit, la réponse courte est "oui". Faites ce que votre patron vous a dit de faire.

Vous pensez peut-être que votre chemin est «meilleur», mais la définition de mieux de votre patron peut être différente de la vôtre. Si vous êtes un programmeur débutant, votre patron aura généralement des connaissances et une expérience beaucoup plus larges que vous. Par exemple, il saura des choses comme:

  1. Ce qui a déjà été essayé dans l'entreprise et pourquoi certaines choses ont fonctionné et d'autres ont échoué. Les causes de l'échec ne sont souvent pas techniques; ils peuvent être davantage liés à l'expertise du personnel, à la volonté d'investir, à la structure organisationnelle ou même à la politique interne.
  2. Quels futurs projets dépendent de l'actuel.
  3. Le plan stratégique de l'entreprise; en particulier la vision de l'entreprise de ce pour quoi ils veulent être connus.
  4. Qu'est-ce qui attribue de la valeur aux clients dans vos produits?
  5. Quels types de choses peuvent être expliqués par vos commerciaux / marketing ), et donc utilisé pour vendre le produit.
  6. Les implications juridiques de faire les choses d'une manière par rapport à une autre.
  7. Les impacts économiques / financiers généraux de faire les choses d'une manière par rapport à une autre.
  8. La durée de vie prévue du code que vous écrivez.
  9. Plans de maintenance / amélioration.

Dans un monde idéal, votre Le directeur vous expliquerait toutes ces choses, afin que vous connaissiez le contexte complet du travail que vous faites. Mais tous les managers n'ont pas le temps / l'envie de le faire. Vous pouvez pousser pour ces explications, mais arrêtez de pousser si vous ressentez un ennui. Sans ces explications, vous ne pouvez pas dire quelle approche est «meilleure», alors faites simplement ce que votre patron vous a dit de faire.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...