Motivar-se a escrever o código depois de criar algo [fechado]

Isso acontece apenas comigo ou isso é familiar para você também?

É assim: você precisa criar algo; um módulo, um recurso, um aplicativo inteiro ... tanto faz. É algo interessante que você nunca fez antes, é desafiador.

Então você começa a pensar como vai fazer isso. Você desenha alguns esboços. Você escreve alguns protótipos para testar suas idéias. Você está juntando peças diferentes para obter uma visão completa.

Você finalmente acaba com um design que gosta, algo simples, claro para todos, fácil manutenção ... o nome dele. Você cobriu todas as bases, pensou em tudo. Você sabe que terá essa classe e esse arquivo e esse esquema de banco de dados. Configure isso aqui, adapte essa outra coisa lá etc.

Mas agora, depois que tudo estiver resolvido, você deverá sentar e escrever o código para ele. E não é mais um desafio .... Estive lá, fiz isso! Escrever o código agora é apenas "formalidades" e faz com que pareça reiterar o que você acabou de terminar.

No meu trabalho anterior, às vezes me safava porque alguém fazia a codificação com base nas minhas especificações, mas no meu novo show eu sou responsável por todo o processo, então eu tenho que fazer isso também (porque sou pago para fazer isso) isto).

Mas tenho um projeto de estimação em que estou trabalhando em casa, depois do trabalho, e sou apenas eu e ninguém está me pagando para fazê-lo. Faço o trabalho criativo e, quando chega a hora de anotá-lo, não me apetece (vamos navegar um pouco na web, ver as novidades no P.SE , no SO etc.).

Eu só quero passar para a próxima coisa desafiadora, e depois para a próxima e a próxima ...

isso acontece com você também? Como você lida com isso?

Como você se convence a escrever o código?

Eu aceito qualquer resposta.

Se o desafio para você é projetar e não implementar, talvez você precise de um fator motivador diferente:

Se é um projeto para animais de estimação (não para o trabalho), estou ansioso para vê-lo ganhar vida, portanto, projetá-lo não é suficiente para mim. Quando você cria seus próprios projetos de animais de estimação, qual é o objetivo? É para algo que você precisa usar? Nesse caso, você pode usar isso como motivação para implementá-lo. Para ver isso funcionar. Para fornecer a funcionalidade que você estava procurando sair dela.

Você planeja disponibilizá-lo para outras pessoas? Um fator motivador pode ser vê-los se beneficiar do produto final. Eles não vão tirar o utilitário dele se estiver apenas no modo de design. E se você planeja comercializá-lo, use o fato de que ninguém pagará pelo seu projeto de estimação enquanto ele estiver preso no modo de design, como um fator motivador.

Quando trabalho por conta própria, adoto uma abordagem mais iterativa do que poderia no trabalho - não me preocupo com todos os detalhes antes de gerar algo. Pode levar mais tempo, mas 1), uma vez que é apenas para mim (ou para alguém que ainda nem sabe que existe de alguma forma), então eu tenho a flexibilidade de experimentar e levar o meu tempo. 2) Passo vários ciclos refatorando e aprendendo maneiras melhores de fazer as coisas. Por minha própria conta, figurativamente falando.

Em última análise, porém, não é a verdadeira satisfação em ver algo surgir do nada? Isso é o que faz para mim. Se isso não for adequado para você, a menos que sua motivação seja o produto final, não sei se entendi por que você deseja trabalhar no projeto de estimação. Se o design é o que mais lhe agrada, e você faz isso no trabalho, parece que já obtém a satisfação que procura.

Você precisa de prototipagem rápida, em casa.

Quando você aplica o mesmo nível de rigor profissional em um projeto pessoal particular, isso resulta facilmente em excesso de engenharia.

É perfeitamente aceitável definir um alto padrão para um projeto pessoal, mas você deve entender que talvez não tenha recursos suficientes (horas de codificação, além das 8 horas diárias de trabalho) para progredir no projeto.

