Ne jamais présenter un simple problème

J'ai jeté un coup d'oeil rapide à votre profil et j'ai remarqué que vous avez fait le tour de la communauté StackExchange pendant un certain temps. Vous aurez sans doute remarqué ici que les questions qui reçoivent les meilleures réponses sont celles qui présentent le problème et le raisonnement qu'elles ont déjà pris pour tenter de répondre à la question.

La vie professionnelle est comme ça. Si vous posez une question, vous voulez être sûr de leur faire savoir aussi ce que vous avez fait pour essayer d'y répondre vous-même. Si vous exposez votre raisonnement, vous faites savoir à la personne que vous faites une tentative avant de poser une question et que vous n'êtes pas simplement paresseux. ** Si un pair vient me voir avec un problème et m'expose la façon dont il a tenté de répondre à une question, non seulement cela l'aidera à se guider sur la bonne voie, mais je l'aiderai également à comprendre comment il a pu réfléchir à la question pour y parvenir lui-même. Plus vous exposez votre processus de réflexion et votre raisonnement, plus les autres personnes peuvent vous aider à vous appuyer sur eux pour de futurs problèmes.

Il y a quelques points à déballer ici.

Je supposais que tous les autres membres d'une entreprise technologique aimaient parler de technologie…

Pas nécessairement. Beaucoup de techniciens parlent de technologies qui sont pertinentes pour la tâche qu'ils accomplissent actuellement, mais peuvent n'avoir absolument aucun intérêt pour autre chose.

Je pense que vous vous trompez peut-être entre cela et :

On m'a aussi grondé pour avoir “pris le mauvais chemin” en essayant de résoudre un problème que je ne connaissais pas au lieu de demander à quelqu'un qui était

Considérez le garçon qui a crié au loup :) Si vous passez le temps de quelqu'un d'autre à parler de choses qui n'ont pas de rapport avec ce qu'il fait, alors lorsque vous lui posez une question pertinente, vous pouvez constater qu'il a l'impression d'avoir déjà perdu assez de productivité avec vous.

J'essaie presque toujours de résoudre les problèmes par moi-même pendant au moins une heure. Est-ce trop court ?

Dans de nombreux cas, oui, c'est trop court. À moins que le problème que vous essayez de résoudre ne soit simple, vous devriez alors consacrer plus de temps à rechercher et à essayer différentes permutations. Si le problème est simple, alors une recherche appropriée sur le web devrait donner les bons résultats.

Mettez tout cela ensemble, et ce que je vois, c'est un jeune programmeur qui a quelques problèmes de jugement, ce que votre responsable des ressources humaines vous a dit. Ce n'est pas insurmontable, mais il y a certaines choses auxquelles vous devez réfléchir.

• Sauvegardez des questions techniques hypothétiques pour la salle de déjeuner. Il n'est pas approprié, à moins de bien connaître les gens, de perdre votre temps et celui des autres sur des questions sans rapport. Si on vous dit que vous posez trop de questions et que vous prenez trop de temps pour les poser, alors vous posez clairement les mauvaises questions. Si vous n'avez rien à montrer comme un effort concerté pour résoudre un problème, alors vous n'avez pas assez essayé. En fait, n'ayez pas peur d'utiliser les ressources comme le débordement de cheminée s'il y a quelque chose de tangible à demander qui pourrait être du domaine public. Enfin,
• Enregistrez les questions pour les questions spécifiques aux entreprises. Ne demandez pas comment piloter votre outil de programmation, mais _demandez des questions spécifiques au domaine ou à l'environnement qui ne seront pas dans le domaine public.

Il y a beaucoup de choses que vous pouvez faire pour améliorer. Vous trouverez peut-être que le PIP peut être un outil très précieux pour vous aider à devenir un meilleur développeur :)

Le problème est que, lorsque vous interrompez le travail de quelqu'un, il ne perd pas seulement les 5 à 15 minutes qu'il lui faut pour répondre. Ils perdent beaucoup plus de temps, car ils doivent se concentrer à nouveau. Et cela peut être très frustrant.

J'étais dans une situation similaire à la vôtre. J'avais l'habitude d'aller voir les gens et de leur poser des questions tout de suite. Même quand ils faisaient quelque chose qui me bloquait. Cela pouvait même interrompre d'autres personnes à proximité.

Mon manager m'a donné une solution : utiliser le courrier électronique et la messagerie instantanée, même lorsque la personne est assise à côté de vous. De cette façon, vous réfléchirez davantage à la manière de formuler la question, et pendant ce processus, vous pourrez y répondre vous-même. De plus, l'autre partie peut vous répondre lorsqu'elle a du temps libre.

Une autre option consiste à organiser une réunion, où tout est mis au clair.

Je vais essayer de répondre du point de vue de l'entreprise. Je ne suis pas cette entreprise, donc il y a peut-être des choses que je ne vois pas, mais j'ai déjà vu cela dans ma propre entreprise.

Trop de questions

La plupart de votre confusion semble venir du fait que vous n'avez pas compris que poser des questions est un jeu dangereux. **Quand vous posez une question, vous admettez que vous ne savez rien, et que vous ne pouvez pas le comprendre. En tant que développeur de logiciels, l'une de vos tâches est de le comprendre. Vous insultez l'équipe de développement “actuelle” en demandant essentiellement : “Vous avez écrit un code tellement merdique que je ne peux pas comprendre comment le lire ou ce qu'il fait, alors je vais avoir besoin que vous me l'expliquiez”

