La recherche constante d’exemples de code est-elle le signe d’un mauvais développeur? [fermé]

Je suis un étudiant CS avec plusieurs années d'expérience en C et C ++. Depuis quelques années, je travaille constamment avec Java / Objective C pour le développement d'applications. Je suis maintenant passé au développement Web et je me concentre principalement sur le ruby ​​on. rails et je me suis rendu compte que (comme dans le développement d'applications, vraiment), je me référais trop à un autre code. Je recherche constamment la fonctionnalité de Google pour de nombreuses choses que j'imagine que je devrais être capable de faire à partir de zéro, ce qui m'a vraiment fait perdre un peu confiance en moi.

Les fondamentaux ne sont pas un problème, je n'aime pas utiliser cela à titre d'exemple, mais je peux parcourir le javabat en java / python lors d'un sprint - ce n'est évidemment pas un accomplissement et ce que je veux dire, c'est que j'ai une base solide pour les fondamentaux Je pense?

Je sais ce que je dois utiliser généralement mais la syntaxe de référence est constante. J'aimerais avoir des conseils et des suggestions à ce sujet, car cela m’a beaucoup empêché de chercher du travail dans ce domaine même si je termine mon diplôme. Ma principale raison de poser des questions n’est pas vraiment sur l’emploi, mais plutôt sur le fait que je ne veux pas être le seul à un hackathon à ne pas modifier le code sans escale et rester assis avec 20 onglets Google / github ouverts, et je me suis abstenu d’assister à tout. en raison d'un léger manque de confiance ...

Une personne est-elle un mauvais développeur en recherchant constamment des exemples de code pour des tâches complexes à modérées?

Copier-coller à l'aveuglette: mauvais.

Recherchez de la documentation, lisez des exemples de code pour mieux comprendre: bien.

Je préférerais travailler avec quelqu'un qui surveille les choses tout le temps et s'assure que tout fonctionne comme prévu plutôt que quelqu'un qui a trop confiance en lui et qui pense tout savoir mais ne le sait pas. Mais le pire, c’est quelqu'un qui ne se soucie pas de comprendre comment les choses se passent et qui copie simplement le code du Web (sans critique).

Si vous codez vos solutions de manière maintenable et COMPRENEZ réellement ce que vous copiez / collez / modifiez, alors il n'y a pas de problème.

Je meurs à l'intérieur chaque fois que je demande à un développeur senior pourquoi il a fait quoi et la réponse est "je ne sais pas, j'ai copié-collé le code et cela a fonctionné à ce moment-là".

Comme pour la programmation de la documentation API , la recherche d’exemples de code est un signe non pas d’un mauvais programmeur, mais de celui qui manque de fluidité ...

... Ici, je parle de fluence. Être capable non seulement de quelque chose, mais couramment.

Savez-vous ce que c'est que de parler couramment? C'est à ce moment-là que, pour quelqu'un qui vous regarde, il semble que vous codiez au fur et à mesure que vous tapez ...

• ... Comme si le bon code découlait simplement de vos doigts vers l'écran. Comme si vous ne vérifiiez pas la documentation, les tutoriels et les manuels de l'API. En fait, vous les vérifiez tous, mais c'est invisible parce que tout est dans votre tête. Vous avez toutes les connaissances dont vous avez besoin directement dans votre cerveau - chargées, chargées et prêtes à être utilisées.

... C'est la connaissance courante. C'est quand cela vous prend une minute pour faire ce qui prend un débutant une heure. Ça vaut vraiment la peine. Ça sent la victoire.

... et la pratique est pour moi le seul moyen fiable d'acquérir la fluidité.

Il existe une théorie de l'apprentissage appelée cycle de Kolb (d'après la personne qui l'a décrite). Les entrées de ce cycle sont:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Différentes personnes aiment commencer à différents endroits du cycle. Il est donc tout à fait possible d’apprendre en recherchant des échantillons (la phase d’observation réflexive), puis en passant de ces échantillons à une vue d’ensemble via l’abstraction.

D'autres personnes apprendront de différentes manières: certaines personnes aiment commencer par essayer (c'est-à-dire par expérimenter), puis par réfléchir à ce qui a bien fonctionné ou non. Le fait est que ce ne sont que différentes façons de s'attaquer au problème de l'apprentissage: aucune d'entre elles n'est incorrecte.

