¿Qué debería saber todo desarrollador pero probablemente no?

Estas son algunas de las mías (para agregar a las excelentes respuestas hasta ahora):

1. Su capacidad para comunicarse con otros desarrolladores, gerentes de proyecto, gerentes de producto, arquitectos, jefes, clientes, etc. tendría un impacto mayor de lo que piensa. Entonces, comience a mejorar su capacidad de escribir correos electrónicos convincentes, escribir actualizaciones de estado, escribir un error, hablar frente a 10 personas y hablar frente a 100 personas. Sí, estas son habilidades significativamente diferentes.
2. Un bloque de código suficientemente grande sin la documentación que lo acompaña podría ser una caja negra. A pesar de lo que la gente dice, el código extraterrestre es duro, maldito duro.
3. No importa cuánto creas que entiendes un problema, algún caso extraño surgirá DESPUÉS de que creas que has terminado. A veces aparece como un error P0 dos noches antes de pasar a GA.
4. Para reforzar el número 1, la mayoría de las personas en el mundo tecnológico son horribles para comunicarse. Incluso si tienen una licenciatura en inglés o comunicación de masas o marketing. Los expertos en tecnología suelen ser peores.
5. Algún día tendrías que cavar en un bloque de código escrito 10 años antes. Y no importa cuán “zen” seas, hay una buena posibilidad de que quieras estrangular a la persona que lo escribió.
6. Cada pieza de código base suficientemente grande tiene errores. Y tiene muchos errores latentes (es decir, nadie sabe que están allí). Y al tratar de agregar alguna nueva característica o corregir un error conocido, hay una muy buena posibilidad de que le haga cosquillas a uno de esos errores latentes y su vida sea un infierno.
7. Hay muy pocos desarrolladores que pueden perseguir un error de un sistema al siguiente y al siguiente y encontrar la verdadera causa raíz. El hecho de que alguien tenga N años de experiencia en algún lenguaje, sistema operativo, marco, etc., no significa que realmente puedan hacerlo.
8. Una persona de prueba realmente competente es casi tan rara como un unicornio. Si encuentra uno trabajando con usted, cuente sus estrellas de la suerte. Tal persona puede destrozar su servicio en pedazos en poco tiempo, exponiendo muchos de los errores. Ayúdelos a descubrir sus errores y a perseguirlos y corregirlos ANTES de que el cliente los encuentre y usted esté en sesiones de depuración durante toda la noche.

¿Qué debería saber todo desarrollador pero probablemente no?

Continuando de la excelente lista de Alan Mellor:

1. El control de calidad no es su equipo de prueba personal . Lanza tu código no probado a ellos, y las probabilidades son buenas de que encuentren tantos errores, recibirás una severa reprimenda … o ser despedido por incompetencia.
2. “¿Qué problema estás tratando de resolver?” Comenzar tu trabajo sin una respuesta clara a esa pregunta generalmente conduce a sangre, sudor y lágrimas innecesarias … y no hay un producto viable para demostrarlo. (Muchas startups murieron para traerte esta información).
3. Los controles de realidad son siempre su responsabilidad . Cuando su jefe se compromete a entregar flujos de datos de 2000 x 100KB / s a ​​través de Gigabit Ethernet, es su responsabilidad hacerle saber que “2 en 1 simplemente no funcionará”.
4. La aritmética mental nunca pasa de moda . Ver [3].
5. Sɥᴉʇ sucede, especialmente en el código . Es por eso que tenemos códigos de error, ¡así que deja de ignorarlos!
6. No eres Superman Las sesiones de codificación de toda la noche a menudo significan sesiones de depuración / reescritura de toda la semana. Manténgase saludable y bien descansado.
7. La otra regla 80-20 . El primer 20% del proyecto lleva el 80% del tiempo, mientras lidias con las tecnologías y los requisitos. El otro 80% toma el 80% para siempre, a medida que lidia con nuevas tecnologías (también conocidas como distracciones) y requisitos (también conocido como “el cliente cambió de opinión”).
8. Una máquina verde mala se hará cargo de su código para el mantenimiento . ¡Esa persona probablemente serás tú, en un estado de WTF estaba pensando cuando escribí esto?!?! , así que escribe un código simple y comprensible. En las palabras inmortales del Dr. David Bruce Banner: “Hola, no me enojes. No me gustaría cuando estoy enojado “.
9. Las revisiones de código no son concursos molestos . El objetivo es hacer un mejor código, no comparar los tamaños de las pitones de cada uno.
10. Es un trabajador pobre quien culpa a sus herramientas . Eliges las tecnologías, vives con las consecuencias. Tal vez la próxima vez no estés tan ansioso por subirte al autobús v0.1 de TresCool.js.

