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

time management strategies (8)

Escribo y ejecuto pruebas de integración y de sistema, pero no pruebas de unidad, porque no tengo necesidad de realizar pruebas tempranas (preintegración): ¿una prueba de implementación interna o solo prueba el comportamiento público?

Un corolario de la Ley de Conway es que necesita probar las interfaces de software internas 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.

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 puntos negativos. No tengo la capacidad de consultar rápidamente con otros desarrolladores, rara vez tengo un segundo ojo para mi código, y estoy seguro de que ustedes también pueden encontrar muchos otros aspectos negativos.

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

Estoy aprendiendo a pasar mucho más tiempo planificando mi día que antes. Esto incluye la planificación de proyectos, hasta la escritura del 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 con algo. Tener todo dividido en pequeñas tareas hace que sea mucho más fácil comenzar después de una interrupción.

Estoy en la misma situación. Ya hay muchos buenos consejos arriba, pero una cosa que agregaría es encontrar cuándo son tus mejores tiempos de codificación y asegurarte de que estés codificando durante ese tiempo. Tengo unas pocas horas por la mañana que parece que estoy en mi mejor momento para programar. Intento mantener ese tiempo libre de todas las distracciones. Planee cosas como reuniones, redacción de documentos, 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 sea 2 a 5 veces más productivo para la codificación.

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

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

Como resultado, recomendaría tratar de mejorar las habilidades de negociación y centrarme en mejorar la forma en que describe los conceptos técnicos en términos que un no programador pueda entender. Leer libros como Llegar a Sí y Cómo ganar amigos e influir en las personas es una buena manera de comenzar.

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

Según la investigación operativa, el trabajo más corto primero es el mejor planificador para hacer la mayor cantidad de cosas por hacer.

Utilizo un archivo de texto para recopilar todas las cosas que hago todos los días. Cada vez que me encuentro con un problema, tengo una pregunta o encuentro una solución, la agrego a mi archivo. Es de muy poca tecnología pero proporciona una gran cantidad de información, como "¿Dónde gasto la mayor parte de mi tiempo?" o "¿Cómo solucioné ese problema antes?". También hace que sea muy rá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 placa, organizados en orden de prioridad y actualizados con frecuencia. Me ayuda tanto a mí como a mis clientes a concentrarme en lo que debería trabajar a continuación, por lo que la bomba siempre está cebada.

Eventualmente me alejaré de los archivos de texto plano para usar algo como FogBugz, pero por ahora no puedo mejorar el precio, ni lo fácil que es buscar, ni lo fácil que es enviar correos electrónicos.

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

Lista diaria de lo que voy a hacer.
Eliminar tantas distracciones como sea posible para centrarse en las tareas. Desactiva el correo electrónico, desactiva la mensajería instantánea, etc. incluso durante un período de tiempo determinado y luego, durante un descanso, revísalos.
Tómese tiempo para aprender sobre otras técnicas de codificación, herramientas y sabiduría de programación. Esto me ha parecido crucial para mi desarrollo. Es muy fácil simplemente codificar y sentirse productivo. ¿Qué pasa con lo que podría ser si tuvieras más conocimientos / armamento bajo tu cinturón para tocar el siguiente widget? Sé que este realmente suena contraproducente pero realmente no lo es. Conocimiento / saber como es nuestra moneda real. Cuanto más sabemos, más podemos tomar una mejor decisión sobre cómo se debe hacer algo y hacerlo más rápido.
Tome descansos y sea consciente de su cuerpo. Cuando estamos cansados, no pensamos tan bien y cometeremos más errores, nos frustraremos más fácilmente, etc.
Aprende a usar la regla 80/20 a tu favor. No me refiero a escatimar o ser perezoso. A menudo, aunque trabajamos nuestra cola para ese 20% cuando no era necesario.
Fíjese metas (diarias, semanales, quincenales). Asegúrese de que los objetivos también estén en línea con los que está codificando o puede encontrar que ha perdido tiempo.

Desde un aspecto técnico consideramos:

Considerar la prueba de unidad / TDD. He encontrado en mi propio trabajo que esto realmente ahorra tiempo. Se necesita un tiempo para dominarlo, pero con cualquier cosa mejorarás.
Cuida tu código. Refactorícelo (especialmente si comienza la prueba unitaria). Cuanto mejor sea su código, más fácil será mantenerlo, lo que llevará menos tiempo. Cuanto más fácil sea comprender, más rápido podrá cambiar / implementar características.