Divulgation complète - Je suis une personne âgée qui a été formée à un système pré-Internet différent disponible au travail. J'ai observé les compétences des jeunes développeurs se détériorer progressivement, principalement parce qu'ils ne conservaient pas les informations ou ne comprenaient pas la solution qu'ils avaient récupérée sur Internet. J'ai constaté que le niveau de compétence qu'une personne possédait après une ou deux années d'expérience, il y a 20 ans, correspond maintenant à celui qu'une personne possède après cinq à sept années d'expérience. (Oui, c’est une observation personnelle, mais j’ai beaucoup embauché, je n’ai aucune donnée statistique à ce sujet et, oui, je suis parfois vieux et grincheux, prenez cette affirmation avec un grain de sel. Et restez en dehors de ma cour. )

Regarder tout est inefficace en termes de temps. C'est aussi un symptôme de quelqu'un qui n'a pas beaucoup de connaissances approfondies. Les personnes ayant une connaissance approfondie peuvent écrire du code plus rapidement que celles qui ne savent pas comment résoudre un problème sans chercher. Il vaut donc la peine d'apprendre à gérer plus de choses sans avoir à chercher continuellement.

Maintenant, je ne dis pas que vous ne devriez jamais regarder les choses, mais que vous devriez apprendre à conserver les connaissances et ne plus avoir besoin que de regarder les choses que vous utilisez rarement ou lorsque vous rencontrez un problème, un langage ou un paradigme véritablement nouveau. Et je ne dis pas que vous ne devriez pas lire pour suivre les nouvelles solutions, les nouveaux outils et les nouveaux langages.

Mon véritable souci avec les développeurs qui recherchent trop souvent le fait qu’un trop grand nombre d’entre eux (pas nécessairement vous) ne développent jamais les compétences analytiques nécessaires pour comprendre les problèmes qu’ils rencontrent et les solutions nécessaires. Lisez combien de questions il y a où la personne met dans le message d'erreur qu'il ou elle ne comprend pas clairement, mais qui devrait être assez clair pour quiconque opérant au niveau professionnel. Ou ceux où la personne dit, "ça ne marche pas, pourquoi?" sans référence au message d'erreur ou à la façon dont il ne fonctionne pas et le code est syntaxiquement correct. Ou ceux qui reçoivent un morceau de code qui devrait fonctionner,

Donc, si vous recherchez des éléments qui font partie de la fonctionnalité principale du (des) langage (par exemple, SQL doit inclure SQL si vous accédez à des bases de données) que vous utilisez depuis plus de six mois, je suppose que vous recherchez également beaucoup. Si vous recherchez des fonctionnalités avancées, en particulier celles que vous utilisez rarement, vous vous en sortez bien.

Mais comment apprendre à retenir plus d'informations? D'abord, comprenez pourquoi le code a été rompu. Même si quelqu'un vous donne une solution de travail, si vous ne voyez pas pourquoi cela a fonctionné et que ce n'est pas le vôtre, alors demandez. Si vous ne comprenez pas le message d'erreur, demandez ce qu'il signifie et essayez de le résoudre vous-même.

Et ne jamais couper et coller une solution que vous ne comprenez pas. En fait, ne pas couper et coller du tout. Si vous souhaitez conserver des informations, vous devez les saisir. En fait, écrire physiquement le code vous-même vous aide à l'apprendre. C'est une technique d'apprentissage bien connue.

Pratiquez-vous à généraliser votre compréhension du code. J'ai vu des gens poser des questions similaires encore et encore au fil du temps parce qu'ils ne comprenaient pas que la solution apportée au problème ABC il y a un mois était la même que celle proposée pour le nouveau problème DEF.

Ainsi, lorsque vous avez effectué une recherche, prenez le temps de réfléchir aux types de problèmes qu’il serait bon de résoudre et rédigez vous-même des notes à ce sujet. Ensuite, lorsque vous avez un problème à résoudre, vérifiez d’abord vos propres notes pour voir si vous avez déjà noté une technique possible. Si vous évaluez plusieurs façons de résoudre un problème, prenez des notes sur le type de problème, les solutions possibles que vous avez examinées et les avantages et inconvénients de chacune d’elles. Encore une fois, la prise de notes aide à consolider les connaissances dans votre cerveau, vous avez déjà votre propre processus de pensée en termes de pour et de contre, et vous n'avez pas à le refaire (ou du moins pas aussi profondément, vous pouvez toujours plus de techniques possibles) pour le prochain problème similaire.

