Comment devenir un programmeur plus autonome et plus autonome? [fermé]

Le facteur le plus important dans ce qui me retient d'être un développeur stellaire est ma dépendance aux autres. J'ai l'impression de poser trop de questions parce que je crains les conséquences de tout casser et de retenir tout le monde. Je suis donc trop prudent en posant tellement de questions que j'obtiens essentiellement les réponses après suffisamment de questions. J'ai reconnu que c'est mauvais mais je veux l'arrêter. En partie, il y a des moments où je ne connais tout simplement pas le code (c'est une branche avec laquelle je n'ai jamais travaillé ou c'est un tout nouveau produit), mais je veux moins compter sur les autres. En guise de préface, ce type de questions ne concerne pas les modèles génériques ou les langages: généralement mes questions tournent autour de la façon dont nous codons dans notre entreprise et comment nous faisons fonctionner les choses dans notre écosystème. Je veux pouvoir prendre des spécifications et rouler avec eux sans avoir l'impression d'avoir besoin d'aide à chaque étape. Est-ce normal? Avez-vous vécu cela, et si oui, comment l'avez-vous surmonté?

Je vois que de nouveaux développeurs entrent dans un travail et se sentent immédiatement inadéquats. J'ai fait de même au début de ma carrière. Je pense qu'il y a au moins deux problèmes majeurs que la plupart des gars intelligents doivent surmonter: la perception du temps et leur propre capacité naturelle.

Perception du temps
Les gars intelligents sont habitués à résoudre les problèmes assez rapidement. Je me souviens avoir été consterné quand j'ai dû passer une heure sur un seul problème de calcul. Passer 60 minutes sur un problème n'est plus rien. Ces jours sont finis ... enterrez-les et dites au revoir. La complexité et la taille de la plupart des logiciels sont aujourd'hui scandaleuses. Les gens ne comprennent pas tous les outils dont ils ont besoin pour faire avancer les choses. L'un des hommes clés du langage JavaScript, Douglas Crockford, a déclaré:

"Misapplication of standard tools...is the new standard."

Il n'y a tout simplement pas assez de temps dans le monde pour apprendre tous les outils de développement.

Capacité naturelle
Votre intelligence, votre capacité à résoudre des problèmes et vos compétences naturelles vous ont permis de vous lancer dans l'ensemble du développeur. Il n'y a tout simplement pas de place pour rien de moins dans ce domaine. Alors, que faites-vous avec 100 000 lignes de code, langages et frameworks que vous connaissez à peine, les modèles de conception et les paradigmes que les gens vous poussent, les gars qui le savent le plus comme le dos de leur main, les clients qui le veulent hier et un patron qui attend le monde de vous? Freak out car votre capacité naturelle échoue.

Oui, c'est normal. Je panique toujours avec certaines des choses qui me sont jetées.

Ce qui peut être fait?

Il est temps d'améliorer ces capacités naturelles avec un bon travail dur à l'ancienne. Travaillez à décomposer les problèmes en parties plus petites. Et sachez que contrairement à beaucoup de choses que vous avez pu faire dans le passé, ces problèmes prennent beaucoup de temps à résoudre. Alors n'abandonnez pas après seulement 15 minutes d'examen d'un problème complexe. Au lieu de cela, décomposez les problèmes et arrêtez de regarder l'horloge. Après un certain temps, 30 minutes de travail avec un problème ne sont vraiment plus ce qu'elles étaient.

La confiance en soi joue un grand rôle dans sa capacité à s'autogouverner. Il en va de même pour l'équipe, en particulier les seniors les plus expérimentés. Il est bon de faire attention à ne pas casser les choses, mais cela ne signifie pas que vous devez poser un flux constant de questions.

Utilisez plutôt le contrôle de code source. Tant que vous ne consignez pas un changement, vous ne pouvez pas casser le produit principal et mettre les autres développeurs en colère. Apportez également des modifications que vous pouvez comprendre et tester et assurez-vous de les tester bien avant l'enregistrement.

