Les programmeurs GUI ont-ils un avantage indu sur les autres?

Il est facile pour les gestionnaires et les clients d'apprécier ce qu'ils peuvent voir.

J'ai vu de nombreux développeurs de GUI qui sont des programmeurs moyens avec une connaissance minimale des principes de conception ou d'autres idiomes de programmation. Cependant, ces lacunes passent souvent inaperçues, en particulier de la part de la direction et des clients, si le programmeur peut créer une interface utilisateur impressionnante. À tel point que de nombreux développeurs d'interfaces graphiques que je connais passent des heures à embellir l'interface graphique au détriment de l'écriture de mauvais code non maintenable.

En revanche, les programmeurs de niveau intermédiaire qui développent des API ou des fonctionnalités métier ou du code de base de données (SQL, etc.) sont désavantagés car il n'y a rien de tangible à présenter. Un réviseur de code ou un architecte peut peut-être apprécier l'élégance, la bonne conception, l'évolutivité, etc. du code, mais cela ne signifie rien pour le monde extérieur. Votre code peut fonctionner pendant des années sans se casser, peut être très facile à entretenir et avoir de bonnes performances, mais il ne suscite jamais le «wow» que fait une interface graphique élégante.

À mon avis, un corollaire à cela est (et je vais être fortement rétrogradé pour cela, je sais) qu'il y a moins de motivation pour un programmeur GUI à écrire un bon code propre.

EDIT : Je dois expliquer ici que par programmeur GUI, je ne veux pas dire un concepteur web / GUI à part entière, mais un programmeur frontal, par exemple, un programmeur java-swing.

Le reste de la communauté est-il d'accord?

Je pense que je vois votre point, mais je soupçonne qu'il y a aussi une question opposée à considérer.

Essentiellement, je pense que vous suggérez que, parce que l'interface utilisateur est l'élément de l'application `` face aux utilisateurs finaux '', les développeurs de l'interface utilisateur bénéficient d'une plus grande visibilité que les membres de l'équipe travaillant dans des couches plus profondes de l'application.

Je suis certainement d'accord qu'il peut y avoir une visibilité plus élevée. Par exemple, les développeurs travaillant sur les éléments de l'interface utilisateur peuvent interagir plus souvent avec les utilisateurs finaux (sans doute, pour de bonnes raisons, car ils se concentrent sur l'aspect interaction humaine / ordinateur).

Pourtant, je pense que la plus grande visibilité entre en jeu même en cas de problème. Par exemple, les utilisateurs finaux sont très susceptibles de signaler des problèmes en tant que «problèmes d'interface graphique» même lorsqu'ils ne le sont pas.

Tout peut se résumer à la perception, et une organisation mature devrait être capable de reconnaître les valeurs, les vertus et les faiblesses des différents membres de l'équipe indépendamment de la couche de l'application sur laquelle ils travaillent. Une organisation mature peut également être allée au-delà de distinctions telles que `` développeur d'interface utilisateur '' et `` développeur de couche métier '', reconnaissant qu'ils sont tous membres de l'équipe de toute façon, avec une expertise différente peut-être, mais essayant toujours de s'instruire mutuellement sur ces domaines d'expertise.

Pour une personne qui ne fait affaire avec aucun programmeur, je peux dire avec confiance qu'elle croirait ce genre de choses. Ils ne connaissent pas la quantité de travail qui va en arrière-plan, tout ce qu'ils voient est un tas de boutons / zones de texte / menus / [insérer un élément GUI] et la vitesse nécessaire pour accomplir ce que le bouton a commencé. Donc, au départ, les utilisateurs de l'interface graphique sont plus appréciés.

Si la personne fait affaire avec des programmeurs, c'est un peu différent. Comme vous l'avez dit, ils remarqueraient si vous le rendiez évolutif, plus facile à maintenir, réécrivait un algorithme pour qu'il soit plus logique ou toute autre tâche de type maintenance. Ce genre de personne regarderait tous les programmeurs de la même manière.

Au milieu, cela dépend de ce que vous faites. La vitesse devient alors le facteur important ici. Si vous pouvez montrer avant et après les enregistrements du temps qu'il faut pour qu'un formulaire soit traité et stocké et qu'il y a une amélioration, vous êtes égal. Si vous pouvez montrer l'application sous charge de 100 clients et leur montrer le serveur en train de fondre, puis leur montrer votre version où tout va bien, votre égal. Etc.

