Os programadores da GUI têm uma vantagem indevida sobre os outros?

É fácil para gerentes e clientes apreciarem o que podem ver.

Eu já vi muitos desenvolvedores de GUI que são programadores comuns, com conhecimento mínimo de princípios de design ou outros idiomas de programação. No entanto, essas deficiências geralmente passam despercebidas, especialmente pela gerência e pelos clientes, se o programador puder criar uma interface de usuário impressionante. Tanto é assim que muitos desenvolvedores de GUI que conheço passam horas embelezando a GUI à custa de escrever códigos ruins e inatingíveis.

Por outro lado, programadores de camada intermediária que desenvolvem APIs ou funcionalidade comercial ou código de banco de dados (SQLs etc.) estão em desvantagem, pois não há nada tangível para mostrar. Talvez um revisor de código ou um arquiteto aprecie a elegância, o bom design, a escalabilidade etc. do código, mas isso não significa nada para o mundo exterior. Seu código pode funcionar por anos sem quebrar, pode ser muito fácil de manter e ter um bom desempenho, mas nunca provoca o 'uau' que uma GUI de aparência elegante faz.

Na minha opinião, um corolário disso é (e eu vou ser muito criticado por isso, eu sei) que há menos motivação para um programador de GUI escrever um bom código limpo.

Edição : Devo explicar aqui que, por programador de GUI, não me refiro a um designer de web / GUI completo, mas a um programa front-end, por exemplo, um programador de Java-Swing.

O resto da comunidade concorda?

Acho que entendi seu ponto de vista, mas suspeito que também haja uma questão oposta a considerar.

Basicamente, acredito que você está sugerindo que, como a interface do usuário é o elemento do aplicativo 'na cara' dos usuários finais, os desenvolvedores da interface do usuário desfrutam de uma maior visibilidade do que os membros da equipe que trabalham em camadas mais profundas do aplicativo.

Certamente concordo que pode haver uma maior visibilidade. Por exemplo, os desenvolvedores que trabalham nos elementos da interface do usuário podem interagir com os usuários finais com mais frequência (sem dúvida, por boas razões, uma vez que se concentram no aspecto de interação humano / computador).

No entanto, acho que a maior visibilidade entra em jogo, mesmo nos casos em que há um problema. Por exemplo, é muito provável que os usuários finais relatem problemas como 'Problemas da GUI' mesmo quando não o são.

Tudo pode se resumir à percepção, e uma organização madura deve ser capaz de reconhecer valores, virtudes e fraquezas dos vários membros da equipe, independentemente da camada do aplicativo em que trabalham. Uma organização madura também pode ter ido além de distinções como 'desenvolvedor de interface do usuário' e 'desenvolvedor da camada de negócios', reconhecendo que todos são membros da equipe de qualquer maneira, talvez com conhecimentos diferentes, mas sempre tentando se educar nessas áreas de conhecimento.

Para uma pessoa que não lida com programadores, posso dizer com confiança que eles acreditariam nesse tipo de coisa. Eles não sabem a quantidade de trabalho em segundo plano, tudo o que vêem é um monte de botões / caixas de texto / menus / [inserir elemento da GUI] e a velocidade necessária para realizar o que o botão iniciou. Então, inicialmente, as pessoas da GUI são mais queridas.

Se a pessoa faz negócio com os programadores, então, é um pouco diferente. Como você disse, eles notariam se você o tornasse escalável, mais fácil de manter, reescrevesse um algoritmo para que fizesse mais sentido ou qualquer outra tarefa do tipo manutenção. Esse tipo de pessoa olharia para todos os programadores igualmente.

No meio, depende do que você está fazendo. A velocidade então se torna o fator importante aqui. Se você pode mostrar antes e depois das gravações de quanto tempo leva para um formulário ser processado e armazenado e há uma melhoria, você é igual. Se você pode mostrar o aplicativo sob carga de 100 clientes e mostrar a eles o servidor derretendo, e depois mostrar a eles sua versão onde tudo está bem, é igual. Etc.

