Je suis moi-même programmeur, et je me concentre sur le web, le calcul distribué et le traitement des données.
Je considère le web comme la technologie de présentation et de visualisation la plus populaire et nativement multiplateforme ; le calcul distribué comme l’architecture la plus adaptée à la collaboration entre programmes et aux programmes coopératifs ; et le traitement des données comme quelque chose qui exige à la fois des fondamentaux, des compétences, de la cognition, de la vision et des connaissances du domaine. Ainsi, faire du traitement des données améliorera vos fondamentaux, vos compétences, votre cognition, votre vision et vos connaissances du domaine.
Ce ne sont que des paroles en l’air, et plutôt alambiquées avec ça. Mais comprendre des paroles en l’air n’est pas chose si simple pour moi.Je crois que l’amélioration des capacités vient de l’accumulation, il faut donc conserver un enthousiasme durable pour les choses fondamentales.
Je pense que les fondamentaux devraient inclure, maissont loin d’être limités à：
structures de données et algorithmes、
algorithmes、
réseaux (tcp/ip, p2p, http, etc.)、
architecture des ordinateurs et systèmes d'exploitation (gestion de la mémoire, tampons et caches à grande vitesse, threads et concurrence, ressources et contention, cycles CPU, principes de localité, etc.)。
Je crois que les fondamentaux ci-dessus ne peuvent jamais être « maîtrisés », du moins à mon niveau d'intelligence. Par exemple, si vous avez lu Structures de données de Yan Weimin, c'est bien ; si vous avez aussi lu Introduction à l'algorithmique, c'est mieux ; si vous pouvez lire Algorithms de Princeton, vous êtes plutôt bon ; et si vous avez aussi lu quelques articles et réellement tapé du code avec vim, emacs, VS, Eclipse ou Sublime, alors vous devriez pouvoir voir d'un coup d'œil les défauts et les niveaux dans les articles d'algorithmes des blogs du monde entier—alors vous avez une réelle compétence.L'importance de la structure des connaissances et l'expérience de projet s'influencent mutuellement. Pour le même projet et des rôles similaires, en raison de structures de connaissances différentes, l'amélioration et les enseignements tirés diffèrent également, et le bénéfice que cette amélioration apporte au projet suivant ou à des projets plus complexes diffère également. Sur une plus longue période, cette différence devient aussi énorme que valoir 100K contre 1M.
Avoir dix ans d'expérience professionnelle, ou répéter une seule chose pendant dix ans—la différence réside peut-être précisément ici.Je pense que des affirmations comme « maîtriser Java » existent bel et bien, mais ne pas discuter de la JVM, c'est être un. La familiarité avec les classes et les frameworks vient de l'ingénierie et des projets. Vous pouvez bien connaître une API simple, ou chercher à comprendre l'AOP ; l'application peut être très simple ou très complexe. Si les scénarios de performance vous importent, vous devriez alors consciemment prêter attention à la JVM. Mais la JVM est un effort d'ingénierie massif, donc la comprendre est un processus de long terme, ce qui fait de la maîtrise une chose plutôt difficile. Cependant, dans de nombreux scénarios courants — par exemple, BufferedReader, FileChannel, mmap peuvent tous être des options pour l'E/S — lequel est le plus approprié dépend souvent de ce que la machine virtuelle et le système d'exploitation font en dessous. C'est seulement alors que vous pouvez déterminerles meilleures pratiques.Au passage, vous acquerrez aussi une compréhension plus profonde de configurations simples telles que Xss, Xmx et directMemory. En même temps, cela vous aide à voir les limites des langages fondés sur une machine virtuelle. Par exemple, le BlockBuffer de HBase est en soi une conception destinée à améliorer l'efficacité de lecture, mais à cause du tas et des mécanismes de GC de la JVM, cette conception peut pénaliser HBase.
Ce point devrait aussi s'appliquer à C# & CLR.Les personnes qui ont travaillé pendant de nombreuses années croient toutes avoir atteint, ou se targuent d'avoir atteint, un niveau de maîtrise dans un domaine. Certaines l'ont effectivement atteint, mais cela s'accompagne souvent d'une certaine affectation, d'hypocrisie et d'un fort penchant à étaler son intelligence ; elles n'auront pas de véritable discussion avec vous. De telles personnes peuvent exister parmi les amis, les camarades de classe, les collègues et les supérieurs. Un programmeur ne vit pas dans un monde isolé. Outre le maintien de la confiance et de l'humilité dans ses capacités et un effort accru, vous devez aussi vous tenir à vos propres principes et ne pas être influencé par une culture d'entreprise ou une culture de cercle qui n'est pas suffisamment positive. Ce n'est qu'en étant vous-même que vous pourrez mieux traiter la technologie et apporter à votre employeur une meilleure ambiance et une réelle valeur.
Le monde ne manque pas de trolls ; certains trolls sont eux-mêmes tout à fait compétents, même bien plus compétents que vous. C'est simplement leur façon de vivre. Le contrôle émotionnel n'est pas une technique ; plus vous le comprenez à fond, plus vous voyez clairement ce qui est un troll et ce qui relève de la frustration de vouloir que le fer devienne de l'acier (la déception face au manque de progrès de quelqu'un).En matière de pragmatisme technique, il existe toujours un point de vue selon lequel, si vous n'êtes jamais allé aux États-Unis, vous ne devriez pas connaître les Stars and Stripes. Par exemple, toutes les entreprises ou tous les programmeurs n'entreront pas forcément en contact avecbig data, mais dans les temps anciens, avant que les humains puissent voler, ils avaient déjà commencé à explorer et à interpréter la civilisation au moyen de totems et de peintures murales. Ce genre de chose est en fait la puissance de la foi ; pour le dire crûment, c'est là que réside votre intérêt ; pour le dire plus crûment encore, l'opportunité sourit toujours aux esprits préparés. Que vous soyez disposé à vous préparer dépend de votre attitude et de votre compréhension ; que la préparation puisse être utilisée à l'avenir dépend de l'opportunité. La force et la chance sont toutes deux importantes, mais la chance est quelque chose que vous ne pouvez pas contrôler.
Certains enseignants de certaines écoles enseignaient déjà alors que Weibo n'en était encore qu'à sa phase de croissance :informatique sociale. Si vous n'avez pas ce canal de connaissances, vous ne reconnaîtriez probablement pas la signification d'ETL, de l'exploration de données et des index inversés ; vous êtes peut-être déjà à l'aise pour modifier, ajouter et compilerlucene.
Mais peu importe à quel point le savoir est bon, sans pratique il ne s'élèvera pas. Je pense qu'un bon programmeur devrait se concentrer sur le code et l'implémentation, mais devrait abandonner le simple principe de copie, même si la copie suffit à faire le travail dans la plupart des cas. En privé, écrire une portion clé de code une douzaine de fois est vraiment idiot et assez stupide. Mais si chaque façon d'écrire comporte de la réflexion et de la compréhension, et que vous le faites de manière sélective, alors quand vous regardez les patrons de conception et le refactoring—ah, c'est donc vraiment comme ça. Jouer à l'idiot à la manière des fèves de fenouil (comme Kong Yiji, s'obsédant sur des détails insignifiants) n'est pas si insupportable ; au moins vous comprenez ce qui ne va pas et ce qui fait la différence, et cela crée aussi des occasions de s'améliorer en dehors du travail.Beaucoup de gens ont ce point de vue : les Chinois sont mauvais en technologie et ne savent de toute façon pas écrire Hadoop ; gagner de l'argent est le plus important—mais ils se considèrent quand même comme plutôt capables.
En fait, prendre « écrire Hadoop » et « gagner de l'argent » comme critère est en soi trop limité. Dans cette vie, l'argent est bien sûr important, mais que vous écriviez un Hadoop utilisable, un mini système d'exploitation ou une mini machine virtuelle, rien de tout cela ne doit être pris trop au sérieux. La profondeur de compréhension que crée la lecture du code source par rapport à l'implémentation par soi-même est aussi différente que le ciel et la terre. Cette approche du « vieil homme insensé qui déplace des montagnes » consiste davantage à vous forcer à comprendre plus, plus précisément et plus profondément. La plupart des experts de Hadoop, en fait, n'ont fait que lire le code source et sont déjà capables de publier des livres. En réalité, beaucoup d'entreprises exécutent simplement quelques algorithmes de fouille de données très simples et matures ; les ingénieurs d'iQiyi font de la régression linéaire juste assez pour être pratique ; la plupart des entreprises traitent encore des logs. Parfois, penser à un algorithme brillant n'est pas aussi important que de passer à des SSD. Alors, si vous n'avez pas cet environnement ou ces conditions, vous arrêtez simplement de faire de la recherche ? Je ne pense pas.
En ce qui concerne le fait de gagner de l'argent, je pense que tant que votre intérêt se trouve là et que vous faites bien les choses, l'argent viendra de lui-même. Si vos revenus n'augmentent pas, c'est souvent parce que ce que vous faites n'appartient pas à la catégorie des hauts revenus ; écrire des programmes vous rend rarement riche. Pour être honnête, une journée de dépenses d'une escort girl peut représenter plusieurs fois votre salaire, sans parler des revenus de l'escort girl elle-même. Si vous voulez faire la fête dans une boîte de nuit et que vous ne commandez pas deux bouteilles de Louis XIII, les hôtesses pourraient même vous traiter de faux riche. Si vous n'envoyez pas les bouquets de fleurs rouges, bleues ou vertes que vous convoitez, vous auriez trop honte de rentrer avec elle au complexe d'appartements ou à l'hôtel pour discuter d'algorithmes génétiques.
Donc ceux qui discutentd'algorithmes génétiquesavec des escort girls — le patron Wang et l'ingénieur Li — leurs revenus sont encore moins comparables à ceux d'un programmeur.
Ne cherchez donc pas trop délibérément à lier l'écriture de programmes au fait de gagner de l'argent ;cela limitevotre capacité à gagner de l'argent.
Source :http://www.cnblogs.com/foreach-break/p/be_a_real_programmer.html