Olhando para a minha carreira e vida como programador, havia várias maneiras diferentes de melhorar minhas habilidades de programação - ler código, escrever código, ler livros, ouvir podcasts, assistir a screencasts e muito mais.

Minha pergunta é: Qual foi a coisa mais eficaz que você fez que melhorou suas habilidades de programação? O que você recomendaria para outras pessoas que desejam melhorar?

Espero respostas variadas aqui e nenhuma resposta única "tamanho único" - eu gostaria de saber o que funcionou para pessoas diferentes.

Em nenhuma ordem específica ...

• Trabalhar com pessoas muito mais inteligentes que eu

• Sempre ouvindo o que os outros têm a dizer, independentemente de serem juniores, intermediários, seniores ou guru. cargo não significa nada.

• Aprender outras estruturas / idiomas e ver como eles fazem as coisas, e comparar isso com coisas que eu já conheço

• Lendo sobre padrões, práticas recomendadas e examinando minhas coisas antigas e aplicando esses padrões sempre que necessário

• Programação em par

• Discordando de tudo o que Joel diz. ;)

Decidir TO ser um 'Jack-of-all-trades'

Bem no início de minha carreira, eu era especialista em um banco de dados e linguagem de programação específicos. Infelizmente, esse banco de dados em particular perdeu as 'guerras do banco de dados' e descobri que minhas opções de carreira eram ... limitadas. Depois disso, conscientemente decidi que nunca mais me deixaria encaixotar dessa maneira. Então, estudei tudo o que pude ter: Windows, Unix, C, C ++, Java, C #, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL, etc. Quaisquer que sejam as ferramentas e tecnologias novas ou incomuns, eu tornou-se o 'go-to-guy' - "Pergunte a Craig, se ele não souber, ele aprenderá". Como resultado, trabalhei em todos os tipos de projetos, desde sistemas embarcados para telemetria ambiental até sistemas de comando e controle para defesa antimísseis.

O único problema que já tive foi com empresas que insistem em me colocar em uma especialidade, quando minha especialidade é ser generalista. [EDIT: Também conhecido como Polymath ou Renaissance Man ou multi-especialista. ]

Algo a ter em mente ... qual é a meia-vida do conhecimento em alta tecnologia? Ele acompanha a Lei de Moore: metade de tudo que você sabe ficará obsoleta em 18 a 24 meses. Um especialista que escolhe a disciplina errada pode ser facilmente prejudicado pela pressão da tecnologia; um generalista só precisa adicionar mais algumas habilidades e lembrar as lições do passado ao aplicá-las.

Eu sempre pensei em mim como um programador bem bacana. Então, um novo cara, chamado Aaron, foi contratado para a nossa equipe. Aaron era obviamente muito melhor que eu na maioria das áreas. Ele era mais novo que eu também. Ele me fez perceber que eu realmente não havia melhorado muito nos últimos anos. Eu era um hacker ad-hoc, e um medíocre nisso.

Isso me alertou para tentar conscientemente melhorar a mim mesmo e, principalmente, a qualidade do código que escrevo.

Aaron me levou a aprender muitas coisas. Ele me ensinou como a maior parte do código que escrevo terá que ser mantida e estendida por pelo menos vários anos; portanto, devo escrever o código com isso em mente. Eu deveria escrever testes automáticos para o meu código. Aaron estava sempre falando sobre como eu nunca deveria parar na primeira versão de trabalho, mas refatorar e refinar até que o código seja elegante. Eu descobri que as linguagens e ferramentas que eu estava usando tinham muito espaço para melhorias.

A coisa mais importante que aprendi com Aaron foi nunca parar de aprender.

Depois de alguns anos, Aaron deixou a empresa. Eu me senti vazio. Os últimos anos com ele me elevaram a novos níveis de habilidade, e eu percebi que agora era muito melhor do que o resto da equipe. Eles ainda estavam escrevendo códigos ruins e cometendo os mesmos erros de antes. Eu tentei ensiná-los, mas eles não tinham interesse em aprender. Na verdade, eles ficaram irritados por alguém ser tão arrogante em dizer quais erros estavam cometendo.

Então, alguns meses depois, deixei a empresa também. Mudei-me para uma empresa menor, com uma equipe muito talentosa. Todo mundo lá queria aprender mais, e eu adorei.

Estou feliz por conhecer Aaron. Sem ele, eu provavelmente ainda estaria trabalhando na velha empresa com a velha gangue, indo a lugar nenhum e pensando demais em mim.