Em resumo, depende da pessoa e do que você está fazendo.

Como o "especialista em interface do usuário" da minha empresa (o responsável por todo o desenvolvimento da interface do usuário, não apenas o design), acho que você pode estar perdendo parte da história. Enquanto eu sou o responsável pela interface do usuário, também trabalho no back-end, nos bancos de dados, etc. Faço tudo isso (somos uma equipe pequena). [Desenvolvimento de C # e ASP.Net WebForms]

Primeiro de tudo, sim, é muito mais fácil para as pessoas não técnicas apreciarem o trabalho de um desenvolvedor de GUI, porque é isso que as pessoas enfrentam. Para pessoas não técnicas, a GUI é o aplicativo . A desvantagem é que a GUI também é a primeira a ser responsabilizada quando algo dá errado.

Em segundo lugar, o desenvolvimento do front-end tem sido muito mais desafiador para mim do que o back-end já foi (algoritmos obscuros / complexos à parte). Há muito mais para se proteger, é apátrida (nossos aplicativos estão na Web), os navegadores não se comportam de maneira consistente (as bibliotecas JavaScript eram uma dádiva de Deus) etc. Espero que a maior parte dessa complexidade seja devido à estrutura que tenho. trabalhar com (ASP.Net WebForms) e que todas as coisas difíceis não serão um problema no futuro.

No geral, tive muito mais dificuldade em resolver problemas de interface do que problemas de back-end.

Eu odeio o desenvolvimento de GUI por duas razões,

1. Sou mais lógico do que graficamente artístico e minha interface do usuário sempre sofre como resultado.
2. Como a interface do usuário não se baseia na lógica, os testes de unidade são quase impossíveis de serem escritos com algum significado

No final do dia, no entanto, acho que meu código será mais apreciado pelo usuário final (em oposição, talvez, a um patrocinador do projeto), do que o de um desenvolvedor medíocre que é um gênio na UI, pois geralmente funciona .

Para (talvez) expandir um pouco a resposta do @ TheLQ, acho que também depende do "visualizador".

Eu tive alguma experiência com alguns gerentes / supervisores de nível superior que não têm experiência em programação. Alguns reconhecem que não programam, mas entendem que o cromo e as calotas são tão importantes quanto o motor e o chassi.

E já tive experiência com alguns gerentes / supervisores de nível superior que não se importam com outras métricas além da escalada da interface do usuário. Mesmo afirmando que mais desenvolvedores orientados à interface do usuário eram importantes.

IMHO, todos sabemos que você não pode polir um bosta e um aplicativo rápido, confiável e feio será muito pior do que um aplicativo que pareça bom e funcione bem. Está tudo nos olhos de quem vê e, até certo ponto, você tem o poder (independentemente do que faz) de ser visto à luz que deseja, trabalhando para aqueles que apreciam as mesmas qualidades que você.

EDIT: devo acrescentar que, sendo alguém que se sente mais à vontade trabalhando em itens de nível inferior, fico desanimado quando você trabalha tão duro quanto a equipe da interface do usuário e é o polonês elogiado na demonstração e não o fato de o sistema " apenas funcionou ". Mas, como eu disse, sei que meu supervisor sabe que o trabalho é necessário em todas as áreas.

Eu acho que existe uma presunção geral por aí de que os desenvolvedores da interface do usuário são os desenvolvedores "juniores". Só consigo pensar em um caso em que encontrei um cara de interface do usuário que era considerado sênior.

Dito isto, acho que a interface do usuário é muito mais difícil do que qualquer outra parte de nossos aplicativos. E não estou falando sobre o design de UX, estou falando sobre a codificação. Quantas outras áreas codificamos onde devemos contabilizar dezenas, senão centenas, ou possíveis cenários? Apenas redimensionar uma tela às vezes pode se tornar uma dor real quando você precisa descobrir o que precisa acontecer com algumas dezenas de elementos. Isso ocorre principalmente quando você tem diretrizes que dizem "precisamos oferecer suporte a 800x600" e, em seguida, designers de UX que nunca usam nada além de resoluções em HD.

Portanto, se eles obtêm mais bondade por causa de mais exposição, provavelmente merecem. Geralmente, eles estão errados com mais frequência do que com os bons.

Muitas vezes parece haver a ideia de que um programador de GUI está na parte inferior da cadeia de programadores. Quão difícil pode ser arrastar e soltar um botão no VS para um formulário? Você levará uma semana para programar isso? Está desenhando algumas barras. Portanto, não estou surpreso ao ver a idéia de que os programadores da GUI, por serem os botões que arrastam, também devem estar escrevendo código horrível.

A programação da GUI tem alguns desafios únicos. Multithreading para manter a GUI ativa enquanto os dados são carregados. Isso leva ao encadeamento de código seguro e adequado. O desempenho é muito importante. Ninguém gosta de esperar dois minutos até obter o controle do aplicativo novamente. A reutilização também se torna um grande problema. Se você tiver que escrever dez telas semelhantes, é melhor estruturar bem seu código. Isso leva a um código melhor. E, é claro, criar uma boa interface gráfica do usuário é um desafio em si.

Mas para algumas pessoas, basta arrastar um botão para o seu aplicativo. Assim como para algumas pessoas, a lógica de negócios nada mais é do que "analisar uma mensagem e colocá-la no banco de dados".

Eu acho que é óbvio que eles fazem. Talvez os desenvolvedores de primeira linha estejam isentos, mas a maioria dos outros não.

Quando seu gerente pergunta o que você fez no mês passado, é fácil mostrar uma interface gráfica interessante. É difícil mostrar uma API legal. Muito difícil. O frescor da API só é aparente através do uso real - não pode ser apreciado de relance.

Você pode se safar de todo tipo de hackery e atalhos nos sistemas internos. Ao lidar com a GUI, você não tem essa liberdade. Sua API interna pode ter inconsistência e você espera que os codificadores lidem com ela porque é muito difícil de corrigir. Você não pode tentar fazer com que seus clientes façam a mesma coisa. Então, em certo sentido, as pessoas que precisam lidar com os componentes visíveis do usuário precisam seguir um padrão mais alto.

Vou dizer que sim, por uma simples razão: o iPhone. Todo mundo com quem conversei acha isso fantástico por causa da interface elegante, mas só posso imaginar o trabalho abaixo para tornar tudo isso possível.

Depende da audiência. Eu trabalho com muitos analistas financeiros e a idéia deles de um bom design de GUI é aquela que possui tantos campos quanto você pode inserir em um formulário. Sério, estou falando de 75 a 100. Eles são viciados em dados que sempre querem mais. Recentemente, melhorei o desempenho em alguns procedimentos armazenados que podiam levar 45 segundos para carregar (calcular médias ponderadas desde o início das coisas). Reduza para 30 segundos; Estou pensando uau, corte um terço do tempo; deve ser um item de linha no meu currículo. Ninguém nem percebeu. Continuou trabalhando nele e chegou a 15-20. Mudança perceptível. Todo mundo estava muito feliz. Eu ainda acho que a GUI é uma abominação e se tirássemos essa porcaria inútil, ela seria carregada em 2 segundos,

Portanto, se você deseja que os usuários realmente o amem, lembre-se de que a melhor interface do usuário não é nenhuma interface (gostaria de lembrar quem disse isso). Depois de querer ver todos esses dados, meus analistas perceberam que são eles que fazem toda a entrada de dados - o horror.

Testar partes da interface do usuário do aplicativo é um pesadelo.

Todas as pessoas ao redor se sentem competentes para dar um conselho ou definir uma demanda sobre como você deve fazê-lo.

Depois que o sistema funciona, mais tarde, mesmo que alguém se lembre acidentalmente de quem ele é a virtude, ninguém se lembrará de quem fez o quê.

Mas se algum erro for visto ( alguns sempre acontecem), o primeiro homem a ser condenado será o programador da GUI. O usuário simplesmente nunca viu os outros!