Maintenant, la partie délicate ici, c'est que parfois c'est exactement le cas et vous devriez poser des questions. Il est juste important de se rappeler que, quoi qu'il arrive, il y a un côté négatif à ces questions.

Une autre chose que je crois sentir dans votre PO, c'est que vous posez des questions bien trop tôt. Il est tout à fait normal qu'un nouveau développeur reste assis à lire, et à faire des recherches pendant toute une journée, pour écrire deux lignes de code. En fait, avec 14 ans d'expérience, je finis toujours par le faire. L'écriture de code professionnel n'est pas une question de “quantité”, mais de “qualité” et de capacité à reproduire ce succès. Je doute qu'on vous reproche de prendre 100 fois plus de temps pour faire un dixième du travail d'un développeur formé et établi. En fait, quand j'engage quelqu'un, je déduis le premier mois comme n'attendant pas de vrai travail, et les six premiers mois comme n'attendant pas grand chose.

Ne passant pas assez de temps seul

C'est énorme ! Lorsque vous demandez de l'aide à un membre de l'équipe, vous réduisez également la productivité de cette personne. Vous avez un impact sur son processus et l'insultez (voir ci-dessus) en même temps. Vous n'avez aucun moyen de gagner si vous devez demander de l'aide. Considérez chaque demande comme une bataille perdue. Vous pouvez toujours gagner la guerre, mais vous avez perdu cette bataille.

Il y a certaines choses que vous pouvez faire pour atténuer le problème :

1. Demandez par e-mail, jamais en personne ou en chat. Le chat est peut-être le moyen préféré pour le faire “officiellement”, mais le courrier électronique est plus agréable parce que le destinataire peut s'en occuper à sa guise.
2. Approchez-le d'une position “inférieure”. Vous êtes le suppliant ici. Faites un peu d'introspection. Ce n'est pas grave. Un petit peu ne vous fera pas de mal et montrera au destinataire que vous vous souciez de son temps, c'est-à-dire “Je sais que vous êtes très occupé, mais je n'arrive pas à trouver comment intégrer votre API. Quand vous aurez quelques instants, pourrez-vous me montrer ce que je manque ?” Cela montre que vous êtes dans le faux, pas eux. C'est important.
3. Énumérez les étapes que vous avez franchies par vous-même. “Le document API dit de passer dans une chaîne représentant l'identifiant de l'utilisateur. J'ai essayé de passer la propriété user.id et le nom d'utilisateur, ça n'a pas marché.” Cela montre que vous avez au moins essayé quelque chose, et qu'en général, vous commencez à “obtenir” le produit.

Meilleur jugement lorsque vous posez des questions

Cela, pour moi, ressemble à une “plainte” que vous avez faite à quelqu'un, et ils n'avaient pas une façon agréable de dire, “Vous ennuyez tout le monde avec vos questions nulles. Arrêtez ça !” En d'autres termes, je pense que ce n'est pas un problème. Une fois que vous aurez corrigé vos autres problèmes, ça disparaîtra.

Mauvaise documentation

Ahem ! C'est une autre insulte personnelle. Ne dites jamais ça. JAMAIS ! !! Une fois de plus, vous dites que la qualité de leur code est si mauvaise que vous ne pouvez pas le comprendre. Leur réponse sera toujours : “Ça marche pour tout le monde, donc c'est toi l'idiot, pas moi !”

Aussi, c'est un peu “bienvenue dans le monde réel”. Dans le monde réel, les clients paient pour des applications qui fonctionnent et non pour du code ou de la documentation (la plupart du temps), il est donc très courant que la documentation se dégrade avec le temps.

Si vous pensez que la documentation est médiocre et qu'elle doit être traitée, alors abordez ce point, discrètement, avec votre chef d'équipe. Laissez-les décider.

Je vais cependant vous dire ceci. Peu importe à quel point la documentation est mauvaise, avec le code source sous les yeux, vous ne devriez pas en avoir besoin. C'est très agréable à avoir, ne vous méprenez pas, mais vous pouvez travailler sans cela.

Being Late

Évidemment, ne soyez pas en retard. Ce n'est pas la peine de réfléchir. En fait, dans votre situation actuelle, soyez en avance de 30 minutes ! Pas d'excuses. Vous ruinez tout espoir de trouver votre prochain emploi avec celui-ci. Si j'appelle le département des ressources humaines et que je demande votre présence, et qu'ils me disent “Il était souvent en retard” ou “Il a été noté pour son retard”, c'est un signal d'alarme instantané. Je le mentionne, parce que, que vous gardiez cet emploi ou que vous en trouviez un nouveau, c'est cela plus que toute autre chose qui vous empêchera d'obtenir votre prochain emploi.

Code de qualité inférieure

C'est probablement vrai. Étant donné le problème de la question, vous n'écrivez probablement pas un bon code. Mais vous êtes nouveau, et c'est normal. Je trouve que les universités n'enseignent rien du tout sur le codage du monde réel. Je n'ai jamais embauché quelqu'un qui sortait tout droit de l'université et qui était un “bon développeur”. Cela ne veut pas dire qu'il n'est pas devenu un bon développeur. C'est juste qu'ils ne commencent pas de cette façon. Pour écrire un bon code, il faut se tenir au courant des dernières tendances et techniques. Vous apprenez constamment. Le moment où vous vous arrêtez est le moment où vous commencez à être nul.

En conclusion

