A procura constante de exemplos de código é um sinal de um desenvolvedor ruim? [fechadas]

Eu sou um estudante de CS com vários anos de experiência em C e C ++ e, nos últimos anos, trabalho constantemente com Java / Objective C no desenvolvimento de aplicativos. Agora, mudei para o desenvolvimento web e estou focado principalmente no ruby. rails e cheguei à conclusão de que (como no desenvolvimento de aplicativos, na verdade) faço referência demais a outros códigos. Eu constantemente uso a funcionalidade do Google para muitas coisas que imagino poder fazer do zero e isso realmente quebrou um pouco minha confiança.

Fundamentos básicos não são um problema, eu odeio usar isso como exemplo, mas posso executar o javabat em java / python em um sprint - obviamente não é uma conquista e, mas o que quero dizer é que tenho uma base sólida para os fundamentos Eu acho que?

Eu sei o que preciso usar normalmente, mas faz referência constante à sintaxe. Gostaria de receber alguns conselhos e sugestões sobre isso, pois isso tem me atrasado bastante em termos de procura de trabalho nesse campo, mesmo que eu esteja terminando minha graduação. Meu principal motivo para perguntar não é realmente sobre emprego, mas mais do que eu não quero ser o único cara em um hackathon que não cria códigos ininterruptos e fica sentado com 20 abas do Google / github abertas, e evitei participar de qualquer devido a uma ligeira falta de confiança ...

Uma pessoa é um desenvolvedor ruim, constantemente procurando exemplos de código para tarefas moderadas a complexas?

Copiar e colar às cegas: ruim.

Procure documentação, leia exemplos de código para entender melhor: bom.

Prefiro trabalhar com alguém que procura as coisas o tempo todo e garante que tudo funcione como pretendido do que alguém confiante demais que acha que sabe tudo, mas não sabe. Mas o pior é que alguém que não se incomoda em entender como as coisas funcionam e apenas copia acriticamente o código da Web (e, quando os relatórios de erros começam a chover, fica incapaz de consertar qualquer coisa corretamente).

Se você codifica suas soluções de maneira sustentável e realmente entende o que você copia / cola / modifica, não há problema.

Eu morro por dentro toda vez que faço perguntas a um desenvolvedor sênior sobre por que ele fez o que e a resposta é "Não sei, copio e colo o código e funcionou naquele momento".

Assim como com a habilidade de programar com / sem documentação da API , procurar exemplos de código é um sinal não de um programador ruim, mas de um que não possui fluência ...

... Aqui, eu estou falando sobre fluência. Sobre não ser apenas capaz de algo, mas fluente.

Você sabe o que é ser fluente? É quando, para alguém que olha para você, parece que você codifica enquanto digita ...

• ... Como se o código certo simplesmente fluísse dos seus dedos para a tela. Como se você não conferisse os documentos, tutoriais e manuais da API. Na verdade, você fazer check-los todos, mas isso é invisível porque está tudo na sua cabeça. Você tem todo o conhecimento necessário no seu cérebro - carregado, carregado e pronto para usar.

... Isso é conhecimento fluente. É quando você leva um minuto para fazer o que leva um novato em uma hora. Vale a pena o esforço, realmente. Cheira a vitória.

... e a prática é para mim a única maneira confiável de adquirir fluência.

Existe uma teoria da aprendizagem chamada ciclo de Kolb (em homenagem à pessoa que a descreveu). As entradas neste ciclo são:

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

Pessoas diferentes gostam de começar em lugares diferentes do ciclo. Portanto, é perfeitamente possível estar aprendendo pela procura de amostras (a fase de observação reflexiva), em seguida, trabalhar fora dessas amostras para a grande figura via abstração.

Outras pessoas aprenderão de maneiras diferentes: algumas pessoas gostam de começar tentando (ou seja, com a experimentação) e depois refletir sobre o que deu certo ou errado. O ponto é que essas são apenas maneiras diferentes de atacar o problema de aprender coisas: nenhuma delas está incorreta.