En bref, cela dépend de la personne et de ce que vous faites.

En tant qu '"expert UI" dans mon entreprise (le gars en charge de tout le développement UI, pas seulement de la conception), je pense que vous pourriez manquer une partie de l'histoire. Pendant que je suis le responsable de l'interface utilisateur, je travaille également sur le back-end, sur les bases de données, etc. Je fais tout (nous sommes une petite équipe). [Développement C # et ASP.Net WebForms]

Tout d'abord, oui, il est beaucoup plus facile pour les non-techniciens d'apprécier le travail d'un développeur d'interface graphique, car c'est ce qui est en face des gens. Pour les personnes non techniques, l'interface graphique est l'application . L'inconvénient est que l'interface graphique est également la première à être blâmée en cas de problème.

Deuxièmement, développer le front-end a été beaucoup plus difficile pour moi que le back-end (hormis les algorithmes obscurs / complexes). Il y a tellement plus à se prémunir, il est sans état (nos applications sont sur le Web), les navigateurs ne se comportent pas de manière cohérente (les bibliothèques JavaScript étaient une aubaine), etc. J'espère que la plus grande partie de cette complexité est due au cadre que j'ai de travailler avec (ASP.Net WebForms) et que toutes les choses difficiles ne seront plus un problème à l'avenir.

Dans l'ensemble, j'ai eu beaucoup plus de difficulté à résoudre les problèmes d'interface utilisateur que les problèmes d'arrière-plan.

Je déteste le développement d'interface graphique pour deux raisons,

1. Je suis plus logique que graphiquement artistique et mon interface utilisateur en souffre toujours.
2. Comme l'interface utilisateur n'est pas basée sur la logique, les tests unitaires sont presque impossibles à écrire avec un sens

À la fin de la journée, cependant, je pense que mon code sera mieux apprécié par l'utilisateur final (par opposition, peut-être à un sponsor de projet), que celui d'un développeur médiocre qui est un génie de l'interface utilisateur, car il fonctionne généralement .

Pour (peut-être) développer un peu la réponse de @ TheLQ, je pense que cela dépend aussi du "spectateur".

J'ai eu une certaine expérience avec quelques gestionnaires / superviseurs de niveau supérieur qui n'ont pas d'expérience en programmation. Certains apprécient de ne pas programmer, mais comprennent que le chrome et les enjoliveurs sont tout aussi importants que le moteur et le châssis.

Et j'ai eu de l'expérience avec certains gestionnaires / superviseurs de niveau supérieur qui ne se soucient d'aucune mesure autre que le grésillement de l'interface utilisateur. Même en indiquant que les développeurs plus orientés UI sont importants.

À mon humble avis, nous savons tous que vous ne pouvez pas peaufiner une merde et une application rapide, fiable et laide sera bien pire qu'une application qui a l'air bien et qui fonctionne bien. Tout est dans l'œil du spectateur et dans une certaine mesure, vous avez le pouvoir (indépendamment de ce que vous faites) d'être vu à la lumière que vous voulez, en travaillant pour ceux qui apprécient les mêmes qualités que vous.

EDIT: je pourrais ajouter, étant quelqu'un qui se sent plus à l'aise de travailler sur des éléments de niveau inférieur, j'ai été blasé lorsque vous travaillez aussi dur que l'équipe de l'interface utilisateur et c'est le vernis qui est loué dans la démo et non le fait que le système " vient de travailler ". Mais comme je l'ai dit, je sais que mon superviseur sait que le travail est nécessaire dans tous les domaines.

Je pense qu'il y a une présomption générale que les développeurs de l'interface utilisateur sont les développeurs "juniors". Je ne peux penser qu'à un cas dans lequel j'ai rencontré un gars de l'interface utilisateur qui était considéré comme senior.

Cela dit, je pense que l'interface utilisateur est beaucoup plus difficile que toute autre partie de nos applications. Et je ne parle pas de la conception UX, je parle du codage. Combien d'autres domaines codons-nous dans lesquels nous devons prendre en compte des dizaines, voire des centaines, ou des scénarios possibles? Le simple redimensionnement d'un écran peut parfois devenir une douleur royale lorsque vous devez comprendre ce qui doit se passer avec quelques dizaines d'éléments. Cela survient principalement lorsque vous avez des directives qui disent "nous devons prendre en charge 800x600", puis les concepteurs UX qui n'utilisent jamais autre chose que des résolutions HD.