Ce post a été dur, mais je voulais montrer, clairement, quelle peut être la position d'une entreprise. Il arrive souvent que les (entreprises) terminent leurs commentaires en parlant tellement de “manager” que cela peut être difficile à comprendre. J'ai essayé de réduire autant que possible la prise de parole du manager à ce poste, mais cela signifie que le résultat est un peu brutal.

Vos mesures les plus importantes pour réparer votre carrière défaillante :

1. SE PRÉSENTER TÔT AU TRAVAIL ! !! (je ne peux pas insister assez sur ce point)
2. Posez des questions en pensant que vous insultez déjà la personne à qui vous les posez.
3. Montrez votre travail. Lorsque vous posez une question, indiquez clairement ce que vous avez déjà fait.
4. Passez plus de temps à apprendre par vous-même. Il est important de passer beaucoup plus de temps à faire des recherches qu'à poser des questions. Honnêtement, 3-4 jours à chercher quelque chose par vous-même, seront plus respectés qu'une question de 30 secondes.

Je voulais essayer d'y voir clair d'un point de vue de gestion.

Un PIP est une chose complète

Il est fort probable que l'amélioration des performances soit un ensemble de choses que votre direction a mises en évidence, toutes faites ensemble. Je suppose que si vous étiez la personne qui pose beaucoup de questions, mais qui arrive tôt, reste tard et fait un excellent travail en écrivant le code, l'équipe traiterait la question posée comme une bizarrerie personnelle, ou que vous êtes exceptionnellement minutieux. Mais quand l'équipe doit aider à trouver et à corriger plus de bugs dans votre code, après avoir répondu à plus de questions que d'habitude, et qu'elle vous voit travailler moins d'heures ou arriver en retard sans préavis, l'équipe et le responsable vont penser que vous ne contribuez pas au niveau que vous devez atteindre, et que vous ne mettez pas de temps supplémentaire pour vous mettre à niveau. La question a probablement été posée à la lumière des autres problèmes, car si vous essayez de corriger la qualité du code en posant PLUS de questions, l'équipe ne pourra pas le supporter.

Chaque heure compte

Un nouveau diplômé de l'université EST un investissement dans le temps de l'équipe. Tout manager qui vous dit le contraire n'a jamais embauché un nouveau diplômé, ou bien il ment, ou bien il a des chefs d'équipe vraiment exceptionnels qui travaillent pour lui. Toute nouvelle embauche est un investissement, mais les diplômés de l'université ont PLUS de temps. En général, le compromis en vaut la peine, mais sachez que les diplômés posent plus de questions que les développeurs chevronnés. Cependant, chaque heure compte. Une équipe de développeurs sera plus efficace en une semaine si tout le monde est au courant, connaît le code et ne pose pas trop de questions. De plus, une équipe dans cet état gélifié pourra poser des questions et y répondre très rapidement - ce qui accélère également la productivité.

Répondre aux questions doit prendre du temps. Et il y a un changement de contexte chaque fois qu'un développeur arrête d'écrire du code et commence à répondre à des questions. Ainsi, une réponse à une question fortement axée sur les interruptions est beaucoup plus néfaste pour la productivité que de s'asseoir pendant une heure et de répondre à une série de questions.

Je ne risquerais pas de me tromper en disant que TOUT changement de contexte coûte 1 heure, donc même si vous avez une question de 5 minutes, vous avez coûté une heure à l'équipe lorsque quelqu'un s'arrête pour répondre à votre question. Cela signifie que prendre une heure et ne pas l'obtenir, puis demander de l'aide coûte en fait plus de temps que de prendre 2 à 4 heures.

Il n'y a pas de “ça ne prendra que 5 minutes à l'autre gars pour me faire gagner une heure”. Étant donné qu'il faut au moins une heure par interruption, l'autre gars a intérêt à vous faire gagner 2-4 heures.

Conseils pour bien poser des questions :