Divulgação completa - Sou uma pessoa idosa treinada em uma pré-Internet diferente, disponível na era do trabalho. Eu assisti as habilidades dos desenvolvedores mais jovens se deteriorarem constantemente devido a eles não reterem informações ou entenderem a solução que eles pegaram da Internet. Observei que o nível de competência que uma pessoa possuía após 1-2 anos de experiência, há 20 anos, agora é o nível de competência que uma pessoa possui após 5-7 anos de experiência. (Sim, é uma observação pessoal, mas fiz muitas contratações, não tenho dados estatísticos sobre o assunto e sim, às vezes sou velho e irritadiço, aceite essa afirmação com um pouco de sal. E fique fora do meu quintal. )

Procurar tudo é ineficiente em termos de tempo. Também é um sintoma de alguém que não tem muita profundidade de conhecimento. Pessoas com conhecimento profundo podem escrever código mais rapidamente do que pessoas que não sabem como resolver um problema sem procurar informações. Portanto, vale a pena aprender a lidar com mais coisas sem ter que procurar continuamente.

Agora não estou dizendo que você nunca deve procurar coisas, estou dizendo que você deve aprender a reter conhecimento e só precisa procurar coisas que usa raramente ou quando encontra um problema, linguagem ou paradigma genuinamente novo. E não estou dizendo que você não deveria estar lendo para acompanhar novas soluções, ferramentas e idiomas.

Minha real preocupação com os desenvolvedores que pesquisam as coisas com muita frequência é que muitos deles (não necessariamente você) nunca desenvolvem as habilidades analíticas para entender os problemas que eles têm e as soluções necessárias. Leia quantas perguntas existem onde a pessoa coloca a mensagem de erro que claramente não entende, mas que deve ser bem clara para quem trabalha no nível profissional. Ou aqueles em que a pessoa diz: "não está funcionando, por quê?" sem referência à mensagem de erro ou como ela não está funcionando e o código está sintaticamente correto. Ou aqueles que recebem um pedaço de código que deve funcionar,

Portanto, se o que você está procurando é algo que faz parte da funcionalidade principal do (s) idioma (s) (BTW, isso deve incluir SQL se você estiver acessando bancos de dados) que você usa há mais de seis meses, suspeito que você também esteja procurando Muito de. Se o que você está procurando são recursos avançados, especialmente aqueles que você pode usar raramente, está indo bem.

Mas como você aprende a reter mais informações? Primeiro entenda por que o código quebrou. Mesmo se alguém lhe der uma solução funcional, se você não entender por que isso funcionou e o seu não, pergunte. Se você não entender a mensagem de erro, pergunte o que significava e tente resolvê-la.

E nunca recorte e cole uma solução que você não entende. De fato, não recorte e cole. Se você deseja reter informações, é necessário digitá-las. Escrever o código fisicamente ajuda você a aprendê-lo. Essa é uma técnica de aprendizado bem conhecida.

Pratique a generalização de sua compreensão do código. Vi pessoas fazendo perguntas semelhantes repetidas vezes ao longo do tempo, porque não entendem que a solução que tiveram um mês atrás para o problema ABC é a mesma solução para o novo problema DEF.

Portanto, quando você tiver pesquisado algo, dedique algum tempo para pensar sobre que tipos de problemas seria bom para resolver e escrever notas para si mesmo. Então, quando você tiver um problema a resolver, verifique primeiro suas próprias anotações para ver se você já notou uma técnica possível. Se você avaliar várias maneiras de resolver um problema, faça anotações sobre o tipo de problema, as possíveis soluções analisadas e os prós e contras de cada uma. Novamente, a anotação está ajudando a solidificar o conhecimento em seu cérebro, você já tem seu próprio processo de pensamento em termos de prós e contras elaborados e não precisa fazer isso novamente (ou pelo menos não com tanta profundidade, você pode procure ainda mais técnicas possíveis) para o próximo problema semelhante.