J'ai même un petit projet de test que j'utilise pour écrire des programmes simples et uniques, donc je n'ai pas à me soucier de tout ce qui se passe dans l'application principale.

Enfin, n'oubliez pas que chaque décision s'accompagne d'un certain niveau de concessions mutuelles. Il est impossible d'avancer sans faire une sorte de sacrifice à un certain niveau. Ne cherchez pas la perfection, ne cherchez pas à être génial et soyez attentif à vos actions. Parce que vous devez toujours être prêt à accepter les critiques et à expliquer vos idées et pourquoi vous les avez faites. Soyez fier des décisions que vous prenez. Même lorsqu'ils ont tort, il y a beaucoup à apprendre.

La première chose est de ne pas avoir peur de poser des questions. J'ai même vu des architectes seniors poser des questions sur le code. Ils ne sont pas censés tout savoir; ils doivent en savoir suffisamment pour faire le travail et être capables de comprendre le reste.

La meilleure tactique serait probablement:

• Découvrez comment effectuer des recherches sur Google. Vous pouvez trouver des réponses à presque n'importe quoi avec un petit travail d'enquête. Stack Overflow fait des merveilles pour ces problèmes difficiles à résoudre.
• Apprenez à déboguer. J'ai passé des heures à entrer dans un code d'entreprise profond et original, seulement pour trouver la variable X est 3 au lieu de 7. Être capable de lire du code et de déboguer est probablement la meilleure façon de devenir autonome.

N'ayez pas peur de poser des questions générales

J'avais l'habitude d'essayer de trouver la moindre question que je pouvais poser et de pouvoir continuer mon travail, de peur d'être considéré comme incompétent si je posais des questions générales auxquelles tout le monde semble connaître la réponse. Je n'ai pas compris la différence entre l'ignorance et l'incompétence. L'ignorance signifie simplement que vous n'avez pas encore appris quelque chose et est parfaitement acceptable tant qu'elle ne persiste pas. Faire semblant de ne pas être ignorant est bien pire.

Si vous trouvez que les réponses des gens ne vous mènent que si loin, vous devez leur demander de vous apprendre à pêcher au lieu de vous en remettre un autre. Demandez comment votre partie s'intègre à l'ensemble. Si votre question semble aussi simple que «qu'est-ce que SQL de toute façon», posez-la le plus tôt possible. Vous pourriez avoir l'air un peu stupide maintenant, mais vous aurez l'air beaucoup plus stupide plus tard.

Accordez-vous une période d'attente

Ne posez pas de questions dès que vous les avez. Selon la complexité, donnez-vous entre une demi-heure et une journée pour essayer de le découvrir par vous-même. Souvent, vous le résolvez vous-même. Sinon, vous pourrez dire à votre collègue ce qui n'a pas fonctionné, ce qui peut l'aider à vous donner une meilleure réponse.

De plus, si votre collègue ne connaît pas de réponse du haut de sa tête, faites attention à la façon dont il y parvient. Souvent, vous n'avez pas besoin d'autant d'aide que vous le pensez. Si je n'ai pas le temps pour une question, je vais souvent diriger quelqu'un dans une direction vague et lui dire que je viendrai faire un suivi quand j'aurai une minute, et ils l'ont généralement résolu au moment où j'y arrive.

Jetez quelques brouillons

Asseyez-vous et déposez tout ce qui vous vient à l'esprit, puis vous êtes écrivain. Mais un auteur est celui qui peut juger de la valeur de ses propres trucs, sans pitié, et en détruire la plupart.
—Sidonie Gabrielle Colette

N'ayez pas peur d'écrire du code qui n'en fera jamais une version. Plus vous obtenez d'expérience, plus vite vous serez en mesure de dire que vous suivez le mauvais chemin, mais que vous continuez à emprunter le mauvais chemin. Souvent, la valeur d'une solution n'apparaît pas tant que vous ne l'avez pas vue mal dans un premier temps.

L'autosuffisance viendrait avec

