Escrevendo minha abordagem de resolução de problemas no papel? [fechadas]

Eu sou um novato em Ciência da Computação e começamos a fazer alguns projetos reais em Python. Descobri que sou muito eficiente quando uso o método de caneta e papel que meu professor sugeriu nas aulas. Mas quando não consigo escrever meu problema e trabalhar meus algoritmos no papel, sou muito lento. Durante os laboratórios, sempre pareço levar a tarefa de volta ao meu dormitório. Quando chego lá e escrevo, resolvo o problema que me levou a toda a classe em 5 minutos.

Talvez seja porque eu fico estressado vendo as pessoas resolvendo laboratórios antes de mim. Ou talvez seja o método de caneta e papel.

Eu estava navegando pelos fóruns e alguém escreveu que, se você tiver que escrever seus programas em papel, não deverá ser um programador. Estou realmente preocupado porque sou muito melhor quando posso ver o que o programa está fazendo e acompanhar o meu caminho antes de digitar o código real. Estou fazendo algo errado?

Edit: Desculpe por não estar claro, mas quando eu disse escrevendo no papel, quis dizer que minha abordagem de solução de problemas (por exemplo, escrever exemplos, criar tabelas com valores etc.) não é o meu código real. Eu apenas uso o papel para divulgar minhas idéias.

Não há nada errado em elaborar seus algoritmos no papel primeiro. Não muito para codificação cotidiana, mas para algoritmos mais complexos, programadores profissionais os trabalham no papel ou em um quadro branco o tempo todo, especialmente se um formato gráfico deixar mais claro. Para um aluno, todo programa é complexo.

Se você deseja melhorar o design de algoritmos em um computador, existem algumas técnicas que você pode praticar. Não comece escrevendo o código, escreva as mesmas coisas que você colocaria no papel como comentários e depois expanda-o para código real ou comentários mais detalhados, um por um.

Por exemplo, se estou excluindo um elemento do meio de uma lista vinculada, posso começar com algo como:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Posso substituir // find the elementpor uma função por mais pseudocódigo e continuar até que eu tenha uma solução completa. Não pense que o código precisa ser escrito de maneira linear.

Vá em frente! Se chamarmos o que você está fazendo de pensar e projetar sua solução, faz sentido que seu processo seja muito mais rápido do que apenas explodir o código.

As pessoas gostam de pensar (e as barulhentas gostam de nos dizer) que seu modo de agir é melhor. Mas a capacidade de todos e a combinação de habilidades são diferentes. Então faça o que funciona para você. À medida que você adquire prática, provavelmente passará a fazer mais do trabalho de design em sua cabeça e usará papel para problemas maiores.

Uma coisa a observar é a forma que os exames terão. Eles estarão no papel ou serão baseados em computador? Se eles são baseados em papel, seu caminho lhe dará uma vantagem. Se eles são baseados em computador, tudo bem: faça um design em papel e escreva o código. Tudo o que funciona melhor!

Não escrevo códigos reais no papel, mas, para qualquer coisa não trivial, quase sempre começo em um quadro branco ou em um notebook. Eu costumo esboçar:

• Algoritmos / fluxo de processo / controle
• Estruturas de dados
• Relacionamentos
• Componentes (como decomponho esse problema)

Geralmente é uma combinação de esboços, pseudocódigo e inglês.

Acho que, ao fazer isso, é mais fácil visualizar quando começo a codificar. Também identificarei falhas antes de iniciar o código, porque consigo ver tudo à minha frente (em vez de rolagem incessante e salto de janela). Não só isso, uma vez escrito, posso deixar as coisas se formarem no fundo da minha mente enquanto estou trabalhando em outras tarefas. Também posso trabalhar de maneira não linear, enviando uma ideia para o papel quando ela me atingir e depois voltar quando chegar ao ponto em que preciso.

Enviar algo para o papel é uma tremenda ajuda para a retenção de memória. O slogan da marca de notebooks Field Notes é o seguinte:

Não estou anotando para lembrar mais tarde, estou anotando para lembrar agora.

Depois de adotar uma abordagem mais focada em escrever as coisas no papel, mesmo se eu fizer uma entrada no aplicativo ToDo no meu telefone um momento depois, acho que o pensamento está cimentado na minha cabeça muito melhor do que apenas fazer a nota eletrônica. Como planejamos minha codificação em papel / quadro branco, as idéias ficam na minha cabeça melhor.

Também serve como uma referência útil quando é hora de documentar o que escrevi.

Eu não acho que exista algo inerentemente errado com o código de desenho (pseudo ou não) no papel primeiro - não é realmente diferente de escrevê-lo em um quadro branco, o que muitas pessoas fazem ao discutir como resolver um problema.