Qual é o objetivo mais essencial no seu projeto de estimação? Para provar a utilidade de uma de suas idéias? Se for esse o caso, reduza o projeto até que ele se torne um projeto de prova de conceito . Em seguida, use prototipagem rápida para que você possa realizar mais com menos tempo de codificação.

Acho que sou só eu, mas tenho o problema oposto. Normalmente, tenho problemas para pensar em todos os detalhes antes de começar a escrever o código e de fato me deparar com os problemas relevantes. Realisticamente, geralmente tenho apenas um design vago na cabeça quando começo a codificar alguma coisa. Meu grande desafio é conseguir pensar em todos os detalhes e ter um design inicial.

Definitivamente, posso me relacionar com isso. Adoro aceitar o desafio de coisas que não encontrei, mas tenho dificuldade em começar a trabalhar em tudo o que já resolvi. A maior coisa que faço é me forçar a sentar com o objetivo de fazer o X funcionar e funcionar. Normalmente, quando começo, acabo me divertindo e fazendo mais do que planejei em primeiro lugar, mas se não forçar um objetivo, ficarei cansado por horas.

Também estou com você no sentido de que isso acontece mais em casa, no trabalho lateral do que no escritório. Não sei se são mais distrações, estar queimado do trabalho ou o que ...

Certamente entendo sua frustração como já passei por isso antes.

Apesar de temer algumas chamas da comunidade, pois sei que essa não é uma ótima abordagem, vou compartilhar minha abordagem para projetos paralelos com você. Observe que esse método funciona para mim e eu o uso em projetos de médio / longo prazo, não o faria por algo pequeno (como geralmente tenho a motivação para finalizá-lo de uma só vez).

Pegue o projeto inteiro e divida-o em 'pacotes', cada um consistindo de partes que irão interagir frequentemente. Em seguida, divida cada pacote em pedaços pequenos (pense em algumas horas no máximo) que você pode criar e codificar.

Idealmente, você poderá concluir cada peça a qualquer momento que você alocar para o seu projeto paralelo por um dia, mas isso não é necessário (depende da pessoa).

Pessoalmente, eu não me defino com um prazo estimado para cada peça, porque fico desapontado e desmotivado depois que falho nessa estimativa, portanto, não recomendo. Não tenha pressa, mas também não demore muito.

Agora, cada peça pequena recebe todos os estágios do seu processo normal de desenvolvimento, design, teste, implementação e tudo o que você precisa fazer. A idéia é dar a cada peça um bom pontapé inicial, mas ainda não um toque final completo.

Isso mantém minha motivação, porque eu sei que, depois de algumas horas de material chato de codificação, terei mais projetos para fazer (gostoso). Não se desvie de seus objetivos, apenas continue fazendo essa tarefa terrível e logo ela terminará.

Depois de ler todas as peças, observe a embalagem. Veja como funciona, o que está fazendo, revise o pacote inteiro novamente. Tenho certeza de que haverá mudanças e ajustes, faça-os agora. Mantenha as informações mais vitais em sua mente, pois você precisará delas ao trabalhar em todos os outros pacotes. Faça anotações também, elas ajudam muito.

Leia cada pacote e lembre-se de todos os outros que você fez antes. Como o novo código que você está escrevendo vai interagir com as coisas que você escreveu há uma semana? Não tenha medo de procurar coisas que você já escreveu e talvez tenha esquecido.

Finalmente, quando você está sem pacotes, geralmente deixo passar alguns dias, descanso-me e concentro-me em outra coisa.

Normalmente, estou ansioso para voltar e começar a entrelaçar os pacotes e fazer alguns testes divertidos, não há muito mais código para escrever e o objetivo está próximo, isso é motivação suficiente para mim.

Espero que isso ajude você em seus empreendimentos.

Tenho sempre encontrado que as premissas originais não detinha inteiramente e mais ou menos do design original teve de ser alterado com base na experiência adquirida ao fazer a implementação real.