E ao decidir o que aprender a seguir, aprofundar-se em uma de suas principais tecnologias antes de começar a aprender os primeiros 30 dias em mais uma outra tecnologia (isso pressupõe que você tenha conhecimento suficiente para realmente realizar seu trabalho, se precisar use 6 tecnologias - obtenha o básico das seis primeiras antes de se aprofundar). Depois, vá e volte, aprendendo coisas novas, em um nível básico, aprendendo algo com mais profundidade e, em seguida, aprendendo mais novas tecnologias em um nível básico. Se você fizer isso com o tempo, descobrirá que seu nível básico do que você deseja obter de uma nova tecnologia é muito mais profundo, porque você entende perguntas mais avançadas a serem feitas.

Outra maneira de aprender a reter conhecimento é ensiná-lo a outra pessoa. Responda a perguntas em locais como este, apresente tópicos de treinamento para sua equipe, faça apresentações nos grupos de usuários locais, escreva entradas de blog e ajude a manter um wiki de informações em sua empresa para ajudar outros desenvolvedores.

Procurar exemplos de código não é um sinal de desenvolvedor ruim. Raramente precisamos de tão poucas coisas para lembrar todas as interfaces de que precisam com precisão; portanto, é natural procurar coisas e exemplos de código geralmente são a referência mais fácil de usar.

O que você não deve fazer é copiar e colar exemplos, porque eles trabalham lá, então eles devem trabalhar aqui também, sem entender como eles funcionam. Isso geralmente leva a muitos bits inúteis que foram copiados acidentalmente e o resultado é difícil de manter, porque se você não sabia como funciona quando o escreveu, também não saberá seis meses depois e não poderá consertá-lo.

Mas desde que você entenda o código que está copiando de um exemplo, é uma maneira válida de concluir o trabalho mais rapidamente, e isso geralmente é bom.

Essas respostas são muito boas. Mas você sofre de um problema muito mais profundo do que copiar / colar ou falta de "habilidade".

A comparação é letal. Quanto mais você se comparar com as outras pessoas e permitir que o talento delas afete a maneira como você se vê, mais se encolherá e morrerá por dentro. Você não vai a hackathons por medo de que as pessoas vejam como você não tem talento. E a única razão pela qual você acha que não tem talento é porque se compara aos hackers que conseguem distribuir mais códigos do zero, mais rapidamente.

Mesmo que "Linhas de código por minuto" seja uma boa métrica para medir habilidades, você precisa aceitar o fato de que sempre haverá melhores desenvolvedores por aí do que você . E é ok para mostrar aos outros que lhe falta em habilidade.

Você não precisa ser tão bom quanto, ou melhor do que ninguém. Você precisa se contentar com o fato de que sempre lhe falta de alguma maneira e de que está aprendendo constantemente. Se você não pode ser feliz por ser um desenvolvedor inferior, NUNCA ficará feliz.

Mais uma coisa: o seu medo de rejeição por pessoas que você considera "superiores" é exatamente o que está impedindo que você esfregue os ombros com melhores desenvolvedores e aprenda com eles. Portanto, seu medo impede você de crescer, o que mantém seu medo. O que impede você de crescer. Veja o ciclo? Você tem que quebrar o ciclo em algum lugar.

Eu acho que muito disso depende de como sua mente funciona. Minha memória fede, então prefiro pegar um código o mais próximo possível do que quero e retrabalhá-lo para que ele faça o novo trabalho. Serve como um exemplo e um lembrete de todas as coisas que tenho que fazer. Por exemplo, eu uso SQL simples há 20 anos, mas nunca consigo me lembrar do layout de uma instrução SELECT ou UPDATE. (Eu acho que é preciso parênteses, mas eu não me lembro qual.) Por outro lado, algumas poucas coisas que me lembro; Posso reunir uma implementação do Java Iterator com os olhos fechados.

A maior parte do código que copio é meu, mas certamente copio outros quando estou aprendendo algo novo.

Eu não sei sobre hackathons. Eles podem recorrer a um subconjunto de programadores com memórias fotográficas. Eu tentaria e veria. Se parecer um idiota te incomoda, você não deveria estar programando.

Exortaria você a entender, completamente, todo o código que você copia e modifica, mas, até ler algumas das outras respostas, nunca me ocorreu que alguém pudesse copiar sem entender. (Parece que estou aprendendo novos vícios o tempo todo neste site ...)