• Comprendre et poser des questions en fonction de l'urgence - si vous devez absolument résoudre un problème en une heure, alors interrompre presque tous ceux qui peuvent vous aider est une bonne idée. Si on vous a donné un délai de 3 semaines, alors il est préférable d'interrompre moins et de résoudre davantage vos propres problèmes. Cela signifie qu'en cas d'urgence, les gens posent souvent beaucoup de questions qu'ils chercheraient autrement par eux-mêmes. Parce qu'il est absolument essentiel d'avoir la réponse le plus rapidement possible.
• Utilisez les forums de questions dans le but défini, ou intuitionnez le but à partir des questions/réponses existantes. Les Stack Exchanges, par exemple, ont un ensemble assez étendu de règles de base qui sont assez bien documentées, et une attente particulière que les utilisateurs recherchent les réponses précédentes avant de les poser. Un autre forum peut s'attendre à des questions répétées, mais seulement sur un domaine très étroit.
• Faites une recherche sur votre question. Attendez-vous à ce qu'écrire une bonne question puisse prendre autant de temps que de donner la réponse - dans de nombreux cas, vous décrivez (de manière laconique !) les étapes qui vous ont amené au point de ne pas pouvoir répondre au problème. Il est également probable que vous documentiez tous les symptômes du problème.
• Ciblez vos questions - déterminez qui peut réellement répondre aux questions lorsque cela est possible plutôt que de les poser à tout le monde. Toutes les questions ne valent pas la peine d'être discutées.
• Regroupez une grosse pile de questions - surtout si vous êtes nouveau, prenez une journée pour examiner le problème et le code. Regroupez vos questions en une liste à puces avec des sujets regroupés. Demandez ensuite à un mentor ou à un ami où aller pour obtenir de l'aide sur ces sujets. Il est fort probable que la plupart des questions de l'heure 1 recevront une réponse à l'heure 6. Les questions qui sont arrivées dans l'heure #1-2 et qui n'ont pas pu être répondues à l'heure #8 sont probablement en haut de votre liste puisque vous savez qu'en 8 heures vous n'avez pas pu le comprendre.
• Le code n'est pas “auto documenté” mais beaucoup d'informations peuvent être apprises en le lisant. J'ai appris beaucoup de systèmes non documentés en m'asseyant avec un cahier et en dessinant ma version du dessin au fur et à mesure. Si vous n'avez pas lu plusieurs niveaux au-dessus et plusieurs niveaux en dessous de la zone dans laquelle vous travaillez et que vous n'avez pas lu les documents des API externes que vous utilisez, vous n'avez pas fait suffisamment de recherches.
• Lorsque vous essayez de trouver une réponse, cela va beaucoup plus loin si vous pouvez suggérer des possibilités, plutôt que de demander la réponse. “Serait-ce la bonne façon de faire” est préférable à “Comment faire ? - même si la réponse est "vous le faites complètement mal” - vous pouvez toujours demander “pourquoi ma façon de faire est mauvaise” et, plus méta, “comment pourrais-je apprendre à le faire bien à plusieurs reprises” ? C'est l'approche “apprendre à un homme à pêcher” - apprenez à pêcher, ne posez pas de questions qui ne vous permettent d'obtenir qu'un seul poisson.
• Évitez les questions qui ne sont qu'une façon polie de ne pas être d'accord. Il y a une ligne entre “ma façon de faire est-elle réalisable” et “je ne comprends pas (c'est-à-dire que je ne suis pas d'accord) pourquoi vous l'avez fait à votre façon”. Ce sont de bonnes conversations, mais elles sont plus faciles à tenir de manière informelle une fois que vous avez appris à connaître les gens.
• Modérez vos questions générales - ce sont généralement les questions “pourquoi”. Les nouvelles personnes sont tout à fait en droit de poser beaucoup de questions “où” et “qui” (où sont les documents, où est le processus pour cela, où est la place dans le code que je pourrais vouloir examiner ? qui peut répondre à cela ? qui dois-je inviter à l'examen ?) et un certain nombre de questions “comment” - est-ce ainsi que je dois l'aborder ? comment puis-je obtenir votre accord ? Mais “pourquoi” comme dans “pourquoi l'avons-nous construit de cette façon”, “pourquoi ne documentons-nous pas davantage le code”, “pourquoi n'est-ce pas une priorité ? - ils sont légitimes, mais tant que vous n'avez pas plus d'expérience du travail et de l'entreprise, ce ne sont pas les questions les plus nécessaires. Elles peuvent être GRATUITES pour un tête-à-tête avec votre patron lorsque vous n'avez pas d'autres questions urgentes, mais si le "pourquoi” supplante le “où”, le “qui” et le “comment”, alors vous ne vous concentrez pas sur votre travail.

J'ai connu exactement la même situation.

Problème

Ce que vous décrivez est le problème auquel sont confrontés la plupart des jeunes diplômés. La plupart des universités ne vous enseignent que des notions de base ou des concepts, alors que dans la pratique, vous avez besoin de beaucoup plus.

La plupart des entreprises qui embauchent de jeunes diplômés ont mis en place des plans de formation, que vous devriez pouvoir suivre et qui devraient vous permettre de faire votre travail en toute confiance d'ici un an environ. Mais certaines personnes deviennent curieuses, si vous leur donnez une tâche simple pour réparer un petit élément d'un système, elles ne l'obtiennent pas avant de maîtriser l'ensemble du système et je crois que vous êtes l'une de ces personnes…

Je pense que vous posez des questions parce que,

• Vous avez l'impression de prendre plus qu'un temps raisonnable pour accomplir une tâche, car vous ne comprenez pas une partie du système. Si mes hypothèses sont justes, alors arrêtez de poser des questions, à moins que vous ne deviez le faire (point final - dès maintenant)

• Commencez à passer plus de temps à comprendre le système (pas seulement 8 heures)

• Utilisez plutôt le SO ou d'autres sites connexes (après avoir fait votre partie de recherche)

• Demandez à votre entreprise de vous former correctement @les domaines pour lesquels vous avez besoin d'aide.

• J'ai suivi la procédure ci-dessus et je travaille maintenant dans la même entreprise après 5 ans et je peux prétendre que j'en connais plus que quiconque ici.

Il y a déjà beaucoup de réponses ici, mais je voudrais aborder quelques parties spécifiques de votre question.

Bien qu'on m'ait aussi grondé en disant que je ne passe pas assez de temps à essayer de comprendre les choses par moi-même avant de demander de l'aide aux autres. Mais ce n'est pas vrai, et mon manager n'aurait aucun moyen de savoir combien de temps il s'écoule entre le moment où je rencontre un problème et celui où je demande de l'aide à quelqu'un. J'essaie presque toujours de résoudre les problèmes par moi-même pendant au moins une heure.

Est-ce trop court ? Quel est le temps raisonnable à consacrer à un problème avant de demander à un collègue qui connaît la réponse ?

L'emphase ajoutée est la mienne.

Pour commencer, oui, une heure est probablement trop courte. Mais je dis probablement… cela dépend vraiment du problème. Et avoir une limite de temps est une bonne chose, mais vous devriez vous fier davantage aux indicateurs que vous êtes face à un mur qu'à une simple limite de temps. Mais surtout, lorsque vous êtes prêt à poser des questions, le destinataire de vos questions devrait être en mesure de voir les recherches que vous avez faites sur votre problème, juste par le type de question que vous posez.

Et c'est là que nous arrivons à la partie en gras de la citation. Vous avez raison sur le plan technique. Mais en fonction de la question que vous posez, des informations que vous fournissez avec la question, du contexte de la question et de la facilité avec laquelle je peux trouver la réponse avec une simple recherche sur Google, je peux faire une assez bonne estimation de l'effort que vous mettez à résoudre le problème par vous-même. Si vous posez une question, et que la première recherche sur Google que j'essaie donne votre solution comme résultat numéro un, cela fait en gros deux coups pour vous. Peu importe que vous ayez passé 10 minutes ou 10 mois sur le problème. Vous devriez déjà avoir étudié cette page et soit elle a résolu votre problème, soit vous me parlez de cette page et de la raison pour laquelle elle n'a pas résolu votre problème.

Mais en plus, quel genre de questions vous posez-vous ? Demandez-vous des solutions directes ? Ou demandez-vous un petit coup de pouce dans la bonne direction ? Parfois, le mur auquel vous êtes confronté est que vous ignorez totalement l'existence d'une bibliothèque ou d'une partie de la base de code qui rendra la résolution de votre problème simple.

Ich würde sagen, Sie haben durch die Schule der harten Schläge gelernt, was dieses Unternehmen erwartet. Fragen an dieser Stelle sind tabu.

Ich denke, Ihr Hauptproblem ist Sichtbarkeit. Fragen zum Thema Schlaffheit zu stellen, ist etwas, das viele Leute sehen können; selbst wenn sie sich nicht gezwungen fühlen, darauf zu antworten, könnte das ihr Urteil über Sie beeinträchtigen. Wenn Sie derweil einen Tag damit verbringen, an Ihrem Schreibtisch ein einzelnes Merkmal herauszufinden, sieht niemand, dass sich das Rad dreht. Sie scheinen etwas falsch zu machen, anstatt einfach nur auf die Tasten an Ihrem Schreibtisch zu hämmern, der nach Arbeit aussieht. Sicher, vielleicht wird Ihre Produktivität in wöchentlichen, monatlichen oder jährlichen Überprüfungen schlecht widergespiegelt. Aber Ihre lockeren Fragen werden mehrmals am Tag gesehen, während Ihre tatsächliche Produktivität viel seltener gemessen wird.

Ich war in einer Position wie der Ihren. Ich wurde eingestellt, um Fehler in einem proprietären CMS zu beheben, während der Hauptentwickler (read:only) sich wie verrückt darum bemühte, Funktionen für Kunden hinzuzufügen. Wir waren weit im Rückstand. Die Codebasis befand sich nicht in der Versionskontrolle, und jede Seite hatte ihre eigene maßgeschneiderte Version. Es war ein völliges Durcheinander.

Naiverweise hielt ich es für besser, 10, 20 oder 30 Minuten von meiner und der Zeit des Lead zu plaudern, damit er mir Dinge erklären konnte, als einen halben oder ganzen Tag oder sogar mehrere Tage damit zu verbringen, eine Funktion zurückzuentwickeln, um 1. herauszufinden. was getan werden sollte, 2. wie es funktionieren sollte, und 3. wie der Fehler behoben werden sollte.

Als mein Chef (einer von zwei Partnern) davon erfuhr, stellte sich heraus, dass mein Chef (einer von zwei Partnern) mir gegenüber schlecht zeigte, dass ich nicht in der Lage war, den Code alleine zu beheben, und dass ich die Zeit unseres kostbaren Chefentwicklers in Anspruch nahm. (Der Hauptentwickler schien es zu genießen, darüber zu sprechen, wie seine Codebasis funktionierte - auf jeden Fall beschwerte er sich nicht bei meinem Chef darüber, wie er mir sagte). Also hörte ich auf, Fragen zu stellen, und meine Produktivität fiel wahrscheinlich auf 10% von dem, was sie war. Ich wurde etwa einen Monat später entlassen.

Wie auch immer, diese Firma sagt Ihnen auf eine schlechte Art und Weise, dass sie diese Zeiteffizienz und den Dokumentations-Nebeneffekt nicht zu schätzen wissen. Also tun Sie es nicht.

Verbringen Sie einen Tag damit, etwas herauszufinden. Verbringen Sie ein paar Tage - verbringen Sie eine Woche! Wen interessiert das schon? Nicht diese Firma. Was auch immer Sie tun, stellen Sie keine Fragen, denn das ist etwas, was ihnen nicht wichtig ist. Ob es das Management ist oder die Kollegen, die sich beschweren, spielt keine Rolle. Das Unternehmen hat Ihnen gesagt, welche Art von Kultur es pflegt.

Wenn Sie also über Ihre Situation nachdenken, mit Verspätung und schlechtem Qualitätscode, dann könnte sich eine sinkende Produktivität als zu viel herausstellen. Anstatt zu warten, bis die Axt fällt, sollten Sie sich vielleicht nach einem Ort umsehen, der besser zu Ihnen und Ihrem Stil passt. Irgendwo, wo es vielleicht ein paar Code-Kommentare und Dokumentation gibt, für den Anfang.

Also, wie ist meine Geschichte geendet? Nach einer Zeit der Arbeitslosigkeit bekam ich einen neuen Job. Abgesehen davon, dass die Codebasis viel besser ist (wir verwenden ein CMS nach Industriestandard, wir arbeiten mit Versionskontrolle, wir haben Entwicklungs-, Staging- und Prod-Umgebungen usw.), sind meine Kollegen hervorragend, und mein Unternehmen fördert das Lernen. Wir haben ein Wiki, in dem wir unsere Informationen austauschen und vermeiden, das Rad neu zu erfinden. Wir plaudern den ganzen Tag, reden über die Arbeit, stellen Fragen, machen Brainstorming, tauschen Nachrichten, Informationen und Entdeckungen aus. Wir starten Projekte, um unsere Prozesse zu verbessern, wie z.B. agil, vagabundierend und die Implementierung kontinuierlicher Integration. Wir lehren uns gegenseitig und lernen voneinander. Wir verhalten uns wie Kollegen und Mitarbeiter, nicht wie Konkurrenten. Wir haben eine Einarbeitung und Orientierung für Neueinstellungen und Auftragnehmer, die ohne diese Kultur nicht möglich wäre. Das ist eine gute Sache, denn in der Zeit, in der ich hier bin, sind wir von zwei (mich eingeschlossen) auf acht angewachsen, und in arbeitsreichen Zeiten auch Auftragnehmer.

Unser Unternehmen schickt uns auf Schulungen und Konferenzen und ermutigt uns, uns Zeit für webbasierte Kurse und Castings zu nehmen. Ich habe in dieser Zeit hier mehr gelernt als in jeder anderen Periode meiner Karriere, insbesondere in Fächern, in denen ich ausdrücklich nicht arbeite. Es ist wunderbar; ich bin jetzt seit 4,5 Jahren hier und sehe nicht viel Grund zu gehen, außer eine neue Technologie zu erlernen. Die Kultur an meinem neuen Arbeitsplatz ist wirklich darauf ausgerichtet, zu lernen, zu verstehen und die besten Praktiken umzusetzen, was zu Produktivität führt. Es ist eine Win-Win-Situation.

Im Ernst, es gibt bessere Orte, für die man arbeiten kann. Das ist nicht der richtige Ort für Sie, und Sie sind auch nicht die richtige Person für sie.

Si vous posez des questions qui ne sont pas liées au travail, cela peut être considéré comme du bavardage inutile, ce qui est une mauvaise chose aux yeux de votre patron, alors arrêtez de le faire.

Cependant, poser des questions liées au travail est une bonne chose car cela montre que vous vous intéressez à votre travail et que vous voulez vous améliorer.

Si vous avez été accusé de faire perdre du temps à d'autres personnes, je suggère qu'elles doivent mieux gérer leur temps et vous dire qu'elles sont occupées plutôt que de répondre à des questions alors qu'elles devraient faire autre chose. Toutefois, il serait plus utile de leur demander s'ils ont le temps de répondre à une question avant que vous ne posiez cette question.

Il me semble que votre patron est un peu bête, ou qu'il veut simplement se débarrasser de vous pour une raison quelconque. Ils vont échouer car ils ne documentent pas les choses, ce qui est une recette pour le désastre quand leur(s) principal(aux) développeur(s) part(ent), a(ont) été là, a(ont) fait(s).

Types de questions relatives au travail :

1. Comment faire quelque chose que je dois apprendre pour faire le travail.

2. Comment faire quelque chose que je dois apprendre pour faire le travail, mais qu'on m'a déjà dit.

3. Comment puis-je faire quelque chose que je devrais déjà savoir ?

4. Comment puis-je faire quelque chose qui n'est pas conforme au travail, et je sais qu'il n'est pas conforme ?

5. Comment puis-je faire quelque chose qui n'est pas conforme au travail, et je ne sais pas qu'il n'est pas conforme ?

6. Questions drôles et bavardages.

Donc…

Vous pouvez poser autant de questions que vous voulez. Ils peuvent penser que vous êtes ennuyeux, mais c'est une bonne/intelligente façon d'être ennuyeux. Si vous demandez aux numéros 2, ils pensent que vous avez un problème de compréhension. Ou alors vous aimez juste poser des questions mais vous n'écoutez pas. Selon votre position et les choses bizarres que vous apportez à l'équipe, les numéros 3 peuvent être d'accord - vous connaissez bien un domaine spécifique, vous êtes bon marché, peu importe. Cependant, il vaut mieux ne pas demander aux #2 après avoir demandé aux #3.

Il ne fait aucun doute que les #4 ne sont pas bons. Vous pouvez vous en tirer en demandant certains d'entre eux, mais pas en tant que nouvel employé. Vos collègues s'attendent à ce que vous posiez les questions aux numéros 1 (et à certains numéros 2) bien avant de penser aux numéros 4. Si vous demandez beaucoup de #4, ils pensent que vous êtes partout.

C'est le pire. Le simple fait de demander quelques #5 peut vous rebuter auprès de n'importe quel membre de l'équipe. Cela signifie que vous ne comprenez pas et que vous n'avez probablement pas l'aptitude pour comprendre.

Hmmm… Les #6 dépendent de la personne. Beaucoup de gens peuvent demander à des tonnes de #6 s'ils sont divertissants ou drôles. D'un autre côté, si vous n'êtes pas un numéro 6, cela peut être très mauvais, surtout si vous demandez à des numéros 2 à 5.

Si vous vous demandez pourquoi ils ne peuvent pas être gentils avec moi et m'aider si j'ai des problèmes et que je demande à des numéros 2 à 5 tout le temps. Parce qu'ils peuvent engager quelqu'un d'autre qui en sait plus et qui ne pose pas de questions stupides. Si j'étais vous, je commencerais à être plus attentif, peut-être même en portant un bloc-notes avec vous en permanence, et quand quelqu'un répond à quelque chose, vous vous assurez d'être sûr à 100% de l'obtenir ou vous demandez des éclaircissements sur place.

Cette réponse concerne la façon de prendre en compte les réactions (les autres réponses couvrent déjà très bien la façon de poser des questions).

Bien qu'on m'ait également réprimandé pour avoir “pris le mauvais chemin” en essayant de résoudre un problème que je ne connaissais pas au lieu de demander à quelqu'un qui le connaissait. Lorsque j'ai posé des questions sur la contradiction, mon responsable et les RH m'ont dit que je devais simplement mieux savoir quand poser des questions. Je n'avais jamais réalisé que poser des questions pouvait être si dangereux.

C'était une mauvaise réaction de votre part. Imaginez-vous à leur place pendant un moment. Vous savez que certains employés ont de mauvaises performances et vous leur dites ce qu'ils doivent améliorer. Sans prendre la peine de réfléchir à ce que vous leur dites, sans montrer le moindre intérêt pour votre feed-back, et encore moins vous excuser de ne pas répondre aux attentes, cet employé prétend à tort que vous vous contredisez.

Lorsque vous recevez un feed-back, en particulier s'il est négatif, vous devez d'abord écouter, puis chercher à comprendre (en posant des questions de clarification si nécessaire), et seulement alors répondre.

C'est parce que, sauf si vous avez intentionnellement foiré, vous et votre patron n'êtes pas d'accord sur le fait que vous avez foiré ou non. Soit votre patron a tort, soit c'est vous (ou les deux). Vous devriez envisager la possibilité que ce soit vous, car il est très peu probable que votre patron ait entièrement tort et vous avez entièrement raison - et même si c'est le cas, vous ne pouvez convaincre votre patron qu'il a tort qu'en lui montrant où il a tort, et cela exige de l'écouter aussi. Par exemple, après avoir entendu que vous posez à la fois trop et trop peu de questions, vous pourriez demander :

J'ai donc posé des questions inutiles et je n'ai pas posé les questions nécessaires. Comment dois-je déterminer quelles sont les questions nécessaires ? C'est-à-dire, quels types de questions devrais-je poser davantage et quels types de questions devrais-je poser moins ?

La discussion factuelle suivante aurait probablement révélé ce que vous devez faire pour vous améliorer.

Est-ce habituel ? La nouvelle personne dans une entreprise n'est-elle pas censée être curieuse ou poser des questions qui ne sont pas immédiatement liées à son travail ?

Dans quelle mesure poser des questions est attendu ou souhaité diffère selon les lieux de travail. Vous pourriez souhaiter vous adapter à la culture de votre lieu de travail, ce que vous pouvez découvrir en observant vos pairs, en prenant note de la façon dont les gens réagissent à vos actions (sont-ils ennuyés par vos questions ou en sont-ils ravis ?) ou en leur demandant leur avis (“Était-ce correct pour moi de demander cela ?”).

Je pense que si vous êtes jeune comme moi, votre mentalité est de gagner du temps et de trouver la réponse, puis de passer au problème suivant. Cependant, je trouve qu'avec les générations plus âgées, ce n'est pas une préoccupation ni une priorité pour eux. Donc oui, prendre une heure pour résoudre un problème est trop court pour quelqu'un de plus âgé, mais cela peut vous sembler trop long. Je vous suggère d'observer le fossé entre les générations et de suivre le mouvement même si vous n'êtes pas d'accord. Vous finirez par résoudre plus rapidement les problèmes avec plus d'expérience.

Pour ce qui est de se mettre dans le pétrin en posant des questions, j'essaie d'utiliser l'explication de “Je veux voir comment faire” ou de suivre les normes de l'entreprise. Une fois de plus, j'ai remarqué que chez les générations plus âgées, cela est irritant pour une raison quelconque. Je pense que les personnes âgées ont tendance à penser que j'ai résolu ce problème par moi-même et que je n'ai reçu aucune aide, donc elles sont moins disposées à aider. Ils se sentent également interrompus. Comme quelqu'un mentionné ci-dessus, essayez de trouver le bon moment pour demander de l'aide, tout en caressant votre ego, IE “J'ai entendu dire que vous étiez le type à qui s'adresser à ce sujet…”. “Quelqu'un a dit que vous êtes l'expert en…”. J'espère que cela lui fera oublier une interruption et qu'il sera plus disposé à aider puisque vous lui avez donné quelque chose à prouver. Faites attention à ce dernier conseil, car je suis sûr que dans certains cas, il pourrait se retourner contre vous.

J'ai du mal à le définir exactement, mais j'ai travaillé avec un certain nombre de jeunes développeurs, et certains d'entre eux ont posé des questions auxquelles il était très satisfaisant de répondre, et d'autres non. Répondre à vos questions distrait vos collègues de leur travail, et ce n'est pas grave, si quelque chose de bon en découle et que l'entreprise en profite à long terme. Cela signifie que vous devez poser la bonne personne, poser la bonne question, et arriver à un endroit où vous avez acquis une compréhension qui vous permet de faire des progrès significatifs. Si vous avez un don pour cela, les gens auront l'impression que le temps passé à vous aider est du temps bien utilisé, et que vous êtes un collaborateur précieux. Sinon, ils risquent de vous trouver plutôt ennuyeux.

Évidemment, s'il y a beaucoup de choses que vous ne savez pas, cela vous met dans une situation délicate, mais l'attitude et l'aptitude font une grande différence. Personne ne s'attend à ce que vous sachiez tout, mais ils se soucient de la façon dont vous gérez la situation. D'autres personnes ici présentes ont déjà évoqué les choses que vous pouvez faire pour en avoir le plus possible pour votre argent lorsque vous faites reléguer un développeur senior, je ne répéterai donc pas leurs conseils ; j'essaie simplement de faire la lumière sur les sentiments de vos collègues qui ont conduit à cette situation, afin que vous puissiez les comprendre et les éviter à l'avenir.

C'est presque une suggestion pour votre employeur, mais peut-être pourriez-vous faire en sorte que cela fonctionne pour vous.

Vous ont-ils assigné un mentor lorsque vous avez commencé ? Donner à un nouvel employé un mentor attitré, quelqu'un à qui il peut s'adresser pour poser ses questions, est une bonne idée. Cela lui donne une personne déjà expérimentée dans l'entreprise et évite au nouveau venu d'embêter constamment les autres. :-)

