¿Qué debe saber todo programador?

Independientemente de los lenguajes de programación o los sistemas operativos utilizados o el entorno para el que se desarrollan, ¿qué debe saber todo programador?

Algunos antecedentes:

Estoy interesado en convertirme en el mejor programador que pueda. Como parte de este proceso, estoy tratando de entender lo que no sé y me beneficiaría mucho si lo supiera. Si bien hay un montón de listas en torno a "n cosas que todo desarrollador de [insertar lenguaje de programación] debería saber", todavía tengo que encontrar algo similar que no se limite a un lenguaje específico.

También espero que esta información sea de interés y beneficio para otros.

Cómo tragar orgullo y admitir errores sin tomarlos personalmente.

Cómo pensar como un usuario, y no como un programador experto en tecnología.

Cuándo pedir ayuda y cuándo NO pedir ayuda.

Cómo leer el código de otras personas.

Familiaridad con los sistemas de control de versiones. No tiene que ser todos, pero se deben conocer los conceptos básicos que se pueden aplicar a todos ellos.

Aquí están mis 10 bits:

• Cómo ser humilde Todos estamos aquí para aprender. Puede ser más inteligente que otros, pero hay muchas personas más inteligentes que usted.
• Cómo estudiar / consumir información. ¡No sé tú, pero siempre estoy estudiando! ¡Libros, Internet, lo que sea!
• Qué es un diccionario y cómo usar uno, y cómo encontrar siglas rápidamente.
• Cuáles son las herramientas básicas del comercio y qué hacen (IDE, CVS et al).
• Conozca la terminología común y lo que significan: patrones de diseño, usabilidad, pruebas (¡ja!), Pila, etc.
• Comprender la POO.
• Sea "capaz" en al menos un idioma, nada sorprendente, solo sepa cómo identificar variables y métodos, etc. Desde aquí puede aprender RÁPIDO.
• Comprenda que las personas finalmente usan software y quieren hacer felices a esas personas.

Tal vez sea demasiado sutil, pero lo considero como "saber qué problema resolver". Muchos programadores (y personas normales) desperdician un tremendo esfuerzo resolviendo cosas que simplemente no son muy importantes; o crean una solución, con una gran cantidad de trabajo extra, que no es exactamente lo que se necesita.

Cómo relajarse. Es el secreto de la productividad.

Finalmente, la fuerza de voluntad y la cafeína no son suficientes. Esta constante contracción que hacemos es muy perjudicial.

Este es un gran problema.

Tipo de datos básicos y teoría de algoritmos. Cosas como la notación Big O, matrices, colas, etc.

Cómo elegir la herramienta adecuada para la tarea correcta, y no participar en guerras tontas sobre sus herramientas de programación favoritas.

Bueno, aquí está mi .02 $:

• El aprendizaje nunca se detiene. No importa lo bueno que creas que eres, siempre hay alguien mejor que tú, y siempre hay algo que puedes mejorar sobre ti. Si deja de aprender, inevitablemente se degradará como programador. Leer libros. Leer blogs Habla con otros programadores.
• Intenta aprender varios idiomas. Al menos uno de ellos orientado a objetos. Además, debe saber algo sobre diversas tecnologías relacionadas con el lenguaje que aprende (por ejemplo, si aprende Java, sería bueno que supiera algo sobre Spring, etc.).
• Refactorización Tarde o temprano necesitarás ese conocimiento.
• Aprenda a lidiar con el código heredado.
• Escribir pruebas unitarias. Aprenda sobre TDD.
• Aprende a trabajar en equipo.
• Escribe código elegante y legible. Como dice el viejo dicho: "Escribe tu código como si la persona que lo va a mantener es un asesino en serie psicótico que sabe dónde vives".
• Aprende a ser flojo y disciplinado al mismo tiempo. Los buenos programadores poseen ambas cualidades. Por extraño que parezca, no son contradictorios entre sí, sino complementarios.

No se puede probar la calidad en un producto.

Todo programador debe comprender los patrones de diseño .

Llego un poco tarde a este, pero iré con el conocimiento establecido por Edsger Dijkstra:

Además de una inclinación matemática, un dominio excepcionalmente bueno de la lengua materna es el activo más vital de un programador competente.

Si no puede escribir un buen párrafo, es probable que tampoco pueda escribir un buen código.

No se entusiasme demasiado, se apegue o sea religioso con respecto a una tecnología, sistema operativo o idioma dado, ninguno es perfecto, a la larga es probable que termine deseando poder crear su propia carta a partir de lo que gusta de cada uno diferente.

Piénselo como si fuera un automóvil; es posible que no haya conducido un automóvil en particular antes, pero todos tienen llaves, volantes, aceleradores y frenos: debería poder subirse a uno y conducir rápidamente una vez que sepa dónde está. Trate los sistemas operativos y los lenguajes de manera similar y concéntrese en aprender los conceptos esenciales que los subyacen, incluso si está en medio de los detalles de una instancia determinada.

Y con el tiempo intente comprender y apreciar la ascendencia, el patrimonio y los puntos en común de las diversas tecnologías que lo ayudarán a mantener la perspectiva. Tenga en cuenta, por ejemplo, que, si bien el árbol evolutivo se ramifica activamente y está lleno de callejones sin salida, con el tiempo la tecnología tiende a converger repetidamente en torno a las "mejores prácticas" y las "economías de escala" ( por ejemplo, observe que una Mac no es tan diferente a un PC bajo el capó en estos días ...).