... cheguei à conclusão de que ... faço referência demais a outros códigos. Eu pesquiso constantemente a funcionalidade do Google para muitas coisas que imagino que devo fazer do zero e isso realmente quebrou um pouco minha confiança.

Então pare. Siga na outra direção por um tempo. Implemente tudo você mesmo, mesmo que saiba que pode encontrar exatamente o que precisa em muito menos tempo.

O que aconteceu é que o seu músculo que resolve problemas (nome latino gluteus mojo ) se atrofia pelo desuso, e agora você evita usá-lo porque sabe o quão fraco é. Você precisa começar a construir e tonificar esse músculo, assim como trabalhava no bíceps na academia. Comece com altas repetições e baixa resistência - muitos problemas fáceis. À medida que você cria confiança, passe para problemas mais longos e difíceis.

Você sentirá gradualmente seu retorno regressivo e sua necessidade de confiar no Google diminuirá. Continue exercitando esse músculo, no entanto, e certifique-se de não voltar aos seus velhos hábitos. Desafie-se a resolver um problema primeiro e só depois procure outras soluções. Às vezes, você descobrirá que outras pessoas encontraram uma maneira melhor de fazer a mesma coisa; outras vezes, decidirá que sua própria solução é melhor.

Uma pessoa é um desenvolvedor ruim, constantemente procurando exemplos de código para tarefas moderadas a complexas?

Uma pessoa que é incapaz de fazer qualquer coisa sem encontrar exemplos é um péssimo desenvolvedor. A questão é: você não saberá se é capaz ou não até tentar.

Você é jovem e trabalhou com muitas linguagens de programação. Eu acho que você provavelmente entende os novos idiomas mais rapidamente do que os antigos. Você ainda não dedicou tempo suficiente em um único idioma em um aplicativo grande o suficiente para desenvolver fluência.

Você está sempre procurando soluções abrangentes: todo o processo de conexão de uma grade da Web a uma tabela de banco de dados ou uma parte menor, como formatar a cadeia de conexões (eu tenho que procurar isso quase sempre, desde que escrevo cerca de quatro por ano. )?

Você sempre procurará referências à sintaxe de diferentes linhas de código ou funções. Quanto mais você programa, mais desafios e diferentes ambientes e alterações de idioma você se depara. Se você precisar de um tutorial inteiro sempre que fizer algo, terá um problema.

Eu tinha um professor que costumava dizer que ele odiava fazer testes com base na tentativa de reter um monte de informações que você abarrotou na noite anterior, porque você esquece muito disso depois. É melhor conhecer seus recursos e usá-los adequadamente para encontrar as informações que você não conhece. Eu gosto de aplicar um princípio semelhante a tudo o que faço, incluindo o trabalho.

Eu acho que as ferramentas mais importantes que você tem são seus recursos, desde que você os use adequadamente. Portanto, quando estou escrevendo código, chego o mais longe possível do meu conhecimento existente e, em seguida, faço pesquisas perguntando a outros programadores ou pesquisando na Internet, a fim de entender melhor a solução apropriada. O conhecimento aumentará com o tempo e, depois de um tempo, você naturalmente conhecerá e entenderá melhor as habilidades. Estou constantemente pesquisando as coisas, se preciso ou não das informações, e posso dizer honestamente que aprendo algo novo todos os dias.

Se você entende o problema que está tentando resolver e entende como deseja resolvê-lo, procurar a sintaxe correta não é grande coisa na minha opinião.

Eu me formei há cerca de dois anos e fui jogado para os lobos quando consegui meu emprego. Eu tive que aprender, manter e atualizar um aplicativo grande escrito em um idioma que nunca havia tocado antes. Eu recebia um relatório de erro, examinava o código e descobria como eu queria corrigi-lo, e depois tinha no google exemplos de como fazer as coisas que eu queria naquele idioma.

Se você está fazendo as coisas e compreendendo o suficiente para não produzir rotatividade desnecessária, provavelmente está bem.

