Evite se tornar um programador “teórico”

Eu encontrei este artigo em várias postagens no SO. Eu me vejo caindo no sexto arquétipo; o "teórico".

Ele define o "teórico" como:

O teórico sabe tudo o que há para saber sobre programação. Ele ou ela pode passar quatro horas lecionando sobre o histórico de uma linguagem de programação obscura ou fornecendo uma prova de como o código que você escreveu não é perfeitamente ideal e pode levar mais três nanossegundos para ser executado. O problema é que o Theoretician não sabe nada sobre desenvolvimento de software. Quando o Theoretician escreve o código, é tão "elegante" que meros mortais não conseguem entendê-lo. Sua técnica favorita é a recursão, e todo bloco de código é ajustado ao máximo, em detrimento da pontualidade e legibilidade.

O teórico também é facilmente distraído. Uma tarefa simples que leva uma hora leva três meses para os teóricos, pois eles decidem que as ferramentas existentes não são suficientes e precisam criar novas ferramentas para criar novas bibliotecas e construir um sistema totalmente novo que atenda aos seus altos padrões. O teórico pode ser transformado em um dos seus melhores jogadores, se você conseguir que ele jogue dentro dos limites do projeto em si e pare de gastar tempo trabalhando no The Ultimate Sorting Algorithm.

Mesmo ao trabalhar no que deveria ser um projeto simples, tenho a tendência de me incomodar ao tentar projetar tudo do zero (isso provavelmente explica por que perdi cerca de 2 anos tentando criar um sistema operacional a partir do zero. Mas até vi que ele foi inútil eventualmente).

O que pode me ajudar a evitar fazer isso? E siga os princípios do KISS?

obrigado

Sendo teórico por natureza, posso dizer-lhe que trabalhar em uma loja Ágil curará rápida e decisivamente todas essas tendências. Em particular, uma operação de programação eXtreme, com programação em pares (idealmente rotacionando frequentemente), desenvolvimento orientado a testes, time boxing e sprints limitados, mostra imediatamente seu trabalho para todos os seus colegas verem e exige que você abra e colabore em minuto a minuto. Essa é uma mudança enorme das tarefas separadas em um ambiente isolado de escritórios, no qual floresce o trabalho no estilo teórico. Requer total honestidade e integridade total, pois todos dependem ativamente de todos os outros continuamente.

Ainda prezo meu olhar no umbigo, mas tenho de o fazer em casa, ou naquelas raras ocasiões em que posso trabalhar em um projeto paralelo que não faz parte do desenvolvimento da linha principal.

1. Tenha objetivos para o que você deveria estar desenvolvendo.

2. Limite essas metas a algo que possa ser entregue em um futuro próximo.

3. Em seguida, concentre-se nesses objetivos, eliminando todas as outras considerações. Sem fundo. Sem história. Sem extensões. Nada geral ou abstrato.

4. Em seguida, reduza-os ainda mais ao mínimo que você puder fazer, que poderá ser entregue. Não é bom. Não é flexível. Não pode ser mantido. Meramente Aceitável.

5. Em seguida, priorize no mínimo absoluto necessário para atingir o mínimo que você pode fazer. O ponto é escolher uma data em cerca de uma semana e avançar nessa data. Se você não pode entregar algo em uma semana. Limitar. Foco. Aparar. Reduzir.

6. Em seguida, elimine o cotão. Você só tem uma semana. Continue cortando.

7. Em seguida, concentre-se apenas em uma implementação reduzida que será feita o mais cedo possível. Idealmente, menos de uma semana, para que você tenha tempo para escrever a documentação.

Eu trabalhei com teóricos. Considero os "extras" uma desculpa para evitar realmente fazer algo que possa ser rotulado como um fracasso.

Fazer - e falhar - é difícil. Falar sobre fazer algo é mais fácil do que fazer algo. Muita pesquisa e pensamento são uma maneira de evitar fazer a coisa errada e depois retrabalhá-la depois de saber que os usuários mentiram.

Basta colocar o código na frente deles. Eles chamarão o código de falha. Acontece. Mas no processo de falha, você aprenderá quais são os requisitos reais. E você aprenderá que eles mentiram.

Não tenho certeza se isso é algo tão ruim de ser. Claramente, você precisa ser produtivo ou não fará seu trabalho, mas ter interesse no campo, ser um estudante da arte, por assim dizer, não é uma coisa ruim.

Eu jogaria com seus pontos fortes, procuraria oportunidades em que seu estilo e preferência sejam uma vantagem.

Para garantir que você permaneça produtivo enquanto se dedica a escrever uma estrutura MVC em Erlang (ou o que achar interessante), talvez você deva marcar seu trabalho mais essotérico para, digamos, uma hora por dia. Durante o resto do dia, concentre-se no trabalho pesado e faça o trabalho. Quando vir algo interessante que o distraia como favorito ou faça uma anotação, mas siga em frente, volte para ele no intervalo de tempo previsto.

