¿Por qué los desarrolladores de backend tienen más confianza en su profesión que los desarrolladores frontend?

Puedo responder esto en dos palabras cortas: cambio constante

… Para agregar algunas palabras más:

Cambio constante = nunca lograr nada cercano a la maestría, NUNCA

Algunas razones:

1. Las herramientas y los idiomas disponibles para el trabajo front-end son mucho menos maduros que el back-end. La mayoría de las técnicas, metodologías, herramientas, paradigmas, etc. de back-end se han perfeccionado y probado durante años (décadas en algunos casos) y, en comparación con las herramientas de front-end, son estables como una roca. Las herramientas frontales son casi tan estables como un kleenex pegado al ala de un avión … en una tormenta eléctrica.
2. Herramientas de solución de problemas: no me hagas empezar. Las herramientas de front-end evolucionan mucho más rápido que las utilidades de solución de problemas. Tratar de comprender qué impulsa una respuesta específica a un evento particular en el front-end es usualmente factible, pero a menudo puede ser como usar una cuchara para atrapar un murciélago en un garaje oscuro lleno de herramientas de jardín y un piso grasiento que no usa más que orejeras.
3. La política, las tendencias, la competencia de la empresa para la financiación de capital riesgo, etc. impulsan la rotación de marcos cada vez diferentes (no necesariamente siempre mejores) que reemplazan el marco de mierda caliente del año anterior (o del mes anterior). A menudo, estos implican un cambio de paradigma completo. Universalmente, responden algunas deficiencias de la solución anterior de mierda caliente … solo para revelar alguna otra deficiencia propia … que luego será reemplazada por el siguiente enfoque defectuoso.
4. Las soluciones front-end deben funcionar en múltiples entornos diferentes (dispositivos) de diferente forma, tamaño, capacidad, interfaz (clic, deslizar, pestaña), etc. de múltiples proveedores diferentes que viven en múltiples plataformas diferentes (múltiples sistemas operativos x múltiples versiones) con múltiples diferentes caprichos que todos se actualizan constantemente (estoy hablando del Browserverse aquí, amigos, esta realidad sola le daría pesadillas a un desarrollador Java dedicado … si pudiera dormir). No olvide que css, html y javascript a menudo cambian. Oh, ¿mencioné que para hacer algo útil tienes que usar estas 3 tecnologías completamente diferentes y siempre cambiantes? Si, eso es una cosa.
5. Las tendencias de diseño cambian constantemente, a menudo sin razón lógica (es moda, no lógica). Las opiniones subjetivas de las personas (usuarios, tomadores de decisiones) que tienen cero conocimientos técnicos impulsan el cambio constante de las interfaces (esto no es una crítica de esas personas: tienen mucha de su propia experiencia relevante para el negocio, intenten comercializar un producto en un espacio competitivo “Es una perra y requiere verdadera habilidad, experiencia y aprendizaje constante”.
6. La belleza / maldición que es javascript. Lo mejor de JavaScript es que puede escribirlo de la manera que desee, haciendo lo que quiera, lo que también es una maldición total. Créeme.
7. Necesidades comerciales competitivas. Tiene que verse genial (al menos la versión de esta semana de genial). No olvides que tiene que ser más rápido que el del otro tipo … oh, y recuerda hacer que funcione en todo el navegador … espera, tenemos que poner algo de SEO allí … pones análisis allí, ¿verdad? Es mantenible por alguien más a quien nunca conocerás, ¿verdad? ¿Cómo es que mi abuela no puede verlo mientras ejecuta Win 98 en su Atari 800?

Entonces, imagine que su sustento en un trabajo muy competitivo y muy visible dependía de golpear de manera competente un objetivo que se encuentra encaramado en un automóvil en movimiento … el uso de un arma en la que nunca ha sido entrenado cambia completamente su configuración cada año (el arma del año pasado es ballesta de este año, que reemplazó a los nunchuks láser del año anterior) … oh, no olvides que todos pueden ver y juzgarán tus resultados. Ah, y cuando consigas un nuevo trabajo, usarán algo completamente diferente.

Dime, ¿cuánta confianza tendrías?

Supongo que esto tiene más que ver con la seguridad en sí mismo. El desarrollo de backend que siento se trata de datos y cifras. Como desarrollador de backend, el trabajo principal es atender las solicitudes y respuestas. Esto implica escribir lógica empresarial, manipular datos, asegurar el servidor de intentos maliciosos, garantizar una mejor velocidad de respuesta y diseñar la estructura de datos de la aplicación. En pocas palabras, se trata de los datos y los números. Cada aspecto se puede medir definitivamente en números. Se trata de escribir algoritmos matemáticos a veces.

En pocas palabras, como desarrollador de back-end, simplemente escribo lógica de negocios contra una especificación dada. No necesito preocuparme por la compatibilidad con dispositivos o usuarios finales. El rendimiento se mide a tiempo, las bases de datos se pueden ajustar. No necesito preocuparme por las diferentes percepciones de todos los interesados ​​dentro del equipo, a diferencia de un desarrollador frontend donde la configuración regional, la percepción del usuario final, la experiencia del usuario y la compatibilidad del dispositivo pueden tener múltiples variaciones para tener en cuenta.

Escribir código en el navegador y la tierra del usuario genera muchas más incógnitas, especialmente una vez que comienzas a considerar CSS. Los servidores se ocupan principalmente de la recuperación, transformación y entrega de datos.

Es posible tener una cobertura de prueba de cada punto final y operación en un servidor. Por lo tanto, uno puede confiar en que el sistema está funcionando como se esperaba. La complejidad en un servidor es menor, y las posibles ramificaciones de código son menores. La mayoría de los servidores utilizan el enfoque MVC, que separa muy bien las preocupaciones.

Rápidamente se vuelve imposible probar cualquiera, excepto las rutas de usuario más críticas a través de una interfaz de usuario. Esto significa que hay más posibilidades para que el sistema se comporte de manera interesante e incorrecta. No creo que nadie vivo entienda completamente el DOM y todas las peculiaridades del diseño y el posicionamiento entre todos los navegadores. Claro que existe la especificación, pero estaré condenado si puedo clavar flotadores cada vez.

Las interfaces y los usuarios generalmente crean mucha más complejidad, por lo que tengo mucha menos confianza en ellos. No es una cuestión de experiencia, es una cuestión de componentes del sistema y de que trabajen juntos de manera predecible.

Claro, puede tener un servidor que es mucho más complejo que el navegador, estoy hablando en general.

Diría que el desarrollo front-end está sujeto a muchas más críticas subjetivas que el desarrollo back-end.

En el back-end, algo funciona según lo previsto o no. No tiene aspecto, por lo tanto, a nadie le importa cómo se ve. Todo lo que le importa es si funciona, lo que se puede responder con un agradable y objetivo sí o no.

En el frente, tienes que lidiar con mucho más que eso. Debido a que el desarrollo front-end abarca elementos de diseño, experiencia del usuario, interacción, multimedia y muchas otras áreas, hay muchas más partes interesadas y, por lo tanto, está sujeto a muchas más opiniones y críticas generales. Todos quieren meter el remo. Por lo tanto, más críticas == menos confianza.

Hago desarrollo tanto front-end como back-end, y siento que puedo seguir con las cosas mucho más cuando estoy trabajando en el back-end. Es mas simple. Menos opiniones Ya sabes lo que dicen sobre las opiniones. 😀

Creo que es el resultado de la tecnología cambiada y el papel cambiante de los desarrolladores front-end en los últimos años. La tecnología para el frente y el back-end ha cambiado notablemente. En el back-end ha habido cambios importantes como big data, bases de datos NoSQL, API relajantes, node.js, etc. Todo lo cual no existía o era intrascendente hace 10 años. En la parte frontal, los principales cambios se han centrado en ajax, javascript y una miríada de nuevos marcos excelentes (pero complicados) que han cambiado completamente las interfaces web.

Si bien tanto el front-end como el back-end han visto cambios considerables, creo que el rol y el lugar de los desarrolladores front-end ha cambiado más que los desarrolladores back-end. Es, por supuesto, una generalización. Conozco desarrolladores front-end que son sumamente seguros y desarrolladores back-end que no lo son en absoluto, pero hay algunos cambios clave que han afectado a los desarrolladores de diferentes maneras.

Los desarrolladores de back-end suelen provenir de universidades con títulos en informática o al menos en ciencias. La tecnología cambia, pero los fundamentos de cómo funciona el software realmente no cambian. Saltar de bases de datos SQL estándar a bases de datos NoSQL requiere algunos ajustes, pero todavía hay conceptos fundamentales que respaldan la necesidad de una base de datos que permanezca igual. Viniendo de una computadora de fondo, los desarrolladores de back-end están capacitados y cómodos con estos conceptos fundamentales, adaptarse a un nuevo lenguaje o tecnología no es un gran salto.

Los desarrolladores front-end, por otro lado, a menudo provenían de escuelas de diseño y programas de diseño gráfico. Esto está cambiando, pero no hace mucho tiempo era bastante común que los desarrolladores front-end no tuvieran efectivamente capacitación en programación. Su conocimiento estaba en html y css y su enfoque real estaba en desarrollar el aspecto adecuado para un sitio. Era más un problema de diseño gráfico que un problema de desarrollo. Este papel ha cambiado completamente en los últimos 10 años más o menos. Con los avances en los marcos javscript y js, se necesita una cantidad increíble de desarrollo en el front-end y se espera que los desarrolladores front-end completen eso. Sin embargo, muchos de ellos no están bien entrenados en los fundamentos del desarrollo de software, por lo que es un cambio mucho más grande de asumir.

Cuando era desarrollador de bases de datos, era fácil ganar confianza porque la mayoría de las personas no sabían lo que estaba haciendo.

Solo vieron el resultado que fue: todos sus servidores de bases de datos funcionaron. Cuando tuvieron un problema, pude recuperarlo para ellos sin ningún drama.

El desarrollo de back-end es difícil de probar, lo que significa que solo hasta que otro desarrollador vea su código comenzarán a darse cuenta de si es un buen programador o no.

Cuando se trataba de tratar con clientes, si intentaba explicar el trabajo que acababa de hacer, incluso si lo intentaban, no podían entender mucho más.

Confiaron en que sabía lo que estaba haciendo, nunca me interrogaron, y los nuevos desarrolladores acudieron a mí en busca de consejos sobre cómo optimizar sus bases de datos.

Esto me dio un alto nivel de confianza.

Desarrollo front-end?

Dios mío, todos criticarán todo lo que hagas. Los diseñadores de front-end son muy críticos con el trabajo de otras personas.

(Suponiendo que está hablando de front-end en un “aspecto y sensación” en lugar de un sentido de “manipulación de datos” de back-end).

1. Los requisitos de un sistema de fondo son lógicos, en general, su solución es correcta o incorrecta; más rápido o más lento de lo que era; permite que la gente inicie sesión o no, etc.

   Por el contrario, si un sitio web ‘se ve bien’ / ‘se siente bien’ está abierto a la opinión. No importa cuántos años de experiencia en la industria tenga en diseño, aún tiene que satisfacer las opiniones de varias personas: es posible que no les gusten las mejores prácticas, probablemente ni siquiera estén de acuerdo entre sí.

1. A veces, las opiniones están justificadas y pueden prepararse con anticipación. por ejemplo, “Realmente no quiero que mi marca sea roja”
2. Otras veces, de manera más frustrante, se convierte en un caso de “derramamiento de bicicletas” (ver, ¿Por qué debería importarme de qué color es el Bikeshed?), Es decir, todos tienen una opinión sobre las partes más triviales de las imágenes, y todos quieren su propia opinión de tener razón.

Muchas buenas respuestas aquí. Lo que agregaría es que hay muchas herramientas para el backend, que te permiten hacer tu trabajo de backend literalmente sin hacerlo.

Sí. No puede tener ningún código de fondo y su aplicación seguirá funcionando.

Parse, Firebase, Bubble, Kinvey, etc.

Parse tenía una muestra de una aplicación similar a Instagram en github …

No digo que no necesites escribir código para el backend, pero lo que puedo decir es que definitivamente escribes MENOS código en el backend. Y si escribes mucho, o haces un proyecto muy grande como Facebook, o haces algo mal. Lo siento. Escribir mucho código no se trata de tu experiencia. Se trata de falta de conocimiento.

Hace dos semanas implementé el servidor SocketIO para el proyecto de mensajería con 20 líneas de código. Admite salas de chat, notificaciones de escritura y todas y cada una de las funciones que cualquier mensajero debe admitir. Otra parte de este “backend” construido con Parse sin siquiera código en la nube. Pero desearía que estuviera allí, porque mi cliente se volvió un poco complicado debido a que hizo un trabajo de servidor. Aún así, nunca habrá más de 200 líneas de código.

Entonces, básicamente, los programadores de servidores tienen más confianza en su trabajo porque tienen menos.

Estoy respondiendo como desarrollador de backend que ocasionalmente tiene que hacer un trabajo frontend. Hay varias razones:

1. Tenemos mejores herramientas Aquí entran en juego muchos factores: somos libres de elegir y cambiar cualquier herramienta con la que trabajemos si no nos gustan. Puedo eliminar mysql y reemplazarlo con postgres si decido que es algo razonable, actualizarlo a la última versión o corregir un error si me molesta e implementar el cambio al instante. Puedo elegir usar ruby ​​o python o java o erlang … o todos a la vez donde sea adecuado. Aplique esto durante muchas décadas a todo el software relacionado con el back-end, y obtendrá un código lo más cercano posible a ser lo mejor posible. Destacaré: elegir y ajustar todas sus herramientas es la norma aquí. Como desarrollador frontend, no tiene control del navegador / teléfono que usan sus usuarios, por lo que la actitud predeterminada es vivir con cualquier deficiencia de ellos. Incluso si pudiera enviar un parche al código del navegador (que muy pocos desarrolladores frontales tratarían de hacer), puede tardar una década en aterrizar en la mayoría de los dispositivos de los usuarios. ¿No te gusta JavaScript (considero que está roto por diseño) o algunas de sus verrugas? Mala suerte, no puedo hacer nada al respecto. ¿Crees que debería haber una mejor API de manipulación de imágenes en el navegador? No puedo arreglarlo. Y así.
2. Tenemos control total sobre nuestros entornos. Si se lanzará una nueva versión de una base de datos, puedo elegir actualizarla … o elegir no importarme. La actualización de un nuevo teléfono o navegador puede obligar a los desarrolladores frontend a corregir su código en pánico.
3. No tratamos mucho con la gente, sus gustos y política. Dame tus requisitos funcionales y escribiré el código que los cumpla. Hay muy pocos elementos subjetivos allí. Como desarrollador frontend, puede crear código que cumpla con todos los requisitos dados, pero al cliente / usuario / gerente simplemente no le gusta el diseño y no puede explicar por qué.
4. El desarrollo de backend se ha hecho durante muchas décadas más de lo que llamamos frontend ahora.

La combinación de esos factores conduce a una situación en la que es fácil para mí encontrar soluciones bien diseñadas existentes para mis problemas de back-end, mientras que hay muchas herramientas frontend mal diseñadas, y muchas de ellas no se pueden arreglar o requerirían mucho esfuerzo conseguirlas. Derecha.

Hola,

Los desarrolladores de backend tienen que lidiar principalmente con la base de datos, el servidor y la aplicación. Son responsables de hacer todo el trabajo en el backend que mantiene un sitio web funcional. No le importa a un desarrollador que diga qué, lo único que importa es si su trabajo afecta el rendimiento o no. Están bastante seguros de su trabajo.

Por otro lado, el escenario cambia en caso de desarrolladores front-end. Tienen que lidiar con la apariencia general del sitio web, con el que un usuario normal tiene que interactuar, como temas, colores, diapositivas y barras de navegación. Tienen que ser muy competentes con lenguajes como JavaScript (lenguaje de programación), CSS Frameworks y HTML. Al mismo tiempo, también tienen que ocuparse de los requisitos del cliente. Esta es la razón por la que a veces tienen menos confianza en su trabajo. Empresa de diseño y desarrollo web | Servicios de diseño de sitios web India

Actualmente, el desarrollo front-end está en un gran cambio en su desarrollo. La afluencia de cambios hace que un desarrollador front-end tenga menos confianza en sus habilidades. Antes solo tenía que lidiar con la interfaz de usuario y cómo se veían y actuaban las cosas en la parte delantera. Ahora tiene una afluencia de herramientas como compiladores, marcos de JavaScript, es6, es7, linters, capacidad de respuesta, enlace de 2 vías, flujo de datos de 1 vía, MVC, Flux, Componente, Pruebas y muchas otras cosas que no mencioné. El desarrollo del backend es bastante sencillo. No ha habido tantos cambios en cómo construir API de backend y cómo deberían estructurarse las cosas. Es por eso que los desarrolladores de backend tienen más confianza. Los desarrolladores front-end siempre deben estar atentos a las nuevas tendencias y tecnologías que se están desarrollando. Siempre estás en una afluencia de aprender algo nuevo.

El desarrollo frontend involucra el elemento más impredecible de todos: los humanos sentados frente a una computadora y usando su interfaz. Te sorprenderán cada vez.

Más allá de las opiniones sobre cuán sexy se ve la interfaz, debe responder:

• ¿Le estoy comunicando al usuario cómo funciona el sistema? Si usan un control que has hecho, ¿sucede lo que esperan que suceda?
• ¿Es el sistema eficiente de usar? Ex. ¿Hay demasiados clics del mouse para hacer algo?
• ¿La interfaz guía al usuario de manera que se eviten los errores?
• ¿Cuáles son las consecuencias de que el usuario cometa un error? ¿Puede el usuario recuperarse o desencadena una taza de problemas que se arremolina?
• ¿Podrá el usuario utilizar la interfaz en su propio entorno? A menudo, los usuarios necesitarán usar su software en lugares que son radicalmente diferentes a su oficina tranquila y agradable.

A veces, los desarrolladores frontend tienen la suerte de trabajar con un verdadero diseñador de aplicaciones que comprende todo esto, pero con frecuencia, el desarrollador frontend necesita usar los sombreros de desarrollador y diseñador.

El front-end cambia proporcionalmente a la forma en que usamos Internet y los dispositivos que lo consumimos. Es la parte visible del iceberg que debe cumplir con las expectativas de esos usuarios y dispositivos conectados y representa cómo usamos Internet. Es el negociador que media entre los usuarios y el servidor.

El código de fondo cambia proporcionalmente para lo que usamos Internet. Por lo general, se preocupaba más por servir activos y datos persistentes.

Lo que realmente no ha cambiado todavía estamos utilizando Internet principalmente para realizar las mismas tareas que hemos realizado en Internet. Por esta razón, las soluciones de back-end aún cumplen sus objetivos.

Los principales avances en el backend han sido el uso de servidores web no bloqueantes, websockets, Ipv6 y devOps. Estos no son cambios drásticos en el funcionamiento del backend y la mayoría son opcionales y muchas empresas y sitios no usan ninguno de estos.

Ajax en 2004 no se parece a lo que hacemos ahora con los componentes Angular, Meteor, React y Web, y la forma en que codificó un sitio en ese entonces es muy diferente. Podría abrir el bloc de notas en ese momento y codificar.

Hoy necesita tragar, gruñir, enredarse, npm solo para comenzar. Hay una explosión en las API web para ponerse al día. Cosas como la capacidad de respuesta para adaptarse al tamaño de la pantalla, el soporte del navegador, ARIA y los cambios en las especificaciones CSS no son tan opcionales. Luego están las cosas llamativas que parecen opcionales, pero son las cosas que la gente quiere. La gente quiere: ¡el cliente quiere! Así que cosas como WebGL, animación SVG, etc.

Más recientemente, la progresividad es algo que será necesario para que los sitios web puedan trabajar sin conexión. ¡Este es un cambio que significa que los desarrolladores front-end tendrán que estructurar los sitios y los datos de tal manera que los datos se comporten como si tuvieran un back-end! es decir, los roles de desarrolladores front-end están comenzando a difuminarse en los roles de los desarrolladores de back-end.

Con más dispositivos que nunca, IoT se avecina y más usuarios / dispositivos en línea cada año que exigen una mejor experiencia, el cómo nunca puede dejar de evolucionar. Esto causa incertidumbre en las vidas de los codificadores de front-end que los codificadores de back-end pueden ignorar debido al ritmo más lento que disfrutan.

He sido un tipo completo durante más de 10 años, así que lo intentaré. No llamaría a lo que está hablando una falta de confianza por parte de los desarrolladores front-end, pero tal vez una diferencia en las frustraciones, dadas las diferencias en lo que tratan y de dónde viene cada uno.

Lo primero que puede considerar es que el desarrollo front-end se ejecuta en múltiples entornos, es decir, múltiples navegadores, en múltiples versiones, en múltiples sistemas operativos. Esto invita a la inconsistencia, tanto para la apariencia como para el comportamiento. Debe lidiar con esto, tanto con CSS como con JavaScript, y agrega una capa adicional de frustración, además de escribir cualquier combinación de JS / CSS / HTML que se requiera para resolver un problema en particular.

Sin embargo, en el back-end, tienes UN ambiente por el cual preocuparte: esperas un cierto comportamiento, basado en eso, y eso es lo que obtienes. Trabaje con JavaScript del lado del servidor, luego trabaje con JavaScript del lado del cliente. Incluso con las bibliotecas en las que apoyarse, terminas encontrando inconsistencias (a veces desagradables) entre los navegadores. Cuando trabajo con NodeJS, que usa el motor V8 de Google, es de lo único que debo preocuparme. Sé lo que admite V8, en términos de especificaciones de ECMA e incluso características experimentales. JS es un ejemplo bastante sólido, porque es popular tanto para el servidor como para el cliente, y es una buena comparación.

Del mismo modo, si estoy programando con Java en el servidor, sé exactamente cómo se comportará, porque la JVM y el contenedor de aplicaciones son todo lo que necesito para preocuparme.

Otra cosa a considerar es que si algo en el backend no funciona como está diseñado, el usuario final lo notará en el frente, si los datos que regresan del servidor están formateados incorrectamente y se están rompiendo cuando su JavaScript está intentando para analizarlo, después de una solicitud REST, o los datos son simplemente incorrectos, o no vuelven, en absoluto. La mayoría de los usuarios finales no serán lo suficientemente inteligentes como para darse cuenta de que es un problema de backend, solo ven que está roto. Incluso algunos de sus gerentes de proyecto pueden no saber la diferencia, y por lo general son los primeros en llegar al front end. Las únicas personas que van a saber de inmediato son las personas de control de calidad, y a veces incluso pueden no darse cuenta de lo que está sucediendo, dependiendo de cuánta experiencia tengan y cuánto tiempo hayan estado en el proyecto en el que están trabajando. .

En tercer lugar, como un tipo de pila completa, algo con lo que me encuentro con bastante frecuencia, cuando construyo nuevas funciones de front-end o refactorizo ​​las viejas, para que funcione como realmente estaban destinadas o simplemente reconstruir el código en algo más fácil de mantener, es descubrir que, en realidad, también es necesario realizar una cantidad considerable de trabajo en el backend, a veces, tanto como en el front-end, para admitir la función.

Por último, pero también digno de mención, hablando de refactorizar el código de front-end, es que, culturalmente, he descubierto que la calidad del código de front-end normalmente es una ocurrencia tardía y / o ese código fue escrito por alguien que es más un backend persona, y construyó el código del cliente, de todos modos, simplemente porque nadie más estaba disponible o porque creían saber lo que estaban haciendo. Claro, lo hicieron funcionar, pero el peor código que he visto en mi carrera se debe a esto, y lo veo a menudo en el front end, mientras que la calidad de la programación de back-end tiende a ver más enfoque.

Algo que no es tan cierto ahora, como lo fue hace años, al menos entre las personas con las que he trabajado, la mayoría de los programadores de back-end que he conocido provienen de sólidos antecedentes en informática, o al menos han trabajado lo suficiente y se autoalimentan investigación para tener chuletas de CS sólidas. Hoy en día, lo veo cada vez más en el front-end, ya que la experiencia de JavaScript tiene una demanda bastante alta y la complejidad del lado del cliente de las aplicaciones web ha aumentado (y JavaScript también se ha abierto camino en aplicaciones móviles y de escritorio ) Pero, no siempre fue así. En el pasado, si supiera cómo empalmar imágenes en Photoshop y colocar las piezas en celdas de tabla o mapas de imágenes, y supiera lo poco que había que saber sobre HTML, como un front end, ¡estaba listo para comenzar!

Por lo general, los ingenieros de front-end son los primeros en ser culpados cada vez que algo sale mal. No importa si su base de datos se bloqueó, se notó por primera vez en el front-end. Backend cambió su API sin decírtelo? “¡Maldición! ¿Por qué nuestra IU es tan mala? ”No es una respuesta poco común de la gente.

Ni siquiera me hagas saber cuántos navegadores y dispositivos tenemos que admitir. Y mucho menos correos electrónicos HTML. ¿Tienes un cliente que usa Outlook 2012? Es hora de reescribir sus correos electrónicos usando tablas HTMl 2.1 y etiquetas de fuente 😐 – Dios no permita que tenga un cliente que use Lotus Notes. En estos días solo respondo con “No tenía idea de que podría enviar HTML por correo electrónico. ¡No tengo ni idea de cómo lo hacen! ”, Y consigue que el interno lo haga.

Constantemente tiene que explicar cómo los diferentes dispositivos representarán las cosas de manera diferente. Los diseñadores tienden a querer la perfección de píxeles, que es casi imposible en todos los clientes.

También muchos ingenieros de front-end son autodidactas, más que backend, diría por mi experiencia. Esto generalmente es un problema durante las entrevistas, como ingeniero de front-end, por lo general, puedo acceder a la entrevista, hasta que llegue al chico del backend. Luego me preguntan alguna mierda loca que no tiene nada que ver con nada. ¿No puede detectar la recursividad de la lista vinculada usando la tortuga y el algoritmo de liebre? (literalmente pregunté esto, lo busqué más tarde y algunos doctores inventaron este algoritmo durante 5 años de investigación). No hay forma de que lo invente en 20 minutos. Pero eso significa que soy un ingeniero inferior ya que no sabía lo que era.

También históricamente, el front-end no consistía en programación. Escribiste HTML y / o XML durante bastante tiempo. Sin embargo, todo eso ha cambiado y ahora el front-end es típicamente más complejo que el backend para las aplicaciones CRUD estándar, aunque la actitud aún es backend es superior en inteligencia.

Normalmente no dejo que me moleste. Se hace viejo, y hacer que todos los que tienen un navegador critiquen el front-end (incluso se nos culpa por una mala experiencia de usuario que proviene del equipo de diseño o una API rota) … tiene su efecto.

Honestamente porque hay mucho menos abandono tecnológico y cambio de estilo. Yo diría que en el backend obtienes un gran cambio de paradigma cada 10 años. Lo que significa que puedes conocer tu conjunto de habilidades bastante bien. Además, el conjunto básico de habilidades ha sido el mismo durante mucho tiempo, básicamente, conoce algoritmos, conoce estructuras de datos e intenta no arruinar por completo tu estrategia de almacenamiento en caché.

El desarrollo front-end en este momento cambia el marco cada 3 años, pero lo más importante es que cambian los paradigmas. Por ejemplo, un front-end de desarrolladores web en el mundo .net pasó de: WebForms -> MVC -> Algún tipo de MVVM o MVC basado en el cliente (Angular o noqueado) -> Ahora tal vez Reaccionar o algún equivalente en los últimos 8 años.

La audiencia para los desarrolladores de back-end son ellos mismos y sus pares. Todos hablan el mismo idioma (s), lidian con el mismo tipo de problemas y saben lo suficiente como para poder evaluar su propio código (y el código de los demás) en sus propios términos. Es relativamente fácil saber si estás ganando o perdiendo. La tasa de evolución allí es razonablemente lenta, por lo que es fácil estar al día. El grado de tendencia y brillo es pequeño. La arquitectura y las herramientas son robustas y bien conocidas.

En otros lugares, no hay forma de acercarse a la corrección evidente del código producido allí. Factores como la necesidad de evitar confundir a los usuarios y otros simples mortales asumen una gran importancia. Las modas de interfaz, servicios y TLA (acrónimos de tres letras) desordenan el paisaje. No hay cosas correctas o la forma correcta allí.

Las modas te atraparán especialmente. Mi ejemplo favorito actual de esto es el abandono de los iconos 3D para los feos planos y monocromáticos. La única razón por la que puedo pensar en este cambio es que algunos terrones de marketing en Microsoft (no hay terrones de marketing en el back-end, gracias a Dios) decidieron que tenía que haber alguna forma de avergonzar a las personas que no ejecutaban versiones actuales. Así que los iconos planos telegrafían a los usuarios de versiones anteriores de Microsoft Office. Qué tontas y livianas personas deben ser. Vamos a faltarles el respeto a todos. Debemos borrar el ejemplo de Windows XP (el sistema operativo que no moriría) de los recuerdos de los clientes. Si no podemos proporcionar muchas características nuevas y necesarias, al menos podemos aplicar la presión de grupo. (“Psst. ¿Ves que todavía usa Word 2010?”)

En el frente, es bueno tener menos confianza en nuestra profesión. Las modas son muchas y en gran medida inútiles. Los vendedores de aceite de serpiente florecen. Las mejoras marginales se tratan como revoluciones.

Los desarrolladores de backbend pueden predecir su entorno, saben qué servidor web / base de datos / API / etc está en el servidor. Los desarrolladores front-end aún tienen que lidiar con muchos navegadores posiblemente desconocidos o con errores, complementos, diferentes tamaños y formas de pantalla, rarezas de autenticación Mobile 4G y WIFI, diferentes versiones de Android, etc. o si todavía tienen que codificar excepciones para navegadores antiguos, etc. Además, el código de formulario puede tener que lidiar con intentos de pirateo en evolución, como intentos de inyección SQL …

No estoy seguro acerca de la confianza, pero esto tiene múltiples dimensiones.

Confianza en sus propias habilidades.

Cuando se trata de back-end de tecnología o, más bien, el desarrollo de middleware tiende a tener un ciclo tecnológico más lento que las tecnologías de front-end. Hay muchas tecnologías que existen desde hace bastante tiempo. No se siente seguro al ser el primero de los pocos elegidos en jugar con la nueva tecnología, sino al obtener suficiente experiencia. Eso es algo difícil de hacer cuando (y para mí a veces se siente así) la tecnología “ir a” cambia trimestralmente.

Prefiero decir que los desarrolladores de back-end / middleware tienden a construir una confianza saludable con el tiempo a medida que ganan experiencia. Fron-end (hoy en día son los desarrolladores web en su mayoría) tienen mucho menos tiempo para adaptarse a las nuevas tecnologías y se ven constantemente obligados a aprender cosas nuevas, a veces desde cero. Eso los hace menos seguros, porque les falta experiencia.

Seguridad en el empleo

Otra cosa sobre la confianza es lo seguro que se siente acerca de su situación laboral actual. Es cierto que, como desarrollador front-end, probablemente no tenga muchos problemas para encontrar trabajo. Con la cantidad de software que se está desarrollando hoy en día, hay muchas oportunidades. Sin embargo, si bien los sistemas de back-end tienden a estar orientados por mucho tiempo y son bastante estables, el trabajo de front-end es algo inestable. Una gran cantidad de trabajo front-end hoy en día está en proyectos más pequeños como aplicaciones. Para mí, ese tipo de cosas no se siente muy seguro.

Ser un especialista frente a la demanda

Lo último que es un gran impulso de confianza es la intersección de las dos preguntas siguientes:

1. ¿Cuántas personas en su área, estado o incluso país pueden hacer exactamente el mismo trabajo que usted? En otras palabras: ¿eres un especialista?
2. ¿Hay más demanda que especialistas en esta área específica de trabajo?

Esta es una línea delgada para caminar. Ser especialista en un nicho demasiado pequeño puede generar problemas de empleo. Por otro lado, puede disparar su valor como desarrollador especializado. Con el desarrollo de back-end, hay muchas cosas de nicho en las que puede trabajar.

Estoy seguro de que Internet intentará destrozarme en este debate, pero seguiré adelante y afirmaré que hay menos temas de nicho en el desarrollo front-end que tienen una gran demanda .