Copiar e colar acriticamente puro, como indicado muitas vezes nessas respostas, é ruim. Mas também está escrevendo tudo do zero. Se não for um componente crítico essencial para os seus negócios, procure um trecho de biblioteca ou código para fazê-lo primeiro. A exceção para encontrar um trecho seria que o problema é muito simples, você tem uma imagem muito clara de como fazê-lo e se não estiver usando uma biblioteca: é improvável que precise fazer mais alguma coisa.

Eu sei pessoalmente que se escrever algo comum, é provável que eu tenha alguns erros sutis e talvez um ou dois não tão sutis sem muitos testes. Então, procuro uma solução semelhante, modifique e teste para economizar algum tempo em testes e desenvolvimento. Porque, no final, sou responsável por entregar um produto que funcione, seja extensível, esteja dentro ou abaixo do orçamento e atenda aos prazos. Reutilizar códigos e bibliotecas é um bom passo em direção a esse objetivo.

Acho que ler exemplos de código e apenas ler o código-fonte do que outras pessoas desenvolveram em geral é a melhor maneira de melhorar suas habilidades. Eu realmente acho que abre portas em seu cérebro que não teriam sido abertas de outra maneira.

Se você pensa em uma solução A e alguém pensa em uma solução B, quando cada um de vocês compartilha suas soluções, pode perceber a solução C, que pode ser ainda melhor que A ou B.

Eu acho que existem muitos níveis de proficiência em desenvolvimento de software. Só assim, porque também existem muitos níveis de proficiência na documentação de desenvolvimento de software . Francamente, hoje em dia, os sistemas são ordens de magnitude mais complexas do que quando comecei a programar computadores em meados dos anos 80.

Então, você tinha que saber o que queria que o computador fizesse e havia escrito uma documentação de 15 cm de espessura, informando como o computador fazia certas coisas mais básicas. Colocar o que você queria em uma forma que o computador pudesse assumir era uma questão de conhecer o conteúdo dos índices desses livros e uma linguagem de programação (ou duas. Realmente, depois de aprender quatro ou cinco línguas, as outras são apenas dialetos).

Hoje, essa tarefa exige conhecer uma linguagem, conhecer um sistema, conhecer um paradigma, um modelo de programação e pelo menos um conjunto de API, todos os quais são alvos móveis.

Portanto, uma pessoa com um certo nível de conhecimento básico que pergunta por aí não é um bom tipo de programador. Ele é o melhor tipo de programador, considerando os ambientes atuais e as empresas de desinteresse como a Microsoft, na verdade, aplicam qualquer tipo de rigor à documentação de seus fundamentos. A maioria de suas coisas é material de referência auto-referencial e algum código de amostra muito ruim . (Dois casos em questão que encontrei são o "Windows Installer" e as APIs para criar arquivos de filme WMV.)

Como a Microsoft, o Google e, em menor grau, a Apple, todos confiam na "comunidade" para compensar essa deficiência real. Perguntar não é apenas importante, é vital. E ser uma pessoa que pode ser solicitada e que pode dar respostas e feedback sólidos no ambiente atual é igualmente vital. É por isso que sites como o stackexchange.com são tão úteis quanto eles.

Portanto, faça perguntas (peça inteligentemente!) Para obter amostras e respeite as pessoas que fornecem as respostas, e isso não será visto como um sinal de um "desenvolvedor ruim".

E mais uma coisa: fornecer amostras ruins de verdade é o sinal de um desenvolvedor ruim. Isso torna os desenvolvedores ruins mais fáceis de detectar, mas também estimula as pesquisas no Google. Se você não tem confiança em exemplos de código simples, diretos e específicos, não dê a eles.

E, por favor, não zombe daqueles que perguntam.

Parece-me que o problema é menos para entender o que você está referenciando e mais para questões de facilidade e memória. Se está minando sua confiança, então sim, é um problema - mas certamente pode ser resolvido!

Para mim, esses tipos de desafios surgem em muitos aspectos diferentes da minha vida. Por exemplo, para ser bom em tocar uma peça musical, preciso desenvolver minha independência em relação às partituras que recebi - como você pode realmente sentir a música se o nariz ainda estiver enterrado no livreto? Às vezes, se eu tiver tempo, memorizarei toda a música - mesmo que não seja necessária para o meu show. Por quê? Sem as partituras, é muito mais fácil para mim focar nos aspectos mais desafiadores e abrangentes da música que eu preciso para acertar, e é muito mais fácil para mim entrar nessa zona incrível de pura produção musical. Então eu acho que muitas vezes vale a pena o trabalho extra.

