¿Cómo evitar saltar a una solución bajo presión? [cerrado]

Cuando tengo una fecha límite de programación particularmente estricta (como una hora), si entro en pánico, mi tendencia es saltar a la codificación sin un plan real y espero resolverlo a medida que avanzo. Con el tiempo suficiente, esto puede funcionar, pero en una entrevista no ha tenido éxito, si no es totalmente contraproducente. No siempre me siento cómodo sentado allí pensando mientras el reloj pasa.

¿Existe una lista de verificación o hay técnicas para reconocer cuando comprende el problema lo suficientemente bien como para comenzar a codificar? ¿Cuándo es más productivo pensar y diseñar más frente a codificar algunos experimentos y descubrir el diseño general más adelante?

Aquí hay una lista de técnicas para tomar un examen de matemáticas y otra para tomar un examen oral . ¿Existe una lista similar de técnicas para manejar un problema de programación bajo presión?

RESPUESTAS: Creo que esta es una respuesta válida: cómo resolverla . Encontré ese enlace como una respuesta a Pasos para resolver o abordar una solución . También hubo algunos consejos realmente buenos en ¿Pensar en voz alta durante una entrevista es realmente la mejor estrategia? . Un argumento excelente y conciso para TDD es la primera respuesta al código de escritura de TDD versus averiguar la respuesta a un problema. .

Recuerdo haber leído un estudio sobre cómo los comisarios de bomberos forman un plan de acción al llegar a la escena de un incendio; el estudio los observó (y los condenó) por tener una idea y luego buscar esa primera idea de inmediato. Debido a la presión del tiempo, era más o menos "esto podría funcionar" seguido de "ok, hagámoslo". El estudio señaló que había opciones mejores, más rápidas y más seguras disponibles, pero no se siguieron simplemente porque los alguaciles no pensaron en ellas primero.

Si desea un enfoque estructurado para hacer frente a los "incendios", tal vez saque una hoja de su (nuevo) libro que prescribe varias fases:

RÁPIDO

1. Reacción: movilizar recursos para incidentes
2. Reconocimiento: recopilar datos sobre la situación
3. Apreciación: elija un curso de acción basado en los mejores y peores escenarios
4. Plan: desarrolle un plan basado en el curso de acción
5. Emisión de pedidos: utilice el formato de resumen estándar
6. Implementación: ejecutar y supervisar

o en términos más generales:

1. Despierta a todos y haz que se muevan
2. Averigua qué está pasando
3. Soluciones de lluvia de ideas
4. Elige uno y planifícalo
5. Dile a todos cuál es su trabajo
6. Ejecutar y monitorear

Siempre empiezo entendiendo los requisitos y buscando brechas en ellos que necesiten respuestas.

Luego esbozo (muy aproximadamente y en papel o en una pizarra) dos o tres posibles soluciones. Luego me pregunto: "¿Hay algo más que deba saber para implementar alguno de estos?"

Una vez que tengo mis preguntas iniciales (hay preguntas el 100% del tiempo, si no las tiene, realmente no ha examinado el requisito en profundidad), vuelvo a las partes interesadas para obtener mis respuestas.

Mientras espero sus respuestas, considero mis soluciones y veo si alguna es mejor que las demás o sería mejor una vez que obtenga las respuestas a las preguntas. Por ejemplo, si la pregunta sobre cuándo la necesita es inmediata, podría elegir la que tenga el desarrollo más rápido, pero dejando una forma de mejorar el diseño más adelante. Si me dicen que el rendimiento es crítico, entonces miro las soluciones y determino cuál es más probable que funcione mejor (estas son suposiciones en este momento, pero informadas en general). Si hay una GUI involucrada, podría hacer un prototipo en papel de varios diseños diferentes y hacer que las partes interesadas lo miren antes de codificar cualquier cosa (por lo general, verán que se olvidaron de decirte sobre XYZ, que es algo central para el ¡diseño!)

Una vez que obtengo mis respuestas, elijo un diseño aproximado y luego hago una lista de todas las cosas que tendré que hacer para implementarlo. Entonces empiezo a codificar.

... mi tendencia es saltar a la codificación sin un plan real y espero resolverlo a medida que avanzo.

Lo hice mientras estaba en la universidad. Se convirtió en un problema real y normalmente daría como resultado reescribir el código. Comencé a abordar esto al no escribir el código. Puse énfasis en el pensamiento sobre el problema. Con suficiente práctica, instintivamente alcanzo mis pensamientos en lugar de un teclado.

... en una entrevista ha sido bastante infructuoso, si no francamente contraproducente. No siempre me siento cómodo sentado allí pensando mientras el reloj pasa.

Dentro de una entrevista, debe haber una implementación razonada y bien pensada de una solución y eso no siempre es fácil. Lo que no quieres hacer es dejar escapar respuestas sin pensar. Si sabes la respuesta, dáselo rápidamente. Si no lo hace, confíe en sus pensamientos para razonar una solución. Siempre indique cuándo no sabe y demuestre cómo haría para encontrar una solución.

¿Existe una lista de verificación o hay técnicas para reconocer cuando comprende el problema lo suficientemente bien como para comenzar a codificar?

Desalentaría eso porque puede confiar en él rígidamente. Más bien, pregúntese si comprende el problema lo suficientemente bien como para comenzar a codificar. ¿Cómo sabrías? Porque cuando razonas tu enfoque y luego lo examinas, dado tu conocimiento actual del idioma, tendrá sentido. Siempre tenga un plan y enfoque. También recuerde que el código nunca termina y que el código que no evoluciona morirá, así que espere volver a su código con frecuencia.

¿Cuándo es más productivo pensar y diseñar más frente a codificar algunos experimentos y descubrir el diseño general más adelante?

Querrá conocer el diseño general y pensarlo. Luego comienzas a hacer la estructura de clase y los talones. Luego revísalo de nuevo. ¿Tiene sentido? La codificación de experimentos es una excelente manera de demostrar que algo funciona bien y debe usarse, pero no debe confiarse en él para moldear o dar forma al código que escribe.