Por último, recuerde que no importa cuánto se divierta con todo esto, la tecnología representa esencialmente una lente imperfecta entre lo que su mente puede imaginar y lo que realmente produce. Haz tu mejor esfuerzo, aprende a aprender y mantente adaptable ...

Cómo programar en C.

Que el día que dejes de aprender debería ser el día en que ya no seas programador.

Pruebas unitarias y depuración.

• Expresiones regulares
  • Para qué son buenos
  • Cuando no a utilizar ellos
  • Cómo escribir expresiones regulares legibles
  • Cómo depurarlos

Se mencionó antes, pero creo que merece su propia respuesta.

Nadie quiere usar software. Quieren problemas resueltos.

Coffee e IntelliSense son tus mejores amigos.

Cómo observar un gran objeto complicado y descomponerlo en pequeños objetos simples que aún logran la misma tarea cuando se vuelven a armar.

Nunca confíes en un usuario ( especialmente si la aplicación es pública!), A menudo harán todo lo que esté en su poder para romper tu aplicación de una forma u otra.

Hazlo a prueba de futuro y ampliable: nunca sabes cuándo quieres expandirlo en unos pocos años y te das cuenta de cuánto esfuerzo se necesitaría para volver a codificar el código mal creado.

Que el programador no lo sabe todo y siempre debe tratar de aprender nuevos lenguajes / tecnologías, etc.

Los fundamentos del buen diseño de interfaz de usuario y diseño de comunicación (también conocido como gráfico) .

Veo muchas aplicaciones y proyectos arruinados por un mal diseño o una mala usabilidad. Solo aprender los conceptos básicos puede marcar una gran diferencia. Además, las técnicas de resolución de problemas visuales (es decir, cómo comunicar un concepto visualmente) son un desafío estimulante que debería abrir los ojos a nuevas formas de ver, lo que a su vez debería tener un impacto en su código.

Un libro recomendado es The Non-Designer's Design Book de Robin Williams

Esto es lo que dice Joel Spolsky :

¡Guauu! Todos tienen que hacer un diseño gráfico, y no todos los equipos de software tienen el lujo de los diseñadores profesionales. Este excelente y delgado libro le dará una idea de los principios detrás del diseño de la página, las fuentes, etc. La buena noticia es que puede leerlo en el baño antes de que el agua se enfríe, y al día siguiente, sus cuadros de diálogo y puntos de poder y Las páginas web comenzarán a verse mejor.

Todo programador debe saber aprender rápidamente. Muchas veces entras en un trabajo y se te pedirá que desarrolles una tecnología que nunca has usado. Es posible que le den una semana más o menos para ponerse de pie (si tiene suerte) antes de que le pidan que escriba un código de calidad de producción.

Control de versiones. Y para citar a mi novia: "¡No solo quiero que laves los platos, quiero que te guste !"

Los requisitos cambian, su código tendrá que adaptarse y puede ser o no usted quien tenga que adaptarlo.

Ha habido varias preguntas aquí relacionadas con temas que se ven afectados por esto.

La parte superior de mi cabeza:

1. Muy pocos problemas de programación requieren matemáticas más allá de la suma, resta, multiplicación y división. Si está pensando en usar el cálculo para resolver un problema, investigue las alternativas exhaustivamente antes de hacerlo.

2. Cada vez que te encuentras adivinando cómo debería funcionar algo, lo estás haciendo mal. No es tu trabajo ser telepático.

3. La persona que te da la especificación rara vez sabe todo lo que quiere hasta que lo has descifrado.

4. Más de la mitad de ser un gran programador proviene de tratar con seres humanos. Interactuar con su equipo, administrar su gerente y perfeccionar al usuario final son la mitad del trabajo.

5. Un buen código está escrito para que la gente lo lea tanto como para que lo lea tu compilador.

6. Las mejores prácticas y la realidad práctica estarán en conflicto más de lo que piensa el programador, pero menos de lo que lo hace el gerente. Cuando parecen estar en conflicto, depende de usted delinear y comprender el conflicto y luego ceder a lo práctico. La solución sutil e inteligente solo es mejor que la fea y brutal si es más rentable a largo plazo.

7. Las grandes herramientas no pueden ser grandes programadores, pero las malas herramientas nos hacen igualmente horribles.

8. Nunca menosprecies una tecnología, pero siempre busca la mejor alternativa.

9. Cuantos más idiomas conozcas, mejor estarás en el que estás usando.

10. No se preocupe por el lento arrastre de pensamientos orientados a la programación en su vida diaria. Incluso cuando no estamos en una computadora, todos sufrimos limitaciones de ancho de banda, tenemos penalizaciones de rendimiento por el cambio de tareas y necesitamos cargar cosas desde el almacenamiento de respaldo. Se supone que las computadoras imitan el pensamiento humano y los análogos están en todas partes.

Leer el código de otras personas no va a estropear tu cerebro, sino más bien descubrir por qué no lo habrías hecho de esa manera (si es mejor o no, esa es otra pregunta).

¡Esto le proporciona programación de gedankenexperiment , y ocasionalmente encuentra a alguien implementando algo mucho mejor! Me gusta mucho mejor.

Esta respuesta se expande naturalmente a leer su propio código, por lo tanto, se expande para usar el control de versiones y DIFF, y por lo tanto a 42.