Le mentor connaîtra également les bonnes personnes à qui poser des questions et les bons endroits où chercher des choses telles que des documents. Par exemple, certains projets peuvent avoir des documents Google Doc, un autre les a sur un serveur de fichiers interne et un troisième les a engagés dans le dépôt de sources. Alors que d'autres projets n'ont pas de documents du tout.

Un autre conseil est que lorsque vous commencez à travailler sur un nouveau projet, demandez une visite. Un bloc solide de quatre heures de temps avec vous et une personne expérimentée peut vous mettre au courant sans que ces quatre heures de temps ne soient des interruptions réparties sur plusieurs mois.

Une chose à retenir : le code est comme la grammaire. Les gens savent peut-être que le leur est nul, mais n'aiment pas qu'on le leur dise. Par exemple, si je vous faisais remarquer que vous avez à plusieurs reprises mal orthographié “jugement”, vous pourriez être agacé parce que je n'ajoute rien de constructif. Eh bien, je l'ai fait quand même :)

Mais ajoutez à cela le fait que de nombreux programmeurs chevronnés ont tendance à adopter une attitude de diva. Ce que vous considérez comme des questions sincères, ancrées dans la logique, peut être très menaçant pour eux. J'ai travaillé avec d'innombrables exemples (et j'en suis peut-être un moi-même) qui ont maintenu le même vieux code merdique qui n'est plus pertinent depuis 15 ans. Ils savent qu'il y a une meilleure façon de faire de nos jours, mais ils n'ont aucun intérêt ou motivation pour apprendre de nouvelles choses, donc votre simple présence en tant que prochaine génération est une menace pour eux. Lorsqu'ils font le prima donna act, riez simplement et souvenez-vous que c'est vous qui avez le vrai pouvoir - vous avez de nombreuses années devant vous pour travailler avec la technologie du futur et la direction ultime de votre carrière est toujours entre vos mains. Ce n'est généralement pas le cas pour les snobs chevronnés.

Je suis d'accord avec ceux qui ont mentionné que cela ne semble pas être un bon incubateur pour les développeurs en herbe. Cependant, c'est courant. Il faut du temps et de l'expérience pour identifier votre créneau, trouver un employeur qui vous convienne et déterminer ce qui compte le plus pour vous. Alors, payez vos cotisations là-bas, prenez vos galettes, planifiez votre carrière et sortez après quelques années de travail solide. Pour l'instant, suivez simplement les conseils pour ce qu'ils valent, ne vous inquiétez pas pour le PIP et n'oubliez pas que votre situation actuelle n'est qu'un moyen de parvenir à une fin. Vos supérieurs hiérarchiques s'attendent à ce que vous pointiez à l'heure comme si vous travailliez chez Wendy’s. Il n'en est pas forcément ainsi, même pour les nouveaux développeurs inexpérimentés, de sorte qu'il peut y avoir un avenir bien plus prometteur ailleurs.

J'ai essayé de leur dire exactement ce que je vous ai dit ici. Ils se sont fâchés contre moi parce que je me suis disputé avec eux “bec et ongles” et que je n'ai pas bien suivi leurs conseils. Je leur ai dit que j'essayais juste de leur faire entendre mon point de vue… ils se sont énervés.

Je pense pouvoir expliquer pourquoi ils se sont énervés : ils ne veulent tout simplement pas de retour d'information. Votre manager ne vous a pas invité à donner votre avis, il a simplement dit, avec ce plan d’“amélioration nécessaire”, que vous avez un mauvais comportement et que vous devez le corriger, “dans votre propre intérêt”.

Qui décide de ce qu'est un mauvais comportement ? Les personnes qui vous paient et qui peuvent vous renvoyer, uniquement. Lorsque vous critiquez leurs décisions, ils deviennent agacés, car ils vous paient pour suivre leurs ordres, et non pour les remettre en question. Ce ne sont pas des “juges impartiaux”, ce sont eux qui vous payent. Et si vous les critiquez au moment où ils vous donnent une alerte sérieuse et formelle “changez ou sortez” (ce qu'ils appelaient des “conseils d'amélioration”), cela peut les amener à penser que vous n'avez pas de rédemption.