Se você considera seu design absolutamente infalível e perfeito após desenhar algumas caixas, mas antes de experimentá-lo, considero-o um candidato perfeito para algumas implementações de projetos.

O envio é um recurso. Se você não percorrer toda a distância, você é apenas um arquiteto.

Eu acho que o problema está no objetivo incorreto. Parece que você define a meta "sistema de design". E então você faz bem, e a meta é alcançada. Portanto, uma sugestão é definir outro objetivo "implementar sistema", mas isso está mais relacionado à motivação e como você o faz.

Há uma outra maneira que funcionou bem para mim: definir a meta inicial como "fornecer sistema para usuários específicos" em vez de "projetar sistema" ou "criar sistema". Dessa forma, você não ficará satisfeito até que os usuários obtenham algo valioso. E você faz isso bem desde o início (incluindo testes e outras coisas modernas e sofisticadas).

Além de realmente ser uma questão de motivação, acho que uma parte da solução pode ser encontrada na combinação do processo de design e codificação. É assim que eu faço principalmente. Basicamente, tudo se resume a implementar o básico do seu design quando você pensa nisso e depois passa para a próxima etapa.

Por exemplo: se eu projetei minhas classes básicas, eu as escrevo e executo alguns testes. Depois, projetei um banco de dados subjacente, configurei e testei. Em seguida, tenho os métodos e funções necessários para obter tudo dentro / fora do banco de dados, eu continuo. O teste é feito com mais facilidade, pois já tenho minhas classes básicas prontas. E quando finalmente chego ao design da interface do usuário, já tenho todo um conjunto de códigos prontos para brincar.

Agora, isso pressupõe que você também projete em blocos vinculados por meio de interfaces. Não conheço a palavra cara, pois não sou programador em educação, mas você entende o que quero dizer.

Espero que isto ajude.

Depois, anote suas idéias de design, publique-as (em um blog), faça o possível para explicar o problema e a solução que você encontrou para os outros.

Um truque: escreva sua explicação sobre o design como um programa alfabetizado! :) Então você se ocupa da parte interessante (suas idéias de design), mas na verdade as justifica com o código real que você fornece ao lado.

E publique o programa alfabetizado como uma apresentação de suas novas idéias para outras pessoas!

Isso vai parecer banal, mas apenas comece. Você provavelmente precisará abrir seu ambiente de desenvolvimento, então faça isso. Provavelmente, você precisará definir cada uma das classes em seu design e escrever as assinaturas dos métodos deles. Você precisará começar a implementar os métodos mais importantes.

Normalmente, nessa época, esqueci que tinha problemas para começar e estou na zona.

Funciona cerca de 80% do tempo. Quanto ao resto, há Tetris.

Definitivamente não é só você! Na verdade, estou adiando um projeto agora.

Ninguém pode motivar você, a não ser você mesmo.

Crie uma linha do tempo realista e desafie-se a concluir cada seção a tempo. Você não tem nada para mostrar aos projetos se eles nunca passarem na fase de design.

A julgar pela sua pergunta, seu problema é que você parece estar reinventando a roda. Se você já fez tudo isso, por que precisa fazer novamente? Não existe uma estrutura para fazer isso por você? Se não (embora isso seja improvável), por que não escrever um?

Uma tarefa importante da programação não é fazer coisas chatas novamente , mas fazê-lo uma vez, fazê-lo corretamente e depois reutilizá-lo. Ou melhor ainda: encontrar alguém que já fez isso de uma vez e corretamente.

Eu entendo totalmente de onde você está vindo. É o problema que lhe interessa e, depois que você descobre, a implementação é apenas um trabalho.

Por que você não apenas arquiteta a solução e faz com que outras implementem?

Coisas que eu faço:

• Coloque um cronômetro grande na minha frente (pode estar no modo reverso, em pedaços de 1 hora)
• Me force a ficar acordado até alcançar algum objetivo (às vezes com uma cerveja, descobri que um pouco de álcool ajuda)

Nem sempre funciona, no entanto

PS. Eu trabalho em casa