Et pour décider quoi apprendre ensuite, approfondissez l'une de vos technologies principales avant de vous lancer dans l'apprentissage des 30 premiers jours d'une autre technologie (cela suppose que vous disposiez de suffisamment de connaissances pour effectuer votre travail, si vous en avez besoin. utilisez 6 technologies - commencez par les notions de base avant d’approfondir). Ensuite, allez et venez, apprenez de nouvelles choses, au niveau de base, apprenez quelque chose de plus en profondeur, puis apprenez plus de nouvelles technologies au niveau de base. Si vous faites cela au fil du temps, vous constaterez que votre niveau de base de ce que vous voulez d'une nouvelle technologie est beaucoup plus profond, car vous comprenez des questions plus complexes à poser à ce sujet.

Une autre façon d'apprendre à conserver les connaissances consiste à l'enseigner à quelqu'un d'autre. Répondez à des questions telles que celle-ci, présentez des sujets de formation à votre équipe, faites des présentations dans vos groupes d'utilisateurs locaux, écrivez des entrées de blog et aidez-nous à maintenir un wiki d'informations dans votre entreprise pour aider d'autres développeurs.

Rechercher des exemples de code n'est pas un signe de mauvais développeur. On a rarement besoin d'aussi peu de choses pour se souvenir avec précision de toutes les interfaces dont ils ont besoin. Il est donc naturel de regarder les choses et les exemples de code sont généralement la référence la plus facile à utiliser.

Ce que vous ne devriez pas faire, c'est copier-coller des exemples, car ils y travaillent. Ils doivent donc travailler ici aussi, sans comprendre comment ils fonctionnent. Cela conduit généralement à beaucoup de morceaux inutiles qui ont été copiés accidentellement avec un résultat difficile à maintenir car si vous ne saviez pas comment ça marche quand vous l'écrivez, vous ne le saurez pas six mois plus tard et ne pourrez pas répare le.

Mais tant que vous comprenez le code que vous copiez à partir d'un exemple, c'est un moyen valable pour faire le travail plus rapidement, et c'est généralement une bonne chose.

Ces réponses sont plutôt bonnes. Mais vous souffrez d'un problème beaucoup plus profond que le copier / coller ou le manque de "compétences".

La comparaison est mortelle. Plus vous vous comparez à d'autres personnes et laissez leur talent affecter votre perception de vous-même, plus vous vous ratatinez et mourrez à l'intérieur. Vous n'allez pas à des hackathons parce que vous craignez que les gens ne voient à quel point vous êtes sans talent. Et la seule raison pour laquelle vous pensez que vous n'êtes pas doué, c'est parce que vous vous comparez à des pirates informatiques qui peuvent extraire plus de code à partir de rien, plus rapidement.

Même si les "lignes de code à la minute" étaient un bon indicateur pour mesurer les compétences, vous devez accepter le fait qu'il y aura toujours de meilleurs développeurs que vous . Et c'est bien de montrer aux autres que vous manquez d'habileté.

Vous n'avez pas besoin d'être aussi bon ni meilleur que quiconque. Vous devez vous contenter du fait que vous manquerez toujours d'une manière ou d'une autre et que vous apprenez constamment. Si vous ne pouvez pas être heureux d'être un développeur inférieur, vous ne serez jamais heureux.

Une dernière chose: votre peur du rejet de la part de personnes que vous considérez comme "supérieures" est exactement ce qui vous empêche de côtoyer de meilleurs développeurs et d’en tirer des enseignements. Donc, votre peur vous empêche de grandir, ce qui maintient votre peur. Ce qui vous empêche de grandir. Voir le cycle? Vous devez briser le cycle quelque part.

