Como evitar pular para uma solução quando está sob pressão? [fechadas]

Quando sob um prazo de programação particularmente rigoroso (como uma hora), se eu entrar em pânico, minha tendência é pular para a codificação sem um plano real e espero que eu descubra isso à medida que for avançando. Com tempo suficiente, isso pode funcionar, mas em uma entrevista foi bem-sucedido, se não totalmente contraproducente. Nem sempre estou confortável sentada ali pensando enquanto o relógio passa.

Existe uma lista de verificação ou existem técnicas para reconhecer quando você entende o problema suficientemente bem para começar a codificar? Quando é mais produtivo pensar e projetar mais do que codificar algumas experiências e descobrir o design geral mais tarde?

Aqui está uma lista de técnicas para fazer um teste de matemática e outra para fazer um exame oral . Existe uma lista semelhante de técnicas para lidar com um problema de programação sob pressão?

RESPOSTAS: Acho que essa é uma resposta válida: Como resolvê-lo . Encontrei esse link como resposta às etapas para resolver ou abordar uma solução . Havia também algumas dicas realmente boas em . Pensar em voz alta durante uma entrevista é realmente a melhor estratégia? . Um argumento grande e conciso para o TDD é a primeira resposta para o TDD Writing code vs: descobrir a resposta para um problema? .

Lembro-me de ler um estudo sobre como os agentes de incêndio formam um plano de ação ao chegar ao local do incêndio; o estudo os observou (e condenou) por terem apresentado uma idéia e depois perseguidos a primeira idéia imediatamente. Devido à pressão do tempo, foi praticamente "isso pode funcionar" seguido de "ok, vamos fazer isso". O estudo observou que opções melhores, mais rápidas e seguras estavam disponíveis, mas elas não foram seguidas simplesmente porque os marechais não pensaram nelas primeiro.

Se você deseja uma abordagem estruturada para lidar com "incêndios", talvez tire uma folha do livro (novo) que prescreve várias fases:

RRAPID

1. Reação - Mobilize recursos para incidentes
2. Reconhecimento - Colete dados sobre a situação
3. Apreciação - Escolha um curso de ação com base nos melhores e piores cenários
4. Plano - desenvolva um plano com base no curso da ação
5. Emissão de pedidos - Use o formato padrão de informações
6. Implantação - Executar e monitorar

ou em termos mais gerais:

1. Acorde todos e mova-os
2. Descubra o que está acontecendo
3. Brainstorm solutions
4. Escolha um e planeje-o
5. Diga a todos qual é o trabalho deles
6. Executar e monitorar

Sempre começo entendendo os requisitos e procurando lacunas neles que precisam de respostas.

Depois, esboco (muito grosseiramente e em papel ou em um quadro branco) duas ou três soluções possíveis. Então me pergunto: "Há mais alguma coisa que preciso saber para implementar alguma dessas coisas?"

Depois de fazer minhas perguntas iniciais (há perguntas 100% do tempo, se você não tiver nenhuma, realmente não analisou o requisito em profundidade.), Volto às partes interessadas para obter minhas respostas.

Enquanto eu estou pensando em suas respostas, considero minhas soluções e vejo se alguma é melhor que as outras ou seria melhor assim que eu receber as respostas para as perguntas. Por exemplo, se as perguntas sobre quanto tempo você precisar forem imediatas, eu poderia optar pelo que teve o desenvolvimento mais rápido, mas deixando em aberto uma maneira de melhorar o design posteriormente. Se eles me dizem que o desempenho é crítico, analiso as soluções e determino qual delas tem maior probabilidade de ter um desempenho melhor (essas são suposições neste momento, mas as informadas em geral). Se uma GUI estiver envolvida, eu posso criar um protótipo em papel de vários designs diferentes e fazer com que as partes interessadas as vejam antes de codificar qualquer coisa (geralmente elas verão que se esqueceram de falar sobre XYZ, que é algo central para o Projeto!)

Depois de obter minhas respostas, escolho um design aproximado e, em seguida, faço uma lista de todas as coisas que terei que fazer para implementá-lo. Então eu começo a codificar.

... minha tendência é entrar em codificação sem um plano real e espero que eu descubra isso à medida que for avançando.

Eu fiz isso enquanto estava na universidade. Tornou-se um problema real e normalmente resultaria na reescrita do código. Comecei a resolver isso não escrevendo código. Coloquei ênfase no pensamento sobre o problema. Com bastante prática, instintivamente busco meus pensamentos em vez de um teclado.

... em uma entrevista, foi bem-sucedida, se não totalmente contraproducente. Nem sempre estou confortável sentada ali pensando enquanto o relógio passa.

Em uma entrevista, deve haver uma implementação fundamentada e bem pensada para uma solução e isso nem sempre é fácil. O que você não quer fazer é deixar escapar respostas sem pensar. Se você souber a resposta, dê-a rapidamente. Caso contrário, confie em seus pensamentos para raciocinar uma solução. Sempre indique quando você não sabe e demonstra como iria encontrar uma solução.

Existe uma lista de verificação ou existem técnicas para reconhecer quando você entende o problema suficientemente bem para começar a codificar?

Eu desencorajaria isso, porque você pode confiar nisto rigidamente. Em vez disso, pergunte-se se você entende o problema suficientemente bem para começar a codificar. Como você saberia? Porque quando você raciocina sua abordagem e a examina, dado o seu conhecimento atual da língua, fará sentido. Sempre tenha um plano e abordagem. Lembre-se também de que o código nunca termina e o código que não evoluiu morrerá, portanto, espere retornar frequentemente ao seu código.

Quando é mais produtivo pensar e projetar mais do que codificar algumas experiências e descobrir o design geral mais tarde?

Você desejará conhecer o design geral e refletir sobre ele. Então você começa a criar a estrutura da classe e os stubs. Em seguida, revise-o novamente. Isso faz sentido? Os experimentos de codificação são uma ótima maneira de demonstrar que algo funciona bem e deve ser usado, mas não deve ser utilizado para modelar ou modelar o código que você escreve.