Les développeurs forts doivent-ils porter le poids du monde sur leurs épaules? [fermé]

En tant que développeurs, nous nous efforçons constamment de résoudre les problèmes des masses. Nous recherchons également constamment de nouvelles méthodologies, de nouveaux langages et éventuellement des organisations pour nous aider à renforcer notre capacité à résoudre les problèmes.

J'ai l'impression d'avoir toujours été l'un des meilleurs membres de mon équipe. Je sens également que je cherche des moyens d'améliorer mon travail d'une manière dont les autres s'en moquent souvent. Je commence à ressentir un peu d'épuisement après environ 6 ans de soutien technologique. Je blâme le fait que je travaille si dur et me tiens à des attentes élevées.

Certains des plus grands développeurs de la planète n'écrivent même plus de code pour vivre. Souvent, son burnout. Certains ont dit qu'ils se lassent du "jeu", mais je me demande si le problème est un peu plus simple. Un de "porter le poids du monde sur nos épaules".

Si vous sentez que vous êtes un développeur fort et que vous pensez également que ce n'est pas un problème pour vous, veuillez m'éclairer avec votre approche. Comment restez-vous à jour avec la technologie, aidez-vous les autres et résolvez-vous les problèmes rapidement / avec précision sans vous retrouver complètement?

Si vous êtes le développeur le plus fort de votre entreprise / équipe, vous voudrez peut-être opter pour une "ligue plus importante". Les bons développeurs "bouillonnent" souvent là où ils peuvent être moyens. Si vous «portez le monde» parce que vos pairs ne sont pas à la hauteur, il n'y a peut-être pas d'autre choix que de chercher de meilleurs pairs.

Je pense aussi que vous obtenez un burn-out dans chaque emploi. Je suis sûr qu'il y a beaucoup de gens qui "ne codent plus" qui le manquent beaucoup.

Je pense que si vous êtes un très bon développeur, vous pouvez trouver un poste qui aura le bon équilibre de codage, d'architecture et de leadership.

Je sais qu'ici, chez Google, une fois que vous êtes devenu un développeur expérimenté, vous pouvez choisir entre une gestion et une piste technique. Est-il également très courant de changer complètement de domaine (pas seulement des projets) tous les deux ans? D'après ce que je sais, le premier est courant dans d'autres sociétés (Intel, MS, IBM), mais les domaines de commutation peuvent ne pas être aussi courants.

Plus vous vous mettez de pression pour faire du bon travail, mieux vous faites. Mieux vous faites, plus vous donnez de travail.

C'est un cycle qui, à moins que vous n'interveniez et que vous ne commenciez à dire «non» à certaines choses, puisse entraîner un épuisement rapide.

Voici mon tour:

C'est l'effort et l'effort continu pour s'améliorer que vous ne voyez pas toujours chez tous les autres autour de vous.

C'est la perspective que ce que vous venez de construire peut toujours être meilleur, pourrait toujours être amélioré.

C'est de l'humilité, car même si une solution est élégante, elle peut toujours être simplifiée.

Pour être honnête, ce sont les qualités qui font de quelqu'un de formidable, pas seulement dans la programmation, mais dans à peu près n'importe quelle carrière, vu sous un angle différent.

C'est l'une des nombreuses raisons pour lesquelles les gens vraiment fantastiques commencent d'abord par une attitude et des perspectives fantastiques. Ils ont tendance à dépasser la norme et à se hisser au sommet d'une équipe s'ils ne sont pas entourés de personnes partageant les mêmes idées.

D'autres, peuvent ou non venir avec eux. En fin de compte, selon l'équipe qui vous entoure, vous pouvez certainement avoir l'impression de porter le poids de plus d'une personne sur vos épaules, car il est toujours plus facile pour un membre de l'équipe qui n'est pas aussi motivé que vous de simplement côte à côté.

