Software Engineering Tips (nota de Pablo: tomen en cuenta que estamos hablando de startups, evidentemente algunas de estas cosas no son tan implementables, o faciles de implementar en empresas ya formadas, con productos en el mercado, etc) :
Puesto que el software está en el corazón de cada arranque moderno necesita ser elegante, simple y ágil. En vez de tener un ejército de codificadores paga tener un puñado de ingenieros elegantes, apasionados, que aman lo que estan haciendo. Un equipo pequeño, apasionado puede lograr generalmente más que un ejército. Incluso mientras que la compañía crece usted puede todavia lograr mucho con un equipo pequeño.
Tip 0: Deben tener código
Código de sw funcionando prueba que un sistema es posible, y también prueba que el equipo puede construir el sistema. Tener código funcionando es un launchpad para su negocio. Después de que esta listo, el negocio puede suceder. En los viejos días, se financiaron compañías de tech basandose en una idea escrita en un pedazo de papel, pero esos días son largos idos. Hoy, un arranque necesita tener no solamente código de sofwtare funcionano, pero un sistema montado y usuarios activos para conseguir capital para la empresa.
Tip 1: Debe tener un co-fundador técnico
Cualquier startup comienza con una idea y apenas algunas personas. Muchos de co-fundadores de Startups son techies, apasionados sobre tecnología. No fue siempre asi. Apenas algunos años atrás un equipo de fundación puramente técnico habría tenido problemas para levantar capital porque había una escuela del pensamiento seguna la cual solamente MBA podrían dirigir una compañía. Ahora, tener un co-fundador técnico es una ventaja.
Tip 2: Contraten solo Ingenieros clase A+ que aman programar
Hasta hace poco tiempo, la construcción de un sistema de la escala grande que funcione era como magia negra. La mayoría de los proyectos del software demoraban años, y tenían equipos grandes de ingeniería que tenían poco consenso en qué era necesario hacer y cómo lograrlo. Los sistemas que resultaban estaban llenos de bugs,eran inestables, y dificiles de mantener y de extender. El problema era justamente que habia mucha gente y que no eran excelentes en programar. Los startups no pueden permitirse tener ingenieros menos de A+.
Tip 3: Mantengan un equipo de pequeño y no outsourceen
Un equipo de 2-3 ingenieros rockstar puede construir practicamente cualquier sistema porque son buenos en lo que hacen, les encanta disenar software, ponen foco en la meta, y no se meten en los asuntos del otro. Un equipo de 20 ingenieros mediocres no llegara lejos. La verdad es que la mayoría del software bueno es construido hoy por apenas un puñado de buenos ingenieros. Menos es más se aplica igualmente al código y al número de la gente que trabaja en él.
Tip 4: Hagan preguntas dificiles durante la entrevista
No hay nada peor que ser suave durante una entrevista con un empleado anticipado y emplear a la persona incorrecta en la compañía consecuentemente. Esto es malo para la empresa, pero más importantemente es malo para la persona. Al final terminará despidiendolo, pero sería el mejor apenas no incurrir en esta equivocación de entrada. Sean duros y hagan muchas preguntas técnicas durante la entrevista.
tip 5: Eviten emplear a gerentes no técnicos
Ustedes no necesitan estetipo de gente en un equipo pequeño. ¿Si cada uno es bueno, sabe lo quehace y ejecuta su tarea, para que necesita un gerente? Gente que sobrepone procesos complejos por encima de sus objetivos van a retrasarlos y frustralos.
Tip 6: Cultiven una cultura ágil
Los startups modernos necesitan moverse muy rápidamente. No hay tiempo para planificar por 6 meses y después de ejecutar porque algún competidor llegara antes. El nuevo approach es desarrollar el sistema constantemente. Por supuesto que planificando para el lanzamiento siguiente, pero iterando rápidamente, desarrollando versiones frecuentes, realizando constantemente cambios.
Tip 7: No reinvente la rueda
Muchos startups se ahogan con su infraestructura. Esto incluye dos tipos de cosas – reconstruir libraries y construyendo su propio codigo. En el primer punto – hay tan bibliotecas con codigo fuente ahi afuera que no tiene sentido de escribirlas en casa. Si están utilizando Javascript o PHP o NET O python o rubi, hay probablemente ya bibliotecas listas. Reescribir bibliotecas existentes es una pérdida de su tiempo y no es probable que ustedes puedan hacerlas mejor.
Pablo Brenner & Sergio Fogel Blog 
Me parecieron muy buenos y estoy de acuerdo así como intento poner en práctica siempre (o casi siempre) estos puntos a la hora de llevar a cabo proyectos propios o ajenos. El que puntualmente me resultó interesante, como programador fue el último. Somos muchos los que por momentos, por seguridad o por no conocer los detalles internos de implementaciones ajenas, optamos por escribir nuestras propias librerías, lo cual para los inicios, para lanzar un prototipo, o una primera versión que luego iremos mejorando, terminan enlenteciendo los avances, lo cual redunda en desmotivación a corto plazo. También es cierto que en algunos casos, probablemente nuestras librerias propietarias sean de menor calidad que las existentes. Me es útil leer éste punto en particular, que su no aplicación ya me ha jugado varias veces malas pasadas, y que yo mismo debo repetirme a mi mismo en algunos momentos antes de cometer el error.