juego - memory song
es una gran memoria un requisito para una gran programación (24)
Algunos de los códigos mejor escritos que he visto se escribieron de tal manera que cada decisión de diseño era inevitable, y el código se leía como su propia explicación. Eso es mucho mejor en mi humilde opinión que el código que requiere que el lector (o, peor aún, el mantenedor) guarde toneladas de detalles arbitrarios memorizados.
Mi propio índice de complejidad en el código es "¿Cuántas cosas tengo que tener en cuenta para entender esta línea?"
Más es peor
¿Crees que tener una gran memoria es REQUERIDO para ser un gran programador?
No me considero un gran programador, pero sí creo que soy decente. Pero mi memoria es REALMENTE mala, así que siempre me tengo que recordar a mí mismo cómo hacer las cosas. Quiero decir que "sé dónde mirar", pero a veces me hace sentir que soy un programador horrible. Lo que lo empeora aún más es que siempre me olvido de dónde están las cosas en mi código fuente o qué algoritmo utilicé para ciertas situaciones.
Piensa en los grandes programadores que has encontrado en tu vida, ¿no parecían todos ellos tener recuerdos increíbles?
Creo que es posible recordar diferentes tipos de cosas con diferentes grados de aptitud.
Por ejemplo, a veces me parece que tengo un recuerdo bastante malo cuando se trata de hechos y cifras aleatorias, así como de cosas que he hecho o haré, lo que significa que el software de seguimiento de errores es una herramienta invaluable.
Por otro lado, puedo recordar la estructura de las piezas complejas de software que he escrito, y dónde encontrar cosas específicas dentro de eso.
Esto puede ser sobre la asociación lógica. El software bien diseñado debe tener (en teoría) una estructura lógica, que puede hacer que sea más fácil almacenarlo en la memoria si su cerebro está conectado de esa manera.
Sin embargo, es posible que la información aleatoria no tenga estas asociaciones, lo que las hace más difíciles de recordar.
Creo que eso depende La memoria para un programador es muy muy importante. Tanto a corto como a largo plazo. Sin embargo, para qué usa esa memoria es lo importante. Como programador, si lo estás usando para memorizar cualquier matiz de una API, diría que estás desperdiciando tu memoria.
En última instancia, trato de utilizar mi memoria para recordar las cosas importantes y todo lo que no puedo encontrar fácilmente en un momento posterior. Por lo general, pongo material API en la memoria a corto plazo y uso google e intellisense para ayudarme con los detalles. Por otro lado, los patrones de diseño, las metodologías, las lecciones aprendidas de la experiencia suelen ser lo que trato de poner en la memoria a largo plazo, de modo que pueda usarla eficazmente en el futuro sin tener que volver a aprender todo.
En resumen, sí, un programador necesita una buena memoria ... tanto a corto como a largo plazo. Pero necesitan ser sabios sobre cómo usar esa memoria ... y eso, creo, marca la diferencia en un gran programador.
Creo que tener buena memoria es útil para aprender cosas nuevas rápidamente .
Esto no significa que sea un requisito para ser un gran programador.
De hecho, se trata más de inteligencia que de capacidades de memoria , pero es un tema demasiado complejo para poder identificar ciertas cualidades y compararlas con habilidades de programación, y poder recuperar cualquier información relevante.
Ese es el misterio del cerebro.
Creo que uno de los beneficios de tener un buen recuerdo (punto de modestia: tengo buena memoria) es la capacidad de poder pensar en los pies cuando no está frente a una computadora.
Por ejemplo, es posible que se encuentre en una reunión cuando se sugiere un nuevo tipo de funcionalidad para su aplicación. Se puede hacer? ¿Cuánto tiempo es probable tomar? Estas son preguntas que son más fáciles de responder si puedes caminar a través de 250k loc en tu cabeza.
Dicho esto, encuentro un poco de verdad en las opiniones de los demás que mi propio código podría ser menos claro porque puedo recordarlo mejor.
En alusión a Edsger Dijkstra, un programador competente es plenamente consciente del tamaño limitado de su propio cráneo. Cuantos más detalles no metas en tu cabeza, mejor podrás abordar el problema que tienes entre manos.
Modifique mucho su código, refactorice el código, empaque sus ingeniosos algoritmos en objetos, y use esos objetos, de esa manera, no siempre tiene que "micro-recordar" todos y cada uno de los detalles de implementación de sus programas.
Honestamente, he encontrado que la memoria deficiente es una ventaja, incluso una mala memoria a corto plazo. La mala memoria a corto plazo realmente te obliga a romper la separación de preocupaciones. El resultado final es un código muy limpio, muy simple, muy bien encapsulado. De hecho, tengo muy buena memoria a corto plazo, pero he aprendido a esforzarme mucho para no emplearla después de algunas experiencias escribiendo código mientras estaba lo suficientemente distraída como para no poder retener mucho de una vez. De hecho, me impactó observar que el código en realidad era mucho más limpio que el código que había desarrollado en el pasado.
La mala memoria a largo plazo es un activo, porque terminas entrenando muy bien en cómo encontrar y aprender técnicas, API, algoritmos, etc. También tiende a animarte a encontrar un pequeño conjunto de temas comunes para guiarte en tu trabajo. .
En general, la marca de un buen programador no es la complejidad (que es realmente difícil de lograr sin buena memoria), sino la simplicidad (que por naturaleza no requiere mucha memoria).
La Navaja de Occam sugiere que una teoría más simple es más probable que sea cierta.
Si el código es una teoría, que describe entradas que van a salidas, entonces es más probable que el código más corto, usando expresiones idiomáticas esperadas y bibliotecas, sea "verdadero", es decir, es más probable que capture la esencia de la solución, por lo que generalizará a entradas que no esperabas
Un código más breve y no sorprendente es más fácil de recordar.
Los programadores con poca memoria son como las máquinas universales de Turing en comparación con las computadoras prácticas: técnicamente puede lograr las mismas cosas refiriéndose a la información que usted o alguien más ha grabado en alguna parte ... es solo que puede llevar un poco más de tiempo ...
Mientras puedas recordar cómo se escribe Google, estás bien. :)
Pero en serio, necesitas mantener varias cosas en tu memoria a corto plazo a la vez. La memoria a largo plazo es menos importante. Siempre que sepa que algo existe, ya ha visto algo antes, etc., cuando sea relevante, sabrá que puede desenterrarlo.
Los programadores experimentados generalmente pueden regurgitar las API, detalles menores, etc., pero en mi experiencia, esto nunca ha sido un caso de sentarse y memorizar cosas de memoria. Es una consecuencia natural de usar cosas una y otra vez.
No. La capacidad de olvidarte de lo que sabes y seguir aprendiendo es al menos igualmente importante a largo plazo.
Buenas notas, marcadores y búsquedas en la web son un largo camino.
Recordando las cosas realmente simples se requiere para una gran programación. Cosas tan simples como "mantenerlo".
Una perspectiva interesante desde el otro lado de su monitor: Localidad de referencia
No. Pero tal vez te puede hacer genial ...
Un arte de programación (tal vez el arte) es poder abordar los problemas de tal manera que pueda comprenderlos a todos, a pesar de sus limitaciones (como la memoria imperfecta). Esto se debe a que todos , incluidos los más inteligentes, tenemos limitaciones. Toparse con sus limitaciones no es una señal de que tiene limitaciones, sino una señal de que está llegando más lejos.
Este arte (en la medida en que lo sé) incluye cosas como dividir y conquistar (utilizando módulos de varios tipos, para que coincida con la forma del problema); utilizando técnicas estándar para telegrafiar su intención (modismos, patrones de diseño OO son solo uno); separando el núcleo del problema (este no es sobre el código: se trata del problema); y por supuesto comentarios.
Yo solía creer que el código bueno era auto-documentado (e incluso, ese código es verdad ), pero recientemente estoy escribiendo analizadores, e incluir el CFG en un comentario es una referencia muy útil, porque es una representación mucho más simple de la intención del código.
Un codificador debe conocer sus limitaciones . No es realista esperar tener la misma comprensión de algo meses después, como cuando uno estaba en medio de todo. Todo lo anterior implica aceptar ese problema y trabajar en una solución. No solo hace que su código le resulte más fácil de entender más adelante, sino que también facilita que otra persona lo capte ... pero lo más importante es que creo firmemente que un código más claro y simple es, fundamentalmente y de manera trascendental, un mejor código .
El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, se acerca a la tarea de programación con total humildad y, entre otras cosas, evita los trucos ingeniosos como la peste. - Dijkstra
Para mí, hay dos tipos de programadores en el mundo. Los primeros nacieron para hacerlo, el segundo aprendió. En ambos grupos van desde increíblemente pobres hasta increíblemente grandes. ¿La memoria denota esas calificaciones? No absolutamente no. Si bien un buen recuerdo puede ayudarte con el aprendizaje, nada te ayuda más que practicar y comprender. Después de todo, poder recordar toda la Enciclopedia Británica no significa nada sin comprender. El almacenamiento de mi servidor es un ejemplo clásico allí.
La programación se trata de lógica, tanto en el código como en la forma de enfocar el problema. Si desea un código claro y fácil de entender, entonces es probable que descomponga el problema en pequeños fragmentos manejables (es decir, que se ajusten a su mente en su totalidad) y trabaje en cada uno. Cada función luego se condensa en un solo comando para su siguiente etapa de complejidad. Al final de la siguiente etapa, si hay otra, tendrá un conjunto de comandos únicos para construir nuevamente. Nomenclatura lógica, partición lógica, ensamblaje lógico ... Creo que estoy transmitiendo mi punto lógico;)
Mi memoria es espantosa, y me refiero a espantosa. Me pueden presentar a 3 personas y para cuando se dice el nombre # 3, he olvidado quién es el # 1. Todavía puedo escribir un buen código, no todas las veces o todos los días; cuando estás en la zona es otra cosa, en ese punto es arte. Así que, deja tu memoria a un lado, consigue un espacio realmente tranquilo o un generador de ruido rosa y sumérgete. Lo único que te hará un mejor programador es practicar, practicar, practicar. Lo único que hay que recordar es que la programación es una habilidad y se practican las habilidades, y se practica mejor entre amigos que pueden dar críticas constructivas y consejos ... como :)
Disculpas por el nivel de esta respuesta, pero no podía recordar lo que ya había escrito;)
Puedo responder exactamente esto usando solo una palabra: NO. Tener memoria para memorizar todo sobre programación no es obligatorio. Las experiencias y el aprendizaje tedioso por la práctica son los mejores.
Yo también he experimentado esto. Si tiene suficientes horas de experiencia (o puede ser años) creando software con las mejores prácticas aplicadas, entonces es realmente un maestro en su propio trabajo o en los lenguajes de programación que usa para crear software. Por favor, no estés triste si tienes malos recuerdos, pero esforzarte por aprender y practicar siempre puede vencer la debilidad de tu memoria.
Seguramente apocrapful, pero aquí está el número de Einstein :
Un periodista entrevistó a Albert Einstein. Al final de la entrevista, el periodista le preguntó si podía tener el número de teléfono de Einstein para poder llamar si tenía más preguntas.
"Ciertamente", respondió Einstein. Levantó el directorio telefónico y buscó su número de teléfono, luego lo escribió en un trozo de papel y se lo entregó al periodista.
Aturdido, el periodista dijo: "¿Se te considera el hombre más inteligente del mundo y no puedes recordar tu propio número de teléfono?"
Einstein respondió: "¿Por qué debería memorizar algo cuando sé dónde encontrarlo?"
Solía pensar que tener un buen recuerdo ahorraba tiempo porque mientras más recordabas, menos tiempo pasabas buscando, pero las herramientas y el IDE se han vuelto tan buenos ahora, muchas cosas que solía memorizar como la sintaxis y varios fragmentos de código están disponibles rápidamente en unas pocas teclas. Eso, y el hecho de que la cantidad de información en el campo crece mucho más rápido de lo que cualquier programador mortal puede seguir, me hace pensar que la memoria ya no es tan importante. Más importante aún, es tener un buen acceso y organización a información útil.
Solo un simple comentario "La repetición es la madre del aprendizaje", no importa si tienes una memoria buena / mala. La función que usa más en sus programas la recordará mejor. Además, en mi caso, tengo Internet, cuando no recuerdo algo que acabo de preguntar, incluso si es una pregunta fácil o aburrida, y muchas veces recuerdo la respuesta después de publicar la pregunta y luego rápidamente publica la respuesta. El problema es cuánto tiempo pones tu mente a trabajar ...
:)
Tener una buena memoria es bastante útil, pero ciertamente no es necesario. Diría que no es que los grandes programadores tengan una gran memoria, sino que han dedicado mucho tiempo a investigar incluso los problemas más pequeños que han mejorado su comprensión y mejorado la memoria. Si pasas 4 minutos resolviendo un problema (buscando en Google o preguntando en SO), entonces probablemente no recordarás la resolución cuando lo golpees nuevamente 4 meses después. IT podría ser un rasgo evolutivo o simplemente un mal recuerdo =)
Los buenos programadores también tienen principios bien pensados que les permiten trabajar en piloto automático sin cuestionarse ellos mismos. Un buen conjunto de principios también logra consistencia y predictibilidad (que es una cualidad de la memoria) a través del refuerzo.
Esto también se extiende a otros dominios. Los grandes maestros de ajedrez pueden recordar un juego completo jugado hace 40 años. Esto se debe a que recuerdan patrones (aperturas, variaciones, causa raíz y efecto de movimientos que condujeron al final del juego, etc.). que ayuda a agrupar movimientos individuales en unidades.
En el software, las herramientas pueden ser autocompletas o tener una KB / Wiki y el historial de registro de búsqueda, etc., pueden ayudar.
Tener una memoria lo suficientemente fuerte para guardar las cosas que necesita usar hoy es la parte importante. Si busca constantemente respuestas a la misma pregunta, probablemente tenga una memoria débil.
Lo más importante es recordar dónde puedes encontrar las respuestas. A veces blogueo sobre temas que son un poco más complejos, así que tengo un lugar para encontrarlos cuando los necesito. Pero no trato de aferrarme a ellos perpetuamente, porque puedo buscar en mi propio blog y encontrarlos más tarde. Hago lo mismo con los blogs de otras personas y sé qué blogs buscar para ciertos tipos de respuestas.
Cuando todo lo demás falla, ¡Google it!
Tengo este compañero de trabajo que escribe un código realmente malo que es increíblemente difícil de mantener. Llegué a la conclusión de que su problema es buena memoria. Simplemente es capaz de recordar dónde puso qué funcionalidad. Por lo tanto, no tiene que escribir un código que se explique por sí mismo. Él simplemente recuerda esa mierda. El resto de nosotros tiene dificultades para descifrar su código.
Estoy seguro de que la buena memoria no es solo el problema de los muchachos. Pero estoy seguro de que su código mejoraría si su memoria empeorara.
Todo depende de lo que tu buena memoria recuerde ...
He trabajado en el mismo proyecto durante 10 años más o menos y no recuerdo cada línea, quién la escribió y por qué.
Pero ... Puedo recordar prácticamente todas las solicitudes de los usuarios y los problemas del usuario. Quién quería qué y cuándo.
Puedo recordar casi todos los problemas de soporte que hemos tenido.
Encontrar código antiguo es fácil, tenemos excelentes herramientas para eso. Encontrar viejos problemas es un proceso mucho más abstracto: tenemos JIRA y Wikis, pero a veces no lo cortan porque no proporcionan el significado semántico.
Asi que. Presta atención a lo que REALMENTE importa y recuerda eso.
Trata tu memoria a corto plazo como pila (no estática) y no esperes mucho más de ella. Volví al código que escribí hace solo un mes y es casi como si alguien más lo hubiera escrito. Simplemente lleva un tiempo volver a la misma zona.
Me molestan, a menudo por dejar comentarios como pan rallado ... pero funciona. Si termino alguna función y digo "¡AHA, eso es absolutamente BRILLANTE!", Inmediatamente comento mi complejidad, como seguramente voy a olvidar.
Entonces ahora, para responder una pregunta con dos preguntas:
- ¿Qué tenías para almorzar el miércoles pasado?
- ¿Cuál es el propósito de ''contador'' en hash_foo ()?
Al menos, con el n. ° 2, puede volver rápidamente y mirar / recordar.
Yo diría lo contrario, tener un buen recuerdo puede llevar a escribir un código que solo el autor puede entender, porque recuerda los detalles de su lógica. Por otro lado, teniendo mala memoria, documenté mi código y lo escribí lo más claro posible.
Yo diría que es necesario para ser grande y rápido. Mi memoria para los detalles de programación está bien (pero tengo google para eso). Sin embargo, cuando me siento delante de las aplicaciones que he escrito principalmente (~ 30-40 k líneas de código), puedo cargar su estructura casi por completo en mi memoria. Puedo encontrar la forma en que estoy haciendo algo en un par de segundos y recordar por qué lo implementé de la manera en que lo hice. Eso es invaluable. A las 11 a. M. He podido hacer más trabajo que algunos otros durante todo el día. Ahora, eso no me convierte en un gran programador, pero sí me convierte en un programador productivo enormemente productivo. Esto me da tiempo para refactorizar, escribir código adicional, navegar SO, tomar una hora de almuerzo, etc.