• Expérience et exposition accrues dans le domaine.
• Compétences d'observation et d'analyse accrues pour comprendre les systèmes existants et leur comportement, leurs dépendances.

Poser des questions fréquemment risquerait de montrer que vous manquez des deux.

Si vous changez de domaine, de technologie, de plate-forme, de langue, vous revenez à la case départ (presque sans compter votre capacité accrue à résoudre des problèmes similaires et vos connaissances transférables)

Ne pas poser de questions lorsque cela est vraiment nécessaire ferait perdre un temps précieux à la production.

Si vous le faites mal, cela pourrait vous être utile en laissant tomber un mot sur votre hypothèse sur l'étendue des dommages possibles. ou ce que vous pensez pourrait casser pour obtenir une évaluation réelle de vos hypothèses. Souvent, cela pourrait vous permettre de découvrir des points et des angles que vous avez manqués.

Être prudent, c'est bien, mais il vaut mieux que vous commenciez à déterminer la nature de vos questions. Il est préférable de l'écrire sur du papier et d'examiner sa difficulté / sa valeur.

1. Est-ce quelque chose que vous pouvez comprendre avec google / forums ou en y travaillant plus longtemps
2. Est-ce quelque chose que vous pouvez vous débrouiller ou réparer sans trop de frais si vous vous trompez?

Je dirais de regarder les choses sur lesquelles vous travaillez et de commencer à prendre des décisions par vous-même (en respectant bien sûr les spécifications de l'application). À présent, vous devriez avoir une bonne idée de ce qui est un changement de grande envergure et de ce qui est un changement simple. Commencez par les plus simples. Si vous pensez que ce que vous faites est juste, faites-le.

Vous SEREZ faites des erreurs et ce sont inestimables. Apprenez tout ce que vous pouvez d'eux lorsqu'ils se produisent, car ils vous permettront de faire un meilleur travail la prochaine fois.

Une fois que vous êtes à l'aise avec les petites décisions, commencez à prendre les plus grandes. Vous devrez décider jusqu'où aller en fonction de votre projet / environnement / équipe.

C'est le côté décisionnel. L'autre chose que vous devez faire est de continuer à nourrir votre cerveau afin qu'il puisse guider vos décisions. Suivez les sites qui couvrent votre technologie. Il existe des didacticiels en ligne sur presque tout ce qui couvre tout, du simple au bizarrement complexe. N'ayez pas peur de demander aux gens pourquoi ils prennent certaines décisions - en tant que chercheur d'informations, ne pas être conflictuel. La plupart des gens sont plus qu'heureux d'expliquer les choses et vous pouvez en apprendre beaucoup.

Une fois que vous avez les connaissances techniques, le reste est la sagesse et la confiance et celles-ci viennent avec l'expérience.

Quand j'étais un débutant posant des questions, j'essayais toujours d'obtenir une réponse partielle à la chose moi-même, en utilisant les outils disponibles; et quand j'arrivais le plus loin possible, je trouvais exactement comment formuler ma question de manière à être aussi claire et concise que possible, en supposant que la personne à qui j'allais demander de l'aide était occupée. Avec ce peu de préparation, je pense que personne ne m'a jamais dérangé de leur poser des questions, et en fait j'ai eu l'impression qu'ils ont apprécié. Plus tard, lorsque je suis devenu l'expert du domaine, j'ai également aimé aider les gens qui ont clairement indiqué qu'ils respectaient mon temps.

L'autre chose que j'ai faite a été, chaque jour, de parcourir l'architecture du système. D'autres affiches ont commenté ce qu'est une entreprise massive de systèmes modernes, la difficulté à accepter. Je faisais donc des visites guidées du code: commencer à un point d'entrée raisonnable, puis le parcourir, me noter des notes sur le fonctionnement, poser des questions auxquelles je répondrais parfois par moi-même, parfois à d'autres personnes. Ce type de familiarité globale et de compétence de domaine prend du temps, mais vous pouvez l'accélérer; et plus vous en faites, plus tôt vous serez autosuffisant comme vous le souhaitez.