Hay un fenómeno extraño que ha surgido entre los editores de software. Parece haber una tendencia a que las personas inviertan su comprensión de lo que hace que un producto de calidad sea mejor, o al menos esto es cierto cuando se trata de quienes hacen el marketing. Va algo así como: "Su producto tiene un millón de líneas de código, pero el nuestro tiene dos millones, por lo que nuestro producto debe ser mejor".
Nadie sabe de dónde vino este tipo de pensamiento de “más es más”, cuando en el pasado todos trabajaban tan duro para crear una filosofía de “menos es más”. Probablemente comenzó con un periodismo orientado al consumidor, porque muchos escritores intentan impresionar al público citando grandes números. Para la mayoría de las cosas, esto funciona — esta pequeña unidad flash contiene 200 terabytes de datos, esa CPU puede procesar 48 mil millones de instrucciones por segundo — y los escritores no siempre son lo suficientemente expertos en tecnología para entender que lo mismo no se aplica al código fuente.
Pero la eficiencia en la codificación no se trata solo de crear algoritmos ajustados. También se trata de poder reducir los residuos. Esto significa una pérdida de tiempo en términos de la cantidad de tiempo que dedica a solucionar problemas, la pérdida en términos de consumir demasiados recursos informáticos e incluso una pérdida de dinero en términos de la cantidad de cajas de pizza que su equipo ha acumulado en la oficina al final de la semana. Idealmente, usted quiere reducir todas estas cosas.
Entonces, lo que veremos en este artículo serán las cosas que podría hacer para mejorar la eficiencia y aumentar la productividad.
1. Construir un ambiente de trabajo propicio
Cada programador está trabajando en circunstancias únicas, y nuestros lectores son un grupo muy diverso, por lo que será más fácil para algunos de ustedes implementar estas sugerencias que para otros.
Si eres un profesional independiente, felicidades, porque ya eres dueño de tu propio entorno de trabajo. Por supuesto, eso va a cambiar cuando vaya a visitar a un cliente y tenga que trabajar en el lugar, pero aún así es una buena posición si puede tener éxito.
Si usted es el gerente de un equipo de desarrollo, estas sugerencias también pueden ayudar a que su equipo tenga la máxima eficiencia. O bien, si trabaja en un equipo de desarrollo, puede sugerir algunas de estas ideas a su gerente o al menos enviarle un enlace a esta página y esperar lo mejor.
Considere permitir que los miembros del equipo trabajen a distancia
La programación es en parte un ejercicio de lógica, pero es aún más un desafío creativo. Los mejores programadores pueden emplear ambos lados de su cerebro en igual medida para cualquier tarea. La ciencia siempre ha reconocido que las personas creativas hacen su mejor trabajo en la noche, y es algo que todos hemos experimentado. Entonces, ¿por qué la mayoría de los gerentes insisten en una rutina tradicional de 9 a 5?
En realidad, ya sabemos la respuesta a eso. En parte se trata de control, y en parte se trata de hacer las cosas más convenientes desde un punto de vista empresarial (o al menos uno de gestión). Pero esa insistencia en la rutina y la ubicación está afectando la eficiencia y la productividad del equipo.
Lo que hay que tener en cuenta es que sus programadores probablemente estuvieron despiertos toda la noche probando el último juego, o tal vez se fueron de fiesta o simplemente tuvieron que socializar con la familia. Significa que cuando se presentan a trabajar el lunes por la mañana, no solo no los está alcanzando en su nivel máximo de productividad, sino que ya están agotados de energía y cansados.
Dar a los trabajadores una opción sobre cuándo trabajan, e idealmente también dónde, es una excelente manera de mejorar la productividad y la moral. Mientras hagan el trabajo y obtengan excelentes resultados, no debería preocuparse por cuándo, dónde o cómo lo logran.
La excepción es cuando se necesita una colaboración estrecha, pero en realidad a la mayoría de los programadores les va mejor cuando se les deja hacer las cosas a su manera, y la necesidad de una colaboración cercana es rara. La opción de ingresar a la oficina aún debería estar allí, pero no hay una razón realista por la que deba ser requerida a menos que esté trabajando en proyectos militares de alto secreto.
Como freelancer, también puede ver que el punto clave aquí es que si realiza la mayor parte de su trabajo de codificación real en la noche, es probable que haga más. Hay menos distracciones a altas horas de la noche, es más tranquilo y te sentirás más creativo.
Evitar la musica
Todos hemos visto esos estereotipos de películas locas en las que un súper grungy überhacker se pone sus auriculares y se atasca en el death-metal mientras produce sin esfuerzo muchas pantallas de código sin siquiera detenerse a respirar. Y todos los que realmente codificamos en el mundo real sabemos lo ridícula que es esa imagen.
Pero si escuchas música mientras trabajas, ten cuidado. Es bastante fácil encontrarte pensando en la música en lugar de en tu trabajo, y algunos tipos de música pueden tener un efecto soporífero. Cuando haces ejercicio en el gimnasio, el tipo de música adecuado podría inspirarte a presionar esas pocas repeticiones adicionales. Pero nadie ha logrado crear música que lo inspire a encontrar la línea con el punto y coma faltante, o hacer la elección correcta entre usar un bucle for o un bucle while. Lo más cerca que hemos llegado a eso es Electric Dreams.
Tratar de mantener ordenado
El desorden puede ser extrañamente reconfortante, pero también puede ralentizarlo. Puede perder fácilmente los minutos 20 en busca de algo que se ha perdido en el desorden y, luego, olvidar por qué lo quería en primer lugar.
Entonces, a pesar de todos los inconvenientes que causa, ¿por qué somos, al menos algunos de nosotros, tan adictos al desorden? La autora y experta en organización, Julie Morgenstern, afirma que esto se debe a que estas cosas nos conectan con nuestro pasado y juegan un papel en la definición de nuestra identidad. Marcus Geduld, profesor y director de escena de la ciudad de Nueva York, sugiere que se debe a que el desorden es preferible a un entorno "estéril" y compara el caos del desorden con un affirmación de la libertad y la creatividad.
Sin embargo, no hay duda de que reducir el desorden lo ayudará a evitar distracciones y desorganización. Como tal, es un objetivo digno de lograr. Por todos los medios, mantenga algunos objetos sagrados alrededor que lo hagan sentir mejor y menos estresado, pero no exagere. Ordenar es una de las cosas más difíciles de hacer para la mayoría de las personas, y no es solo nuestro físico desktops que necesitan limpieza, pero a menudo nuestra computadora desktoptambién Si realmente tiene problemas con eso, podría intentar usar un DTE minimalista como Fluxbox, que realmente no le permite tener ningún desorden.
Pero en medio de toda esta ordenación, no exageres. Hay un montón de buena ciencia que sugiere que un poco de caos en el entorno puede ser realmente propicio para la creatividad. Uno de los fragmentos de investigación que se citan con mayor frecuencia sobre esto es una entrada en el diario en Psychological Science por Vohs, Redden & Rahinel para la Universidad de Minnesota titulada El orden físico produce elecciones saludables, generosidad y convencionalidad, mientras que el desorden produce creatividad. Probablemente la razón por la que este es el papel al que se aferran los periodistas es que claramente concluye que: "... los participantes en una sala desordenada eran más creativos que los participantes en una sala ordenada".
Mucho menos populares son las opiniones disidentes, tales como Trastorno ambiental conduce a falla autorreguladora (Chaye & Zhu, 2014), publicado en el Journal of Consumer Research. Este estudio encontró que las personas que trabajan en entornos desordenados tenían problemas en su capacidad para realizar tareas.
Entonces, ¿dónde te deja esto? ¿Debes trabajar en caos o esterilidad? La respuesta parece ser encontrar un equilibrio donde sea lo suficientemente caótico como para mantenerte inspirado, pero no tanto para distraerte o tener problemas para encontrar cosas.
Deja algo de espacio detrás de ti para pasear tus pensamientos
Es una buena idea tener suficiente espacio para vagar cuando estás deliberando. Muchos de los mejores almirantes y generales de la historia fueron famosos por el tiempo prolongado que pasaron caminando por la cubierta mientras planeaban estrategias de batalla.
No solo los combatientes siguen esta práctica. Muchos monjes budistas también abogan por la “meditación caminando” y creen que ayuda a promover la claridad mental. Siempre que tenga un problema de programación particularmente complicado que resolver, es posible que le resulte útil estirar un poco las piernas con una caminata meditativa por la terraza. Obviamente, una vez más, la falta de desorden lo ayudará a hacer esto sin terminar en el hospital.
Como jefe, adopte un enfoque cauteloso a la crítica de los esfuerzos creativos
No hay nada malo con la crítica constructiva, pero debe elegir el momento adecuado y abordarlo de la manera correcta, o puede ser contraproducente al hacer que su personal sea menos productivo en el futuro. En lugar de inspirarlos y proporcionarles una visión, puede hacer que teman correr riesgos, lo que es una buena manera de acabar con la creatividad. Marieke Roskes, en Restricciones que ayudan u obstaculizan el rendimiento creativo: un enfoque motivacional, proporciona un marco sobre cómo lidiar con la motivación de los trabajadores creativos y, específicamente, también sobre cómo evitar desmotivarlos involuntariamente (Creativity & Innovation Management, Vol. 24, Iss 2, 2015).
2. Establecer un buen SOP
Hay muchas tendencias pegadizas en la gestión empresarial y los procedimientos de programación que suenan mucho más sensatos en teoría de lo que resultan en la práctica. Si un enfoque en particular funciona para usted o no, depende de su objetivo y de lo que personalmente considere un resultado exitoso.
Un ejemplo de una metodología para la cual trabajé en una empresa en la que trabajé, y que se eliminó rápidamente, es la programación en pares (que no debe confundirse con la programación PEAR). Si bien algunas personas realmente admiran esta metodología de trabajo y elogian su lugar en el paradigma de desarrollo ágil, encontramos que era terriblemente ineficiente. Para empezar, se necesitaban dos programadores para cada estación de trabajo, por lo que pagaba el doble por menos trabajo de desarrollo real. También descubrimos que era mucho más lento trabajar de esta manera debido al flujo frecuente de parada / inicio y la tendencia a un diálogo innecesario.
Las ventajas de la programación en pares fueron que dio como resultado una documentación más natural y una documentación más estricta. También permitió detectar errores más fácilmente y hacer sugerencias sobre cómo reforzar un algoritmo. Al mismo tiempo, sin embargo, las mismas ventajas también crearon problemas porque a veces los ajustes y ajustes no eran realmente necesarios.
Otro riesgo con este enfoque es que puede obtener el efecto identificado por Roskes, donde los programadores pueden dudar en probar cosas porque no quieren ser corregidos. Es posible que encuentres choques de personalidad cuando un desarrollador es muy pedante y tradicional, pero el otro es más creativo y espontáneo.
Los programadores a menudo afirman que prefieren la programación en pares. Es posible que esto se deba a que disfrutan de la interacción social que ofrece, pero esto no contribuye en nada a la eficiencia de la producción, excepto tal vez como un refuerzo de la moral.
Entonces, lo que necesita establecer es lo que realmente funciona para sus desarrolladores y lo que no. Para las cosas que no funcionan, es mejor descartarlos, incluso si se trata de una práctica de tendencias acaloradas. Cualquier cosa que ayude al equipo a progresar rápidamente es algo bueno. Pero si están sobrecargados con una metodología que no se adapta a su estilo, eventualmente resultará en problemas.
3. Fomentar documentación detallada
Si bien puede parecer que la verbosidad aumentaría la ineficiencia, la pequeña cantidad de tiempo que se tarda en dar más detalles y precisión en los comentarios puede ahorrar muchos problemas a medida que el proyecto avanza o se somete a revisiones.
4. Desalentar documentación innecesaria.
El código bien escrito es a menudo auto-documentado. Si es perfectamente obvio lo que hace una función con el nombre que le da (lo que casi siempre debería ser el caso), entonces agregar más descripción es superfluo. Lo mismo ocurre con la denominación de variables y los valores de retorno. Debe quedar claro en el nombre lo que hacen, y en aquellos casos donde no es posible hacerlo, debe incluir una descripción de ellos en los comentarios.
5. El espacio en blanco es tu amigo
Usar el espacio en blanco adecuadamente en su código es valioso para ayudar a que el código sea más fácil de leer, revisar y entender. Va de la mano con una buena documentación y escritura de código de auto-documentación. Debería ser posible para cualquier programador experimentado, o tal vez incluso para alguien que no sea programador, recoger una copia de su código fuente y entender instantáneamente cuál es el propósito de cada función y cómo funciona. Idealmente, alguien debería poder aprender a programar desde nada más que estudiar su código bien escrito.
6. Prefiere la simplicidad a la complejidad.
Cuanto más complejo sea el código, más difícil será desenredarlo. Irónicamente, esto se aplica a los accesos directos de programación, como usar condicionales abreviados en lugar de escribirlos en su totalidad. Se ahorra tiempo en la escritura, pero un programador menos experimentado que revisa su código más adelante puede que no entienda sus intenciones.
7. Prueba exhaustiva
El código debe ser probado de forma incremental y frecuente. Antes de implementar cualquier cosa, debe realizar tantas pruebas internas como sea posible, incluso si su primer lanzamiento será designado como Alfa.
8. Usar control de versiones
Tendrías que estar loco para no usar el control de versiones en un proyecto importante. Sin eso, no estás protegido de tus propios errores menores, y también es muy fácil para otro miembro del equipo sabotear tu código accidentalmente (o intencionalmente) al sobrescribirlo con algo que no te complace.
Al tener en cuenta estas ocho sugerencias clave, podrá desarrollar su propia estrategia para extraer la mayor eficiencia para usted y para cualquier miembro del equipo con el que trabaje. No necesariamente tiene que aplicarlos todos, y es probable que algunos ni siquiera sean prácticos para usted, pero es probable que cualquier combinación de ellos resulte en la realización de su trabajo con menos complicaciones. Un flujo de trabajo más productivo se pagará solo con el tiempo, incluso si es solo en términos de reducción del estrés y le da más tiempo para usted. Ese es un objetivo por el que vale la pena trabajar.
Comentarios Comentarios 0