Je l'ai vu à maintes reprises chez mon employeur actuel. Maintenant, je ne suis plus développeur, mais plutôt directeur de développement. Une grande partie de ce que je fais en tant que facilitateur pour mon équipe consiste à aider à faire face à des situations comme celle-ci, à essayer de hausser la barre unilatéralement pour l'ensemble du groupe. Je peux vous dire que c'est parfois un énorme défi et cela dépend en grande partie de l'équipe que vous avez autour de vous. J'ai de la chance, j'ai une équipe fantastique et cela rend mon travail beaucoup plus facile.

Je suppose donc que ce que j'essaie de dire, c'est ce que vous ressentez pourrait être plus révélateur de qui vous travaillez plutôt que de ce que vous faites réellement. Si vous vous sentez épuisé, il est peut-être temps de changer de carrière et de passer à un petit groupe de personnes intelligentes partageant les mêmes idées et très motivées.

Vous seriez surpris de ce qu'un changement de décor peut faire!

Juste pour élaborer un peu par ce que je veux dire sur la perspective, car je soupçonne que ce que je pensais être une remarque quelque peu sarcastique ne s'est probablement pas déroulée comme je l'espérais. ;)

La thérapie de la pleine conscience et du comportement cognitif serait quelques exemples de sujets que vous pourriez explorer et voir si ceux-ci aident à voir le monde, une suggestion de livre ici étant Mind Over Mood . L'intelligence émotionnelle serait une autre idée dans ce domaine en termes de conscience de soi et d'autogestion en particulier, bien que d'autres domaines soient également utiles. Obtenir des résultatsserait un livre en ligne que je recommanderais pour vous aider avec des idées plus spécifiques. Bien sûr, il existe diverses stratégies d'anxiété et de dépression qui peuvent également venir à l'esprit ici qui ne sont pas nécessairement spécifiques aux programmeurs, mais je soupçonne que certains programmeurs peuvent avoir ce problème dans leur vie. Une autre technique est ce que j'aime appeler les 4 "Re" de reconnaître, recadrer, répondre et réfléchir. Reconnaissez le problème. Recadrez le problème pour le voir sous d'autres angles et points de vue. Répondez à la situation du mieux que vous le pouvez. Réfléchissez à ce qui a été fait, à ce qui a fonctionné et à ce qui n'a pas fonctionné. Planifier, Faire, Vérifier et Agir est un ensemble similaire de 4 étapes dans un ordre peut-être légèrement différent bien qu'il y ait toujours l'idée de regarder les choses, L'amélioration continue du service serait un composant ITIL qui pourrait être utile ici si vous voulez quelque chose de plus technique et pas si délicat.

Bien que parfois j'apprécie de sentir qu'il y a beaucoup de pression sur moi et que cela peut m'aider à atteindre certains objectifs, il y a d'autres moments où cette même pression peut avoir des conséquences quelque peu désastreuses. Trouver le bon équilibre entre ce qui est une bonne motivation pour moi de continuer et de faire un bon travail par rapport à ce qui est trop pour moi à gérer n'est pas une leçon facile à apprendre.

Pour moi, c'est ce qui rend le travail intéressant et me fait me lever le matin. Je sais qu'aujourd'hui, j'aurai probablement l'occasion de résoudre un problème pour plus que moi (oui, je suis optimiste, avec une mémoire courte).

Je peux seulement imaginer que vous êtes pareil (je ne peux pas vous voir le faire par devoir pendant les 5 dernières années). Ma seule supposition est que vous avez frappé un peu l'ornière, et maintenant vous êtes dans un mode réfléchissant. Ce qui, je pense, est tout à fait normal lorsque vous atteignez l'un des points d'inflexion sur les cycles de courbe d'apprentissage de plusieurs années.

Je ne peux que suggérer à ce stade que vous changiez un peu votre objectif (jusqu'à ce que votre passion naturelle revienne) des solutions techniques au renforcement de votre apprentissage de carrière en prenant activement un certain mentorat de jeunes développeurs.