Pessoalmente, tenho resmas de URLs que parecem interessantes e também uma pilha de livros da biblioteca. Talvez eu consiga cerca de 10% desses URLs no final, e talvez leia 50% dos livros no final, mas ainda faço o trabalho diário também.

Eu já tive esse problema. Duas técnicas ajudaram:

1. Use a técnica Pomodoro, ou alguma outra técnica de gerenciamento de tempo, em que você define uma sequência de objetivos de muito curto prazo. Quando você precisa descobrir o que pode realizar nos próximos 25 minutos, ele mantém o foco no trabalho útil.
2. Desenvolvimento orientado a teste. Se você precisar escrever um teste concreto antes de escrever qualquer código, isso minimiza o devaneio. (Não há como escrever um teste para "elegante".) Depois de obter algo funcionando, você pode gastar mais tempo do que deveria refatorá-lo, mas pelo menos estará trabalhando em código real e não em um ideal imaginário.

Não se bata demais. É mais fácil conseguir que um teórico se concentre e faça um trabalho útil do que fazer com que as pessoas que não se importam expandam seus horizontes.

Evite stackoverflow.com . Não me interpretem mal - eu sou um grande fã - mas o SO e outros fóruns orientados à programação tornam perfeito o inimigo do bem . Depois de um tempo, você pode começar a sentir que milhares de pessoas inteligentes estão olhando por cima do seu ombro e nada do que você escreve é ​​bom o suficiente. Apenas faça algo funcionar e tente torná-lo compreensível. Você sempre pode revisitar se precisar de melhorias.

Além disso, evite artigos como o que você vinculou. Você realmente acredita que existem dez tipos de programadores? Ou que alguém que você conhece se encaixa inteiramente em exatamente uma das categorias descritas? Artigos como este têm certo apelo porque contêm um pouco de verdade - você pode ver a si mesmo e / ou alguns de seus colegas de trabalho em alguns dos estereótipos. Mas as categorias contêm tanta água quanto os signos astrológicos. Tente da próxima vez que estiver no mixer pós-conferência: "Olá, sou um Code Cowboy! Qual é o seu tipo?"

Isso não quer dizer que sua pergunta não seja válida - se você está pensando demais, é bom aprender como evitar essa tendência. Mas não deixe que essa crítica convença você a se burlar.

Há uma diretriz simples que, quando totalmente descompactada, explica na íntegra como evitar esse cenário.

Faça a coisa mais simples que possa funcionar.

- Kent Beck

Acho que uma maneira de manter a cabeça fora das nuvens é forçar-se a escrever aplicativos reais do começo ao fim, além de escrever suas APIs ou estruturas teóricas. Tente colocar uma caixa de tempo em torno de algo e tente "finalizá-la" nesse período. Escrever estruturas requer uma boa compreensão dos padrões e da arquitetura do projeto, mas descobri que escrever uma aplicação completa dentro de um período fixo de tempo requer habilidades diferentes do que escrever uma estrutura super bem projetada.

Se você deseja concluir um aplicativo, em algum momento você precisa se atualizar e simplesmente fazê-lo. Isso pode exigir sacrifícios nos projetos ou ser forçado a implementar um recurso de uma maneira que você não está satisfeito, devido a algum tipo de restrição. Eu sou como você - inclinado a escrever e reescrever as coisas um milhão de vezes, mas se eu me deparo com tarefas que precisam ser realizadas dentro de um certo período de tempo, acho que escolho minhas batalhas e apenas aperte a tecla coisas mais importantes.

Simples:

1. Seja pragmático .

O lado oposto do teórico (que tem suas vantagens no lado da informação / conhecimento do domínio de programação) é o pragmático.

Aplicar KISS, DRY, SOC e outra maneira de pensar, conforme descrito nesta resposta , significa ser pragmático.

Você também pode aprender a ser pragmático lendo este livro:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Não esqueça que teoria e prática funcionam juntas, não sozinhas. Sem muita prática, seu conhecimento não é nada. Sem muito conhecimento, você não pode melhorar sua prática rapidamente.

Então pratique bastante. E aprende muito. Mas não deixe que um supere o outro.

Nos seus projetos, defina um prazo. Cumpri-lo. Em seguida, pense pragmaticamente sobre como terminar seu projeto antes desse prazo. (leia o livro, realmente) Em seguida, comece a codificar, comece a ler o que você precisa saber, passe da leitura para a codificação e limite ou o tempo de leitura.

Hum ... Talvez talvez tente conseguir um emprego em uma empresa que exija que você escreva aplicativos em uma linha do tempo. Eu diria por mim mesmo que provavelmente estou o mais longe possível de ser um teórico, pelo menos no trabalho. Fazer esse tipo de trabalho tem seu lugar e hora e é importante para se desenvolver. No entanto, embora eu aprecie esse tipo de habilidade, ela não tem lugar no mundo dos negócios, especialmente onde trabalho. Um ambiente de desenvolvimento acelerado, no qual você escreve aplicativos em semanas às vezes e o cliente os quer ontem! Fui abençoado com desenvolvedores incríveis e levou tempo para que todos trabalhassem em equipe.