Je pense que tout dépend de la façon dont fonctionne votre esprit. Ma mémoire pue, alors je préfère de loin saisir un code aussi proche de ce que je veux que possible et le retravailler pour qu'il fasse le nouveau travail. Cela sert d'exemple et de rappel de tout ce que je dois faire. Par exemple, j'utilise SQL simple depuis 20 ans, mais je ne me souviens jamais de la présentation d'une instruction SELECT ou UPDATE. (Je pense qu'on a besoin de parenthèses, mais je ne me souviens plus lequel.) D'un autre côté, quelques petites choses dont je me souvienne; Je peux combiner une implémentation Java Iterator les yeux fermés.

La plupart du code que je copie est le mien, mais je copie certainement d'autres quand j'apprends quelque chose de nouveau.

Je ne sais pas pour les hackathons. Ils peuvent s’appuyer sur un sous-ensemble de programmeurs possédant des mémoires photographiques. Je voudrais essayer et voir. Si vous ressemblez à un idiot qui vous dérange, vous ne devriez pas programmer.

Je vous exhorte à comprendre, à fond, tout le code que vous copiez et modifiez, mais, jusqu'à ce que je lise certaines des réponses, il ne m'est jamais venu à l'esprit que quelqu'un pourrait copier sans comprendre. (Il me semble apprendre constamment de nouveaux vices sur ce site ...)

... je me suis rendu compte que ... je fais trop référence à un autre code. Je recherche constamment des fonctionnalités dans Google pour de nombreuses choses que j'imagine que je devrais être capable de faire à partir de zéro, ce qui m'a un peu affaibli la confiance.

Alors arrête. Dirigez-vous dans l'autre sens pendant un moment. Mettez tout en œuvre vous-même, même si vous savez que vous pouvez trouver exactement ce dont vous avez besoin en beaucoup moins de temps.

Ce qui est arrivé, c’est que votre muscle de résolution de problèmes (nom latin gluteus mojo ) s’est atrophié du fait de sa désuétude et vous évitez maintenant de l’utiliser car vous savez à quel point il est faible. Vous devez commencer à développer et à tonifier ce muscle comme si vous travailliez sur votre biceps au gymnase. Commencez avec des répétitions élevées et une faible résistance - beaucoup de problèmes faciles. Au fur et à mesure que vous développez de la confiance, passez à des problèmes plus longs et plus difficiles.

Vous sentirez progressivement votre retour au travail et votre besoin de faire confiance à Google diminuera. Continuez à exercer ce muscle, cependant, et assurez-vous de ne pas retomber dans vos vieilles habitudes. Relevez le défi de résoudre un problème en premier et ensuite seulement chercher d'autres solutions. Parfois, vous constaterez que d'autres ont trouvé un meilleur moyen de faire la même chose, d'autres fois, vous décidez que votre propre solution est meilleure.

Une personne est-elle un mauvais développeur en recherchant constamment des exemples de code pour des tâches complexes à modérées?

Une personne qui est incapable de faire quelque chose sans trouver d'exemples est un mauvais développeur. Le truc, c'est que vous ne saurez pas si vous êtes capable ou pas avant d'essayer.

Vous êtes jeune et vous avez travaillé avec beaucoup de langages de programmation. Je suppose que vous comprenez probablement les nouvelles langues plus rapidement que les anciennes. Vous n'avez toujours pas passé suffisamment de temps dans une seule langue pour une application suffisamment grande pour développer votre aisance.

Êtes-vous à la recherche de solutions globales comme le processus complet de connexion d'une grille Web à une table de base de données ou une partie plus petite comme le formatage de la chaîne de connexions (je dois la rechercher presque chaque fois depuis que j'écris environ quatre par an. )?

Vous serez toujours à la recherche de références à la syntaxe de différentes lignes de code ou de fonctions. Plus vous programmez, plus vous rencontrez de défis, d’environnements différents et de changements de langue. Si vous avez besoin d'un tutoriel complet à chaque fois que vous faites quelque chose, vous avez un problème.

J'avais un professeur qui disait qu'il détestait faire des tests en essayant de conserver un tas d'informations que vous aviez fourrées la veille au soir parce que vous en oubliez quand même beaucoup après. Il est préférable de connaître vos ressources et de pouvoir les utiliser correctement pour rechercher des informations que vous ne connaissez pas. J'aime appliquer un principe similaire à tout ce que je fais, y compris au travail.

Je pense que vos outils les plus importants sont vos ressources, dans la mesure où vous les utilisez correctement. Ainsi, lorsque j'écris du code, je vais aussi loin que je peux avec mes connaissances actuelles, puis je fais des recherches en demandant à d'autres programmeurs ou en faisant une recherche sur Internet, afin de mieux comprendre la solution appropriée. Les connaissances se construiront avec le temps et après un certain temps, vous saurez naturellement et comprendrez mieux les compétences. Je suis constamment à la recherche de nouvelles informations, que j'ai réellement besoin d'informations ou non, et je peux honnêtement dire que j'apprends quelque chose de nouveau chaque jour.

Si vous comprenez le problème que vous essayez de résoudre et comment vous voulez le résoudre, rechercher la syntaxe correcte n’est pas très grave à mon avis.

J'ai obtenu mon diplôme il y a environ deux ans et j'ai été jeté aux loups quand j'ai eu mon travail. J'ai dû apprendre, maintenir et mettre à niveau une application volumineuse écrite dans une langue que je n'avais jamais touchée auparavant. Je recevais un rapport de bogue, parcourais le code et découvrais comment je voulais le réparer, puis je devais google des exemples sur la façon de faire les choses que je voulais dans cette langue.

Si vous faites avancer les choses et que vous le comprenez suffisamment pour ne pas produire un roulement inutile, alors vous êtes probablement OK.