Minha experiência com programação tem sido semelhante. Eu acho que as chaves são:

1. pratique o idioma - digite, execute, fale se ajudar; faça isso repetidamente.
2. construa suas instalações - use o mesmo recurso ou padrão em situações diferentes; reunir recursos; faça programas.
3. dê tempo suficiente entre as repetições para garantir que as coisas realmente estejam entrando na sua memória de longo prazo.

Esses princípios parecem se aplicar ao aprender qualquer idioma, na verdade! Veja Como se lembrar de novas palavras, por exemplo. O método Pimsleur também funciona assim.

Descobri que quase todos os princípios, sintaxe e bibliotecas comuns da linguagem e das tecnologias que uso regularmente podem ser completamente memorizados usando essas chaves. Mesmo assim, ainda procuro constantemente na Internet exemplos e sabedoria! Mas, nesse ponto, estou procurando validação do problema que estou tentando resolver, várias abordagens que foram adotadas, ferramentas que podem ajudar e consulta para bibliotecas usadas com menos frequência. É um tipo de pesquisa muito diferente do que eu uso quando estou aprendendo um idioma e aprofundado em tutoriais e manuais.

Na sua história, aqui estão alguns obstáculos específicos que eu acho que você pode estar enfrentando.

1. Se você está enfrentando dificuldades com a sintaxe, talvez não esteja praticando o suficiente. Isso é especialmente verdade se você estiver copiando e colando diretamente no seu código, em vez de desenvolver a repetição e - posso dizer? - memória muscular que o ajudará a ficar realmente bom. Para combater isso, simplesmente desenvolva exercícios e disciplina, concentrando-se na repetição e no tempo, que melhorarão suas instalações nas áreas que você deseja. Sugestões:
   • Escreva um programa simples no mesmo idioma uma vez por dia, todos os dias.
   • Digite exemplos em vez de copiá-los e colá-los.
2. Se você está enfrentando dificuldades na construção de soluções para problemas de tamanho moderado, talvez não esteja obtendo experiência suficiente na construção. Tente esse:
   • Inicie um projeto de tamanho médio em alguma tecnologia ou idioma em que você deseja se aperfeiçoar. Ou experimente um recurso mais robusto em um projeto de código-fonte aberto no qual você esteja interessado. Corte-o um pouco todos os dias. (Lembre-se, quando você estiver buscando esses projetos maiores: vá neles tijolo por tijolo. Não tente construir tudo de uma vez!)
   • Use o mesmo novo recurso em quatro dias consecutivos, em quatro contextos diferentes.
   • Desafie-se a codificar algo com o navegador desligado!
   • Faça anotações sobre o que você está aprendendo. Sintetize o que você está aprendendo e anote suas observações. (Na verdade, escrever as coisas e me forçar a expressar algo com minhas próprias palavras me ajuda muito.)
   • Escreva respostas e verifique-as para perguntas sobre o StackOverflow sobre a tecnologia que você está absorvendo. (Isso geralmente traz o benefício adicional de ganhar um pouco de reputação enquanto você aprende. :-))
3. Você pode estar espalhando sua prática muito pouco. Você parece estar trabalhando em vários idiomas diferentes. Isso tem muitas vantagens, mas tem a desvantagem de diluir sua experiência. Se você estiver gastando tempo trabalhando em cinco idiomas diferentes, memorizará menos do que se estiver gastando o mesmo tempo em um idioma. Pior, existem muitos cognatos não muito parecidos entre diferentes idiomas (foi o que mais, se, elsif ou elif ??) para enganar você. Para combater isso, afie seu foco. Escolha uma coisa para aprender e aprenda a frio. Em seguida, passe para a próxima coisa.

Eu acho que se você se concentrar em criar um código moderado, sua eficiência e produtividade aumentarão. Provavelmente leva mais tempo para procurar código, ler / entender, copiar sua fonte, modificá-lo de acordo, etc.

