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

Question

Como muchos aquí, soy un equipo de desarrollo de un solo hombre. Soy responsable de todo, desde reunir los requisitos del proyecto, diseñar pantallas conceptuales, planificar y desarrollar bases de datos, y escribir todo el código.

Ser un equipo de un solo hombre es bueno, pero tiene sus aspectos negativos. No tengo la capacidad de consultar rápidamente con otros desarrolladores, rara vez tengo un segundo par de ojos para mi código, y estoy seguro de que ustedes también pueden aportar muchos otros aspectos negativos.

Para aprovechar al máximo mi tiempo y comprometerme más eficientemente con mi trabajo, ¿qué consejos o prácticas podría implementar en mi rutina diaria para ser el mejor equipo de un solo hombre posible?

Answer 1

• Lista diaria de lo que voy a hacer.

• Elimina tantas distracciones como sea posible para enfocarte en las tareas. Desactive el correo electrónico , desactive la mensajería instantánea, etc. ... incluso si durante un período de tiempo determinado y luego durante un descanso, consúltelos.

• Tómese el tiempo para aprender sobre otras técnicas de codificación, herramientas y sabiduría de programación. Esto he encontrado que es crucial para mi desarrollo. Es fácil codificar y sentirse productivo. ¿Y qué pasaría si tuvieras más conocimiento/armamento en tu haber para sacar ese próximo widget? Sé que este realmente suena contraproducente, pero realmente no lo es. Conocimiento/saber cómo es nuestra moneda real. Cuanto más sepamos, más podemos tomar una mejor decisión sobre cómo se debe hacer algo y hacerlo más rápido.

• Tome descansos y tenga en cuenta su cuerpo . Cuando estamos cansados ​​que no pensamos así y hará más errores, frustrarse más fácilmente , etc ...

• Aprende a utilizar la regla del 80/20, su ventaja . No me refiero a skimp ni a ser vago. A menudo, sin embargo, trabajaremos nuestro tail off para ese 20% cuando no fuera necesario.

• Establezca metas para usted (diariamente, semanalmente, quincenalmente). Asegúrese de que los objetivos también concuerden con los que están codificando o puede encontrar que han perdido algo de tiempo.

Desde un punto de vista técnico consideran:

• Considere Unidad de prueba/TDD. He encontrado en mi propio trabajo que esto realmente ahorra vez. Se necesita un tiempo para obtener el , pero con cualquier cosa que mejore.
• Cuide su código. Refactorícelo (especialmente si inicia la prueba de la unidad ). Cuanto mejor sea su código , más fácil es mantener que lleva menos tiempo. Cuanto más fácil sea entienda más rápido puede cambiar las características /implementar.

Answer 2

• Asegúrate de refactorizar temprano y con frecuencia. Eso sirve casi como un segundo par de ojos (para mí, al menos).
• No trabaje horas locas (especialmente complicado si está trabajando desde casa). En realidad, trabajar menos horas a menudo resulta más productivo ya que la inminente presión de ruptura/fin de día aumenta su eficiencia.
• Es posible que desee consultar Parkinson's Law para la gestión del trabajo/tiempo.

Answer 3

De acuerdo con la investigación operativa, el trabajo más corto primero es el mejor planificador para hacer la mayor cantidad de cosas.

Answer 4

escribo y pruebas de integración de ejecución y del sistema, pero no hay pruebas de unidad, porque no tengo ninguna necesidad de que las primeras pruebas (pre-integración): Should one test internal implementation, or only test public behaviour?

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

Answer 5

Estoy aprendiendo a pasar mucho más tiempo planificando mi día de lo que solía hacerlo. Esto incluye planear proyectos, escribir código psuedo para la programación que necesito hacer. Encuentro que con todas las interrupciones en mi agenda, es difícil para mí comenzar algo. Tener todo dividido en pequeñas tareas hace que sea mucho más fácil comenzar después de una interrupción.

Answer 6

Utilizo 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, la agrego a mi archivo. Es de muy baja tecnología pero proporciona una gran cantidad de información, como "¿dónde paso la mayor parte de mi tiempo?" o "¿cómo solucioné ese problema antes?". También hace que sea superrápido darle a su cliente una lista de horas al final de su ciclo de facturación.

También utilizo otro archivo de texto (por cliente) que contiene todos los elementos de trabajo en mi plato, ordenados por orden de prioridad y actualizados con frecuencia. Nos ayuda tanto a mí como a mis clientes a enfocarme en lo que debería estar trabajando a continuación, para que la bomba siempre esté preparada.

Eventualmente me alejaré de los archivos de texto plano 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.

Answer 7

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 de un equipo de un solo hombre es la comunicación efectiva con el resto de su empresa. Siempre serás una voz solitaria de programadores en cualquier reunión o discusión sobre la mejor forma de crear software.

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

Cuando hay más de una persona que está de acuerdo en un punto de vista, el punto de vista automáticamente gana credibilidad con aquellos a los que intenta convencer. En ausencia de esta posibilidad, debe esforzarse más para preparar sus argumentos con pruebas bien documentadas y una visión equilibrada.

Answer 8

Estoy en la misma situación. Ya hay muchos buenos consejos, pero una cosa que agregaría es encontrar cuándo son los mejores tiempos de codificación y asegurarse de que está codificando durante ese tiempo. Tengo algunas horas en la mañana que parezco estar en mi mejor momento para codificar. Intento mantener ese tiempo libre de todas las distracciones. Planee cosas como reuniones, escribir documentación, 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 tiene entre 2 y 5 veces más productividad para la codificación.