Convertirse en el equipo de un solo hombre más eficiente [cerrado]

Estoy aprendiendo a pasar mucho más tiempo planeando mi día del que solía. Esto incluye la planificación de proyectos, hasta escribir código psuedo para la programación que necesito hacer. Me parece que con todas las interrupciones en mi horario, es difícil para mí empezar en algo. Tener todo dividido en pequeñas tareas hace que sea mucho más fácil comenzar después de una interrupción.

De acuerdo con la investigación operativa, shortest job first es el mejor programador para hacer la mayor cantidad de cosas.

Escribo y corro pruebas de integración y del sistema, pero no pruebas unitarias, porque no necesito pruebas tempranas (pre-integración): ¿Debería probar una implementación interna o solo probar el comportamiento público?

Un corrolario de la Ley de Conway es que usted necesita probar las interfaces internas de software que separan/integran a los desarrolladores, mientras que un "ejército de un solo hombre" no necesita probar explícitamente sus interfaces internas de esta manera.

Muchos de los otros consejos son buenos, pero se aplican igualmente a los desarrolladores que trabajan en equipo, así como a un desarrollador solitario.

Creo que lo más difícil como un equipo de un solo hombre es la comunicación efectiva con el resto de su empresa. Siempre serás una voz de programadores solitarios en cualquier reunión o discusión sobre la mejor manera de construir software.

Como resultado, aconsejaría tratar de mejorar las habilidades de negociación y enfocarme en mejorar la forma en que describe los conceptos técnicos en términos de no programador puede entender. Leer libros como Getting to Yes y How to win friends and influence people son una buena manera de empezar.

Cuando hay más de una persona de acuerdo en un punto de vista, el punto de vista automáticamente gana credibilidad con aquellos que está tratando de convencer. En ausencia de esta posibilidad usted necesita trabajar extra duro en la preparación de sus argumentos con evidencia bien investigada y una visión equilibrada.

Estoy en la misma situación. Ya hay un montón de buenos consejos anteriores, pero una cosa que añadiría es encontrar cuándo son sus mejores tiempos de codificación y asegurarse de que está codificando durante ese tiempo. Tengo un par de horas en la mañana en las que parezco estar en mi mejor momento para programar. Trato de mantener ese tiempo libre de todas las distracciones. Planifique cosas como reuniones, escribir documentación, hacer pruebas (al menos las cosas tediosas y repetitivas) y todas esas otras cosas para su tiempo menos productivo. Mantenga esas horas de codificación cuando eres de 2 a 5 veces más productivo para la codificación.

• Asegúrese de refactorizar temprano y con frecuencia. Eso sirve casi como un segundo par de ojos (para mí, al menos).
• No trabajes horas insanas (especialmente difíciles si trabajas desde casa). En realidad, trabajar menos horas a menudo resulta más productivo a medida que la presión inminente de descanso/final del día aumenta su eficiencia.
• Es posible que desee buscar Ley de Parkinson para la gestión del trabajo/tiempo.

Uso un archivo de texto para recopilar todas las cosas que hago todos los días. Cada vez que me encuentro con un problema o tengo una pregunta o encuentro una solución, lo agrego a mi archivo. Es muy de baja tecnología, pero proporciona una gran cantidad de información, como "¿dónde estoy pasando la mayor parte de mi tiempo?"o" ¿cómo arreglé ese problema antes?". También hace que sea súper rápido darle a su cliente una lista de horas al final de su ciclo de facturación.

También uso otro archivo de texto (por cliente) que contiene todos los elementos de trabajo en mi plato, organizado en orden de prioridad, y actualizado con frecuencia. Me ayuda tanto a mí como a mis clientes a enfocarme en lo que debería estar trabajando a continuación, por lo que la bomba siempre está lista.

Eventualmente me alejaré de los archivos de texto planos para usar algo como FogBugz, pero por ahora no puedo superar el precio, o lo fácil que es buscar, o lo fácil que es enviar un correo electrónico.