Copier-coller pur et non critique, comme indiqué à plusieurs reprises dans ces réponses, est mauvais. Mais tout est écrit à partir de zéro. S'il ne s'agit pas d'un composant essentiel au cœur de votre entreprise, recherchez d'abord une bibliothèque ou un extrait de code. L'exception à la recherche d'un extrait serait que le problème est très simple, vous avez une idée très claire de la procédure à suivre et, si vous n'utilisez pas de bibliothèque, vous n'aurez probablement pas besoin de faire autre chose.

Je sais personnellement que si j'écris quelque chose de commun, je risque d'avoir quelques bugs subtils et peut-être un ou deux bugs moins subtils sans beaucoup de tests. Je cherche donc une solution similaire, la modifie et la teste pour gagner du temps sur les tests et le développement. En fin de compte, je suis responsable de la livraison d'un produit qui fonctionne, qui est extensible, qui respecte le budget ou qui ne respecte pas le délai imparti. La réutilisation du code et des bibliothèques est un bon pas vers cet objectif.

Je pense que la lecture d’exemples de code, et rien que la lecture du code source de ce que d’autres personnes ont développé, est le meilleur moyen d’améliorer vos compétences. Je pense vraiment que cela ouvre des portes dans votre cerveau qui n’auraient pas été ouvertes autrement.

Si vous imaginez une solution A et que quelqu'un d'autre imagine une solution B, lorsque vous partagez vos solutions, vous pouvez réaliser la solution C qui peut même être meilleure que A ou B.

Je pense qu'il existe plusieurs niveaux de maîtrise du développement logiciel. Justement, car il existe également de nombreux niveaux de maîtrise de la documentation de développement logiciel . Franchement, de nos jours, les systèmes sont des ordres de grandeur plus complexes que lorsque j'ai commencé à programmer des ordinateurs au milieu des années 1980.

Ensuite, vous deviez savoir ce que vous vouliez que l'ordinateur fasse et vous aviez une documentation de 6 pouces d'épaisseur vous expliquant comment l'ordinateur faisait certaines choses plus élémentaires. Pour mettre ce que vous vouliez sous une forme pouvant être prise par l'ordinateur, il suffisait de connaître le contenu des index de ces livres et d'un langage de programmation (ou deux). Après avoir appris quatre ou cinq langues, les autres ne sont que des dialectes.

Aujourd'hui, cette tâche nécessite de connaître un langage, un système, un paradigme, un modèle de programmation et au moins un jeu d'API, qui sont tous des cibles mouvantes.

Donc, une personne avec un certain niveau de connaissances de base qui pose des questions n’est pas un bon type de programmeur. Il est le meilleur type de programmeur, étant donné les environnements d’aujourd’hui et le désintérêt des entreprises telles que Microsoft, qui n’appliquent en réalité aucune sorte de rigueur à leur propre documentation fondamentale. La plupart de leurs contenus sont des références auto-référentielles et de très mauvais exemples de code. (Deux exemples sont "Windows Installer" et l’API permettant de créer des fichiers vidéo WMV.)

Parce que Microsoft, Google et, dans une moindre mesure, Apple, comptent tous sur "la communauté" pour combler cette lacune très réelle, poser des questions n'est pas seulement important, mais essentiel. Et être une personne à qui on peut poser des questions et qui peut donner des réponses et des commentaires concrets dans le contexte actuel est tout aussi essentielle. C'est pourquoi des sites tels que les sites stackexchange.com sont aussi utiles qu'ils le sont.

Alors posez des questions (demandez intelligemment!) Pour des échantillons et respectez les personnes qui fournissent les réponses, et cela ne sera pas perçu comme un signe de "mauvais développeur".

Et encore une chose: fournir de mauvais échantillons est vraiment le signe d’un mauvais développeur. Cela facilite la détection des mauvais développeurs, mais gomme également les recherches sur Google. Si vous manquez de confiance en des exemples de code simples, simples et spécifiques, ne les donnez pas.

Et, s'il vous plaît, ne vous moquez pas de ceux qui le demandent.

Il me semble que le problème pour vous réside moins dans la compréhension de ce que vous référencez, mais davantage avec des problèmes de facilité et de mémoire. Si cela sape votre confiance, alors oui, c'est un problème - mais on peut certainement y remédier!

