Creo que el mío es "no hay tal cosa como un trabajo de cinco minutos": que los programadores tienden a ser demasiado optimistas sobre el desarrollo y que realmente deberíamos pensar en las implicaciones antes de prometer una solución rápida a un problema y luego sumergirnos en el código
Respuestas:
Siempre hay una mejor manera de escribir tu código.
No importa cuán excelente encuentre el código que escribe, se sorprenderá de lo malo que es si lo revisa en unos años. Solo porque unos años antes, no conocías algunos patrones que conoces hoy, o algunas características del lenguaje que has aprendido mientras tanto, etc.
Piensa antes de comenzar a codificar.
No hay nada más permanente que soluciones temporales :)
Si es muy difícil resolver un problema, lo más probable es que el problema en sí esté mal planteado desde el principio.
Su software vivirá considerablemente más de lo que cree que lo hará en el momento en que lo escriba.
Comencé mi carrera en los años 80. Comencé con un software que se originó en los años 70 y todavía se usaba en los 90 (quizás más tiempo, no estoy seguro de su destino). Parte de mi propio código fuente abierto está a la mitad de su segunda década.
Trabajar bien con los demás es muy importante.
"Muéstrame tu 'Vete al chico' y te mostraré tu problema"
Los codificadores de héroes Slapdash, aquellos que simplemente descifran el código sin tener en cuenta la convención, la legibilidad o lo que sea que alguien más esté trabajando, pueden causar más daño que bien.
No digo que las personas que pueden escribir toneladas de código de buena calidad sean algo malo. Solo raro.
Esa sería la lección de humildad.
Aprender nuevos idiomas es parte del trabajo.
Aprendí acerca de cuatro lenguajes de programación en la escuela en los años 80, pero he usado uno de ellos en un trabajo. He tenido cuatro trabajos en los que ni siquiera sabía el idioma para el que me contrataron.
En general, he aprendido y utilizado profesionalmente tal vez una docena de idiomas en mi carrera, incluidos FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript y a pocas DSL pequeñas Haciendo un poco de matemática, parezco promediar un nuevo idioma cada dos años, aunque hay mucha superposición.
Si algo ha sido una constante en mi carrera, es un cambio.
El software nunca está completo.
Siempre hay algunos cambios en los requisitos, mejoras, correcciones de errores que debe estar preparado para manejar. Por lo tanto, sea flexible y acepte el hecho de que "software is never complete"siempre tiene margen de mejora.
Sigue estudiando todos los días. El conocimiento de hoy es obsoleto mañana.
Irónicamente, esta respuesta también debería ser obsoleta mañana. Pero realmente, estudie mucho una o dos cosas y certifíquese si es posible, sea el Dios de esas cosas (tal vez lenguajes de programación o administración de sistemas / redes / bases de datos) y siempre esté atento a otras cosas menores, como otros idiomas sin importancia para tú.
Quiero decir, por ejemplo, ser un excelente profesional de la administración de Java y Oracle DB, pero estudiar un poco de Python, PHP, C ++, HTML5, Javascript, aunque no a un nivel de certificación. Estudie cada marco web o lenguaje que exista. Estudie o intente tener una experiencia (básica) con cada base de datos que exista, como SQL Server, MySQL, Cassandra, HBase, PostgreSQL y todo el mundo sin SQL como MongoDB y CouchDB. Intente tener algo de experiencia con la administración y virtualización de Linux.
Esa es la mayor lección que aprendí de mis 16 años de experiencia. Durante casi 10 años fui un programador en un solo idioma, usando Pascal en su época, y Visual Basic 6 a principios del milenio, y un desarrollador de PHP desde hace 9 años. Pero desde entonces aprendo que los desarrolladores necesitan saber al menos un poco de todo.
He aprendido que el mejor principio de diseño es KISS (¡Hazlo simple, estúpido!) .
He aprendido que mantener su código simple y limpio debe ser la principal preocupación, y cada miembro del equipo debe entender lo que tiene el código. The KISS principleestablece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de ser complejos, por lo tanto, la simplicidad debe ser un objetivo clave en el diseño y se debe evitar la complejidad innecesaria.
Aquí no hay intentos
Digamos que tiene una tarea o un montón de tareas que se estima que demoran 4 días. Luego, su jefe o gerente de proyecto le pregunta si podría intentar hacerlo en dos días por alguna razón importante. Deseando ser un empleado bueno y flexible, puede sentirse tentado a decir: claro, puede intentarlo. Los resultados más probables de esto es que usted no cumple con la fecha límite, o va a hacer un truco a medias para hacerlo. Y no es culpa de tu jefe pedirte que lo hagas, ese es su trabajo. Es tu culpa por no decir que no, que es tu trabajo.
No puedes regatear con el tiempo. Puede negociar con alcance. Sé profesional y no te vengas corto.
"Eso nunca sucederá" en realidad significa "Eso nunca sucederá hasta el primer día de producción"
Escribir código es fácil. Leer el código es difícil. Incluso si el código es tuyo. Entonces, siempre que sea posible, opta por un enfoque legible.
No eres más inteligente que los demás. Nunca pienses que tu enfoque es el mejor solo porque es tuyo.
Presta atención a lo que se dice, no a QUIEN se dice. Pueden surgir ideas brillantes para las fuentes más inesperadas.
No seas perezoso Tómese su tiempo para escribir un buen código. Tendrás que arreglarlo de todos modos a un costo más alto.
¡No use las características de OOP elegantes solo porque puede! - YAGNI (No lo vas a necesitar)
Use fancy OOP featuresporque tienen un beneficio específico y demostrable para el problema que está tratando de resolver . Te ríes, pero veo esto todo el tiempo. La mayoría de los programadores nunca encontraron un objeto que no les gustara. Creo que debería ser al revés: estas técnicas son culpables hasta que se demuestre su inocencia en la corte de KISS .