Cómo escribir un buen código bajo presión.

Ponte duro: no trabajes bajo presión; trabajar sobre la presión.

Créditos de imagen: Pixabay.com

En muchos sentidos, escribir código es casi como realizar una cirugía.

El cirujano está tratando de salvar su vida, pero está operando dentro de un plazo, un plazo que no es negociable. Está bajo una intensa presión.

¿Cómo le gustaría que se comportara el médico? ¿Quieres que parezca tranquilo y sereno? ¿Quieres que emita órdenes claras y precisas a su personal de apoyo? ¿Quieres que siga su entrenamiento y se adhiera a sus disciplinas?

¿O lo quieres sudando y maldiciendo? ¿Te gustaría si se descompone bajo presión y realiza actividades irracionales? ¿Confiarías en tu vida con un médico así?

Un buen programador simplemente no se vuelve bueno porque escribe un código increíble. Se vuelve bueno porque se mantiene tranquilo y decisivo en situaciones de presión. A medida que crece la presión, se adhiere a su entrenamiento y disciplinas, sabiendo que son la mejor manera de cumplir con los plazos y compromisos que lo presionan.

En resumen, lo hace y sigue haciendo lo "correcto" que debe hacerse independientemente de los plazos que se ciernen sobre él.

Y esta no es una tarea fácil de hacer, día tras día. El desafío es mantenerse lo suficientemente frío como para manejar la presión en este momento para que pueda tener éxito en el futuro.

Y aquí están algunas de las formas en que los buenos programadores manejan situaciones de presión.

No honre los compromisos que no haya hecho USTED

Como programador, siempre tienes dos opciones: tu compromiso versus tu miedo.

Su compromiso es la fecha y la fecha límite que usted le dio para completar su trabajo. Y cuando haces eso, lo más importante que tienes contigo es tu palabra, tu confianza. Tienes que hacer que suceda, pase lo que pase. Ahí es donde te ganas tu respeto.

Experimenta miedo cuando alguien más se compromete en su nombre.

Si, eso pasa. A veces se hacen compromisos para nosotros. A veces descubrimos que nuestro negocio ha hecho promesas a los clientes sin consultarnos. Sin embargo, no estamos obligados a aceptar los compromisos.

La diferencia entre compromisos es importante.

Los profesionales siempre ayudarán a la empresa a encontrar una manera de lograr sus objetivos. Pero los profesionales no necesariamente aceptan los compromisos asumidos por la empresa. Al final, si no podemos encontrar la manera de cumplir las promesas hechas por el negocio, entonces las personas que hicieron las promesas deben aceptar la responsabilidad.

Esto no es facil. Se ejerce presión sobre todos cuando no se cumplen los compromisos. Pero al menos si te has comportado profesionalmente, puedes mantener la cabeza en alto y mantenerte firme.

Y si nadie está dispuesto a entender su punto de vista, es hora de renunciar a su trabajo.

No corte las esquinas.

No hay nada llamado "Código rápido y sucio". El código sucio es un código incorrecto. Período. Nunca corte esquinas ni acepte nada que sea de segunda categoría.

Su verdadera prueba como buen programador entra en crisis. Si su comportamiento cambia durante una crisis, entonces no es un buen programador. Por ejemplo, si sigue la disciplina del desarrollo impulsado por pruebas en tiempos que no son de crisis, pero la abandona durante una crisis, entonces no confía realmente en que TDD sea útil.

Si mantienes tu código limpio durante los tiempos normales pero haces un desastre en una crisis, entonces realmente no crees que los problemas te retrasen.

Nunca descuides las pequeñas cosas. Nunca escatime en ese esfuerzo extra, esos pocos minutos adicionales, esa entrega de lo mejor que puede hacer. No importa lo que piensen los demás, sin embargo, es de suma importancia lo que pienses de ti. Siempre recuerda que cortar esquinas te perseguirán, si no ahora más tarde.

Y los programadores profesionales nunca toman la ruta fácil y crean códigos desordenados para moverse rápidamente. Hacen el mejor trabajo posible y ofrecen la salida más limpia posible, pase lo que pase.

Comunicar, comunicar y comunicar.

Comunicación. Se trata de honestidad. Se trata de tratar a las personas de la organización como merecedoras de conocer los hechos. No intentes contarles la mitad de la historia. No intentes ocultar la historia. Los tratas como ... como verdaderos iguales, y te comunicas y te comunicas y te comunicas.

Si tiene información importante para compartir con su jefe, colegas, proveedores, incluso si no son buenas noticias, no espere. Si pospone proporcionarles información procesable hasta que sea demasiado tarde para actuar, entonces sus noticias nunca serán bien recibidas, ya sean buenas o malas.

En casi todos los escenarios imaginables, le conviene comunicarse lo más rápido posible, permitiendo que todos los involucrados comprendan y digieran la información, formulen una reacción apropiada y respondan en consecuencia. Si son malas noticias, su alerta temprana podría permitir una planificación suficiente para minimizar el daño.

Sobre todo, manténgase profesional, cortés, directo y claro: todos los rasgos que moverán su comunicación en la dirección correcta durante su tiempo en su lugar de trabajo actual.

Y, por último, obtenga ayuda cuando las cosas se pongan difíciles

¡Par! Cuando el calor esté encendido, busque un asociado que esté dispuesto a emparejar el programa con usted. Terminará más rápido, con menos defectos. Su pareja le ayudará a mantener sus disciplinas y evitar que entre en pánico.

El rápido tiempo de desarrollo del par a menudo proviene de un mayor enfoque. Emparejar literalmente es tener a otra persona mirando por encima del hombro todo el tiempo. Las personas que participan activamente en el emparejamiento tienen menos probabilidades de distraerse por las interrupciones (por ejemplo, consultar el correo electrónico, divagar en tareas no relacionadas o mirar fijamente la pantalla durante minutos).

Incluso las tareas secundarias relacionadas se pueden bloquear. La persona en el teclado puede enfocarse en golpear el código, mientras que el socio puede preocuparse por la legibilidad, la capacidad de prueba, la solidez, la migración de actualización del usuario y otros problemas de "panorama general" relacionados con el nuevo código. Trabajar con un par proporciona presión positiva para permanecer en la tarea.

El período de ajuste de la programación en solitario a la programación colaborativa es como comer un pimiento picante. Es posible que la primera vez que lo pruebe no le guste porque no está acostumbrado. Sin embargo, cuanto más lo comes, más te gusta.

Y lo más importante de todo es que crea una cultura de colaboración y gratitud. La próxima vez que vea a alguien más bajo presión, ofrezca emparejarse con ellos. Ayúdalos a salir del agujero en el que se encuentran.

Como Booker T. Washington ha dicho con razón.

"Si quieres levantarte, levanta a alguien más".
Sobre el Autor-:
Ravi Rajan es un gerente global de programas de TI con sede en Mumbai, India. También es un ávido blogger, escritor de poesía haiku, entusiasta de la arqueología y maníaco de la historia. Conéctese con Ravi en LinkedIn, Medium y Twitter.

Esta historia se publica en The Startup, la publicación de emprendimiento más grande de Medium, seguida de +445,678 personas.

Suscríbase para recibir nuestras principales historias aquí.