• No optimices demasiado pronto. Los requisitos cambiarán y es poco probable que su código altamente optimizado sobreviva.
• El uso de un marco, un lenguaje o lo que sea solo porque es rápido y no necesita la ampliación ahora, es una señal de optimización temprana. Está justificado si los requisitos exigen que sea rápido, pero la velocidad de ejecución es solo una de las principales consideraciones.
• Los requisitos cambiarán
• Su elección de idioma no determina qué tan “profesional” es usted
• Lo mismo para su elección de sistema operativo
• Lo mismo para su elección de IDE
• Su jefe / clientes quieren una solución de trabajo sobre la mejor solución
• Usar control de fuente. Te salvará el culo algún día
• Utilice la copia de seguridad manual incluso si tiene control de fuente. Te salvará el culo algún día
• Vale la pena echarle un vistazo a la ‘oposición’ de vez en cuando, independientemente del campo en el que te encuentres.
• No trate a un programador de C ++ como si fuera un dios de la programación solo porque usa C ++. Puede significar una cierta habilidad en el manejo de la memoria, y eso es todo.
• El código que se puede mantener es mucho mejor que el código inteligente. El código que resuelve un problema y se puede extender fácilmente es mucho mejor que el código inteligente.
• No obedezca servilmente patrones de diseño u otros marcos de ingeniería de software (DDD, MVC, lo que sea) a menos que tenga un gran equipo, mucho tiempo y mucha experiencia. O no tendrá tiempo suficiente para implementar todos los ideales, o habrá requisitos que lo harán imposible.
• No reinvente la rueda, a menos que sea realmente inteligente
• No solo use los marcos más populares. Sin embargo, hace que la contratación sea más fácil
• Use un código autoexplicativo si es posible
• Comentarios cuando es absolutamente necesario , aunque
• No es fácil mantener la documentación actualizada
• No tienes que aplastar todos los errores
• Solo podrá buscar ayuda en Google de manera efectiva después de haberlo dominado, sea cual sea ” (un nuevo marco, una biblioteca, PNL, comandos IMAP no intuitivos, etc.)

Cómo diferenciar entre prioridad y severidad.

Por lo general, tendrá dos clases de trabajo al mismo tiempo: implementación de requisitos y corrección de errores. Tanto los requisitos como los errores tendrán prioridad y gravedad. Llamemos tanto a los requisitos como a los tickets de errores, ya que generalmente nos ocupamos de ambos utilizando el mismo sistema.

La prioridad es lo importante que es el boleto para el cliente.

La gravedad es lo importante que es el ticket para la solución.

Hacer que los clientes comprendan la diferencia puede hacer que su vida como desarrollador mejore incalculablemente.

Asignar un valor de prioridad a un ticket generalmente se trata de medir su impacto en términos de valor comercial. Los clientes tenderán a priorizar los tickets que creen que los ayudarán mejor a generar ingresos / alcance / retención.

Asignar un valor de gravedad a un ticket generalmente se trata de medir y mitigar el riesgo. Los clientes tenderán a exagerar el riesgo al considerar las entradas de forma aislada. Si también confunden gravedad con prioridad, esto puede conducir al comportamiento clásico de hacer que todo sea de alta prioridad, especialmente al principio de un proyecto. Comprender cómo separar la gravedad y la prioridad puede ayudarnos a tener conversaciones útiles con los clientes sobre cuáles son sus prioridades reales para el trabajo, y nos ayudará a entregar el software de trabajo más rápido.

No estoy completamente de acuerdo con la regla KISS (Keep It Simple Stupid). Creo que todos deberían conocer los inconvenientes de la regla KISS :

En mi experiencia, la regla debería aplicarse al 75% de los casos, pero la regla también es CONS. La mayoría de las cosas más novedosas en la industria de las aplicaciones no son simples, ¿verdad? Piense en el motor de búsqueda de Google, los algoritmos de la base de datos de Facebook, IBM Watson, Counter Strike, Google Maps, Above Photoshop o incluso Quora. Si los algoritmos detrás de estas aplicaciones fueron creados por KISS RULE en foco, estos algoritmos se llamarían operaciones matemáticas simples, no algoritmos en absoluto.

Puede afirmar que cuando enfocamos el enfoque más cerca, las cosas deberían ser muy simples. Bien cierto, pero alguien tiene que DISEÑAR y ver el panorama general en cada algoritmo. Tenemos que diseñar la solución más simple posible, pero a veces no podemos hacerlo simple sin perder la funcionalidad esencial.

Durante mi carrera de programación, he estado allí muchas veces: mis socios están dispuestos a resolver un problema a través de la solución más simple, mientras que estoy dispuesto a tomar el camino más largo. Sus soluciones son muy simples pero rígidas e inconvenientes. Mi solución es complicada pero muy dinámica y conveniente para el cliente. Podría estar diseñando una inteligencia artificial durante semanas, pero adivina qué, ha valido la pena. Mis soluciones a veces son tan complicadas que la mayoría de los desarrolladores ni siquiera se atreven a tocar el código mientras el cliente está sin duda satisfecho.

Las soluciones más simples no siempre son las mejores porque la simplicidad tiene que ver con el precio, la rigidez y la “corrupción de la realidad”. La realidad no es simple . Cuando intentas convertir la realidad en simplicidad, siempre terminas con una gran cantidad de defectos.

Esta es mi opinión honesta, pero estoy de acuerdo en que la simplicidad es importante, aunque a veces tenemos que reconocer que no existe una solución que venga con ambas cualidades: simplicidad y conveniencia. Aconsejo recoger la conveniencia. Después de la decisión, hazlo lo más simple posible.

Mis soluciones a veces son tan complicadas que la mayoría de los desarrolladores ni siquiera se atreven a tocar el código mientras el cliente está sin duda satisfecho. Agencia de diseño gráfico Los Angeles