Duas coisas:

1. Leia o código escrito por pessoas diferentes.
2. Escreva documentação para o código escrito por outras pessoas.

Escrever código é extremamente fácil; qualquer outra pessoa que eu conheça pode fazer isso. Mas ler o código de outra pessoa e descobrir o que ele faz era um mundo totalmente novo para mim.

Vá à academia regularmente.

Sério, meu cérebro funciona muito melhor quando estou em forma. Os problemas se tornam mais fáceis e menos impressionantes, a brincadeira é muito menos tentadora e o trabalho passo a passo não parece uma tarefa tão árdua.

Programação. Trabalhando em projetos interessantes. Não há nada como entrar e trabalhar nas coisas. Especialmente sob pressão. Eu sempre digo a quem me pergunta como programar - basta encontrar um projeto interessante (mesmo que você precise inventar) e trabalhar nele.

Tomei um emprego de meio período como professor de CS na minha universidade. Isso realmente obriga a entender algo em um nível completamente diferente quando você precisa explicá-lo a outra pessoa.

1. Sou um grande fã do sistema "aprenda uma linguagem de programação todos os anos". Um ano dá a você tempo suficiente para superar o viés "ok, eu conheço a sintaxe, então agora conheço o idioma" e obriga você a ir um pouco mais longe e entender o que é benéfico nesse idioma e programar em um estilo nativo para esse idioma (com o que quero dizer, você não acaba escrevendo aplicativos java usando a sintaxe Ruby). Cada idioma mudará a maneira como você pensa sobre programação - eu sabia usar a recursão, mas pensar em recursão não aconteceu até que eu tenha uma aula de prólogo (imagino que uma linguagem funcional como o ML tenha o mesmo efeito).

2. Inicie um projeto Pet. Minha equação pessoal para um bom projeto para animais de estimação é que algo que você tem experiência com + algo que você não faz = aplicativo que você acharia útil. Por exemplo, o Migratr (meu próprio projeto com cafeína de fim de semana que se tornou em andamento) começou como "Eu sei c #, mas nunca codifiquei contra uma API da Web. E quero mover todas as minhas fotos para o Zooomr". Poderia ter sido tão facilmente "Eu já codifiquei contra APIs da Web antes, mas não sei C #"

A publicação do seu projeto de estimação é uma experiência educacional incrível por si só. De repente, tudo o que praticamente ninguém ensina, mas todo mundo deveria saber (para mim, estava configurando seu próprio sistema de teste, tirando o máximo proveito dos sistemas de controle de versão, como acelerar o ritmo quando ninguém mais está definindo seus prazos, como interagir com o seu usuários e como saber quando dizer "não" para apresentar solicitações), tudo isso borbulha para a superfície e obriga a auto-educar em um nível que você não era antes - pelo menos não lendo ociosamente guerras de fogo no dzone sobre o prós / contras da maneira "foo" vs "bar" de fazer as coisas.

Fazer essas duas coisas cobre as duas extremidades do espectro. Aprender um novo idioma fará de você um codificador melhor. O projeto pet fará de você um desenvolvedor melhor: P

Me ensinou a montar. Fiz isso em um chip 6502 antigo quando eu tinha 13 anos? 14? Há muito tempo. Mas não consigo pensar em nada que melhore seu desenvolvimento mais do que descer ao nível de bits.

A montagem de aprendizado fornece uma visão da maneira como os computadores pensam em um nível fundamentalmente mais baixo, e a elegância nesse nível é surpreendente ... não há movimentos desperdiçados, nem 'descarte' de dados. O desenvolvimento nesse nível ensinará a você eficiência e aprimorará seu pensamento crítico e suas habilidades lógicas. Também irá curá-lo de quaisquer hábitos desleixados que você tenha com bastante rapidez!

O chip 65xx tinha três registros (o acumulador, X e Y) e nenhuma instrução no nível da máquina para multiplicar ou dividir. Lembro-me de codificar uma rotina para calcular o dano da batalha, folhear o livro e de repente perceber que teria que escrever minha própria biblioteca de matemática. Passei algumas semanas rabiscando 1 e 0 em todo o meu caderno, tentando descobrir o que 'dividir' e 'casas decimais' realmente significavam.

Estudei C ++, pascal, .NET, muitos outros desde então ... mas nenhum deles me ensinou tanto, me intrigou tanto ou me deixou com a sensação de 'uau' que a montagem no meu antigo comodato fez .