Se você a criar, provavelmente será mais adaptada à sua situação específica e, depois de um tempo, essas soluções chegarão mais rápido do que procurá-las.

A maneira como vejo isso é que você deseja uma segunda opinião sobre uma determinada solução, e então procura como outras pessoas (na Internet) o fazem. Se você estiver fazendo / desejando muito isso, pense nisso como perguntar a um colega sobre o que ele / ela pensa de uma solução. Se você fizer uma pergunta a seu colega a cada 15 minutos, ele provavelmente ficará aborrecido. Portanto, você fará menos perguntas e tentará fazer isso sozinho.

Visualize isso quando quiser pesquisar as coisas na Internet.

A melhor maneira de aprender o que você não sabe: pesquise no google! Eu sinto que você está no mesmo nível da maioria dos desenvolvedores. Coloque o complexo de inferioridade na sua mochila e entre com a mente aberta.

Não tenha medo de fazer perguntas, pesquisar no Google, tentar e falhar. Tudo faz parte disso.

O desenvolvimento de software em configurações corporativas requer uma boa quantidade de reutilização de código. Por que reescrever uma função / método se uma API já existe e é amplamente usada? Provavelmente será tão eficiente quanto qualquer coisa que você escreva e leve menos tempo.

É claro que ter sucesso no desenvolvimento de software também exige uma pausa do teclado, para que você possa ler e compreender o que realmente está acontecendo. Pegue qualquer estrutura da web. Você deve saber o que está acontecendo por baixo para entender o código que está escrevendo, mas provavelmente nunca precisará escrever uma estrutura da Web do zero.

Você apenas precisa escrever um código que tire proveito do tipo de estrutura (digamos, que uma estrutura baseada em componentes exija um certo estilo) e isso deriva da compreensão do quadro geral. Aprenda a imagem maior e você ficará bem.

É claro pelas respostas já dadas que não há nada errado em pesquisar seu problema, em vez de codificar às cegas. Mas a pergunta que não foi abordada, porque você não a fez diretamente, é por que está se sentindo tão insegura - e o que você pode fazer sobre isso? Afinal, muitas pessoas pesquisam seus problemas e têm muita confiança (mesmo aqueles que não deveriam ...)

Então o que fazer? Talvez você só precise de algumas centenas de tapinhas nas costas, o que você acabou de receber, e agora possa codificar com confiança. Mas se isso não der certo, sugiro que você analise os testes automatizados e o desenvolvimento orientado a testes. Nada diz "bem feito" como um "Todos os testes aprovados" do seu conjunto de testes: quando você chega lá, sabe que fez tudo certo.

Você também deve tentar se desafiar um pouco: você diz que está sempre procurando a sintaxe que você já conhece; então, force-se a escrever um código sem procurar a sintaxe e (em breve, se não imediatamente) descobrirá que você está indo muito bem, afinal.

Os desenvolvedores não nascem “ótimos”, mas a grandeza não vem automaticamente com a experiência. Por outro lado, a falta de experiência não torna um desenvolvedor "ruim". A diferença entre um ótimo desenvolvedor e um desenvolvedor ruim não está no conhecimento do domínio, mas na metodologia. A marca distintiva de um grande desenvolvedor é que ele codifica conscientemente. Em outras palavras, um bom desenvolvedor sempre sabe por que está fazendo alguma coisa. Do ponto de vista da ética pessoal, isso requer coragem e integridade intelectual.

É muito importante levar algum tempo e entender o básico, coisas mais complexas que são construídas sobre isso. Se não houver fundamento na compreensão do idioma e do que está acontecendo nos bastidores, a codificação será simplesmente hacking…

Portanto, ler livros com exemplos e fazer referência a eles é uma programação ruim é o contexto da sua pergunta. Bem, como poucas pessoas documentam sua API, um livro é tudo o que resta.

Não sei quais são as suas razões para fazer essa pergunta. Talvez você possa responder isso depois de ler minha situação, pois me refiro a muitos exemplos de código.