Donc, s'ils obtiennent plus de bonté à cause d'une plus grande exposition, ils le méritent probablement. Habituellement, ils se trouvent plus du mauvais côté récepteur que du bon côté récepteur.

Il semble souvent y avoir l'idée qu'un programmeur GUI est au bas de la chaîne des programmeurs. À quel point peut-il être difficile de glisser-déposer un bouton dans VS vers un formulaire? Quoi, ça vous prendra une semaine pour programmer ça? Il dessine des barres. Je ne suis donc pas surpris de voir l'idée que les programmeurs GUI, étant les draggers de boutons tels qu'ils sont, doivent également écrire du code horrible.

La programmation GUI présente des défis uniques. Multithreading pour garder l'interface graphique active pendant le chargement des données. Cela conduit à un code sûr et approprié pour les threads. La performance est très importante. Personne n'aime attendre deux minutes pour reprendre le contrôle de l'application. La réutilisation devient également un gros problème. Si vous devez écrire dix écrans similaires, vous feriez mieux de bien structurer votre code. Cela conduit à un meilleur code. Et bien sûr, créer une bonne interface graphique est un défi en soi.

Mais pour certaines personnes, il suffit de faire glisser un bouton vers votre application. Tout comme pour certaines personnes, la logique métier n'est rien d'autre que "analyser un message et le mettre dans la base de données".

Je pense qu'il est évident qu'ils le font. Peut-être que les maisons de développement de premier ordre sont exemptées, mais la plupart des autres ne le sont pas.

Lorsque votre responsable vous demande ce que vous avez fait au cours du dernier mois, il est facile d'afficher une interface graphique intéressante. Il est difficile de montrer une API sympa. Très dur. La fraîcheur de l'API n'est apparente que lors d'une utilisation réelle - elle ne peut pas être appréciée en un coup d'œil.

Vous pouvez vous en tirer avec toutes sortes de piratages et de raccourcis dans les systèmes internes. Lorsque vous traitez avec l'interface graphique, vous n'avez pas cette liberté. Votre API interne peut présenter une incohérence et vous vous attendez à ce que les codeurs la gèrent car elle est trop difficile à corriger. Vous ne pouvez pas essayer de faire faire la même chose à vos clients. Donc, dans un certain sens, les personnes qui doivent gérer les composants visibles par l'utilisateur doivent en fait suivre une norme plus élevée.

Je vais dire oui, pour une raison simple: l'iPhone. Tous ceux à qui j'ai déjà parlé pensent que c'est fantastique à cause de l'interface lisse, mais je ne peux qu'imaginer le travail en dessous pour rendre tout cela possible.

Cela dépend du public. Je travaille avec beaucoup d'analystes financiers et leur idée d'une bonne conception de l'interface graphique est celle qui a autant de champs que vous pouvez éventuellement brouiller sur un seul formulaire. Sérieusement, je parle de 75 à 100. Ce sont des accros de données qui en veulent toujours plus. J'ai récemment amélioré les performances de quelques procédures stockées qui pouvaient prendre 45 secondes à charger (calculer les moyennes pondérées depuis le début des tâches temporelles). Je l'ai réduit à 30 secondes; Je pense wow, couper un tiers du temps; cela devrait être un élément de campagne sur mon CV. Personne ne l'a même remarqué. J'ai continué à travailler dessus et je suis arrivé à 15-20. Changement notable. Tout le monde était très content. Je pense toujours que l'interface graphique est une abomination et si nous sortions cette merde inutile, elle se chargerait en 2 secondes,

Donc, si vous voulez que les utilisateurs vous aiment vraiment, rappelez-vous que la meilleure interface utilisateur n'est pas du tout une interface (j'aimerais me rappeler qui a dit cela). Après avoir voulu voir toutes ces données, mes analystes ont réalisé que ce sont eux qui font toutes les entrées de données - l'horreur.

Tester les parties de l'interface utilisateur de l'application est un cauchemar.

Chaque personne autour de vous se sent compétente pour donner un conseil ou pour définir une façon de procéder.

Une fois que le système fonctionne correctement, plus tard, même si quelqu'un se souvient accidentellement de ses vertus, personne ne se souviendra de qui a fait quoi.

Mais si une erreur est constatée ( certaines se produisent toujours), le premier homme à être condamné sera le programmeur graphique, l'utilisateur n'a simplement jamais vu les autres!