Olhando para as coisas antigas que escrevi e percebendo o quanto elas eram ruins.

Ler

• livros, não apenas sites
• para auto-aperfeiçoamento, não apenas para o projeto mais recente
• sobre como melhorar seu comércio, não apenas sobre a tecnologia mais recente
• leia o código, não apenas você está trabalhando.

Apenas desenvolva o apetite pela leitura.

Programação.

Sério, existem livros, existem katas de codificação, existem sites como este, mas acredito que a melhor maneira de melhorar como desenvolvedor é trabalhar em projetos reais, com clientes inconstantes e reais, com requisitos reais e em constante mudança, com engenharia real problemas Não há substituto para a experiência.

Eu acho que a coisa mais importante que você pode fazer é fazer um esforço consciente para melhorar. Não existe uma única bala de prata; você precisa continuar procurando novas fontes de informação, novas experiências e mais prática.

E a segunda coisa mais importante, pense no que está fazendo, por que está fazendo e como pode fazê-lo melhor. A mesma coisa com os projetos anteriores. Veja o que você fez e como você pode fazê-lo de maneira diferente agora. Pense sobre o que poderia ter sido feito melhor ou onde você ainda poderia melhorar.

Eu vejo dois grandes exemplos disso trabalhando todos os dias. Eu tenho um colega de trabalho que gosta de aprender e quer ser o melhor desenvolvedor que puder. Ele usa qualquer tempo de inatividade para ler blogs, ler livros, discutir técnicas de programação e fazer muitas perguntas. Ele também melhorou muito notavelmente no ano passado. Outro colega faz seu trabalho, e o faz razoavelmente bem. Mas é só isso que ele faz. Ele segue o que sabe, não faz muito esforço para melhorar, não trabalha em nenhum projeto fora dos projetos existentes e, após 4 anos, ele tem exatamente o mesmo conjunto de habilidades e capacidade de programação que tinha quando eu o conheci. ele.

Muitas pessoas sugeriram escrever código. Eu diria que ler o código de outras pessoas é muito mais benéfico.

Programa em pares com pessoas muito diversas e opinativas

As coisas básicas que me ajudaram como programador:

• Aprendeu a digitar com toque.
• Aprendeu a superar a timidez e fazer perguntas.

Digitar para um programador é essencial. Todo mundo teve um colega de trabalho "programador" que digitou usando exatamente dois dedos e teve que procurar no teclado por tudo. Não tem graça. Aprender a digitar dá um grande impulso à sua produtividade como programador.

E se você não perguntar, ninguém vai lhe contar.

Contribuir para / participar de projetos de código aberto foi de longe a maior coisa para mim.

Você pode ler todos os livros, códigos e projetos de código aberto que desejar, mas precisa entender o aspecto do usuário final do desenvolvimento de software. Você precisa sair da câmara de eco. Então, abordarei alguns pontos não técnicos que ajudarão sua carreira técnica.

1. Afaste-se do teclado e interaja com o usuário final e veja, através de seus olhos, como eles usam o software. Os usuários finais geralmente não são técnicos; portanto, eles veem o software como um trabalho mágico, enquanto você vê o software como um conjunto lógico de etapas. Os dois mundos são completamente diferentes. Então, o que parece fácil e lógico para você pode parecer enigmático e intimidador para os outros.

2. Teste, teste, teste. Muitos dos softwares que vi em grandes empresas usam casos de teste. Inferno, eles usam JUnit, xUnit e todas as outras linguagens de teste de unidade por aí. Mas o problema que eu vi é que a maioria dos programadores nunca vê como é o software deles em Produção. Aprenda como os usuários (ou sistemas, se estes são trabalhos em lotes) interagem com seu aplicativo, biblioteca ou interface para descobrir que tipo de informação repugnante eles lançam nele. Isso ajudará você a gerar bons casos de teste e parará de supor que seu programa sempre receberá o conjunto correto de dados.

Esquema Aprendido.

Escrevendo código e muito.

Aprendendo expressões regulares.

Competindo em concursos do TopCoder Algorithm .

Faça o possível: crie seu próprio projeto, seus marcos, seus recursos, dependências, requisitos e plano de teste. Isso forçará você não apenas a melhorar suas habilidades de programação para operar dentro de parâmetros específicos, mas também servirá para destacar exatamente onde você mais precisa melhorar. Faça atualizações regulares sobre o seu progresso, seja através de um blog ou atualizações formais do projeto, para que você possa ver exatamente onde esteve e para onde espera ir.