Eu tinha um cara que era o mais brilhante possível, mas como você, sempre tive que extrair o último pedaço do código dele, mesmo quando estava funcionando bem, até o ponto em que ele começou a escrever controles personalizados que eram essencialmente os iguais aos fornecidos pelo ambiente. Foi tudo muito legal, mas foi um desperdício de tempo quando tivemos que divulgar as coisas a tempo. Muitas vezes, esses projetos paralelos apoiavam a equipe e, eventualmente, ele começou a sentir a pressão dos outros e se formou. Sugiro começar a trabalhar em um ambiente de equipe com outros bons desenvolvedores que precisam lançar produtos. Sempre há tempo para refatorar e refazer as coisas ou escrever o MergeSort mais excitante de todos os tempos; mas às vezes você precisa levar o produto a um ponto em que ele está funcionando e entregá-lo ao cliente.

Não há nada errado em ser um "teórico" no sentido usual da palavra. Ter conhecimento prévio e ser capaz de entender as pesquisas mais recentes sobre CS é uma grande capacidade de se ter, pois é uma mina de ouro de idéias boas e originais.

A "verdadeira questão" aqui é mais aparente na metade posterior do post. Conheça o objetivo específico do projeto e trabalhe para esse fim, não para outro fim. É realmente apenas uma questão de autodisciplina neste caso. Veja a resposta de S. Lott para mais informações sobre isso :).

Redefina sua mente da programação e até da realização de tarefas para a entrega de software funcional. Ele define suas prioridades.

Como conseguir isso é outra história. A melhor maneira é conceber um projeto e seguir todas as etapas para iniciá-lo na produção. Depois disso, você terá uma mentalidade diferente do que antes.

Obrigado por este post. Faz meu trabalho valer ainda mais a pena. Sinto o mesmo tendo uma educação em Arquitetura da Informação trabalhando como Desenvolvedor de Software. Muitas vezes me vejo lutando com "onde mudar as coisas" em vez de "o que mudar". Existem muitas relações, muitas coisas inteligentes e genéricas que levam muito tempo para descobrir como as coisas funcionam.

Então, começo a fazer perguntas e ainda mais perguntas até conhecer COMO e ONDE isso é realmente construído. E deixe-me dizer-lhe - funciona. Quanto mais perguntas um incêndio, menos importante é manter a arquitetura original e, finalmente, voltar ao básico

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Peça ao seu chefe que consiga um mentor e faça o que o mentor diz.

A parte difícil é manter o foco e reconhecer que "ei, vamos reescrever o sistema operacional" não se beneficiará substancialmente com o término da tarefa que você recebeu (e é por isso que um gerente de projeto não o fará).

Peça também ao mentor que revise TODOS os seus projetos antes da codificação e o código real após a codificação. Isso ajudará você a manter o foco no que precisa ser feito.

Tenho a mesma tentação de projetar demais as coisas, e é preciso autodisciplina e organização para superar isso. Ao codificar para outra pessoa, veja como eu faço isso:

1. Ao iniciar uma tarefa discreta, gaste alguns minutos pensando no que é realmente necessário em termos de funcionalidade, qualidade, data de entrega etc.
2. Dedique mais tempo para planejar como fazer isso , dividindo-o em subtarefas, subtarefas, etc., mantendo os objetivos do cliente do código em mente.
3. Estime o tempo de cada item , adicionando até 50% para incógnitas. Se um item demorar mais de quatro horas, divida-o um pouco mais. (Se eu estivesse fazendo projetos na faculdade, usaria uma planilha, mas como consultor de vários clientes, utilizaria um sistema de rastreamento de problemas chamado Redmine.)
4. Mais importante: faça apenas os itens que eu criei .

Claro, as coisas acontecem. Às vezes, acho que preciso fazer mais coisas - então começo do zero. Às vezes, acho que uma tarefa vai demorar muito mais do que eu pensava - comece de novo no 1º. Às vezes, eu sei com antecedência que meu design precisará de mais detalhes posteriormente - por isso, planejo uma subtarefa de nova estimativa onde recomeço em # 1.

Quanto mais eu faço isso, melhor eu fico. A autodisciplina é um músculo mental que se fortalece com o exercício, e também melhoro em estimar quanto tempo as coisas vão levar e em fazer trocas técnicas. E acho útil lembrar uma citação do general Patton: "Um bom plano executado violentamente agora é melhor do que um plano perfeito executado na próxima semana".

Como desenvolvedor solitário, meu fluxo de trabalho combina isso com aspectos do Agile, incluindo um quadro Kanban. Às vezes, uso tangentes, mas tento limitar os desvios a algumas horas por semana, e funciona muito bem.

Se você planeja trabalhar no setor privado, é realmente importante controlar o impulso "teórico". O programador mais brilhante que eu conheço mora no Vale do Silício, mas não tem emprego há anos porque tem uma reputação de fornecer código perfeito tarde demais.