¿Los programadores de GUI tienen una ventaja indebida sobre los demás?

Es fácil para los gerentes y clientes apreciar lo que pueden ver.

He visto muchos desarrolladores de GUI que son programadores promedio con un conocimiento mínimo de los principios de diseño u otros modismos de programación. Sin embargo, estas deficiencias a menudo pasan desapercibidas, especialmente por la administración y los clientes, si el programador puede crear una interfaz de usuario de aspecto impresionante. Tanto es así que muchos desarrolladores de GUI que conozco pasan horas embelleciendo la GUI a expensas de escribir código incorrecto que no se puede mantener.

Por otro lado, los programadores de nivel medio que desarrollan API o funcionalidad empresarial o código de base de datos (SQL, etc.) están en desventaja ya que no hay nada tangible que mostrar. Quizás un revisor de códigos o un arquitecto puedan apreciar la elegancia, el buen diseño, la escalabilidad, etc. del código, pero no significa nada para el mundo exterior. Su código puede ejecutarse durante años sin romperse, puede ser muy fácil de mantener y tener un buen rendimiento, sin embargo, nunca provoca el 'wow' que hace una GUI de aspecto elegante.

En mi opinión, un corolario de esto es (y voy a ser fuertemente rechazado por esto, lo sé) que hay menos motivación para que un programador de GUI escriba un buen código limpio.

EDITAR : Debo explicar aquí que por programador GUI, no me refiero a un diseñador web / GUI completo, sino a un programador front-end, por ejemplo, un programador java-swing.

¿Está de acuerdo el resto de la comunidad?

Creo que entiendo su punto, pero sospecho que también hay una cuestión opuesta a considerar.

Esencialmente, creo que está sugiriendo que, dado que la interfaz de usuario es el elemento de la aplicación 'en la cara' de los usuarios finales, los desarrolladores de la interfaz de usuario disfrutan de una mayor visibilidad que los miembros del equipo que trabajan en capas más profundas de la aplicación.

Ciertamente, estoy de acuerdo en que puede haber una mayor visibilidad. Por ejemplo, los desarrolladores que trabajan en los elementos de la interfaz de usuario pueden interactuar con los usuarios finales con mayor frecuencia (posiblemente, por buenas razones, ya que se centran en el aspecto de interacción humano / computadora).

Sin embargo, creo que la mayor visibilidad entra en juego incluso en los casos en que hay un problema. Por ejemplo, es muy probable que los usuarios finales reporten problemas como 'Problemas de GUI' incluso cuando no lo son.

Todo puede reducirse a la percepción, y una organización madura debería ser capaz de reconocer los valores, las virtudes y las debilidades de los diferentes miembros del equipo independientemente de la capa de la aplicación en la que trabajan. Una organización madura también puede haber ido más allá de las distinciones como 'desarrollador de interfaz de usuario' y 'desarrollador de capa empresarial', reconociendo que todos son miembros del equipo de todos modos, con diferente experiencia quizás, pero siempre tratando de educarse mutuamente en esas áreas de experiencia.

Para una persona que no trata con programadores, puedo decir con confianza que creerían este tipo de cosas. No saben la cantidad de trabajo que se realiza en segundo plano, todo lo que ven es un montón de botones / cuadros de texto / menús / [insertar elemento GUI] y la velocidad que se necesita para lograr lo que comenzó el botón. Inicialmente, a las personas con GUI les gusta más.

Si la persona hace trato con los programadores, entonces es un poco diferente. Como dijiste, se darían cuenta si lo hiciste escalable, más fácil de mantener, reescribió un algoritmo para que tuviera más sentido o cualquier otra tarea de tipo de mantenimiento. Este tipo de persona miraría a todos los programadores por igual.

En el medio, depende de lo que estés haciendo. La velocidad se convierte en el factor importante aquí. Si puede mostrar grabaciones de antes y después de cuánto tiempo lleva procesar y almacenar un formulario y hay una mejora, usted es igual. Si puede mostrar la aplicación bajo carga desde 100 clientes y mostrarles la fusión del servidor, y luego mostrarles su versión donde todo está bien, su igual. Etc.

