Os programadores séniores aconselham sempre a utilizar livros como uma boa ideia? [fechadas]

Você vai se deparar com programadores como este em toda a sua carreira. Não há nada de errado com experimentação e aprendizagem por conta própria. Claro que os livros são ótimos. Muitas vezes os exemplos funcionam em um ambiente limpo, mas se você é desenvolvedor de outra empresa, não existe um ambiente limpo (sem a interferência de outras pessoas).

É sempre bom saber como fazer as coisas da maneira "certa", mas as opiniões mudam de ano para ano. Então aprenda o que você puder. Pegue o que puder do desenvolvedor sênior, combine-o com seu conhecimento que você aprende sozinho. Eventualmente, você será um desenvolvedor sênior e estará tirando essas experiências e ensinando desenvolvedores juniores.

Só não seja um idiota sobre isso.

Ele realmente chamou você de estúpido, ou ele apenas depreciou o código? Chamar qualquer coisa estúpida é insensato, mas isso não invalida a sugestão. Acho que o Infestus fez uma sugestão valiosa e, no futuro, você deve considerar seriamente suas sugestões. Ele parece ler muito, e pelo menos nesse caso sua opinião é bem informada. A sincronização é cara e complicada. Sua implementação recomendada é mais eficiente e mais simples que a sua e é garantida que funcione.

He is always trying to give me books to read so that I may "learn" which ways to program.

Isso é gentil da parte dele. Ele está ativamente tentando ajudá-lo, mas você parece estar deixando o seu ego atrapalhar. Não leve críticas ao seu código pessoalmente. Código é barato para produzir e fácil de mudar. Se alguém lhe mostrar uma maneira mais simples de fazer algo, agradeça a eles.

E sim, a leitura fará de você um programador muito melhor. Todos os especialistas que conheci leram extensivamente. Se você não está lendo muito, então você é medíocre na melhor das hipóteses, e em outros cinco anos você pode achar que você não está mais comercializável.

A leitura de um livro não deve ser cego: o autor deve tentar convencê-lo dos méritos de seu / sua abordagem como ele apresenta-lo. É razoável que o idoso lhe aponte um livro explicando sua abordagem preferida, em vez de pedir que ele mesmo o explique: embora ele deva ser capaz de explicar os benefícios de suas preferências sem depender do livro, também é uma duplicação de esforços o autor do livro já fez.

Então, leia o livro, veja o que o autor do livro diz, e se confunde você, ou você gostaria de confirmar a sua compreensão, ou você não concorda, então fale com o seu sênior sobre isso, mas agora você será capaz de ter uma discussão mais produtiva.

Existem três elementos-chave para qualquer relacionamento saudável. Comunicação, honestidade e confiança. Isso conta para todos os relacionamentos, até para relacionamentos de trabalho. Você deve conversar com seu supervisor sobre essas preocupações.

Se você não entender os motivos dele para defender um determinado design, diga a ele que . Diga a ele que você não leu o livro e que gostaria de entender por que a maneira dele de fazer isso é melhor. A chave é que você deve estar tentando entender sua maneira de fazer as coisas.

Acho que você também deve tratar essa pessoa com mais respeito. Em sua cabeça, você está chamando-o de nomes depreciativos e criticando sua abordagem ao que você pensa como "aprendizado". Cuidado com isso. Por outro lado, você disse que ele chamou você de estúpido. Isso não é legal, e você deveria dizer a ele que não é legal chamar alguém de estúpido.

As ideias podem ser estúpidas. Todos nós cometemos erros e sentimos falta de coisas, até os caras mais velhos. Quando há uma falha em um projeto, a melhor pergunta a ser feita é: "Por que você está fazendo isso dessa maneira? Não vai acontecer na situação X, Y, Z? O design B não será melhor?"

Tenha em mente que você está trabalhando neste software com outras pessoas. Essa é uma habilidade difícil de aprender. Não importa se você não está escrevendo nada do zero, sempre há espaço para brilhar, tornando seu código o melhor código possível.

E "melhor" muitas vezes significa legível e compreensível . Nós programadores gastamos muito tempo lendo o código de outras pessoas. Se esse código for claro e legível, isso tornará o código realmente valioso. Uma das maneiras pelas quais aprendemos a escrever um ótimo código é lendo muito código bom. Muitas vezes você encontra códigos muito bons em livros. Então, ler um ou dois bons livros de programação provavelmente fará de você um programador melhor.

Na empresa em que você trabalha, provavelmente é. É isso que eles exigem que você faça.