Larguei o meu último emprego.

Eu acho que questionar constantemente o que você está fazendo é a maior coisa. Nunca pense que seu código é perfeito, sempre se esforce para melhorá-lo.

Parece que eu tive 2 ou 3 vezes quando pensei que meu código era perfeito, então percebi que tinha um longo caminho a percorrer.

Acho que o mais importante foi quando comecei a ver meu próprio código como consumido por outros programadores e não por uma máquina. É fácil escrever código que sua máquina pode processar, mas é difícil escrever código SECO e compreensível.

E não quero apenas entender "O que essa linha faz", quero dizer trivial descobrir "Como essa classe se encaixa com todas as outras classes", ao mesmo tempo em que torna a interface das classes tão bem formada que é praticamente impossível abusar disso.

Eles dizem que 70% do bom código é verificação e manipulação de erros. Quando comecei a programar dessa maneira, meu código ficou muito melhor. Pensar no que pode dar errado e lidar com isso imediatamente fez uma enorme diferença. Ele se sente como fazendo tudo o que a verificação é apenas ficar no caminho de obter o código instalado e funcionando, mas diminui o tempo do início ao fim por um fator de 2 a 4.

Quem são essas pessoas "eles" e onde eles "vivem"?

Minha habilidade de codificação melhorou bastante quando comecei a pensar antes de implementar algo como documentar isso .

"Coisa" aqui deve ter toda a granularidade possível. Do método ao produto inteiro. Por exemplo, no nível do método, impede a adição de um método na API que não se encaixa ou não é claro antes de realmente ser gravado. E se eu realmente precisar implementar um método que não possa documentar (facilmente), é um sinal de que há um problema de design em algum lugar ...

Automaticamente, a atitude " se não posso explicar, não escrevo " filtra o código incorreto e, inversamente, quando eu sei como documentar uma coisa corretamente, torna-se mais simples e mais limpa de implementar.

Aprenda e pratique constantemente o que aprende.

Por meio de:

1. Projetos pessoais: Desde que comecei a programar, tenho feito projetos pessoais. Desde pequenos jogos, processamento de imagem, esteganografia, implementação de especificações de tipo de arquivo, implementação de vários protocolos a partir do zero ou implementação de vários programas ao longo do tempo.

2. Lendo livros: Decidi ler e acompanhar vários livros no meu tempo livre. Existem muitos livros bem escritos por especialistas, aguardando para serem lidos. A profundidade que você pode obter de um livro é incomparável, por exemplo, lendo várias postagens no fórum.

Esta é geralmente a minha ordem cronológica de aprender qualquer nova tecnologia:

1. Leia regularmente bons blogs (Atwood, Martin Fowler, etc.), Mantenha-se atualizado com as novidades da tecnologia, Siga coisas sobre novas tecnologias interessantes. Essas etapas me permitem decidir se encontro algo interessante para explorar ainda mais.

2. Leia o livro certo ou qualquer outro recurso para aprender para o seu nível (por exemplo, para iniciantes, se você quiser aprender padrões de design, sugiro 'Head First Design Patterns'). Eu também tenho preferências específicas para livros .

3. Lance um ou dois projetos de brinquedos usando o que aprendi. Não me preocupo com a utilidade do projeto. Minha intenção é apenas explorar meu aprendizado. (por exemplo, um projeto de calculadora para OOP seria bom)

4. Eu veria se eu poderia usar as coisas no trabalho . (por exemplo, embora não usemos o subversion no trabalho, eu o uso como meu repositório local, usei o Ruby para uma tarefa que, de outra forma, seria muito monótona e demorada)

5. Esta é a melhor parte que acho que a maioria das pessoas perde. Sessões de compartilhamento de conhecimento. Dê uma ou duas sessões aos colegas da equipe, por exemplo. Acredito que o ensino é uma das melhores maneiras de realmente aprender a tecnologia. Garanto que seu nível de entendimento da tecnologia se tornará múltiplo, independentemente de o público entender ou não. :-)

Corte em algum projeto de código aberto por alguns meses; quanto maior, melhor. Quando você está interagindo com pessoas altamente opinativas e geograficamente diversas que não o conhecem, você não pode deixar de aprender com seus erros muito mais rapidamente - acho que é um certo fator de constrangimento. Além disso, se você identificar uma ou duas pessoas realmente inteligentes, poderá coletar informações valiosas, se não um conhecimento puro.