Me meto con los juniors

 Hoy me voy a meter con los juniors. Vale, a ver, primero, bienvenido. Este es el podcast de Drupal y Saté. Soy Robert Menetray, hablo de Drupal, bla bla bla bla. Hoy quiero hablar sobre lo que son juniors. Realmente no lo que son juniors que trabajen bien sobre Drupal, no. Me refiero a los juniors que no tocan Drupal en su vida, pero que están metiendo mano a un proyecto de Drupal porque, de alguna forma, se lo han encasquetado, básicamente. Para empezar, te comento tres casos que me he encontrado un poco bestias con mis últimos años. Y digo años porque hay algunos que son un poco viejos, ¿vale? Los tres casos son porque hay de backend, de frontend y de setbuilding. Porque como yo soy full stack, pues hago de todo. Y me encuentro horrores en todos sitios. Eso, por ejemplo, si queréis empezamos con setbuilding. En setbuilding, o implementadores, en WordPress creo que se llaman implementadores, es gente que no toca código. Es gente que solo toca configuración, ¿vale? Configura cosas. Los que son más juniors, aquí, básicamente, la lian mucho con las estimaciones. O, aparte de que están mucho más tiempo del que deberían para hacer cosas muy simples, hay muchas veces que dicen de, no, es que esto realmente no se puede hacer. No, queremos un listado que haga artículos ordenados por fecha con un filtro expuesto que tenga categorías y búsqueda por texto. Uy, no, esto es muy complejo. Esto por código. Por código, no. Si te hubiese escuchado, no sé si fue hace tres episodios o dos, que hablé de las views, las vistas. Esto se hace en media hora o menos en Drupal. Que después tocará hacer el frontend para dejarlo bonito. Puede, sí, seguramente. Pero lo que es hacer las consultas, filtros expuestos, órdenes y todo esto, vistas, o sea, views, te lo da por defecto. O sea, no se hace muy listo para saber usarlo. El tema es tener ganas de formarte y buscar cómo hacer listados en Drupal, básicamente. No es nada complejo. Pues de la misma forma, ¿no? Queremos que haya un formulario, digo custom, que tenga esos campos. O sea, un desarrollo a medida, porque esto no está... El formulario de contacto por defecto en Drupal no permite poner más campos. No, a ver, tienes el modo webform, que te permite poner los campos que tú quieras. O sea, hay gente muy junior, porque cuando digo junior en verdad es gente que no trabajó con Drupal, que le dan casetas en proyecto y básicamente tira balones fuera. Uy, no, esto no se puede. Esto va a ser una cosa custom y como yo no sé hacer código, pues esto no se puede hacer. Vale, fue el siguiente, fuera. O realmente te meten una estimación de, uy, esto van a ser 10 horas, pues claro, tengo que investigar cómo se va a hacer y tal. Y si fuera un senior que trabaja en Drupal, o ya, quizá un junior que trabaja en Drupal, te diría que esto quizá en verdad es una hora porque hay un módulo que te lo hace y se ha de configurar. Por ejemplo, envíos de mails por SMTP. Que he visto gente decir que no, que en Drupal no se pueden enviar mails desde servicios externos. Es un no, perdón, no se has indignado a mi edad si se puede o no. Has dicho que no y te has quedado tan pancho. Bueno, esto para gente de configuraciones, que ni siquiera sabe qué módulos hay, ni cómo se configuran, ni cuánto tiempo puede llevar a hacerlo. Con lo cual las estimaciones casi siempre las hacen mal. O sea, creo que no he visto a nadie que no haya trabajado en Drupal. O sea, la gente que trabaja en Drupal, ya normalmente nos cuesta hacer estimaciones correctas, pero la gente que no trabaja en Drupal la lía muchísimo con las estimaciones y los requisitos de proyecto. Te dicen que sí a cosas que son inviables y te dicen que no a cosas que son hiper simples de hacer en Drupal. Siguiente caso de gente junior que la lía. Llegado a esto de configuraciones, sería la gente de backend. Cuando te dicen de uy no, esto no se puede hacer por configuración, se ha de explicar código a medida. Y aquí es, si es gente que nunca ha tocado Drupal o que no sabe apenas nada de código de Drupal, la lía es pardísima. Meten código PHP a pelo, hacen queries directamente a base de datos y modifican valores en base de datos directamente. Sin usar la rapis de Drupal. Se pasa un docker de Drupal por el forro de los cojones, básicamente. Y te rompen la web por dentro. Y me he encontrado algunas webs hechas así, que es, mira, yo a este proyecto no voy a trabajar. Si quieres hacer una web nueva, pero yo no voy a seguir, yo no de mantenimiento de esta web. ¿Por qué no? O sea, esto no es un Drupal, esto es un Frankenstein y lo que me extraña es que la web esté visible actualmente. Que no esté caída ni hackeada. Bueno, pues la siguiente, coge gente que quizás un senior es muy bueno en PHP, pero no en Drupal. Y en vez de usar Drupal y las buenas prácticas de trabajar en Drupal, ha modificado código del mismo code de Drupal. Y no puedes actualizar la web, porque si la actualizas, la rompes. O sea, no puedes modificar código del code. Pues hay gente que lo hace, ¿vale? Y como digo, pueden ser senior de otras tecnologías, pero no sean ni juniors ni seniors de Drupal. Lo digo en Drupal, pero puede pasar lo mismo en WebPres. Habrá gente muy buena en otras cosas y no en WebPres. Y si le meten mano a un WebPres, lo va a dejar feo de cojones. Y, simplemente, a mí me pasa esto, porque yo no toco WebPres. Por final, si de verdad tu web o tu cliente te importa, busca gente que tenga un mínimo conocimiento. Yo no digo que sea un senior, pero que al menos sea un junior con ganas y que haya tocado más de un proyecto en Drupal. Que si le mencionas views, migrate, exportar configuraciones, y algunas paravitas así, un poco más técnicas, entre comillas, que al menos le suene lo que es. ¿Vale? Y después el último ejemplo va a ser por la gente de Frontend. Ahora me pasa menos, porque en Drupal 8 y 9 las plantillas de Frontend, o sea, Drupal ya no trabaja con plantillas de PHP, como en Drupal 7. Trabaja con plantillas Twiq. Con lo cual, limitas mucho que los de Frontend la leen para el encodigo. O sea, ya no pueden hacer consultas a base de datos directamente en la plantilla. O insertar cosas en base de datos desde la plantilla. Esto lo he visto por estadísticas, que cada vez que se carga la plantilla, metía un insert en base de datos para hacer una tabla custom base de estadísticas. Cosas así de raras he visto desde Frontend. Otra cosa rara que vi es que como antes se permitía meter código PHP, pues nada, que como esta gente no sabía de Drupal, pues hacían debug de las variables que devolvía para ver que valor sabían y cómo se tenían que pintar para meter esta variable visualmente en la parte que el diseñador quería que se viera. Pues bueno, habían hecho debug, habían pintado todos los valores del nodo de la página. Y habían visto, ah vale, es esta variable, la pinto y ya está. Pero todo lo que he hecho de debug antes que he puesto código para aquí para mostrar cosas, no, por qué quitar ese código. Mejor lo dejo donde está y después posee ese elemento display.none para ocultarlo. Y oh, después pasan dos meses y la web valenta de cojones y el cliente se queja de que Drupal va lento y que es una mierda Drupal. No, Drupal no es una mierda. Lo que es una mierda es la agencia o el freelance que has contratado para que te haga esto. Vale. Y esto lo relaciono con lo de que, para ponerle ejemplo, cuando tú tienes un coche, si tienes un coche de una marca X, no te vas a quejar de que la marca del coche X es mala o es buena. Tú lo llevas a un mecánico. Si en vez de llevar a un mecánico decente, ya no digo extraordinario, digo mecánico normalito, lo llevas a un mecánico hiper barato porque te lo hace a menos de la mitad del precio que el otro. Si después, al cabo de un par de semanas, ves que los frenos no te los ha cambiado y te ha puesto nuevos, sino que te ha puesto unos frenos de segunda mano que están gastados o que has visto que el motor ha hecho no sé qué y al cabo de dos meses se ha roto el motor, pues quizás no es culpa de que la marca del coche sea buena o mala. Quizás es culpa de que los llevas a un mecánico que te ha roto el coche por dentro. Vale. Pues en programación es lo mismo. Vale. Y nada, que estoy un poco frustrado en algunos proyectos que me llegan y a algunos les digo, no, es que yo no voy a meter mano aquí. Te vale más hacer la web nueva desde cero que no intentar arreglar lo que te han hecho aquí dentro. O sea, has teado el dinero con esta gente, básicamente. A una gente eso toma como un, sí, me lo temía y a otros es, no, no, eso es que tú no sabes. Y es, bueno, vale, pero yo no voy a coger este proyecto, búscate a otro. Vale. Y te lo digo con toda sinceridad del mundo, cuidado con la gente que cogéis para que os hagan webs. Y que no está de más a veces tener una segunda opinión de alguien un poco más experto, ya no para que haga el trabajo, digamos, gordo, para que dedique gran parte de las obras, pero sí que al menos haga una revisión de que se están usando, pues, que se puede hacer con este módulo. O sea, al menos, revisar los requisitos y enviar las directrices por cuál sería el camino correcto para seguir. Si realmente hace falta hacer código custom para esto. Si realmente hace falta o sería la mejor manera para tener un mejor rendimiento o un mejor SEO o un mejor X. Porque es que, de verdad, he visto burradas de agencias o de freelance que es, esto, endúpalas si no se trabaja. Vale, o sea, tenemos un módulo que se llama MetaTax. No metas los MetaTax por código en las plantillas. Usa el módulo que después lo puede gestionar el cliente. Voy a poner otro ejemplo de burradas que me he encontrado. Y nada, lo que me preocupa más de esta gente es que da muy mala imagen a Drupal. O sea, desde el punto de vista de cliente final, yo quiero tener una web que me funcione bien. Si contato a gente que supuestamente me han dicho que saben del tema, saben hacer webs, y me entregan un producto que es una porquería, yo como cliente, pues este producto es una mierda. Y es el caso del coche. Pues diré que esta marca de coche es una mierda y no la recomendaré. Y me he encontrado gente que ha pasado esto, de que tenía webs en Drupal, que habían acabado hasta las narices, y que se pasaban a otras cosas, que nunca más tocó ir a Drupal. Por ejemplo, tuve una que me llegó de que tenía un... es que no era ni e-commerce como tal, era una web escaparte de nada, cuatro productos, que la habían hecho en Drupal. Pero ella no había pedido en Drupal, ella había pedido pensar que le querían hacer un webpress. Le hicieron la web, la cobraron, le subieron al servidor, y ya está, yo ya he cobrado porque no quiero saber nada. Y la mujer esta me llamó para hacer unas implementaciones de esta web, y al final fue... no, mejor, es que no vale la pena trabajar con esto. Para empezar, tú estás descontenta porque no querías un Drupal, no sé por qué no les dijiste esto a la gente que te lo implementó. Haberles dicho de yo quiero un webpress porque tengo otras webs de un webpress y sé cómo funciona. No me traes otra tecnología que no sé cómo va. Y segundo, las cosas que me estás pidiendo aquí, si, te las puedo implementar, pero no son realmente lo que tú quieres, porque tú quieres que te clone el funcionamiento de una cosa que está en webpress. Y clonarlo exactamente si queda falta meter código custom. Sabes, o sea, no sé si te vale la pena directamente que te gane una web webpress, te salda hasta más barato y sea realmente lo que tú quieres. Y bueno, al final ese cliente no salió. Pero esto de pusieron a gente que hace webs y le encasquetaron una web en Drupal al cliente cuando realmente no lo quería. Y es otro caso de esto, al final es mala política para ese tipo de tecnologías. Y desde mi punto de vista, Drupal es muy bueno, pero es una herramienta. Serviría para unas cosas, pero no para todas. Tienes un martillo y tienes una llave inglesa. Si quieres meter un cuadro en la pared, con la llave inglesa la llevaras un poco difícil. Y con el martillo aún puedes hacer algo. Pues es similar. Yo no recomiendo Drupal para cualquier tipo de proyecto. Tiene su nicho, ¿vale? Y nada, esto. Que estoy frustrado con algunos clientes, posibles clientes que me llegan, que algunos es en plan de, es que Drupal es una mierda, es que tal. Y es en plan, no, sea que lo que te han hecho a ti no es lo que querías tú. Quizá o no te comunicaste bien con tus desarrolladores, o ellos te han vendido la moto o el humo, que también puede ser. O esto, que sí que los entendisteis, pero no tenían los conocimientos técnicos necesarios y te han hecho una mierda de web, por decirlo claro. Y nada, que cuidado con la gente que contratas para que te haga tu web, ¿vale? Y que si eres junior y te quieres dedicar a Drupal, dedícate a Drupal. O sea, fórmate un poco, aprendas buenas prácticas, haz pruebas sin que sean de clientes, haz pruebas, haz webs tuyas propias, lo recomiendo muchísimo, prueba con webs tuyas propias, y aprende cómo funciona internamente. Porque no se parece nada un Drupal 7 a un Drupal 8 o 9. Y tampoco se parece nada con webpress. Cambia muchísimo por dentro. Sobre todo si es de parte de backend de código, ¿vale? Así que, realmente, si quieres dedicarte a esto, fórmate. No le digas que sí a cualquier cliente de, ¡ah, sí, yo te hago una web, tranquilo! Fórmate y no vendas humo, ¡por Dios!