Este engenheiro da Infestus faz um trabalho muito pobre, educando desenvolvedores juniores, dizendo-lhes "isso está escrito no livro, e é por isso". Ele não é um pregador, ele é um engenheiro, e ele deve ser capaz de decifrá-lo e apresentar os conceitos para que os juniores possam aprender com sua experiência.

Gostaria de encorajá-lo a falar com desenvolvedores experientes em sua empresa, fazer perguntas sobre os prós e contras de diferentes técnicas de programação etc. Isso junto com a leitura de livros e blogs (eu recomendaria Joel on Software - apenas Google, é um must) deve lhe dar uma melhor compreensão.

IMHO, existem 2 aspectos aqui, com os quais você deve lidar separadamente:

• O fato de que o cara é um idiota, chamando você de nomes e coisas assim simplesmente porque ele pode (ele é veterano, você não é, se algum de vocês se queixar do outro, ele terá o benefício da dúvida ) é simplesmente um comportamento parecido com a intimidação e simplesmente ruim.

Tente não se inclinar ao nível dele com isso. Não tente intimidá-lo ou "contar com ele" ao chefe ou qualquer outra coisa. Faça o seu melhor para ignorar esse aspecto do comportamento dele, tendo em mente que isso se torna muito extremo (ou seja, se afetar sua produtividade e tal), você deve fazer algo a respeito.

• O fato de ele estar lhe dizendo que seu código é ruim (e como fazê-lo corretamente). Honestamente do que você descreveu, ignorando o tom do cara, esse aspecto de seu comportamento não é tão ruim assim. Você aprende as coisas muito mais rápido e consegue vê-las no contexto apropriado quando você tem alguém mais experiente corrigindo você e dizendo não apenas o que você fez de errado, mas também como fazê-lo direito (em comparação a aprendê-las sozinho) de experimentos pessoais de tentativa / erro e similares).

Muitas vezes eu fiz alguém corrigir o que eu inicialmente achava ser "meu código perfeito" e fiquei chateado porque o cara estava me dizendo o que fazer só para depois perceber que ele estava certo o tempo todo, minha versão era ruim , foi bom, e graças a Deus ele viu isso! :) Então eu aprendi a suavizar meus impulsos iniciais de "Ei, você não me diga o que fazer, mista!" e, em vez disso, toda vez que alguém me corrige, eu primeiro, objetivamente, verifico novamente o meu código, depois dou uma olhada nele, e me certifico de que ele não esteja certo e sou eu quem está cometendo o erro. Se foi minha culpa, agradeço-lhe a ajuda e tenha certeza de que entendi como a solução dele funciona (em vez de apenas copiar / colar).

E ei, às vezes eu acho que a correção oferecida foi de fato pior do que eu inicialmente fiz, em que ponto eu tento falar tudo isso com o outro cara. Honestamente, eu notei que nada ganha o respeito dos outros por você mais rápido do que quando eles vêem que você pode aceitar ser corrigido quando você cometeu um erro, mas ao mesmo tempo, não tem medo de dizer que você é o único. quem está certo quando você pensa que é assim, dado que você pode provar imediatamente que você baseia sua afirmação em alguma pesquisa real, e não apenas ego.

Nesse ponto, acho que você deveria realmente tentar falar com o cara sobre o que ele propõe, o que você propõe e assim por diante. Mostre a ele o que você pensa, como chegou a uma solução específica e por que você acha que é melhor do que a dele (quando você, honesta e objetivamente, pensa que é). Ou, se você descobrir que a proposta dele é melhor que a sua, diga-lhe isso, expresse seu agradecimento pela ajuda. Isso pode reconstruir algumas pontes queimadas.

Experimente sozinho e aprenda tudo o que puder. Depois de ler livros suficientes, você descobrirá que há vários livros sobre assuntos específicos e eles podem se contradizer. Experimente o que achar melhor e experimente os dois se tiver tempo ou quiser comparar / contrastar.

Lidar com seu chefe é um assunto e uma abordagem totalmente diferentes. Se eu quisesse que alguém fizesse algo da maneira exata em um livro, eu contaria a eles. Isso é só comigo porque eu não associo com os leitores da mente. Seu chefe faz disso um hábito, apenas pergunte se ele recomenda livros ou referências quando você começa um novo projeto.

Não importa o que você faça, não pare de trabalhar em novos projetos. Eu sei que é fácil para todos nós dar dicas sobre como lidar com esta situação e eles podem ou não funcionar, mas você é o único que tem que viver com isso e sofrer a negatividade. Você vai ficar melhor, mas isso geralmente vem de escrever mais código em coisas novas, aprendendo com os sucessos e fracassos.

