Perdí la fe en la industria, me quemé, pero el culto a la herramienta me salvó



A menudo critico las tecnologías que considero inadecuadas, y en respuesta recibo (junto con argumentos) pura ira y dolor. A veces fisico.

Los desarrolladores toman la crítica de sus tecnologías favoritas muy personalmente por alguna razón. Este "culto a la herramienta" es un fenómeno tan extraño que no puedo explicarlo lógicamente. Algunos dicen que todos son propensos, porque los procesos de pensamiento de un codificador se entrelazan muy profundamente con su lenguaje de programación. Algunos dicen que es la falacia de un joven: escribes algo por primera vez, funciona, y comienzas a tratar tu lenguaje como algo divino.

Sea lo que sea, nunca lo entendí.

Siempre consideré a los cultistas como imbéciles. Pero siempre trato de entender por qué los imbéciles se convirtieron en ellos, por qué he evitado ese destino. Empiezo a pensar y bam! - Resultó que también soy un imbécil. Soy un cultista que adora a F #. Y, por supuesto, hay una historia detrás de esto.



Comencé como desarrollador junior de C #. Luego, Xamarin en bruto, desarrollo de Android, todo el shebang. Mis primeros pasos en el trabajo estuvieron llenos de dolor. Tuve que escribir una aplicación de Android sola basada en capturas de pantalla y gifs de la versión de iOS. Solo se compiló en cualquier otro momento, los buga estaban por todas partes, y el único comentario que recibí fue: "¿por qué no es así en la captura de pantalla?". Fue una pesadilla y me fui rápidamente.

Luego pasé medio año aprendiendo a codificar en casa, y luego conseguí un trabajo en un gran personal. Allí estaba mucho más organizado: equipo, mentores, exámenes, patrones, revisión de código, linters estrictos, altos estándares de calidad de código, legibilidad y rendimiento. En una palabra, todo estaba maduro. Y pensé que así debería funcionar. Pero, como resultó, fue una pesadilla aún mayor.

Durante más de un año, todo nuestro equipo estaba creando un módulo para una herramienta que funcionaba con herramientas que se usaban para hacer otras herramientas. Probablemente los mismos que usamos para hacer los módulos. Todos los días teníamos que llamar a indios y estadounidenses e informar sobre Dios sabe qué.

En algún momento me di cuenta de que estaba haciendo cada vez menos, pero nada cambió. Mentí entre dientes en inglés roto: “Durante toda la semana pasada busqué un insecto. Todavía no hay éxito. Continuará ".

"Ok Phil, suena genial" - respondieron mis socios transatlánticos.

En un momento, desesperado y vergonzoso, fui a la gerencia y pedí que me despidieran, pero por alguna razón me dieron un aumento. Ya he contado esa historia antes. No estaba feliz ni triste: parecía una broma surrealista, como si la lógica de este mundo se estuviera desmoronando.

Por extraño que parezca, por aburrimiento y por ser extremadamente ambicioso, decidí desarrollar las cosas en casa y hacer todo "correctamente". Tenía numerosas ideas sobre cómo usar proyectos de software para mejorar el mundo y mi billetera. Hice todo por el libro: un documento de diseño, arquitectura, requisitos del sistema, proyectos VSTS. Todo estaba organizado y maduro, como en las corporaciones.

No estaba llegando a ninguna parte.

Conclusión natural: la idea era una mierda. Código antiguo en el contenedor, nueva idea. Mismo resultado. Comienza de nuevo. Esto continuó un par de veces. Le digo a mis compañeros de trabajo y están confundidos. ¿Qué estoy haciendo mal? Lo hago exactamente de la misma manera que aquellos que ya se hicieron ricos por la parte posterior.

Las personas con mi (alto) nivel de autoestima a menudo están mejor que otras, pero a veces tienen que pagar por ello. Necesita mentirse a sí mismo para hacer frente al fracaso. Y me dije: cualquier desarrollador es capaz de cualquier cosa. Se trata de cómo se hace, y mis requisitos para "cómo" son demasiado altos. No son aptos para una startup doméstica y no son dignos de tareas comerciales sin sentido. Pensamiento siguiente: "No estoy listo para abandonar mis estándares de calidad". Incluso si necesito hacer una aplicación que se pedo cuando tocas la pantalla, la haré lo más hermosa y pensada posible.