En resumen, depende de la persona y de lo que estés haciendo.

Como el "experto en UI" de mi empresa (el encargado de todo el desarrollo de la UI, no solo del diseño), creo que puede estar perdiendo parte de la historia. Si bien soy el responsable de la interfaz de usuario, también trabajo en el back-end, en las bases de datos, etc. Lo hago todo (somos un equipo pequeño). [Desarrollo de C # y ASP.Net WebForms]

En primer lugar, sí, es mucho más fácil para las personas no técnicas apreciar el trabajo de un desarrollador de GUI porque eso es lo que se enfrenta a las personas. Para personas no técnicas, la GUI es la aplicación . El inconveniente es que la GUI también es la primera en ser culpada cuando algo sale mal.

En segundo lugar, desarrollar el front-end ha sido mucho más desafiante para mí que el back-end (aparte de los algoritmos oscuros / complejos). Hay mucho más de lo que protegerse, no tiene estado (nuestras aplicaciones están en la Web), los navegadores no se comportan de manera consistente (las bibliotecas de JavaScript fueron un regalo del cielo), etc. Espero que la mayor parte de esta complejidad se deba al marco que tengo. para trabajar con (ASP.Net WebForms) y que todas las cosas difíciles no serán un problema en el futuro.

En general, he tenido muchas más dificultades para resolver problemas de UI que problemas de back-end.

Odio el desarrollo de GUI por dos razones,

1. Soy más lógico que gráficamente artístico y mi IU siempre sufre como resultado.
2. Como la interfaz de usuario no se basa en la lógica, las pruebas unitarias son casi imposibles de escribir con ningún significado

Al final del día, sin embargo, creo que mi código será mejor apreciado por el usuario final (a diferencia de un patrocinador del proyecto), que el de un desarrollador mediocre que es un genio en la interfaz de usuario, ya que generalmente funciona .

Para (tal vez) ampliar un poco la respuesta de @ TheLQ, creo que también depende del "espectador".

He tenido alguna experiencia con algunos gerentes / supervisores de nivel superior que no tienen experiencia en programación. Algunos aprecian que no programan, pero entienden que el cromo y los tapacubos son tan importantes como el motor y el chasis.

Y he tenido experiencia con algunos gerentes / supervisores de nivel superior que no se preocupan por ninguna métrica que no sea la chisporroteo de la interfaz de usuario. Incluso afirmando que más desarrolladores orientados a la interfaz de usuario son importantes.

En mi humilde opinión, todos sabemos que no se puede pulir una basura y una aplicación rápida, confiable pero fea será mucho peor que una aplicación que se ve bien y funciona bien. Todo está en el ojo del espectador y, en cierta medida, tiene el poder (independientemente de lo que haga) para ser visto a la luz que desee, trabajando para aquellos que aprecian las mismas cualidades que usted.

EDITAR: debo agregar que, siendo alguien que se siente más cómodo trabajando en artículos de nivel inferior, me siento hastiado cuando trabajas igual de duro que el equipo de UI y es el pulido que se elogió en la demostración y no el hecho de que el sistema " simplemente funcionó ". Pero como dije, sé que mi supervisor sabe que el trabajo es necesario en todas las áreas.

Creo que existe una presunción general de que los desarrolladores de UI son los desarrolladores "junior". Solo puedo pensar en un caso en el que me encontré donde un tipo de UI era considerado senior.

Dicho esto, creo que la interfaz de usuario es mucho más difícil que cualquier otra parte de nuestras aplicaciones. Y no estoy hablando del diseño UX, estoy hablando de la codificación. ¿En cuántas otras áreas codificamos donde tenemos que dar cuenta de docenas, si no cientos, o posibles escenarios? Solo cambiar el tamaño de una pantalla a veces puede convertirse en un dolor real cuando necesitas descubrir qué debe pasar con un par de docenas de elementos. Esto surge principalmente cuando tienes pautas que dicen "necesitamos admitir 800x600" y luego diseñadores UX que nunca usan otra cosa que no sean resoluciones HD.

Entonces, si obtienen más bondad debido a una mayor exposición, probablemente se lo merezcan. Por lo general, están en el extremo receptor equivocado con mayor frecuencia que en el extremo receptor bueno.

A menudo parece existir la idea de que un programador de GUI está en la parte inferior de la cadena de programadores. ¿Qué tan difícil puede ser arrastrar y soltar un botón en VS a un formulario? ¿Qué, te llevará una semana programar eso? Está dibujando algunas barras. Por lo tanto, no me sorprende ver la idea de que los programadores de GUI, al ser los arrastradores de botones como están, también deben escribir un código horrible.

La programación GUI tiene algunos desafíos únicos. Multithreading para mantener la GUI activa mientras se cargan los datos. Esto conduce a un código seguro y adecuado para subprocesos. El rendimiento es muy importante. A nadie le gusta esperar dos minutos hasta que vuelvan a controlar la aplicación. La reutilización también se convierte en un gran problema. Si tiene que escribir diez pantallas similares, es mejor estructurar bien su código. Esto lleva a un mejor código. Y, por supuesto, crear una buena GUI es un desafío en sí mismo.

Pero para algunas personas simplemente arrastrará un botón a su aplicación. Al igual que para algunas personas, la lógica empresarial no es más que "analizar un mensaje y ponerlo en la base de datos".

Creo que es obvio que lo hacen. Quizás las casas de desarrollo de primer nivel están exentas, pero la mayoría de los demás no lo están.

Cuando su gerente le pregunta qué ha hecho durante el último mes, es fácil mostrar una GUI genial. Es difícil mostrar una API genial. Muy duro. La frescura de la API solo es aparente a través del uso real; no se puede apreciar de un vistazo.

Puede salirse con la suya con todo tipo de hackers y accesos directos en los sistemas internos. Cuando se trata con la GUI no tienes esa libertad. Su API interna puede tener inconsistencias y solo espera que los codificadores se encarguen de ella porque es demasiado difícil de arreglar. No puede intentar y hacer que sus clientes hagan lo mismo. Entonces, en cierto sentido, las personas que tienen que lidiar con los componentes visibles del usuario tienen que seguir un estándar más alto.

Voy a decir que sí, por una simple razón: el iPhone. Todas las personas con las que he hablado piensan que es fantástico debido a la interfaz elegante, pero solo puedo imaginar el trabajo debajo para hacer que todo sea posible.

Depende de la audiencia. Trabajo con muchos analistas financieros y su idea de un buen diseño de interfaz gráfica de usuario es uno que tiene tantos campos como sea posible que pueda atascarse en un formulario. En serio, estoy hablando de 75 a 100. Son adictos a los datos que siempre quieren más. Recientemente, mejoré el rendimiento en algunos procedimientos almacenados que podrían demorar 45 segundos en cargarse (calcular promedios ponderados desde el comienzo del tiempo). Lo bajé a 30 segundos; Estoy pensando wow, corta un tercio del tiempo; debería ser una línea de pedido en mi currículum. Nadie se dio cuenta. Seguí trabajando en ello y llegué a 15-20. Cambio notable. Todos estaban muy felices. Todavía creo que la GUI es una abominación y si sacamos esta basura inútil, se cargaría en 2 segundos,

Entonces, si desea que los usuarios realmente lo amen, recuerde que la mejor interfaz de usuario es ninguna interfaz (desearía recordar quién dijo eso). Después de querer ver todos estos datos, mis analistas se han dado cuenta de que son ellos quienes hacen toda la entrada de datos: el horror.

Probar partes de la interfaz de usuario de la aplicación es una pesadilla.

Cada persona a su alrededor se siente competente para dar un consejo o establecer una demanda sobre cómo debe hacerlo.

Después de que el sistema funciona bien, más tarde, incluso si alguien recuerda accidentalmente quién tiene la virtud, nadie recordará quién hizo qué.

Pero si se ve algún error ( algunos siempre suceden), el primer hombre en ser condenado será el programador de la GUI. ¡El usuario simplemente nunca había visto a los demás!