Me encanta que ya no vivamos en épocas del webmaster que hacía de todo (si, hasta el diseño y el soporte técnico), que exista diversificación de roles y en particular estuve analizando el caso de ciertos perfiles de programadores, donde algunos trabajan con el servidor y otros con el lado del cliente.
En lenguaje menos coloquial, les llamamos Frontend developers y backend developers. Hay demanda por estos perfiles, demanda en serio.
El frontend dev es un ninja del javascript, amante de jQuery, Mootols o incluso devoto de Yahoo por YUI. Le toca pelearse con algo de maquetación, así que el CSS está entre sus herramientas y seguramente es con quien quieres charlar de html5.
El backend developer nos habla en Ruby o Python con fuerza si es cool. Si es más tradicional es PHPero, aunque puede sumarle CodeIgniter, Symphony o Zend a su navaja suiza. Y en muchas empresas .NET pego con fuerza para sus apps web. Muchas veces se involucra con la administración de servidores (aunque ideal si hay un sysadmin para ello), maneja consultas a la base de datos, genera validaciones y sobre un framework establece la dinámica con que funcionará la aplicación web.
El problema es cuando ambos hacen lo mismo
Digamos que no son tan amigos y cada quien está muy reservado con su parte del proyecto. La lista de requerimientos para el backend incluye que genere un set de querys que ayudarán a procesar muchos datos, digamos, la lista de clientes o de ítems en un carrito de compra que vamos a trabajar en nuestra aplicación web. Genera las consultas y nos da el resultado en todos los formatos de moda: Hay .xml, Json, .rss, .csv y por si acaso un .txt. Si tuviéramos información geolocalizada, hasta un .kml estaría en lugar. Tarea lista, continúa peleando contra las posibles inyecciones SQL en el sitio y no quiere saber más de la data.
Entonces, el frontend ya tiene la data y tiene que mostrarla. Genera una interface demasiado 2.0 con drag&drop y juega con arrays de datos en javascript para ordenar estos datos de acuerdo a como los pida el cliente. Práctico, lindo, pero en algún momento ambos están jugando con información, no están del todo de acuerdo y duplican esfuerzos.
Leyendo a Harry Brundage me convenció de que las aplicaciones web hoy en día son demasiado grandes para escribirlas dos veces y el diversificar nos genera un problema mayor que no estamos atacando. El desarrollo web de hoy apesta!
Validación, aquí y allá. ¿Es necesario?
Vamos por el siguiente ejemplo práctico. Hay que validar un formulario para llenar un nuevo pedido. Obviamente, que esto toca hacerlo doble. Ni se te ocurra solo validar en javascript que algún listillo con el firebug instalado te va a poner en aprietos. Y es importante que la validación incluya mucho ajax para ir marcando en color rojo las cajas que no cumplen con la validación.
Y luego, al ritmo del botón de “guardar” validamos de nuevo, verificamos que nadie esté poniendo unas comillas de más y un INSERT o UPDATE para jugar con nuestro sistema. Si lo llegaran a intentar y la validación del lado del cliente no funcionó también hay que enviar un error, mejor si en formato amigable para que el framework de manejo de errores en la aplicación muestre una linda ventanita que te diga que no jodas.
¿Contratamos al que tiene doble personalidad y asume ambos roles?
Si lo tuyo es chico o quieres avanzar rápido, no hay nada mejor que contratar a un developer que pueda con todo. Vas a funcionar, vas a tener un prototipo sin tanto drama, pero no va a ser tan especializado. No imagino la magia que veo en Quora si no tuvieran las funciones tan especializadas, y es que el One-man-band ya está fuera de escena. Hay que especializarse, contratar a diferentes roles, retarlos y ver que trabajen verdaderamente en conjunto.
Aquí es donde muchos gerentes, project managers o team leaders toman un respiro y replican: Esto es casi como cuando nos tocaba que el diseñador cediera en el .psd para quien tenía maquetarlo. Por eso le enseñamos a los diseñadores a usar CSS y los convencimos de que así iban a ganarse la entrada al cielo.
Más especialización
Hemos caminado un largo recorrido para especializar muchas de las tareas de la vida diaria en la web y creo que la especialización va a hacerse mucho mayor. Agrega los retos del desarrollo móvil con todos los dispositivos que ya empiezan a acompañarnos en la forma en que consumimos la web. Lo mejor es que cada día conocemos perfiles mucho más avanzados que están revolucionando el ecosistema. Y si creíste que con saber un lenguaje de programación a fondo ya tenías todo listo para hacer tu trabajo, puedes ser un engranaje más en el motorcito que exige constante innovación y que de vez en cuando nos pongamos a pensar en todo el panorama, no solo en los detallitos.
LA verdad Hay Muchas, Miles de personas FreeLance O Webmaster que son Todo en Uno, tiene ventajas y desventajas.
Si es una empresa grande no creo que hubiera problemas ya que están distribuidos por departamentos.
Recordemos que es mejor trabajar por medio de estándares WEB.
Saludos
De “chico” soñaba ser un master en php, y veía a @Cluster y @GatorV en FdW y decía, yo quiero ser como ellos… El html me parecía demasiado sencillo, tanto que hasta impartí clases de eso. Luego pasó el tiempo y me encontré con WordPress y mas nunca en mi vida tiré una linea de código, osea, desde cero, pues si alguien se dedicó a hacer algo por mi, y hacerlo bien, pues ya todo estaba resuelto.
Me regresé al html y descubrí el css, fue fascinante, ahora veo sitios por ahí realmente bellos y livianos, vectoriales, sencillos y me fijo mucho en el código fuente y me encanta ver como el html5 va avanzando.
La experiencia que tuve usando php, me ha servido de mucho para entender el codex ahora y no complicarme la vida cuando tengo que maquetar algo y me siento bien, aunque tengo muy pendiente el estudio de jQuery o algún otro framework para javascript, pero no me es difícil bajarme algún ejemplo y modificarlo a mi antojo o necesidades.
Ahora me muevo fácil en este asunto, aunque es difícil encontrar equipo de trabajo aquí en Cuba, acá estamos aun en los tiempos de que el “diseñador de páginas web” lo hace todo, y cuando le hablas a la gente de front-end y back-end se quedan con la boca abierta, y si intentas explicarle qué es maquetación y qué es programación, terminas dando una conferencia y la labor educativa no termina nunca… Y ni hablar cuando te toca un Jefe que don´t code…
Buen post C… Un abrazo
También soy cubano: en cuba si muchos desarrolladores saben de terminologías y del desarrollo web en general, en universidades especializadas y en algunas compañías de software reconocidas, aunque cabe resaltar que no es la regla, también trabaje en varias compañías de software en cuba que están a mil años luz de atraso.
Ahora vivo en Alemania, aquí en Alemania también se usa mucho el Front-end y el Back-end aunque también mucho el todo en uno. En mi caso soy un todo en uno.
Ambos tienen sus ventajas y desventajas. Me gusta más tirarle a los dos, de momento aquí en Alemania hay mucho trabajo en ambas ramas.
Además pienso que un buen Front-end debe tener conocimientos de Back-end y viceversa, no se puede mirar todo de un solo lado.
Muy interesante el artículo.
Yo pienso que en latino-america aún no se ve tanta especialización como en los países anglosajones (corrijanme si me equivoco), por lo menos aquí en México conozco muy pocas empresas que realmente tengan roles especializados (si que las hay, pero serán contadas), normalmente los mismos desarrolladores de back hacen el front y me ha tocado ver la ausencia de diseñadores en algunos proyectos (imaginense como quedan visualmente).
El año pasado me toco viajar a España a liderear un equipo completamente enfocado al Front-end, esa ha sido una de las pocas veces donde solamente he programado JavaScript para un proyecto (yo soy desarrollador del front-end
) y tener tiempo completo para hacer una buena arquitectura y aplicar la ingeniería necesaria para hacer el proyecto mantenible y modularizado en el lado de JavaScript.
Pienso que la especialización es buena porque te permite enfocarte en lo que más te agrada y hacer mejor tu trabajo pero al menos en México no lo vez por todos lados.
Saludos
Definitivamente se duplican esfuerzos, adicionalmente es complicado mantener uniformidad en las reglas de validacion en el front y en el back. Por ejemplo una validacion de un valor determinado, si el dia de mañana quiero cambiarlo, tengo q hacerlo en ambos lados…
Por el otro lado es una practica lastimosamente necesaria, jamas dejaria sin validar mi backend si mi front end es basicamente javascript y html, si lo llegara a hacer cualquier persona con basico conocimiento en javascript podria hacer mucho daño…
Una solucion seria hacer toda la validacion en el back y el front simplemente mostraria los mensajes de error q vienen desde el back…. lo cual ahorraria la tarea de duplicar el codigo PERO sacrificaria notablemente el rendimiento de la aplicacion y la experiencia del usuario (porq obviamente para cada validacion se haria un llamado al backend).
Algo que se me ocurre para evitar este problema y solo validar en el front seria usar algo diferente en front como flex. La verdad no se que tan modificable pueda ser, pero con seguridad no tanto como javascript.
Muy buena reflexión.
En mi experiencia ha sido claro que trabajar en equipo, especializando funciones, definitivamente vuelve más compleja la gestión del proyecto, pero también permite hacer cosas mucho más interesantes… ¡y la diversión aumenta!
Pregunta:
¿Qué hay del server side javascript? Hace mucho que no escucho/leo nada al respecto. ¿Podría ayudar a reducir estos problemas? ¿Tiene algún futuro?
También me interesaría escuchar alguna experiencia sobre el Google Web Toolkit para desarrollar front end programando en Java ¿Alguien lo ha utilizado? ¿Qué nos puedes contar al respecto, Christian?
@Rodrigo, Node.js es el rey cuando hablamos de Server Side Javascript. Y estoy viendo a mucha gente meterse por allí. Es bueno que una vez que dominas una tecnología exista la forma de poder llevar esa especialización a otro aspecto de la programación.
Ahora, con respecto a desarollo en Java y Google (que también son grandes promotores de Python), creo que vamos a ver mucho código de parte de ellos que conecte el desarrollo Java de aplicaciones móviles a todo lo que es html5+css3+javascript, aunque no he seguido el tema muy a fondo.
@Crysfel, en tu caso, ya probaste otros ecosistemas donde encontraste la especialización. Y cómo te sentiste, cómo quieres progresar? Y por qué localizar tu talento si el mundo puede ser tu ecosistema para trabajar y tienes la facilidad de desarrrollarte en mercados más globales.
@RogerTm, porfa, no te vayas a quedar en la comunidad de un CMS. Necesitamos gente que se rete constantemente… Y además, por más que estes en Cuba, vos tenes la posibilidad de conectarte hacia afuera y generar proyectos donde no te toque educar sobre la especialización, sino podas asumirla. Por cierto, que bueno leerte por aquí.
@arleytriana, un punto muy interesante el tuyo. Que seas frontend no te hace olvidarte del otro lado, hay que conocer ambas partes, poder moverte por ambos mundos y solo así vas a poder comunicarte sin problema en equipo y avanzar más rápido. Creo que por eso es importante que los diseñadores sepan maquetar sus proyectos. Y que los que maquetan y programan sepan algo de layers y de manejo de psds.. No tienen que especializarse pero un poco de cultura general siempre nos viene bien.
@davidacce, me gusta tu solución de usar el backend para la validación y el fronted únicamente para mostrar leyendas. Básicamente Ajax va por ese camino y si los ingresos de información que tienes no son tan constantes, no estás sobrecargando el servidor.
Pero por otro lado, si va a ser constante el envío de información y la validación, mejor si le pasas un poco de la carga al cliente, que es un costo que no asumimos 😉
Hola, pues en mi caso, soy todo en uno, Front-End, Back-End. Diseño un poco, Maquetar, DBASYS, etc. y para que les digo, es super pesado y en ocasiones aburridísimo, ya que el proyecto lo conoces al derecho y al revés, a tal grado que a veces termina desagradándome por el hartazgo que genera estar metido en las entrañas del mismo. Lo que me llena de satisfacción es que después de un determinado tiempo, llegar de incógnito al negocio de mi cliente y preguntarle a los usuarios que les parece el software, algunos me dicen, muy bueno, nos ayuda mucho, otros dices, esta bien, pero valdría la pena esto o el otro. En fin, a mi me ha gustado mucho el develop desde 1993 y aquí sigo, trabajando por pasión. Punto de vista muy personal.
Ja… te entiendo C, pero no es que llegue, cuelgue WordPress en un host, descargue un theme y salga andando, siempre hay que codear algo, hacer alguna query, maquetar, qué se yo, además, no me gusta usar themes que hay en la web para los clientes (no muchos) que suelo tener, prefiero crear los míos propios…
También he hecho algunas cosas en Drupal, aunque WP es mi favorito.
En cuanto a eso que dices de adecuar una aplicación o asumirla desde cero, es algo difícil, al menos para mi, pues creo que sería mucho más fácil trabajar en equipo y, al menos donde trabajo, soy el único que programa, entonces me es más cómodo adaptar alguna aplicación prefabricada a mi antojo…
Y en efecto, desde que uso CMS´s noto que mi desarrollo como programador ha bajado, pero es que me siento cómodo con ellos… jajaja…
PD: De vez en cuando ando por acá, lo que no comento mucho, o casi nada…
Este tipo de cosas las estoy tratando bastante en alguna que otra lista y en mi empresa.
Creo que la especialización es buena, pero sin olvidar lo que somos, desarolladores web (por centrarnos un poco). No me sirve de nada un tio que es un maquina con Jquery o otro que es la leche picando consultas SQL, un desarrollador web tiene que ser capaz de picar desde el backend hasta el frontend e incluyendo las fases de prototipado.
Si no a lo que volvemos es a un modelo en cascada, uno prototipa, otro diseña, otro genera los datos, otro maqueta, otro la interacción…
Si un tio tiene muchos conocimientos sobre un tema debe ser capaz de transmitirlos al resto del equipo, siempre que estos sean receptivos y la empresa lo facilite.
Al final el que va a hacer la interacción se da cuenta de que no tiene los datos necesarios, el de backend ve que el que prototipo no tuvo en cuenta ciertas cosas, etc.
Creo que el formar equipos debe ser para compartir recursos, conocimientos y habilidades, no para escaquearse de la parte del desarrollo que no te gusta.
Si por ejemplo somos 2 de backend y 2 de frontend seguramente en algunos momentos alguno de los grupos tendrá mucha mas carga de trabajo que el otro, cosa que no tiene sentido desde mi punto de vista.
No creo que sea una generalidad que no exista especialización siendo un “webmaster” todo en uno, pero es cierto que puede suceder que al esforzarse por el equilibrio no se conozca del todo algún tema. Depende mucho de la persona también, quien se esfuerce en conocer el diseño web en general, aunque, en efecto, con el paso del tiempo ha llegado a ser una tarea difícil. El lado positivo de todo esto, de que una persona sepa una “embarrada”, es que conoce al menos el funcionamiento del desarrollo de un sitio web, que le puede ayudar a emplear criterios ya sea del lado del backend o del frontend. Sin duda, el reto es el trabajo en equipo; v. g. un diseñador gráfico que nunca ha hecho sitios web, le cuesta demasiado trabajo comprender cómo se hace un sitio si no sabe ni siquiera lo que significa maquetar un sitio o lo que significan los estándares web. Es importante, sin olvidar la especialización, pretender conocer de manera integral el proceso del desarrollo de un sitio web, no veo por qué renunciar a ciertas tareas o conocimientos.
[…] Maestros del Web window.fbAsyncInit = function() { FB.init({appId: "", status: true, cookie: true, xfbml: true}); }; (function() { var e = document.createElement("script"); e.async = true; e.src = document.location.protocol + "//connect.facebook.net/en_US/all.js"; document.getElementById("fb-root").appendChild(e); }()); Share and Enjoy: […]
Excelente Post!, son verdades muy reales y frecuentes en el día a día de todo desarrollador…
Hola amigos, yo recientemente aca en Perú tube la oportunidad de trabajar en un equipo donde haciamos esa distinción, yo era desarrollador Frontend y un amigo mio Backend, rappidamente uno se da cuenta que las cosas o el producto va saliendo mucho mejor.
El problema vino cuando uno de los dos abandono el proyecto encontrar un desarrollador FRONTEND O BACKEND aca es muy dificil (Almenos en la ciudad en que vivo – Cajamarca). y como dicen ni los términos son bien conocidos.
A la conclusión que puedo llegar es que es bueno conocer ambas partes pero debemos especializarnos en una.
La especialización siempre es importante si se quiere hacer trabajos de gran calidad y destacar en un campo específico. Pero debido a la política de las empresas y a los problemas del día a día, es común que haya una persona o dos que asuma varios roles.
En mi caso, en la empresa hago de todo: diseño web, maquetación, programación front y back, seo, accesibilidad y usabilidad. Si bien tengo que mejorar en el back, me viene genial tener a mi lado un diseñador gráfico y un programador backend, que me sirvan de apoyo cuando hay sobrecarga de trabajo o algún proyecto que pueden hacer mejor.
Pero con lo que depara el futuro y las aplicaciones en móviles, etc. es necesario disponer de un equipo si se quiere un salto de calidad notable.
Te felicito por el post, es un problema muy común, muy bien explicado.
Igualmente en programación siempre veo a los países de Europa o Estados Unidos con grandes programas, sitios, aplicaciones.
Los de América Latina, son buenos pero es que ellos tienen mejores y más tecnologías y se llevan a los mejores de acá jeje.
Saludos
Muy buen post!
Algo que pasa es por ejemplo algunos administradores de los sitios donde van a ir las aplicaciones alojadas o algún programa, por “seguridad” no dejan que los programadores utilicen su host para modificar o añadir ciertas cosas que son útiles para poder terminar el programa, hay veces que por esto algunos equipos se separan ya que no pueden completar el trabajo que hacen.
Muy buen artículo Cvander! Yo creo que actualmente yo le estoy dando a ambas: backend y frontend. Pero a veces aliviaría un poco tener algo de ayuda. Aunque por ej. ya hace tiempo que yo no me encargo del diseño ni del xhtml/css, y tampoco me gusta encargarme del servidor.
Saludos!
[…] Por último existe un error generalizado, que lleva a creer que “ser diseñador gráfico es equivalente a ser diseñador web“, o que el programador debe desarrollar tanto “el trabajo front-end como el back-end“. […]
Christian,
Pese a que te agrada la tendencia actual de la especialización, donde quedó obsoleto el antiguo webmaster que era cortador de boletos, payaso y hasta trappecista, no podrán negar la belleza de aquél entonces en donde todos crecímos en conjunto, en un espíritu de colaboración donde todos le iban aportando con sus propios conocimientos al de al lado, para a la vuelta del camino ser nutridos por quien habíamos ayudado primeramente. ¿Te acuerdas por ahí en el 2003-2004 cuando al alero de forosdelweb fundamos en iberoamerica asociaciones de webmasters de forma coordinada y mancomunada?, no podrás negar que aquello era bonito. Es por eso que aún extraño esa época donde el concepto de monetizar los sitios no existía, donde el imperio del mercado no se había apoderado de la web (tal y como es hoy) y en donde lo único que importaba era aprender, conocer, colaborar y ser colaborados?
Saludos desde Chile,
Ricardo Avalos