Así que establecí un negocio local de culto de carga en casa. Traído sobre todo - rituales, procesos, estándares - pero no la carne real de la cosa. Interpreté a un desarrollador de negocios sin un negocio, como un hombre de las cavernas que hizo una pista y una torre de vigilancia de paja y esperaba que aterrizaran pájaros de acero en ella.

Escribí montones sobre montones de código formal y estricto que no me acercó más al resultado final, sino todo lo contrario. Si lo piensas bien, mi carrera es una historia de fracasos y decepciones. Lo dejé por completo y solo vi programas de televisión en el trabajo mientras tomaba 16 tazas de café al día.

En el fondo, noté un artículo de Habr sobre F #, lo probé y pensé "¡Hm, no está mal!". Mi empleador felizmente pagó por un mes de estudio para mí (aunque él no lo sabe).

F # no fue difícil de aprender, ya que tenía el mismo tiempo de ejecución que C # y ya usaba el enfoque funcional para programar en TypeScript todos los días. Me di cuenta de que puedo transferir cualquiera de mis proyectos a F #. Dejemos mi habilidad técnica fuera de la ecuación por un momento, ya que todo es relativo. En los equipos en los que trabajo soy genial, pero en un equipo de, por ejemplo, desarrolladores de F #, no podría ser más que un conserje.

Pero podía resolver problemas en un nivel básico, aunque en el fondo lo sabía: realmente no podía resolver nada. Continuaré arrojando conocimiento a la basura. Perdí completamente mi fe en la programación.

Un día decidí que ya era suficiente. Iba a renunciar. Era un frío y oscuro día de invierno. Salí de la oficina, me subí a mi auto y no arranca. Después de un tiempo, el motor finalmente cobró vida. No sé si noté el humo del olor a plástico quemado antes, pero luego estalló un fuego debajo del capó. Un par de segundos después, estaba corriendo por el estacionamiento diciéndoles a todos que alejaran sus autos del mío.

Cinco minutos después de pánico y caos, solo quedaba una vieja carcasa de auto en llamas y un teléfono con estúpidos videos de YouTube. Era -30C, y estaba con una capa ligera de un hombre que tenía la intención de conducir a casa en un automóvil cálido. Completamente gastado y moralmente destruido. No tengo dinero para un taxi y me preocupo demasiado por mí como para subirme al transporte público. Caminé a casa, unos 10 km. En casa necesitaba ayudar a mi esposa con el niño, comer, llevarlos a la cama, hacer mil cosas pequeñas. Pero con el tiempo ya no hay nada por lo que distraerme y me quedé cara a cara con mi insomnio y una comprensión: no soy digno de nada, nunca tendré éxito.

En esta, la peor tarde de mi vida, todavía fría por un paseo helado a casa, me di una última oportunidad.



Me senté y escribí un pequeño bioma digital en F #, donde las unidades de aprendizaje automático interactúan entre sí y se desarrollan, mientras juego con los parámetros y veo lo que sucede.

Y sí, esa noche probablemente me volví un poco loco.

Usualmente uso una mezcla del modelo de programación ascendente y descendente. Esbozo una solución aproximada con pseudocódigo, luego empiezo a escribir los detalles más importantes como módulos separados. De pequeño a grande.

Pasando del pseudocódigo al código real, completo uno o dos módulos grandes y verifico si algo funciona. Por lo general, no es así, así que empiezo a repetir, repitiendo este proceso de principio a fin hasta que funcione. Pero la mayoría de las veces me doy por vencido después de la 5ta o 6ta iteración.

Intenté el mismo enfoque con F #. Tuve una visión general del proyecto, y luego la solución fue construir, ladrillo por ladrillo, en mi cabeza. Se te ocurre un caso tras otro y luego, en algún momento, te das cuenta de que sabes cómo hacerlo funcionar. Y luego comienzas a codificar y te das cuenta de que no, no lo haces. Los pensamientos no se traducen a lenguajes de programación, aunque a menudo piensas en ellos. Me pasaba esto todo el tiempo.

