Publicado por Salvatore Sanfilippo, desarrollador y mantenedor del motor de base de datos Redis gratuitoHace unos meses, el responsable de un proyecto de código abierto del sistema me escribió con una comunidad bastante grande y activa. Escribió que durante muchos años ha estado luchando para apoyar su proyecto, pero está experimentando un grave estrés psicológico. Pedí consejo. Respondí que apenas podía dar consejos, pero prometí escribir una publicación de blog sobre lo que pienso sobre esto.
Pasaron varias semanas, comencé a escribir esta publicación varias veces y me detuve porque no tenía tiempo para pensarlo detenidamente. Ahora, al parecer, he completado el autoanálisis de mis debilidades, dificultades y deseo de libertad. Estos sentimientos inevitablemente abrazan la mente humana cuando se concentra en alguna tarea, y un aspecto negativo se manifiesta durante mucho tiempo. Por supuesto, apoyar el proyecto Open Source también trae mucha alegría y placer. Los últimos diez años de mi vida profesional serán recordados por mucho tiempo. Estos son buenos años, aunque no los mejores (fue aún más divertido durante el lanzamiento). Pero aquí me enfocaré en el lado negativo. Solo tenga en cuenta que hay puntos positivos.
Avalancha de solicitudes
No creo en "acción rápida", "pensamiento rápido", "victoria en el tiempo" y cosas por el estilo. No me gusta el mundo superficial con la falta de concentración y atención en la que vivimos debido a las redes sociales, salas de chat, correo electrónico y un calendario lleno de eventos. En los primeros años de Redis, todavía tenía mucho tiempo. Cuando llegó la carta, podía concentrarme tranquilamente en lo que el autor intentaba decir. Podía recordar la parte relevante del código de Redis y, después de considerar cuidadosamente el problema, finalmente expresar mis pensamientos reales. Creo que así es como debería trabajar la mayoría de las personas, sin importar cuál sea su trabajo.
Cuando un proyecto de software alcanza popularidad, como Redis, y la comunicación entre las personas se simplifica tanto como en las herramientas sociales modernas, entonces todo cambia. Los usuarios lo tratan como una entidad inanimada, y la cantidad de mensajes, preguntas, solicitudes y sugerencias está creciendo exponencialmente. Pero al mismo tiempo en la comunidad Redis (aunque me parece que este es un problema común), el número de personas que pueden responder a estas preguntas de manera experta está creciendo muy lentamente. Se crea una congestión obvia. La mayoría de las personas son demasiado pragmáticas sobre este problema. Cerramos el boleto si el abridor no ha respondido nuestra pregunta dentro de dos semanas. Cierre todos los boletos con palabras vagas. Y otras opciones para la limpieza mecánica de la corriente. Pero la realidad es que lleva tiempo procesar bien las revisiones. De lo contrario, simplemente pretende que el proyecto tiene pocos tickets abiertos. Sería bueno tener muchos recursos para contratar expertos pagados a tiempo completo para apoyar cada subsistema de Redis durante un día completo, pero en realidad esto no es factible.
Entonces, ¿qué está pasando? Empiezas a priorizar más: qué considerar y qué no. Y te sientes como un pedazo de mierda, ignorando tantas preguntas y tanta gente, y los contribuyentes creen que no te importa su trabajo. Esta es una situación difícil. Por lo general, al final, solo los problemas críticos se resuelven al final. Todo lo nuevo se ignora, porque las nuevas funciones aún no se han vuelto básicas, y ¿quién quiere aumentar la base del código, obtener aún más solicitudes de extracción y problemas? Puede estar comenzando a escribir código más confuso de lo habitual. Cuanto más confuso sea el código, más difícil será rastrear la causa raíz en caso de un error crítico.
Cambio de rol
Debido a la avalancha de solicitudes descritas anteriormente, su trabajo también está cambiando repentinamente. Redis se ha vuelto popular porque sé cómo diseñar y escribir código. Y ahora, en cambio, me ocupo principalmente de la resolución de problemas y solicitudes de extracción. Y constantemente parece que yo mismo escribiría un código mejor que en estas solicitudes de extracción. Aunque a veces el código es mejor de lo que yo podría hacer, porque hay mejores programadores en la comunidad de Redis. Pero la
mayoría simplemente se escriben para resolver un problema específico. Si bien siempre represento el sistema como un todo, porque he estado trabajando en él durante muchos años. Pero no hay más tiempo para hacer esto. Por lo tanto, las nuevas funciones grandes están menos integradas orgánicamente en el código principal. ¿Qué hay para hacer? A veces solo paso varias semanas en boletos y solicitudes de extracción porque codifico o diseño: este es un trabajo que realmente amo y disfruto. Pero esto, a su vez, aumenta la presión psicológica, porque ignoro a todos.
Para hacer lo que amo y saber hacer bien, tienes que sentirte como una mierda.
Tiempo
Hay dos problemas de trabajo prolongado en un proyecto, al menos para mí.
En primer lugar, antes de Redis,
nunca trabajaba sin descanso, todos los días hábiles. Podría trabajar una semana, parar por dos, luego trabajar por un mes, desaparecer por dos meses. Siempre. Las personas necesitan recargarse, obtener nuevas energías e ideas, ser creativos. Y la programación de alto nivel es un trabajo creativo. Redis en sí vivió así durante los primeros dos años, es decir, cuando se desarrolló a la máxima velocidad. Porque el agotamiento total de mi trabajo cuando quiero trabajar es mayor que cuando tengo que trabajar todos los días de manera sostenible.
Cuando trabajaba solo, podía permitirme un horario gratuito. Tan pronto como comencé a recibir dinero de Redis Labs, mi ética ya no me permitió esto. Tuve que obligarme a trabajar en un horario normal. Esta es una pelea seria conmigo misma, que he estado librando durante muchos años. Además, estoy seguro de que, debido a esto, la calidad y el volumen de trabajo han disminuido, pero no hay nada que hacer: todo está organizado en este mundo. No encontré una manera de resolver este problema. Podría decirle a Redis Labs que quiero volver a mi horario anterior, pero no tiene sentido, porque en este momento estoy "informando" a la comunidad, y no a la empresa.
Otro problema es que mucho trabajo en un proyecto también es una cosa difícil, mentalmente. En el pasado, cambié específicamente el proyecto cada seis meses. Llevo diez años haciendo lo mismo. Para mantener mi mente, comencé subproyectos dentro de Redis. Una vez que hice un clúster, el otro: almacenamiento en disco (ahora abandonado), luego HyerLogLogs, etc. Básicamente, estas cosas son útiles para el proyecto, pero en esencia son otra cosa. Pero al final, siempre regresa a la misma página con tickets y solicitudes de extracción y hace lo mismo todos los días: "La réplica se desconecta debido a un tiempo de espera" y así sucesivamente. Bueno, tratemos con esto una vez más.
Miedo
Siempre tuve miedo de perder el liderazgo tecnológico en el proyecto. No porque no sea bueno diseñando y desarrollando Redis, sino porque sé que mis caminos no coinciden con lo que un gran número de usuarios desean y lo que la mayoría de las personas en TI consideran un buen software. Por lo tanto, tengo que equilibrar constantemente entre lo que considero un buen diseño, un conjunto de funciones, velocidad de desarrollo (lenta), tamaño del proyecto (mínimo) y lo que debo dar a la mayoría de los usuarios. Afortunadamente, hay un porcentaje de usuarios de Redis que entienden muy bien Redis-way, así que al menos recibo algunas palabras de apoyo de vez en cuando.
Desacuerdo
Algunas personas son idiotas completos. Están en todas partes, es natural. En mi opinión, hay mucha más gente buena en programación que en otras áreas. Pero siempre hay un porcentaje de imbéciles absolutos. Como líder del popular proyecto OSS, tendrá que lidiar con ellos de todos modos. Quizás esta sea una de las cosas más estresantes con las que traté durante el desarrollo de Redis.
Inutilidad
A veces me parece que incluso el software más excelente nunca durará para siempre, como una obra maestra de la literatura. Tenga en cuenta que esto no se debe a su calidad, sino a un efecto secundario de su función utilitaria ... Es útil en la práctica. Es por eso que algo más útil vendrá a reemplazarlo. Me gustaría tener tiempo para otras clases. Por lo tanto, a veces parece que todo mi trabajo, al final, es inútil. Diseñamos y escribimos sistemas, pero luego aparecerán nuevos. En general, ¿es al menos un programador aplicado, y no un teórico con "grandes ideas", capaz de dejar algún tipo de rastro? De vez en cuando, creo que tuve la oportunidad de trabajar en grandes ideas, pero me concentré en escribir el software, en lugar de pensar en ello. Por lo tanto, no podría usar mi potencial a este respecto. Esto es lo opuesto al síndrome del impostor: lamento tener que ser más modesto.
Sin embargo, pude trabajar durante muchos años, haciendo lo que realmente amaba, lo que me dio amigos, reconocimiento y dinero. Esto no quiere decir que fue un mal negocio. Sin embargo, entiendo completamente que las personas enfrentan grandes desafíos tan pronto como su proyecto se vuelve popular. Este artículo está dedicado a ellos.