Você escreve os primeiros rascunhos de ensaios para as aulas que não são de CS, antes de digitá-los? Na verdade, eu costumava fazer isso anos atrás quando ainda era estudante universitário, mas depois do meu primeiro ano, me forcei a escrever todos os rascunhos em uma tela, pois isso tornava muito mais fácil escrever rascunhos subsequentes, e a mesma idéia se aplica para escrever código.

Eu sugiro que você tente digitar seus algoritmos, mesmo que seja apenas em um editor de texto como o Word. Quanto mais você faz, mais confortável estará em não confiar em papel e caneta. E se as suas habilidades de digitação estão um pouco ausentes e essa é realmente a fonte de sua frustração, faça um curso de digitação! Seria a melhor coisa que você poderia fazer para sua futura carreira.

Resolver o problema e escrever o código que implementa sua solução são duas atividades diferentes.

Se você não estiver familiarizado com um idioma, gastará muito tempo no próprio código - e não o suficiente para encontrar uma boa solução. Se papel, quadro branco ou começar no teto o ajudarem nesse sentido, faça isso de qualquer maneira.

(Pessoalmente, me pego saindo do computador e andando em círculos, tentando criar uma solução em minha mente)

Você aceitará entrevistas! Eles fazem você escrever código no papel ou no quadro branco. Eu sou exatamente o oposto. Tentar escrever chaves ou cortar e colar com uma caneta é MUITO entediante!

Meu pai usou muito papel ao programar o COBOL. Eu acho que é apenas o seu estilo de pensar.

Costumávamos ter uma aula de dois semestres chamada The Basics of Programming. Os testes no meio do semestre e os exames no final foram feitos em papel. Se você cometeu algum erro de compilação, perdeu uma quantidade séria de pontos. Se você cometeu grandes erros de compilação, falhou. No entanto, acho que desenvolveu a capacidade de analisar qualquer código e encontrar linhas de buggy em um período de tempo relativamente menor.

Não há nada errado com o que você está fazendo, aprendi a programar usando papel e caneta também.

Como outros sugeriram, faça o que funciona para você. Lembro que o primeiro programa Java que escrevi foi principalmente no papel e depois passei duas horas digitando e quinze minutos chorando quando vi mais de 200 erros de compilador. Havia mais, mas o compilador mostraria apenas os primeiros 200! O que estou dizendo é que, escrevendo o código no papel, fui capaz de pensar no algoritmo e na funcionalidade básicos sobre o que o programa precisava fazer. O compilador apontou os motivos pelos quais meu programa não seria executado. 90% dos problemas estavam fora dos limites das exceções com matrizes.

À medida que você ganha mais experiência e confiança, você se vê usando menos papel e caneta. Você já saberá como usar conceitos básicos, como loops e assim por diante. Você terá exemplos em outros programas que podem ser reutilizados. Você usará o compilador e um IDE para encontrar erros óbvios durante a gravação do programa. Agora mesmo que você não tenha essa experiência.

Lendo sua pergunta, pergunto-me se alguns dos seus problemas podem estar relacionados ao foco. Se o uso de caneta e papel em um ambiente silencioso ajuda a se concentrar, então é ótimo.

Você ainda está na faculdade e ainda está aprendendo. Por fim, tudo o que você está fazendo é o que funciona para você. Se, usando papel e caneta, você está ordenando seus pensamentos e pensando de forma clara e calma, então está programando.

Meu código é muito melhor organizado quando escrevo anotações e abordagens em um bloco de notas, checo livros, checo a web e penso nisso. Eu também sou muito mais uma pessoa visual, portanto, desenhar imagens com estruturas de dados é muito útil. Não escrevo todas as linhas, mas escrevo o que considero fragmentos "importantes" ou funcionalidade-chave. Para projetos maiores, inicio o Visio. Não sei por que alguém defenderia pular direto para o teclado, a menos que seja muito mais eficiente ou pago a cada hora.

Faça o que for melhor para você. Eu não escreveria código no papel. Eu escrevo pseudocódigo e desenho fluxogramas no papel, mas escrever o código completo parece uma perda de tempo.

Também estou enfrentando o mesmo problema no meu primeiro dia de aprendizado de habilidades técnicas.

Mas esse tipo de prática não deve dar 100% de sucesso porque, se estamos escrevendo código no papel, não há chance de corrigir bugs, há chances de resolver os erros e exceções durante o trabalho em papel.

Portanto, o trabalho em papel não fornece nenhuma navegação para resolver os problemas. E podemos obter velocidade de digitação como bônus devido à prática do sistema.

Também estou trabalhando com papel, mas quando antes de implementar minha funcionalidade, faça uma estimativa aproximada depois disso, iniciarei Minha implementação no sistema.

Por favor, tente dedicar mais tempo à prática do sistema. Isso dará 100% de confiança e resultado.