Seguir os livros às cegas é uma má ideia, mas há uma diferença entre seguir um livro exatamente e segui-lo cegamente .

Quando você está tentando entender coisas em um livro, geralmente é apropriado para segui-lo exatamente no começo, enquanto você está tendo uma ideia do que ele está tentando lhe ensinar. As probabilidades são de que você ainda não entenderá tudo quando terminar - é assim que coisas como essa normalmente acontecem - mas seguir o livro exatamente no começo lhe dará algo para experimentar, enquanto você tenta entender suas perguntas. É bom que você encontre maneiras de não concordar com o que está no livro, mas terá uma compreensão das questões que o livro estava tentando abordar, de modo que, quando chegar a hora de escrever seu próprio código, você possa abordá-los do seu jeito (ou talvez do jeito deles, pelo menos em parte) em vez de simplesmente deixar esses problemas para te morder mais tarde.

Uma outra coisa que não é inerentemente específica para Java, mas é, no entanto, especialmente comum nessa comunidade. Eu acho que posso adivinhar quais livros você está falando, e eles formam uma parte importante do léxico da comunidade Java. Entendê-los e as maneiras como eles descrevem as coisas ajudarão imensamente quando você precisar entender outro código Java que encontrar. Essa é uma habilidade valiosa por si só.

Ler livros e postagens de blog é muito útil na programação. Existem alguns livros, que todos os desenvolvedores devem ler.

No entanto, os livros não são a única fonte para aprender diferentes conceitos e tecnologias de programação. Atualmente, o treinamento baseado em vídeo sob demanda está ficando muito popular. Você pode conferir Pluralsight , que oferece treinamento de alta qualidade para profissionais.

Na verdade, se você ler apenas livros, isso também não ajudará. Além de ler, há outras coisas que precisamos fazer também. Você pode encontrar mais detalhes aqui .

Você deve perguntar a ele o que está errado com seu método. Se ele é incapaz de responder claramente, você pode ter certeza de que é apenas um cara comum que gosta de se sentir superior.

Dito isso, ler livros, artigos e outras fontes é uma boa maneira de crescer como profissional, é claro, quando confirmado pela prática. Então, é bom que você leia esses livros (mesmo aqueles recomendados pela Infestus). No entanto, os livros devem principalmente ampliar sua compreensão sobre o assunto, uma vez que quase sempre haverá outras maneiras de resolver o mesmo problema.

Sobre sua abordagem "siga por mim mesmo", o ponto é: você consegue sustentar seu ponto de vista? Como você prova que sua solução é melhor que qualquer outra? Algumas vezes você pode criar soluções brilhantes por conta própria, mas, quando comparado a outras soluções conhecidas, você deve ser capaz de argumentar o motivo pelo qual o seu é melhor, já que os outros têm a seu favor, pelo menos, os casos de uso. Então, seja criativo e atencioso, mas o mais importante, seja eficiente.

Se eu fosse, você leria esses livros. Isso irá ajudá-lo, dando-lhe mais argumentos, e, ao mesmo tempo, você pode descobrir que o Infestus - talvez - está erroneamente tomando esses livros como argumentos, e ele ainda não foi visto porque ninguém sabe o conteúdo desses livros. Ou você pode achar que ele realmente k

Minha experiência é que, quando se preocupa com a programação de assuntos, a qualidade e a apresentação de informações com explicações adequadas nos livros é uma magnitude melhor do que quando pesquisamos as mesmas informações sobre assuntos na Internet. A Internet muitas vezes carece de explicação, contexto e qualidade adequados.

A quantidade da informação na internet é maior.

Eu pesquisaria os méritos de cada abordagem e chegaria ao seu próprio julgamento. Se você acha que sua abordagem é melhor, converse com a Infestus até que um de vocês convença a outra. Se você não conseguir chegar a um acordo, você pode pedir uma segunda opinião ou apenas aceitar a abordagem da Infestus, dependendo de quão strong você se sente sobre isso.

No caso de singletons, um argumento que você poderia fazer contra a abordagem enum é que enums não podem estender classes. Eu frequentemente escrevo código assim:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Isso não pode ser feito com enums. Como a abordagem enum não funciona em todos os casos, você poderia argumentar que, por uma questão de consistência, ela deve ser evitada mesmo quando não há necessidade de uma cláusula extends .

Alguns outros argumentos que podem ser feitos contra o uso de enums:

• é um hack - está usando enums para algo que não era destinado a
• é confuso para os leitores que não o viram antes

