Recomendaciones para trabajos de ingenieria informatica

Trabajar en equipo es normalmente algo a los que nos obligan ciertamente en nuestros centros de estudios pero una vez que empezamos a trabajar se vuelve una constante ya que no existe nadie que pueda realizar todo el trabajo (por lo menos en un tiempo optimo). Aunque estos consejos tienen un mayor enfoque a la programacion van mas alla de trabajos de informática pues se pueden aplicar en cualquier ambito de la ingenieria a final de cuentas.

Cuando trabajes en grupo, sobre todo si estáis intentando solucionar un problema, no eches la culpa de nada a tus compañeros, déjales que se equivoquen -es parte de la búsqueda-, colabora y asume las responsabilidades aunque no hayan sido tuyas.
Por el contrario, si alguien nunca asume una responsabilidad o error, o culpabiliza a otros hasta de que no le dejan hacer nada, intenta que quede fuera del equipo. O que al menos no moleste.
Participarás en proyectos interesantes y en otros que son simplones. En realidad todos pueden ser interesantes, depende de la actitud con que los encares: siempre hay cosas que mejorar y aplicar ideas creativas.
Puedes ser un doctor o un graduado en el MIT, pero a la hora de la verdad tu compañero autodidacta y tú ejercéis de ingenieros. Trátalo como tal, los títulos formales solo sirven como carné de autoridad para la universidad, entre colegas no cuentan, solo lo que has demostrado saber hacer.
Lee mucho código de terceros, fundamentalmente de las librerías, módulos y programas que usas habitualmente. Es una de las mejores formas de aprender.
No dejes de leer, no solo de libros técnicos específicos, también de historia de la informática y ciencia, un poco de filosofía y psicología, álgebra, estadística y algo de cálculo.
No te contentes con dominar una herramienta o lenguaje, aprende cómo funciona toda la pila que lo sustenta: el hardware, el sistema operativo, la máquina virtual o compilador, el API, las librerías, etc. Aprende C o ensamblador, son clarificadores de cómo funcionan las máquinas y todo lo que hay por encima.
Domina al menos tres lenguajes diferentes que cubran: compilados, dinámicos, y funcionales.
Tus programas nunca serán perfectos ni lo suficientemente buenos. Con el paso de los años te avergonzarás de tu propio código. Esto es bueno, has mejorado.
Cuando programes piensa en los lectores de ese programa: escribe y comenta en inglés, que el código sea elegante, si el código te parece espagueti o ilegible descártalo y empieza de nuevo, no dejes de refactorizar mientras programas. No tengas miedo de descartar programas, no es tiempo perdido. Programar es como escribir un libro pero más complejo, si hasta los mejores autores siempre descartan capítulos o textos completos, ¿por qué tú habrías de acertar a la primera?
No empieces a programar como un mono, pasa horas pensando, camina, conversa con colegas, pregunta, haz un prototipo, descártalo y vuelve a empezar hasta que esas primeras líneas no te den asco ni te generen desasosiego por lo que se viene: todo lo contrario, deberían entusiasmarte a seguir programando.
De todas las ideas o propuestas, elige siempre la opción más sencilla (el KISS). Si no hay ninguna que sea claramente sencilla es porque falta pensar más. Si durante el desarrollo te das cuenta que hay soluciones más simples para hacer lo mismo (es muy habitual), descarta y comienza de nuevo.
No hagas optimizaciones prematuras ni tampoco diseño de lo desconocido. Lo primero genera código más difícil de verificar y lo segundo complica el sistema con funcionalidades que nunca se usarán.
Si cuando sale una nueva tecnología eres capaz de darte cuenta en qué podría servirte pero te ríes del hype y buzzwords es señal de que estás madurando como profesional.
Si además de acabar tus proyectos en tiempos razonables y con programas fiables, los haces con buen humor, te acaban ilusionando hasta los más coñazos y festejas como un crío cuando pudiste solucionar una tontería que te tomó horas, ya eres un buen profesional. O al menos no un coñazo de profesional. Que es casi lo mismo.
Siempre explica a tus colegas por qué haces algo o tomas una decisión. En el código o tomando un café.