Esta vez, sin embargo, fue diferente. Creé un archivo .txt en VSCode y escribí el pseudocódigo para una función que describe el ciclo de vida de mi aplicación. Y me di cuenta de que mi pseudocódigo es válido en F #. No es necesario traducir nada, solo escribí la función principal de mi proyecto. Bien, cambié la extensión del archivo, lo agregué a la solución limpia. Estaba mi función del ciclo de vida. Acepta el estado mundial actual, algo que lo procesa (el mundo mismo) y escupe el estado actualizado, algo que lo traduce en un conjunto de parámetros de IA y viceversa, además de la propia IA que acepta parámetros y escupe la solución. .

Entonces fue simple. Tomas el estado, lo conviertes en parámetros de IA, los alimentas a la IA, vuelves el resultado al estado mundial, lo entregas al juego y el resultado vuelve a la función del ciclo de vida. Una hermosa recursión, un algoritmo simple, un código sublime, todo el GoF listo para usar. Todo lo que quedaba era hacerlo funcionar.

Pero la cuestión es que ya no tengo que pensar en la arquitectura. Escribo lo que los desarrolladores de Java y Sharp llaman "inversión del contenedor de control", una función que toma la función del ciclo de vida y pasa a través de las funciones de mis módulos (II, Juego). VSCode lo resalta en rojo porque no tiene funciones ni módulos, pero tengo lo que necesito: tan pronto como desaparezcan los resaltados en rojo, puedo construir el proyecto y listo.

Tomo los módulos y los hago, uno por uno, trabajando de la misma manera. Todo el proyecto son 5 archivos. El archivo AI tiene 500 líneas, mucho, pero la mayoría si funciona realmente bien. La belleza de este enfoque es que podría escribir una función del ciclo de vida laboral, el corazón de mi aplicación, sin describir nada más.

Toda la arquitectura tiene 10 líneas de código, escritas en un par de minutos. Sin interfaces, telas abstractas, locomotoras, todas estas DefaultInterfaceNameClasses y otras cosas que tengo que hacer en C # antes de siquiera entender lo que quiero crear. Escribes un núcleo tonto que simplemente resuelve el problema, y ​​es más hermoso que tus sufrimientos a nivel empresarial en Java o Sharp.

Y lo hice todo simplemente escribiendo mis pensamientos en el editor, como si estuviera pensando en F #. En lugar de delinear un plan en los comentarios de C #, escribí funciones de trabajo. En lugar de describir decenas o incluso cientos de interfaces, hay un pequeño archivo con el modelo de dominio de la aplicación. Hizo clic en "construir". Recibió una solución de trabajo. En una noche Con un código de calidad que puedo dar con confianza para revisar. Tan simple como eso.



No sé cuál es el problema: si F # es una tecnología monumentalmente increíble, o si simplemente me queda perfectamente o si se creó específicamente para estas tareas, ¿cuál es la diferencia? Lo importante es que en ese momento me estaba hundiendo y necesitaba un bote salvavidas. La vida me arrojó F # y salí de allí. Ahora no es solo otra tecnología sin alma para mí, es un gran trato emocional.

Ahora, cuando escucho a alguien regañar a F # - “¡Una tecnología muerta! Un juguete geek ... "- Siempre recuerdo la fría noche de invierno, el auto en llamas, el cigarrillo congelado en mi boca, la depresión y F # que me sacó de él. Es como si alguien arrojara mierda a mi mejor amigo.

Puede parecer extraño para un extraño, pero si vivieras ese día en mi lugar, habrías reaccionado igual. Creo que eso es común en cualquier cultista tecnológico. Se enamoraron de sus idiomas, porque tienen un apego emocional a las circunstancias que les hicieron descubrirlo. Y luego vengo y escupo directamente en su alma. ¿Quién es el idiota ahora? Yo soy No lo volveré a hacer, espero.

Source: https://habr.com/ru/post/440914/


All Articles