Pour moi, ce genre de défis se pose dans de nombreux aspects de ma vie. Par exemple, pour pouvoir bien jouer un morceau de musique, je dois développer mon indépendance par rapport aux partitions que je reçois - comment pouvez-vous vraiment sentir la musique si votre nez est toujours enfoui dans votre livret? Parfois, si j'ai le temps, je vais mémoriser le morceau entier de musique - même si ce n'est pas nécessaire pour mon concert. Pourquoi? Une fois les partitions supprimées, il est beaucoup plus facile pour moi de me concentrer sur les aspects les plus difficiles et les plus généraux de la musique dont j'ai besoin pour bien jouer, et il est beaucoup plus facile pour moi d'entrer dans cette incroyable zone de création musicale pure. Je trouve donc que cela en vaut souvent la peine.

Mon expérience avec la programmation a été similaire. Je pense que les clés sont:

1. pratiquer la langue - tapez-la, lancez-la, parlez-la si cela vous aide; faites-le à plusieurs reprises.
2. construisez votre installation - utilisez la même fonctionnalité ou le même motif dans différentes situations; mettre ensemble des fonctionnalités; faire des programmes.
3. Laissez suffisamment de temps entre les répétitions pour vous assurer que les choses se retrouvent vraiment dans votre mémoire à long terme.

Ces principes semblent s’appliquer lors de l’apprentissage d’une langue quelconque! Voir Comment se souvenir de nouveaux mots, par exemple. La méthode Pimsleur fonctionne également comme ceci.

J'ai découvert que presque tous les principes, la syntaxe et les bibliothèques communes du langage et des technologies que j'utilise régulièrement peuvent être entièrement mémorisés grâce à ces clés. Malgré cela, je parcours constamment Internet pour trouver des exemples et de la sagesse! Mais ce point, je cherche à valider le problème que je cherche à résoudre, les différentes approches qui ont été adoptées, des outils qui peuvent aider, et la consultation pour les bibliothèques moins fréquemment utilisées. C'est un type de recherche très différent de celui que j'utilise lorsque j'apprends pour la première fois une langue et que je suis plongé dans des tutoriels et des manuels.

D'après votre récit, voici quelques obstacles particuliers que vous pourriez rencontrer.

1. Si vous vous débattez avec la syntaxe, vous ne vous exercerez peut-être pas suffisamment. Cela est particulièrement vrai si vous copiez et collez directement dans votre code, au lieu de développer la répétition et - puis-je dire? - la mémoire musculaire qui vous aidera à devenir vraiment bon. Pour contrer cela, développez simplement des exercices et de la discipline, en vous concentrant sur la répétition et le temps, qui amélioreront votre équipement dans les domaines de votre choix. Suggestions:
   • Ecrivez un programme simple dans la même langue une fois par jour, tous les jours.
   • Tapez des exemples au lieu de les copier et les coller.
