Tómate en serio el código.

Tal y como yo lo veo, el poder dedicarme profesionalmente a desarrollar sofware es un auténtico privilegio, tenemos en nuestras manos un mundo de posibilidades cada vez que nos ponemos a desarrollar y lo único que nos limita son nuestros conocimientos y el tiempo. Ya que los plazos no van a cambiar es nuestra responsabilidad mantenernos sabios. La excusa del tiempo no vale.

Empápate de todo lo que puedas

Cuando en tu búsqueda diaria de soluciones por  internet te encuentres con una librería o paquete que te solucione el día échale un vistazo a cómo han resuelto el problema, no seas vago, es una pequeña inversión que marca la diferencia. Obviamente el día que vas retrasadísimo y tienes encima a todo el mundo no es el mejor momento para hacerlo, pero si ese buen momento nunca llega es posible que una de las causas sea que necesitas ampliar conocimientos, así que en algún momento tendrás que romper el círculo vicioso.

Intenta conservar tu humanidad

Conforme te vas adentrando en este mundillo te irás dando cuenta de que te estás convirtiendo en un friki de mucho cuidado.

El factor tiempo

El tiempo de desarrollo de una aplicación es cuanto menos Importante, obviamente también es importante que la aplicación esté bien hecha y que hayas aprendido algo por el camino. Si solo has cumplido con el factor tiempo es posible que lo acabes pagando de una forma u otra: oxidándote como una perra o volviéndote loquísimo para saber por qué está dando ese maldito error.

No te cases con un solo lenguaje o tecnología

Hay una tendencia a idealizar el lenguaje de programación con el que estamos cómodos y ya llevamos un tiempo trabajando y a poner a otros que se suelen usar para las mismas tareas a parir o llenarlos de topicazos.

Por ejemplo: El mister C# que dice que PHP es un lenguaje que no tiene cabida en el mundo profesional y que es algo así como para niños. Y el mister PHP que dice que C# es un timo porque solo corre en windows y encima es scritly typed y tiene que ponerle los tipos a las variables, ¡E incluso declararlas!

Aprender otros lenguajes te hará mejor programador, enseñándote otros paradigmas para problemas los problemas que resuelves todos.

Siempre, siempre, siempre hay cambios

Vas a hacer el análisis más riguroso, vas a exponer todo lo que va a hacer la aplicación con pelos y señales, vas a preguntar a todos si están de acuerdo, pero cuando llegue el momento en el que vuelvas victorioso con la aplicación desarrollada tras presentarla en el mejor de los casos te vas a llevar un par de cambios o nuevas features absolutamente necesarios. Esto es así y hay que aceptarlo, cuenta con ello y si puedes incluso planifícatelo.

Mantén las cosas simples

Cuando estamos empezando a desarrollar software el principal reto es conseguir hacer que el código haga las cosas que queremos que haga, esto puede avanzar hasta que llegue un punto en el que te sientas bastante confiado y cómodo con tu capacidad de resolver los problemas que se te presentan día a día.
Por suerte o por desgracia, haber recorrido ese camino no tiene por qué significar que estés aplicando patrones de diseño o TDD. Al margen de estudiases todo esto en la carrera, lo que pasa en muchos casos es que en la práctica estas cosas se dejan bastante de lado, si no hay alguien que haya comprendido muy bien la utilidad de este tipo de cosas, el apagado de fuegos diario te va a empujar a que las dejes de lado. Es tu responsabilidad dedicarle tiempo y hacer ver que contribuyen de forma brutal a la calidad del software final. Hay quien dice que el 80% del coste de los desarrollos se va en debugging, utilizar más los patrones de diseño, hacer nuestro software testable (TDD) o implementar bien conceptos como SOLID harán que ese, a mi parecer enorme  80% disminuya.

Ahora volverás a mirar arriba y dirás: qué cojones quiere decir eso de mantener las cosas simples? menudo coñazo es eso de estar creando 10 clases para algo que antes usaba solo 2.

Me explico con una pequeña metáfora que suelo usar: Imagina que te pones a construir un puente y no tienes npi de ingeniería, empezarías colocando vigas, soldándolas, colocando otras para apañar partes que están más débiles y metiendo parche tras parche. Vamos a imaginarnos que al final acabas construyendo algo que como puente es funcional, aunque al final ha sido un proceso en el que te has complicado la vida muchísimo, has malgastado recursos, es muy poco mantenible e incluso poco fiable. Esto también pasa con el software de forma mucho menos evidente.