Eu nunca tive a chance de ir para a universidade, pois estava na rua aos 16 anos. De alguma forma, aos 24 anos, eu estava em posição de estudar em uma faculdade de correspondência e fazer certificações de fornecedores como SCJP, SCJD, SCBCD e SCWCD. Devo admitir que às vezes lutei e tive que ficar on-line para obter exemplos. Inconscientemente, embora neste momento eu tivesse um tumor cerebral crescendo na minha cabeça (em 2010 era do tamanho de uma laranja). Após minhas 5 cirurgias cerebrais, 6 semanas combinam quimioterapia / radioterapia e 10 meses de quimioterapia, ainda estou programando com sites codificados escritos à mão que são visíveis no meu perfil.

Sim, eu preciso de muitos exemplos de código agora com danos cerebrais, então isso me torna um programador ruim?

Então eu vejo que você mencionou que está indo para um hackathon. Estive em algumas no ano passado (mais de 15) e notei que elas são ótimas para aprender. E por ótimo aprendizado, quero dizer aprender a nunca mais codificar dessa forma. Eu geralmente tento fazer algo novo a cada hackathon, só para aprender coisas novas. Como há uma enorme restrição de tempo, você confia apenas em copiar e colar todo o código que pode encontrar, e isso chega a te incomodar ao testá-lo.

No entanto, coisas boas surgem disso, você: A) APRENDE muito durante o teste de bugs (também chora muito) B) Saiba que nunca mais codificará assim e aprenderá melhores práticas de codificação. Além disso, em hackathons, você encontrará pessoas que podem ensinar tantas coisas novas que você nunca soube e fará coisas que nunca fará na escola.

Então, o que estou dizendo é que copiar e colar é ruim, e você não aprenderá nada, e o tempo economizado por copiar e colar o morderá mais tarde durante o teste de bugs e você não tem idéia do que escreveu, são oito da manhã, e são abastecidos com toda a cafeína. Mas acho que, desde que você teste seu código com bug, terá que aprender tudo o que copiou antes.

Bem, não me considero um bom programador. Mas o que eu faço é simples. Se não sei fazer algo, na verdade, procuro algum código / exemplo na Internet. Depois de ler, tento reescrevê-lo, otimizá-lo e usar as coisas que melhor se adequam ao código que eu quero.

Nota: Ler código da Internet não faz de você um desenvolvedor ruim. É sempre bom ver como as outras pessoas fazem isso, e você sempre aprenderá alguma coisa. Mas então, copiá-lo às cegas não é bom.

Se um desenvolvedor / aluno diz ... Wikipedia ... para copiar / colar o código em seu projeto, simplesmente tenta fazê-lo "funcionar", então as únicas habilidades que essa pessoa está desenvolvendo é 'Como pesquisar no Google'. Pode haver algum processo de osmose lá, mas não um monte. (Você não acreditaria em quantas pessoas fazem isso nos cursos da faculdade)

NO ENTANTO, se você analisar o código de outras pessoas e realmente pensar no que está acontecendo no próprio código, isso não fará de uma pessoa um desenvolvedor ruim. Isso os torna um desenvolvedor determinado e provavelmente indica um estilo de aprendizado mais tátil ou visual. Eu aprendo pelo exemplo muito bem. Se alguém me diz algo ou tenta me explicar, geralmente peço que me mostrem do que estão falando.

Olhar, analisar e aprender com o código realmente os torna um bom desenvolvedor ao longo do tempo , porque estão lendo e aprendendo no idioma que estão usando.

Costumo brincar que conheço os meandros das linguagens de computador do que meu idioma nativo em inglês. O que implora a pergunta; "Você me explica isso em Java plz?"

Eu acho que é um pouco como jogar xadrez. Verificamos as peças individualmente e traçamos onde elas podem se mover de acordo com as regras, e precisamos passar por essa verificação consciente por um certo período de tempo até que o subconsciente se junte, revelando padrões e sequências inspiradas.

Com a programação, pode haver mais peças e regras, geralmente estou tropeçando com sintaxe e preso a bugs que levam uma eternidade para serem descobertos, passando pelas 'regras', mas eventualmente o subconsciente entra em ação. às vezes volta e se maravilha com o que pode fazer.