Es bueno que el creador de tu instrumento favorito no escuchara burros cuando inventó la bicicleta

El verano pasado, los chicos y yo hablamos sobre nuestra lib, que nuestro cliente no aceptó y la tiró a la basura. Bombardeamos, porque creíamos en nuestra decisión y se lo contamos a la comunidad: los desarrolladores comunes definitivamente lo comprobarían y no cambiarían por tonterías.

Pues claro. Estábamos literalmente arrastrados por una ola de críticas. Hubo muchas personas a las que no les gustó mi presunción y yo personalmente, está bien, no tengo problemas con ellas. Estaba enfurecido con personas aparentemente inteligentes que ni siquiera querían mirar el código y profundizar en el contexto, porque dijeron desde el umbral: "Ustedes hicieron una bicicleta". Y todos respondieron: reinventar la rueda es malo, terrible, pesadilla, inaceptable, vergüenza, ejecutarlos, linchar. De hecho, solo un idiota desarrollará una nueva herramienta para una tarea que alguien ya ha resuelto.

Me sorprende lo rápido que se realizan los diseños para este truco. Le pregunté incluso a las personas más críticas y profundamente reflexivas: "¿es malo reinventar las bicicletas?". Responden "sí" en menos de un segundo.

Bueno no, hombres, eso no servirá. Paremos aquí, echemos un vistazo y pensemos en detalle.

---

Una vez hice una aplicación de front-end en casa durante bastante tiempo. Usé el reactivo, pero no lo tomé para administrar el estado, no tuve ese problema. Entonces apareció el problema y comencé a hacer "mi bicicleta". Los tíos inteligentes me dijeron que soy un idiota y que necesito tomar Redux. Yo tomé.

Dos meses después, la mayor parte del código del proyecto era una adaptación del editor a mi arquitectura. Esta herramienta me creó muchos más problemas de los que resolvió. No porque los editores sean malos, simplemente no encajan.

Una persona de una gran corporación tomó la decisión de trabajar con el estado de la aplicación web de una gran corporación. Los editores resuelven un montón de problemas que enfrenta una aplicación de este tipo, y lo hace bien. ¿Y qué está haciendo la industria? La industria dice: Dan Abramov nos dio el camino. Ahora mi sitio web en dos formas utilizará editores para trabajar con el estado.

Amigo, los editores están hechos para trabajar con el estado, pero no con tu estado. No necesita una cadena persistente de todos los segmentos del estado de la aplicación, no transmite la acción en la red y no hace mucho más para editar el editor. Al mismo tiempo, usar editores no es fácil. Tendrá que recompensar cien kilómetros de código para explicarle al editor cuál es su condición, dónde y cómo se actualiza, qué cambios son significativos y cuáles no. Para que los editores automaticen un problema que usted no tenía. En serio, ¿has visto al menos una vacante para una reacción, pero sin un editor? Yo no.

Hay análogos, pero también son voluminosos. A veces, la forma más económica de resolver un problema no es tomar una herramienta para todo, sino escribir una solución de dominio que sea adecuada para usted. Dios mío, el mecanografiado es lo suficientemente poderoso como para escribir un mvm básico, mvc o lo que quieras en un par de horas, de modo que resuelva solo los problemas que tengas. Haz que salga más barato y más rápido. Y tal vez su solución funcionará bien, crecerá con el proyecto y se convertirá en el estándar.

Pero esto está prohibido, porque otros desarrolladores le dijeron: “Hombre, no reinventes la rueda. Simplemente tome el más popular en el mercado ".

En mi proyecto, por ejemplo, MobX era más adecuado, pero tampoco super. Funcionaría mejor para mí exactamente la bicicleta que inventé. Pero parecía que me quitaron el derecho de tomar una buena decisión, porque no importaba lo que hiciera, nadie me escucharía. Nadie está listo para creer que resultará mejor y más barato.

Esto crea un círculo vicioso. Si todos usarán solo lo inventado antes que ellos, entonces el progreso en el desarrollo se detendrá. Te dicen, si quieres hacerlo mejor que en el final, hazlo en casa en tu tiempo libre. Dices ok, comienzas a trabajar de noche, lo terminas, vas a decirle a la gente sobre tu decisión, pero nadie está listo para mirar debajo de su capó: "esto es una bicicleta".

Pero, de hecho, todo lo que hacemos es inventar bicicletas. "Bicicleta" es simplemente una artimaña retórica dañina para justificar su pereza o para afirmarse en una disputa con otro desarrollador.

Los creadores de la editorial, reaccionan y mobix, después de todo, también "hicieron su bicicleta". Bueno, ¿qué, a menos que para cuando apareció el angular, no tuviéramos una biblioteca para trabajar con la interfaz de usuario del navegador? JQuery Knockout Esto también es genial, por cierto. Después de todo, siempre había vanilla js y una API de navegador. Entonces, ¿por qué estos idiotas resolvieron el problema resuelto?