Eu confio strongmente nos livros como fonte de conhecimento - essas são excelentes fundações e acho que a Infestus está certa em consumir quantidades significativas de livros em seu tempo livre, já que eles realmente aceleram suas habilidades. Os livros não são a única fonte de informação que eu acho que você deveria estar consumindo - participe de seu grupo de usuários locais, leve os boletins informativos de tecnologia relevantes para sua caixa de entrada, leia blogs.

No entanto, discordo com a afirmação de que, por estar escrito de uma determinada maneira em um livro, é assim que deve ser feito. Sim livros fornecem ótimos conselhos, e são escritos por especialistas, e revisados por especialistas, mas tendo sido envolvidos em um livro comparativamente simples, posso dizer que normalmente leva pelo menos dois anos para começar a escrever, editar e lançar um livro. . O ritmo da mudança na tecnologia é rápido e o conselho de dois anos atrás pode não ser mais um conselho correto para hoje. Princípios genéricos geralmente resistem ao teste do tempo, mas a otimização de uma atividade específica pode ser invalidada com um novo hardware ou uma nova versão do software.

A sugestão de pedir ao Infestus para passar sugestões com você é excelente - vá embora, leia tudo e volte com um monte de perguntas que você já tentou responder / resolver para si mesmo junto com o seu apoio. evidência para o seu método.

Houve dúvidas sobre se, após 5 anos, você ainda era um junior. Para mim, a principal medida de saber se alguém é júnior não é anos de experiência, mas o quanto eles exigem alimentação por colher. Espero que um desenvolvedor de nível intermediário seja relativamente autossuficiente, um consumidor atento de fontes de conhecimento que possa agir sobre ele e estendê-lo à sua situação. Eles também devem estar no estágio em que podem começar a ensinar juniores porque eles têm uma compreensão firme de seu tópico para que possam explicar as coisas com clareza. A outra competência central é a confiança - se você fez o trabalho, leu o material e produziu algo decente, não tenha medo de defendê-lo em uma quadra de debate, já que um júnior requer validação, um desenvolvedor solicita consenso.

Deixando de lado os modos de trabalho, deixando de lado a realidade do papel de mentor que os desenvolvedores seniores têm, deixando de lado o seu próprio desejo de explorar, deixando de lado o comportamento insultuoso e deixando de lado fetiches para livros ...

Os propósitos de uma revisão de código em uma equipe são 1) validar código e 2) garantir que a pessoa que escreve o código entenda o significado por trás da melhoria do código. Não é o lugar para dizer "mude isso porque Martin Fowler disse isso no livro do GoF". No entanto, é o lugar para dizer "mude isso porque [breve explicação]; há mais detalhes discutindo isso no livro do GoF".

Se o seu desenvolvedor sênior não for, pelo menos simples e sutil, fornecer uma explicação para uma mudança, e insistir em usar o palavreado de "por causa de [book]", ele está sendo um pouco inteligente e um idiota. Como você lida com isso? Mencione isso em uma reunião da equipe, verbalmente, e peça aos seus colegas de equipe que forneçam uma declaração ou duas explicando brevemente a vantagem ou a necessidade da mudança, junto com a referência útil do livro. Certifique-se de agradecer-lhe pela referência do livro.

Encare isso, seu objetivo é apreciar a sugestão de mudança e não ficar desmotivado por sua tarefa ou seu trabalho. Diz-lhe isso. "Eu apreciaria mais a sugestão de mudança se você pudesse descrever brevemente a vantagem ou necessidade da mudança quando você revisa o meu código; como eu estou achando que as referências do seu livro são um pouco desmotivadoras."

Se ele continuar a se recusar a fornecer uma explicação simples com suas referências de livros, se você puder fornecer outro livro ou recurso de igual ou maior notoriedade na indústria com uma opinião diferente e corresponder ao seu cenário, talvez você possa adicionar sua própria referência de livro em seu comentário de revisão em consideração de manter o código original. Faça isso bastante vezes, ele pode recuar. Tenha muito cuidado para que o contra-argumento seja correto e significativamente mais importante; não há problema em permitir que um desenvolvedor sênior esteja errado e ainda tenha o que quiser, isso é algo que aprendi e tenho que aprender.

Eu diria que aprender programação apenas com livros é impossível, mas os bons vão te dar um grande impulso. É como karatê - você não vai conseguir faixa preta apenas lendo sobre isso;) Eu acredito que neste caso partucular, o Sr. Infestus estava se referindo ao "Java Efetivo", de Joshua Bloch. É realmente um ótimo livro sobre desenvolvimento em Java e você definitivamente deveria lê-lo se você ainda não o fez.