Comment un nouveau programmeur peut-il impressionner l'ingénieur logiciel (patron)?
Je travaille à mon premier travail de programmation. Mon patron est un ingénieur logiciel très intelligent et j'ai l'impression d'avoir très peu à offrir par rapport à lui. Le problème, c'est qu'il est toujours occupé et qu'il a besoin de quelqu'un pour l'aider. J'ai l'impression de ne pas être assez bon, mais je veux quand même réussir. Je veux être un excellent programmeur.
Que puis-je faire pour l'impressionner?
Je vous remercie.
Je t'ai déjà parlé d'Ashton?
Ashton était votre fermier classique nourri au maïs. Ses parents étaient des hippies qui n'ont jamais vraiment réussi à se rassembler jusqu'à ce que sa mère hérite de 15 acres dans une partie rurale du Michigan. La famille a déménagé là-bas, a acheté quelques chèvres laitières et a eu du mal à gagner sa vie en vendant du fromage de chèvre biologique aux yuppies du marché fermier d'Ann Arbor.
Depuis l'âge de dix ans, Ashton a dû se réveiller tous les matins à 4 heures du matin et traire ces fichues chèvres, et c'était épuisant. Ashton aimait aller à l'école parce que cela signifiait qu'il ne travaillait pas jusqu'aux genoux dans la merde de chèvre. Tout au long du lycée, il a étudié son cul, espérant qu'une bourse pour une bonne université serait son ticket de sortie de la ferme. Il a trouvé que le collège était tellement plus facile que la vie à la ferme qu'il ne comprenait pas pourquoi tout le monde ne se sentait pas bien comme lui. Il s'est spécialisé en génie logiciel parce qu'il ne pouvait pas imaginer que les ingénieurs soient obligés de se réveiller à 4 heures du matin.
Ashton est diplômé de l'école sans en savoir beaucoup sur l'industrie du logiciel, vraiment, alors il est allé à la foire de l'emploi, a postulé pour trois emplois, a été accepté par les trois et a choisi celui qui a payé le plus: quelque chose de fou comme 32000 $ par an, travaillant dans une grande entreprise de meubles du sud-ouest de l'État qui fabriquait des fermes de cabines pour des entreprises du monde entier. Il n'a jamais voulu revoir une ferme, il était donc déterminé à faire bonne impression sur son patron, Charlie Sherman.
"Ce ne sera pas facile", a déclaré son compagnon de cabine, Jeff. "Elle est quelque chose d'une légende ici."
"Que voulez-vous dire?" Il a demandé.
"Eh bien, tu te souviens il y a quelques années, quand il y avait tout ce tollé sur Y2K?"
Ashton était probablement trop jeune. "Y2K?"
"Vous savez, personne ne s'attendait à ce que tous les anciens programmes informatiques écrits dans les années 1960 soient toujours en cours d'exécution en 2000, ils n'avaient donc de la place que pour deux chiffres pour l'année. Au lieu de stocker 1999, ils en stockeraient 99. Et puis lorsque l'année a basculé le 1er janvier 2000, les systèmes informatiques se sont écrasés, car ils ont essayé de faire correspondre "100" à deux chiffres.
"Vraiment? Je pensais que c'était un mythe ", a déclaré Ashton.
"Dans toutes les autres entreprises du monde, rien ne s'est produit", a déclaré Jeff. "Ils ont dépensé des milliards de dollars pour vérifier chaque ligne de code. Mais ici, bien sûr, ce sont des salauds bon marché, donc ils n'ont pas pris la peine de faire des tests. "
"Pas du tout?"
"Rien. Aucun test. Nada. Et voilà, quand les gens ont repris leur travail le 2 janvier, rien n'a fonctionné. Ils ne pouvaient pas imprimer les calendriers de production. Ils ne pouvaient même pas activer la moitié des chaînes de montage. Et personne ne savait quels changements ils étaient censés opérer. L'usine s'est littéralement arrêtée. "
"Vous plaisantez", a déclaré Ashton.
"Je te chie pas. L'usine était totalement silencieuse. Maintenant, Charlie, elle était nouvelle à l'époque. Elle avait travaillé chez Microsoft, ou la NASA, ou quelque chose ... personne ne pouvait comprendre pourquoi quelqu'un comme elle travaillerait dans notre petite aisselle d'entreprise. Mais elle s'est assise et a commencé à coder. Et le codage. Et le codage.
"Charlie a codé pendant neuf jours d'affilée. Neuf jours sans dormir, sans manger, certaines personnes ont même affirmé qu'elle n'était jamais allée aux toilettes. Elle est passée de système en système et les a littéralement réparés. C'était quelque chose à voir. Mon Dieu, il y avait COBOL systèmes qui devaient être réparés. Toute l'usine est à l'arrêt, et Charlie envoie des gens à la bibliothèque universitaire d'Ann Arbor pour trouver de vieux manuels COBOL. Les ouvriers de la chaîne de montage tremblent, car même les thermostats avaient un bug Y2K. Et Charlie boit tasse après tasse de café et tape comme une folle. "
"Sensationnel. Et elle n'est jamais allée aux toilettes?
"Eh bien, cette partie pourrait être un petit peu d'exagération. Mais elle a vraiment travaillé 24 heures sur 24 pendant neuf jours consécutifs. Quoi qu'il en soit, le 11 janvier, environ cinq minutes avant le début du quart de jour, elle sort de son armoire, va à l'imprimante de ligne, frappe un bouton et boum! sort les calendriers de production et les calendriers d'équipe, et tout est parfait, parfaitement formaté, en utilisant une police légèrement plus petite pour que le "2000" tienne où il disait "99", et elle a même écrit un nouveau système d'optimisation des priorités qui les aide à rattraper 9 jours de production manquée sans énerver trop de clients, et toutes les chaînes de montage commencent à fonctionner comme si de rien n'était, et la chaleur s'allume et les factures sortent imprimées avec '2000' comme année à la place de '19100', et après ce jour, personne n'a trouvé un seul bug. "
"Oh allez!" Dit Ashton. "Personne n'écrit de code sans bugs."
"Elle l'a fait. Je l'ai vu de mes propres yeux. Le premier jour, ils ont fait deux jours de cabines sans hoquet. "
Ashton était stupéfait. "C'est épique. Comment puis-je être à la hauteur? "
"Vous ne pouvez pas, mon pote, personne ne le peut", a déclaré Jeff, se retournant vers son terminal informatique, où il a repris une guerre des flammes en ligne pour savoir qui gagnerait dans un combat, Spock ou Batman, qui faisait rage depuis plus de quatre mois.
Pas un à abandonner, Ashton a juré qu'il ferait un jour quelque chose de légendaire. Mais la vérité est qu'il n'y a jamais eu d'autre Y2K. Et personne, dans cette partie du Michigan, n'a donné de folie à une bonne programmation. En fait, il n'y avait presque rien à faire pour les programmeurs. Ashton s'est vu confier de petits projets stupides ... À un moment donné, il a passé trois semaines à gérer un cas où la taxe de vente dans un comté particulier était erronée parce que certains codes postaux s'étalaient sur deux zones de taxe de vente différentes. Le plus drôle, c'est que c'était dans une partie peu peuplée de l'État de New York où personne n'a jamais acheté de bureaux et où il n'y avait jamais eu de client, donc son code ne fonctionnerait jamais.
Déjà.
Pendant deux ans, Ashton est entré dans le travail avec enthousiasme et excitation, et il mourait d'envie de faire une différence et de faire quelque chose de formidable et génial, tandis que ses collègues surfaient sur Internet, envoyaient des messages instantanés à leurs amis et jouaient au solitaire informatique pendant des heures.
Jeff, son compagnon de cabine, n'avait qu'une seule responsabilité: mettre à jour la feuille de calcul Excel hebdomadaire indiquant combien de personnes ont été blessées au travail cette semaine-là. Personne ne l'a jamais été. Une fois par semaine, Jeff a ouvert la feuille de calcul, est allé au bas de la page, a entré la date et un zéro, appuyez sur Enregistrer, et c'est tout.
Ashton a même écrit une macro pour Jeff qui automatisait cette tâche. Jeff ne voulait pas se faire prendre, alors il a refusé de l'installer. Ils n'étaient plus en termes parlants après cela. C'était gênant.
Le matin de son anniversaire de deux ans dans la cabine, Ashton se rendait au travail quand il a réalisé quelque chose.
Aucune ligne de code qu'il avait écrite n'avait jamais été exécutée.
Aucune chose qu'il avait faite en deux ans de travail n'avait eu d'impact sur le monde.
Et il faisait putain de 24 degrés dans cette partie du Michigan, et il était gris et puant, et sa Honda était un morceau de merde, et il n'avait pas d'amis en ville, et rien de ce qu'il importait.
En descendant l'avenue Lincoln, il aperçut l'entreprise de meubles devant vous sur la gauche. Trois drapeaux flottaient devant le campus de l'entreprise: un drapeau américain, un drapeau du grand État du Michigan et un drapeau blanc et rouge avec le logo de l'entreprise. Il monta dans la voie de virage derrière une longue file de voitures attendant de tourner à gauche. Il fallait toujours quatre ou cinq cycles de feux de circulation, à l'heure de pointe, pour faire le tour, donc Ashton avait beaucoup de temps pour essayer de se rappeler si un code qu'il avait jamais écrit était jamais utilisé par n'importe qui.
Et ce n'était pas le cas. Et il a repoussé une larme.
Et au lieu de tourner à gauche, il est allé tout droit, causant presque un accident parce qu'il a oublié que le feu de virage à gauche ne signifiait pas que vous pouviez aller tout droit.
Et il a roulé tout droit sur Lincoln Avenue, et a pris l'autoroute Gerald Ford, et il a juste continué à conduire jusqu'à ce qu'il arrive à l'aéroport à Grand Rapids, et il a laissé sa vieille Honda merdique juste devant le terminal, sachant parfaitement bien il serait remorqué, et n'a même pas fermé la porte de la voiture, et il est allé directement au comptoir de Frontier Airlines et il s'est acheté un billet sur le prochain vol vers San Francisco, qui partait dans 20 minutes, et il a obtenu dans l'avion, et il a quitté le Michigan pour toujours.
Rappelez-vous la scène dans Aladdin où Aladdin veut impressionner Jasmine, et le génie lui dit qu'il ferait mieux de se concentrer uniquement sur lui-même? Même principe ici.
Si le patron est bien meilleur que vous et que vous le savez, il le sait probablement aussi. Il n'attend pas de grands exploits de programmation rock-stardom de votre part. Comme il s'agit de votre premier emploi, il vous a probablement embauché parce qu'il a vu le potentiel de devenir un bon codeur en vous. Donc, si vous voulez vraiment l'impressionner, apprendre. Apprenez la langue, apprenez le système sur lequel vous travaillez, apprenez les tenants et aboutissants et les coins sombres. Concentrez-vous sur l'apprentissage des principes corrects, en les apprenant bien et en les apprenant rapidement, dans cet ordre.
Et rappelez-vous qu'une partie de l'apprentissage consiste à copier les connaissances que d'autres personnes possèdent déjà. N'ayez pas peur de poser des questions, à vos collègues ou sur StackOverflow, ou de rechercher des choses sur Google. Quoi que vous fassiez, ne faites pas semblant de savoir quelque chose alors que vous ne le savez vraiment pas, afin d'éviter de paraître stupide. Tout bon développeur le remarquera rapidement, ce qui vous fera paraître encore plus stupide à leurs yeux. L'humilité a toujours tendance à être considérée comme une vertu chez les ingénieurs.
Faites un bon travail et cela impressionnera le patron.
Deux mots: soyez fiable.
À votre poste, vous n'étiez pas embauché pour être la personne la plus intelligente de l'équipe. Vous avez été embauché pour le potentiel que vous avez montré et parce qu'il y a des tâches adaptées à votre niveau de compétence qui doivent être accomplies.
Montrez que vous pouvez être à la hauteur de cette confiance en premier et, au fur et à mesure que vous vous familiarisez avec le code et l'entreprise, trouvez des moyens de dépasser leur première impression de vous. Ce dernier peut prendre un certain temps, mais ne vous méprenez pas d'être junior pour être inférieur.
Il me semble qu'il y a toujours eu un travail incroyable avec une salle pleine de programmeurs incroyables et accomplis. Tout le monde était une rockstar, quelques personnes de l'équipe Macintosh d'origine, près de la moitié des gens là-bas avaient publié des livres, c'était un endroit formidable.
J'ai donc passé ma première année là-bas à essayer d'impressionner tout le monde. Je sentais que je devais faire quelque chose d'incroyable et cela m'a conduit à en apprendre plus que je n'aurais jamais cru possible en très peu de temps. Au cours de ma deuxième année, je me suis calmé, j'étais beaucoup plus confiant dans ce que je faisais, un peu plus vocal sur mes opinions, et en regardant autour de moi, je devenais de plus en plus pessimiste quant au produit que nous construisions.
C'était la dernière année que ce projet était entièrement financé. Ces ingénieurs incroyables, que je regarde toujours aujourd'hui, ont passé 5 ans et des millions de dollars à construire framework après framework, une plateforme d'application pour construire au-dessus d'une application qui n'avait pas vraiment été livrée et enfin, une interface utilisateur et un workflow que personne ne pouvait comprendre, même les gens qui l'ont construit.
Smart est surévalué. Être une "rockstar" est surfait. C'est une excuse vraiment facile pour augmenter votre seuil de complexité. Cela vous fait penser qu'il est plus important de réécrire un système qui fonctionne pour être "plus propre" au lieu d'implémenter la prochaine chose qu'un client a demandée.
Jacob Kaplan Moss m'a dit un jour un programmeur que je ne nommerais pas, il a dit: "Il est trop intelligent. Il écrit ces bibliothèques compliquées vraiment intelligentes que je ne peux pas utiliser parce que je ne suis pas assez intelligent. Les gens stupides devraient écrire des bibliothèques pour que les stupides puissent les utiliser ".
Les programmeurs que les ingénieurs "accomplis" ont tendance à snober, les gens qui écrivent Ruby et JavaScript et d'autres langages "jouets", ces gens font des PRODUITS et ils LES EXPÉDIENT. Le code pourrait être laid) , l'architecture n'est peut-être pas aussi pure et propre que vous le souhaiteriez, mais ils expédient bon sang et dans cette industrie, c'est ce qui compte vraiment.
Si j'étais vous, j'abandonnerais d'essayer d'être cette rockstar et me concentrerais sur l'expédition et la construction de produits. Vous ne devez pas juger de votre contribution en fonction de l'intelligence de votre code, vous devez le juger par le nombre de personnes qui l'exécutent tous les jours et qui sont heureuses.
Écrivez un code clair et solide.
Frappez à sa porte. Demandez-lui s'il a des emplois de merde qu'il repousse et que vous pourriez peut-être gérer. Dites-lui de vous renvoyer un e-mail plus tard s'il n'a pas le temps pour le moment.
Lire Knuth
(corollaire: beaucoup de gens ont Knuth, mais personne lit Knuth)
Tous les vraiment bons programmeurs avec qui j'ai travaillé ont des traits communs:
(1) Même si vous n'avez pas avez pour être bon en maths pour faire de la programmation, ils l'étaient quand même (et ils ont aimé)
(2) Ils apprécient une qualité que j'appellerai 'élégance' - pas à confondre avec brièveté (!!!)
(3) Ils sont bons dans la conception de logiciels (même si aucun de nous ne peut expliquer ce qu'est réellement une bonne conception)
De plus, je trouve personnellement les traits suivants à portée de main:
(a) prendre plaisir à résoudre des énigmes
(b) écrire du code lisible
(c) une bonne mémoire
(d) peut facilement s'adapter superficiellement à d'autres langages de programmation (étendue)
(e) apprenez votre langue principale en profondeur (par exemple, faites la certification Java si Java est votre environnement (pour les détracteurs ignorants qui n'ont jamais fait cela mais qui ont retiré la certification puisque la certification de Microsoft est (était?) vraiment mauvaise ... l'avantage est pas en ayant le morceau de papier, l'avantage est en l'étude))
(f) étant donné le choix de faire quelque chose de simple et facile puis de passer à autre chose, ou quelque chose de super compliqué qui prendra des semaines/mois, je fais la chose simple. J'aime le simple, car il tend vers la robustesse, il est également plus flexible lorsque les exigences changent à mi-parcours et est beaucoup plus facile à communiquer aux autres membres de l'équipe.
(g) si vous faites quelque chose que vous jugez particulièrement rusé, documentez-en le smeg
Quelqu'un (Djikstra?) A dit que le débogage est deux fois plus difficile que le codage, donc si vous écrivez du code qui est aux limites de vos capacités, vous n'êtes par définition pas assez intelligent pour le déboguer.
========
Cela dit, devenir un codeur intelligent/meilleur n'est pas la même chose que faire avancer votre carrière.
Il n'y a vraiment qu'un seul "ingrédient secret" requis pour faire avancer votre carrière, et ce sont les compétences humaines.
Si vous voulez vraiment faire progresser votre carrière, la meilleure chose à faire est d'arrêter et de vendre des voitures pendant 6 à 12 mois.
Je code depuis plus de 20 ans et j'ai actuellement 10 programmeurs qui travaillent avec moi. Je dois dire que ceux qui m'impressionnent sont ceux qui ont bien fait leur travail, livré dans les délais et avec qualité (moins de bug). communiquer fréquemment, montrer de la passion sont tous des facteurs importants.
c'est à ce sujet que je peux partager dès maintenant. ;)
Eh bien, je voudrais juste ajouter cette citation de l'évangile:
"Celui à qui on peut faire confiance avec très peu peut aussi faire confiance à beaucoup, et celui qui est malhonnête avec très peu sera aussi malhonnête avec beaucoup."
Ayant été un patron de programmeurs, je peux vous dire que rien ne m'a fait plus plaisir que lorsqu'un programmeur a corrigé un bug que j'étais trop paresseux pour corriger!
Donc, si vous le pouvez, corrigez ses bugs pour lui.
Comme Steven le dit, Mason a raison - concentrez-vous sur votre propre jeu. La chose à garder à l'esprit est que votre patron veut juste que vous fassiez bien votre propre travail. Il a probablement en fait aime le fait qu'il est meilleur que vous - s'il ne l'était pas, il pourrait bien se sentir en insécurité (les patrons sont humains!). En ce moment, vous êtes dans une position idéale pour apprendre de son expérience - ne perdez pas de temps à rivaliser avec lui, demandez plutôt ses conseils sur les choses. Si vous avez déjà lu les 48 lois du pouvoir, la clé est "Ne jamais éclipser le maître".
Résolvez le cube de Rubik. Le patron saura que vous aimez les énigmes difficiles et vous donnera des tâches difficiles.
Si vous voulez faire bonne impression sur votre patron, soyez honnête. Lors de votre 1-1 hebdomadaire, demandez-lui ce qui est le plus important pour vous de vous concentrer et faites-le. Essayez de comprendre ce qu'il pense de votre rôle et faites de votre mieux pour le remplir. Il est possible qu'il ait besoin de vous pour effectuer certaines tâches afin qu'il puisse se concentrer sur ce qu'il fait. Si vous vous efforcez de faire les choses qu'il fait, vous pourriez ne pas faire assez de votre propre tâche. Trouvez votre place dans l'équipe, Excel à cela, puis développez. Dites-lui que vous voulez aider.
@Mason a raison
- ecoutez
- apprendre
- poser des questions pertinentes à des intervalles respectueux (par exemple, deux fois par jour, pas toutes les 5 minutes)
- détendez-vous et soyez vous-même
À mon avis, le plus grand atout qu'un programmeur vert puisse apporter à la table, au-delà de ses compétences techniques existantes, est l'initiative et la passion. Si vous montrez à votre patron que vous êtes agressif pour apprendre de nouvelles choses, agressif pour apprendre votre chemin dans l'entreprise, la base de code, les outils et vos collègues, et que vous montrez que vous êtes passionné par ce que vous faites , cela impressionnera. Sauf si vous travaillez pour un horrible manager, auquel cas vous voulez quand même sortir.
Je suggérerais également de mettre certains l'accent sur les choses "soft skills". Démontrez que vous n'êtes pas juste un geek qui est inutile dans toute sorte d'interaction interpersonnelle. Faites-vous des amis avec les gens des ventes, du marketing, du support, du développement commercial, de la gestion de projet, etc. Montrez que vous êtes un bon communicateur et quelqu'un qui peut travailler avec les gens pour faire avancer les choses.
Si vous avez la liberté de le faire: écrivez des subventions, apportez de l'argent de subvention de l'extérieur ou démarrez une coopération qui a une valeur commerciale, avec de nouveaux partenaires qui vous considèrent comme un programmeur compétent ou, au moins, un employé de valeur.
Ne vous embêtez pas à impressionner les gens ou vos patrons. Personne n'est impressionné par le simple fait de parler. Concentrez-vous plutôt sur le code d'expédition. Assurez-vous d'être impliqué dans des projets ou des applications qui seront utilisés par des personnes. Plus vous aurez de code en production, plus vous serez pertinent. Plus vous êtes pertinent pour les gens, plus ils comptent sur vous. Le repos est tout spectacle magique.
Travailler dur. Faites tout ce qu'on vous dit et apprenez tout. Vous avez beaucoup de chance de travailler avec quelqu'un qui en sait beaucoup plus que vous, continuez à travailler jusqu'à ce que vous puissiez vous rattraper.
En plus de travailler dur et de réussir dans le travail que vous occupez maintenant, j'aimerais donner quelques conseils qui sont peut-être une réponse à la question que vous ne posez pas. (Ce n'était même pas sur mon radar lorsque j'ai obtenu mon premier emploi logiciel).
Internet est créé par des gens comme vous. Et des gens comme vous peuvent gagner de l'argent sur Internet.
Trouvez quelque chose qui vous passionne. Construit le. Vends le. Soyez votre propre patron.
Ouvrez http://news.ycombinator.com et commencez à lire les articles. Vous allez voir une vague sans fin d'histoires de gens comme vous, qui ont eu une idée, construit un site Web et réussi à gagner un dollar ou deux en le faisant. C'est inspirant et révélateur, il y a un gars qui gagne un salaire ridiculement bon en vendant un générateur de cartes de bingo aux enseignants ... un autre gars qui a vendu un site Web à Google pour des millions. Il y a aussi beaucoup d'autres trucs technologiques intéressants.
"Rich Dad, Poor Dad", il y a des endroits où il a de bons conseils.
"La semaine de travail de quatre heures", prenez celle-ci avec un grain de sel, mais il a des façons intéressantes de voir le travail et la vie.
Continuez à apprendre du gars dont vous êtes maintenant. Il y a tellement de choses à apprendre dans "ton premier vrai travail" que je ne peux même pas commencer. À long terme cependant (trois, cinq, dix, vingt ans) si vous apprenez à gagner votre propre argent, vous n'aurez pas à vous soucier d'impressionner quelqu'un d'autre.
Vous pouvez rarement impressionner les gens en essayant de les impressionner. Et tant que vous essayez d'impressionner les gens, et qu'ils ne semblent pas impressionnés, votre frustration grandira.
Faites votre travail d'une manière qui vous rend fier de vous. Ne vous inquiétez pas de ce que quelqu'un pense. La seule personne que vous pouvez rendre heureux, c'est vous.
J'ai aimé l'histoire publiée dans la réponse, mais c'est plus amusant qu'une réponse fiable.
Il est normal que tout le monde soit comme vous: essayer d'être meilleur dans ce que nous faisons, c'est humain. Mais la vérité horrible est qu'il y a si peu de chances que vous soyez le meilleur.
En ce qui me concerne, j'ai toujours eu peur des soucis d'humilité, parce que je déteste ces petits combats enfantins pour savoir qui a raison et qui n'a pas raison, et voici pourquoi.
Tant que vous n'êtes pas parmi les meilleurs, il vaut mieux essayer de travailler pour avoir plus d'expérience en comparant ce que vous savez et faites à ce que les meilleurs programmeurs savent et font.
On pourrait dire que je me compare aux meilleurs programmeurs, mais c'est à moitié juste: - Je me compare mieux aux meilleurs, sachant que je suis juste ridicule par rapport à eux, ce qui rend le principe de la comparaison assez stupide et inutile - Je ne considère pas leur renommée mais plutôt ce qu'ils ont obtenu pour l'obtenir, car en réalité, la plupart des mythes de génies s'estompent lorsque vous connaissez des faits réels, comme le fonctionnement des affaires. Cela ne change rien au fait qu'ils ont accompli un excellent travail, mais n'oubliez pas que l'expérience est difficile à évaluer si vous pensez aux conditions de travail. - Au final, ce processus évite le processus de compétition qui me dérange vraiment et m'aide à me concentrer sur ce qui est important: apprendre par la pratique, mais aussi apprendre à l'aide d'un bon moteur de curiosité.
Vous pouvez admirer quelqu'un tout ce que vous voulez, pensant qu'il est tellement meilleur que tous les autres employés ou autres programmeurs que vous rencontrerez, mais vous devez vous rappeler que le monde est vaste et que le gars que vous admirez est en fait assez moyen par rapport aux autres meilleurs il y a des gens expérimentés là-bas, alors peut-être que vous vous sentirez mieux une fois que vous l'aurez impressionné, mais vous ressentirez la même chose contre d'autres personnes avec une meilleure expérience que lui, donc ce sera tout pour rien.
Quittez ce petit jeu et essayez de trouver des sujets plus intéressants dont vous pourriez avoir entendu parler, car cet ingénieur dont vous parlez est certainement occupé à travailler pour quelque chose de moins génial que vous pensez.
Je dois être d'accord avec certains des autres ici en ce que vous risquez d'échouer dans votre objectif - parce que vous vous concentrez sur le mauvais problème, ou au moins votre concentration est trop étroite.
Vous voulez être un grand programmeur - l'opinion subjective d'un ingénieur logiciel vous confère-t-elle ce titre et cette capacité (autre que Joel)? Si vous vous concentrez uniquement sur l'impression de votre patron, vous ne vous concentrez pas sur le travail ou sur l'amélioration de vos compétences - vous n'êtes pas concentré sur votre objectif de devenir un grand programmeur. Vous essayez de vous faire respecter plutôt que de le gagner.
Prenons le pire des cas (parce que les programmeurs aiment le faire) - votre patron vous déteste absolument sans raison objective (vous portiez un chapeau de Patriotes le premier jour, peu importe). Il n'aura jamais une bonne opinion de toi. Si vous vous concentrez sur l'accomplissement des tâches qui vous sont assignées, sur la résolution des problèmes de manière efficace et élégante, et sur l'avancement de vos compétences techniques - vous vous améliorerez - alors en fin de compte, vous êtes le gagnant - indépendamment de ce que pense votre patron.
Le travail d'Ashton était une recette pour l'échec non pas parce que son code n'était pas utilisé, mais parce que le travail ne lui procurait aucun avantage pratique autre que la sécurité dans la hiérarchie de Maslow. At-il appris de nouvelles compétences? Non. Son travail lui a-t-il permis d'être créatif? Non. Cela lui a-t-il valu le respect? Non.
Étant donné qu'il s'agit de votre première position, il vous offrira la plupart de ces propriétés par défaut. Vous aurez vos premières expériences de programmation professionnelle, vous aurez de nouveaux défis à la fois techniques et non techniques. Mais il arrivera un moment où vous deviendrez trop grand pour la position ou cela vous dépassera, et vous devez vous améliorer continuellement pour ne pas être pris au dépourvu par elle.
Encore une chose, si Ashton va mesurer sa propre valeur simplement en fonction du nombre de personnes utilisant son code, je lui suggère de rejoindre un club de fidélisation. Le seul bonheur durable dans la vie est celui que nous créons pour nous-mêmes. Vivre strictement selon l'opinion des autres sur nous produit des êtres humains tragiques et inauthentiques.