Douglas Crockford inventó JSON. El bobo incompetente no parece saber que ya tenemos XML. Mucho antes que él, los programadores inventaron una forma de intercambiar datos. ¿Quién creía que estaba allí?

Malos ejemplos? Pues claro. De hecho, en su cabeza, las personas de grandes corporaciones tienen derecho a inventar bicicletas. Tienen, pero tú y yo no.

---

La TI más empresarial en la Federación de Rusia son los bancos. Y si observa los productos técnicos de cualquier Sberbank, Tinkov o Alf, verá que todos tienen las mismas aplicaciones con aproximadamente el mismo diseño. Estos son sistemas casi idénticos. Lo mismo para el usuario, están hechas de diferentes maneras, en diferentes pilas, por diferentes personas. Todos estos bancos tienen sus propios enfoques de desarrollo únicos. Los gigantes mundiales de TI también tienen muchos de los mismos productos. Cuando los grandes banqueros se juntan y deciden que necesitan productos digitales, contratan a un ejército de desarrolladores y los obligan a hacer lo mismo que otros bancos ya han hecho, por centésima vez, pero de una manera nueva.

Esto se trata de bicicletas.

Hubo problemas de larga duración en cada proyecto en el que trabajé, porque algo no estaba automatizado. Porque una vez que le dijeron a alguien: no reinventes la rueda, solo cierra el boleto. Sí, el negocio está esperando sus boletos, y necesita ser alimentado, pero seamos honestos: sé muy bien que siempre tenemos más presupuesto de lo que el negocio piensa.

Lo tengo todo con el dinero del negocio que gasto en él. Una gran empresa tiene mucho dinero y los impulsa al desarrollo. Los desarrolladores que resuelven problemas y al mismo tiempo realizan una investigación pueden gastar esta enorme cantidad de dinero. Y los gerentes pueden gastar, pero los gerentes los gastarán para pagar nuestra sesión sin sentido en millones de reuniones inútiles. Las empresas ya han gastado dinero en desarrollo, y si no lo convierte en programación, los secuaces de las empresas lo gastarán en sus estúpidos procesos que no son necesarios para nadie excepto para ellos mismos.

He visto suficientes tipos que "trabajan" durante 18 horas al día. Y sé bien que si permaneció en la oficina durante 18 horas, realmente trabajará tanto como si estuviera sentado 8.

Nuestra manera colectiva de engañar a un negocio se explica de manera muy simple: no se equivoca. Las empresas no entienden por qué no debemos hacer funciones durante dos semanas, sino poner en orden el legado. Esto es normal y sabemos cómo resolverlo. Trabajas para una empresa durante medio día y trabajas para un proyecto durante medio día. Vine a trabajar, cerré la norma diaria; eso es todo, tienes una carta blanca para la investigación.

Mientras estamos resolviendo negocios prácticos y momentáneos de la Lista de Deseos, él está listo para que paguemos por este trabajo. De hecho, el desarrollo real comienza donde hay programación por el bien de la programación. Cuando te deleitas en la mecánica pura por el simple hecho de no joder nada, un clic momentáneo y entusiasmo por la ingeniería, porque esta es la única forma de superar los límites, aparecen nuevas formas y herramientas para resolver problemas prácticos nuevamente, solo que mejor.

Cuando desarrollo algo, algo que ya se ha hecho, no lo reinvento exactamente como el suyo. Se me ocurre mi enfoque. Él siempre es algo mejor, siempre algo peor. Y siempre es un invento. La gran mayoría de mis inventos van al basurero de la historia, pero siempre existe la posibilidad de que invente algo realmente genial. Incluso de pasada, incluso si yo mismo no le doy importancia, no importa. Alguien verá, en otro lugar, que la industria recibirá un nuevo estándar que comenzará a resolver nuestros problemas. Solo esta idea me lleva a escribir código.

El código abierto también tiene muchos de los mismos proyectos. Los que resuelven el mismo problema. ¿Estás listo para decir que todos los que los hacen son tontos? No estoy listo. Cuando quiero hacer un lote para la serialización, obtengo cinco o seis soluciones principales, cada una de las cuales tiene ventajas únicas. A veces, una de estas ventajas es crítica para mí, en esos momentos estoy lleno de gratitud hacia los chicos que decidieron hacer esta "bicicleta".

Cuando me dicen que ya se ha inventado todo en el desarrollo, pregunto: "¿qué, no tenemos ningún problema?".

¿No escribimos un repetitivo del día a día? ¿No eliminamos la automatización una y otra vez cuando llenamos nuestros archivos con el mismo código? Todavía estamos haciendo mucho de lo que la máquina podría hacer ahora. Y hacemos esto porque todavía no hemos inventado enfoques, porque siempre insertamos palos en las ruedas de las bicicletas.

---

Mira mi podcast