2. Si vous avez du mal à trouver des solutions à des problèmes de taille moyenne, votre expérience de la construction risque de ne pas être suffisante. Essayez ces:
   • Commencez un projet de taille moyenne dans une technologie ou une langue dans laquelle vous voulez réussir. Ou essayez-vous à une fonctionnalité plus chunk sur un projet open source qui vous intéresse. Entaillez-vous un peu tous les jours. (N'oubliez pas que lorsque vous partez pour ces projets plus importants, allez-y brique après brique. N'essayez pas de tout construire en même temps!)
   • Utilisez la même nouvelle fonctionnalité sur quatre jours consécutifs, dans quatre contextes différents.
   • Relevez le défi de coder quelque chose avec le navigateur Web désactivé!
   • En fait, prenez des notes sur les choses que vous apprenez. Synthétisez ce que vous apprenez et notez vos observations. (En fait, écrire des choses et me forcer à exprimer quelque chose avec mes propres mots m'aide beaucoup.)
   • Rédigez des réponses et vérifiez-les pour les questions StackOverflow sur la technologie que vous absorbez. (Cela a souvent l'avantage de vous donner un peu de réputation pendant que vous apprenez. :-))
3. Vous avez peut-être trop dispersé votre pratique. Vous semblez travailler dans plusieurs langues. Cela présente de nombreux avantages, mais présente toutefois l’inconvénient de diluer votre expérience. Si vous passez du temps dans cinq langues différentes, vous en mémoriserez moins que si vous passez le même temps dans une seule langue. Pire encore, il existe de nombreux liens apparentés entre différentes langues (était-ce sinon si, elsif ou elif ??) pour vous faire trébucher. Pour contrer cela, accentuez votre concentration. Choisissez une chose à apprendre et apprenez-le froid. Ensuite, passons à la chose suivante.

Je pense que si vous vous concentrez sur la conception de code modéré, votre efficacité et votre productivité augmenteront. Il faut probablement plus de temps pour rechercher le code, le lire / le comprendre, le copier dans votre source, le modifier en conséquence, etc.

Si vous le proposez vous-même, il est probablement plus adapté à votre situation spécifique et, au bout d'un moment, ces solutions vous parviendront plus rapidement que de les rechercher.

La façon dont je vois les choses, c’est que c’est comme si vous vouliez un deuxième avis sur une certaine solution, vous regardez donc comment d’autres (sur Internet) le font. Si vous vous trouvez trop en vouloir ou en vouloir trop, considérez cela comme interroger un collègue sur ce qu’il pense d’une solution. Si vous posez une question à votre collègue toutes les 15 minutes, il / elle sera probablement ennuyé (e). Par conséquent, vous poserez moins de questions et tenterez de le résoudre vous-même.

Visualisez ceci lorsque vous souhaitez rechercher des informations sur Internet.

La meilleure façon d'apprendre ce que vous ne savez pas: google it! Je pense que vous avez raison sur la plupart des développeurs. Mettez le complexe d'infériorité dans votre sac à dos et entrez-y l'esprit ouvert.

N'ayez pas peur de poser des questions, faites des recherches sur Google, essayez et échouez. Tout cela en fait partie.

Le développement de logiciels dans un contexte d'entreprise nécessite une grande quantité de réutilisation de code. Pourquoi réécrire une fonction / méthode si une API existe déjà et est largement utilisée? Ce sera probablement aussi efficace que tout ce que vous écrivez et prendra moins de temps.

Bien entendu, réussir dans le développement de logiciels nécessite également une pause du clavier afin de pouvoir lire et comprendre ce qui se passe réellement. Prenez n'importe quel framework web. Vous devez savoir ce qui se passe en dessous pour comprendre le code que vous écrivez, mais vous n’aurez probablement jamais à écrire vous-même un framework Web.

Il vous suffit d'écrire du code qui tire parti du type de framework (par exemple, un framework basé sur des composants nécessite un certain style) et cela provient de la compréhension d'une image plus grande. Apprenez la plus grande image et tout ira bien.

Il ressort clairement des réponses déjà données qu'il n'y a rien de mal à rechercher votre problème au lieu de coder à l'aveuglette. Mais la question qui n'a pas été abordée, parce que vous ne l'avez pas posée directement, est la suivante: pourquoi vous sentez-vous si peu sécurisé - et que pouvez-vous faire à ce sujet? Après tout, beaucoup de gens cherchent leur chemin sur Google et ont beaucoup de confiance en eux (même ceux qui ne devraient pas ...)

Alors que faire? Peut-être n’avez-vous besoin que de quelques centaines de tapes dans le dos, que vous venez de recevoir et que vous pouvez maintenant coder en toute confiance. Mais si cela ne fonctionne pas, je vous suggère de vous pencher sur les tests automatisés et le développement piloté par les tests. Rien ne dit "bien fait" comme un "Tous les tests passés" de votre suite de tests: Lorsque vous y arrivez, vous savez que vous avez bien fait les choses.

Vous devriez également essayer de vous mettre au défi un peu: vous dites que vous recherchez toujours la syntaxe que vous connaissez déjà; alors forcez-vous à écrire du code sans rechercher la syntaxe, et vous découvrirez (bientôt, sinon immédiatement) que vous vous en sortez bien.

Les développeurs ne naissent pas «grands», mais la grandeur ne vient pas automatiquement avec l'expérience. Inversement, le manque d'expérience ne rend pas un développeur «mauvais». La différence entre un grand développeur et un mauvais développeur ne réside pas dans sa connaissance du domaine, mais dans sa méthodologie. La marque distinctive d'un grand développeur est qu'il code consciemment. En d'autres termes, un bon développeur sait toujours pourquoi il fait quelque chose. Du point de vue de l'éthique personnelle, cela nécessite courage et intégrité intellectuels.

Il est si important de prendre un peu de temps et de bien comprendre les bases, des choses plus complexes qui s’appuient assez bien sur cela. S'il n'y a aucune base pour comprendre la langue et ce qui se passe dans les coulisses, coder sera simplement du piratage…

Donc, lire des livres avec des exemples et y faire référence est une mauvaise programmation, voilà le contexte de votre question. Bien que peu de gens documentent leur API, il ne nous reste plus qu'un livre.

J'ignore quelles sont les raisons pour lesquelles vous avez posé cette question. Vous pourrez peut-être y répondre vous-même après avoir lu ma situation car je me réfère à de nombreux exemples de code.

Je n'ai jamais eu la chance d'aller à l'université car j'étais dans la rue à 16 ans. J'ai été en mesure, à 24 ans, d'étudier dans un collège par correspondance et d'obtenir des certifications de vendeur en tant que SCJP, SCJD, SCBCD et SCWCD. Je dois admettre que j'ai parfois eu des difficultés et que je devais me connecter pour obtenir des exemples. Sans le savoir, à ce moment-là, j'avais une tumeur au cerveau qui se développait dans ma tête (en 2010, elle avait la taille d'une orange). Après mes 5 chirurgies cérébrales, 6 semaines combinent chimiothérapie / radiothérapie et 10 mois de chimio, je continue à programmer avec des sites codés à la main et lisibles à partir de mon profil.

Oui, j'ai besoin de beaucoup d'exemples de code maintenant avec des dommages au cerveau, alors est-ce que ça fait de moi un mauvais programmeur?

Alors je vois que vous avez mentionné que vous allez à un hackathon. Je suis allé à quelques-uns au cours de la dernière année (plus de 15) et j'ai remarqué qu'ils sont parfaits pour apprendre. Et par excellent pour apprendre, je veux dire apprendre à ne plus jamais coder de la sorte. J'essaie surtout de faire quelque chose de nouveau à chaque hackathon auquel je participe pour apprendre de nouvelles choses. Comme il y a une énorme contrainte de temps, vous vous contentez de copier-coller tout le code que vous pouvez trouver et cela vous mordra dans le cul lorsque vous le testerez.

Cependant, de bonnes choses en ressortent, vous: A) APPRENEZ tant au cours des tests de bogues (pleurez aussi énormément) B) Sachez ne plus jamais coder comme ça et apprenez de meilleures pratiques de codage. De plus, lors de hackathons, vous rencontrerez des personnes qui peuvent vous apprendre autant de choses nouvelles que vous ne saviez pas et vous ferez des choses que vous ne ferez jamais à l'école.

Donc, ce que je dis, c'est que copier-coller est mauvais, et vous ne saurez rien, et le temps que vous avez enregistré par copier-coller vous piquera plus tard lors du test de bogue et vous n'avez aucune idée de ce que vous avez même écrit, il est 8 heures, et sont alimentés avec toute la caféine. Mais, je pense que tant que vous testerez le code de votre code, vous devrez apprendre tout ce que vous avez copié auparavant.

Eh bien, je ne me considère pas comme un bon programmeur. Mais ce que je fais est simple. Si je ne sais pas comment faire quelque chose, je regarde un code / exemple sur Internet. Puis, après l'avoir lu, j'essaie de le réécrire, de l'optimiser et d'utiliser les éléments qui conviennent le mieux au code que je veux.

Remarque: lire du code sur Internet ne fait pas de vous un mauvais développeur. Il est toujours bon de regarder comment les autres le font et vous apprendrez toujours quelque chose. Mais ensuite, le copier aveuglément n'est pas bon.

Si un développeur / étudiant va dire .. Wikipédia .. pour copier / coller du code dans son projet, il essaie simplement de le "faire fonctionner", alors la seule compétence que cette personne est en train de développer est "Comment google". Il pourrait y avoir un processus d’osmose, mais pas un tas. (Vous ne croiriez pas combien de personnes font cela dans les cours du collège)

CEPENDANT, si vous analysez le code d’autres personnes et pensez vraiment à ce qui se passe dans le code lui-même, cela ne fait pas de la personne un mauvais développeur. Cela en fait un développeur déterminé et indique probablement un style d'apprentissage plus tactile ou visuel. J'apprends par exemple très bien. Si quelqu'un me dit quelque chose ou essaie de l'expliquer, je lui demande généralement de me montrer ce dont il parle.

Regarder, analyser et apprendre à partir du code en fait un bon développeur au fil du temps , car ils lisent et apprennent dans la langue qu'ils utilisent.

Je dis souvent en plaisantant que je connais les tenants et aboutissants des langages informatiques par rapport à ma langue maternelle anglaise. Ce qui pose la question; "Voulez-vous m'expliquer cela à Java plz?"

Je pense que c'est un peu comme jouer aux échecs. Nous vérifions les pièces individuellement et déterminons où elles peuvent se déplacer conformément aux règles. Nous devons ensuite procéder à cette vérification consciente pendant un certain temps, jusqu'à ce que le subconscient se connecte, révélant ainsi des motifs et des séquences inspirées.

Avec la programmation, il peut y avoir plus de morceaux et de règles, je suis souvent en train de trébucher avec la syntaxe et collé à des bugs qui prennent une éternité à trouver en suivant "les règles", mais finalement le subconscient va entrer en jeu. Quand il reste assez longtemps, je peux lire de retour parfois et s’émerveiller de ce qu’il peut faire