ASM51

Lidar com programadores é complicado, eles são muitos orgulhosos e eu não sou diferente, dado que também sou um.

Como pedir para uma pessoa assim melhorar o trabalho que vem fazendo sem ter uma briga? Sem chiliques, sem piadinhas e esquivas da questão de se fazer um código mais legível, que seja mais amigável ao usuário ou que tenha que atender um outro requisito do cliente?

Aos poucos parece que estou me tornando um sub-gerente, meu gerente anda sobrecarregado e tenho que ir atrás de formas de desafogar o homem e acabo agindo em quase todos os campos da empresa, desenvolvimento, compras, testes, manutenção e tal como outro post sobre gestão de pessoas, acho que lidar um especialista cheio de ego, é pior do que lidar com um pessoa do chão de fabrica.

O bom para mim, é que ver essas coisas é como se olhar no espelho e é um horror, que Deus me ajude para que possa ser mais razoável com a idade.

Meu, lidar com pessoas é uma loteria sabe...
As vezes tu encontra gente que pensa igual a ti e o negócio fluí, as vezes tu encontra gente cabeçuda e não adianta.
Em uma empresa onde trabalhei, tive alguns colegas de setor com quem era super fácil conviver e até fico surpreso quando o pessoal me conta coisas positivas que eles falavam de mim mesmo sem necessitar.
Agora, já trabalhei com supostos amigos que passavam o dia inteiro falando mal de mim pelas costas e que depois se faziam de pãozinho na tua frente.
E aparentemente o que eu escrevi até aqui não tem muito nexo com o que tu se propuseste a discutir no tópico, mas bem ao contrário, justamente o ego é que faz isso!
Há pessoas que tem aquele lance de ter que ser o membro alfa do grupo, e mesmo que isso prejudique a empresa, acaba boicotando boas idéias ou até mesmo o convívio com os colegas.
Só sei que, quando tu começa a ver que já passou mais de uma década nesses tipos de ambientes começa a dar aquele arrependimento por não ter escolhido uma profissão que pudesse
ser executada sozinho, tal como dentista ou advogado.

Fundamental -Deixa TEU orgulho de lado. Armado só vai ferrar as coisas.
1-Chega no cara como se VC tivesse com o pepino de simplificar a coisa.
2-Diz que o Boss fodão te intimou e que VC tá meio perdido e PRECISA da ajuda dele.
3- Ele vendo vc de guarda baixa vai baixar tb a dele.
4- Sutilmente vc vai mostrando que ele tb poderia simplificar a parte dele.....que isso agradaria o chefe.....blablabla....!
5- Papo vai papo vem pode até rolar um chopinho na saída ou algo mais depois......!

Uma vez li um livro do Jack Ganssle, e uma coisa que ele defende (dentre muitas outras) são padrões bem estabelecidos.
Por exemplo, é importante que todos numa empresa ou equipe indentem o código igual, dêem nomes de variáveis e funções de forma semelhante, comentem de forma semelhante, e assim por diante. E não dá prá esperar que as pessoas cheguem num consenso, cada um vai fazer de um jeito. A solução é documentar estes padrões, virar documento oficial da empresa, e obrigar os funcionários a seguirem este padrão.
A forma de fazer os programadores seguirem o padrão é através de um processo que ele chama de code-review, muito interessante, IMHO. A ideia é que antes do programador testar o código no dispositivo destino (seja uma placa embarcada, ou mesmo um computador), ele chame duas ou três pessoas que vão ficar por umas duas a três horas revisando o código atrás de bugs. E por bug, inclui-se código mal indentado ou documentado.
Escrever um código sabendo que alguém vai olhar de forma crítica automaticamente muda a postura do programador. Só que o revisor não pode ficar no "eu acho". Ele tem que se basear em um documento de referência da empresa.

Eu concordo contigo Xultz, mas assim mesmo a questão do ego bagunça as coisas.
Eu trabalhei em uma empresa onde não havia padrão para nada, ou seja, esquemas, códigos-fonte, e afins eram feitos ao gosto de desenvolvedor e as vezes nem feitos eram. Então criei alguns modelos e digamos até uma metodologia para fazer as coisas. O pessoal que entrou depois até aceitava as coisas na boa, porém, o cara que já era mais antigo na empresa além de não querer entrar no esquema ficava só debochando da coisa e apontando os pontos fracos,mas sem nunca propor algo melhor.
O cara que tem que ser o mais inteligente do bando senão entra em depressão só prejudica a equipe.

Bom, pra não ficar pessoal, tem que ser feito uma revisão de rotina, para *todos* os códigos, como o xultz falou. Isso realmente deveria ser implementado, mas dependendo da metodologia (ou da falta dela), não há passos de revisão, e fica tudo por isso mesmo.

O ideal é ter um procedimento formal, especialmente se é um projeto novo: teve código novo feito do zero, antes de fazer aprimeira versão "oficial", marca uma reunião e vão todos os envolvidos fazer um revisão do código. A revisão em si é uma das coisas mais chatas que existem na face da terra, mas o resultado geralmente é bom, pode evitar bastante bugs futuros e problemas de suporte.

E o mais importante, isso vale pra seus códigos também, você pode até mesmo melhorar o seu código. Com o tempo, vocês podem ir criando checklists (o código tem comentários? check. As variáveis seguem o padrão estabelecido? check. Tem código open-source?... etc).

Se o gerente não te encarregou disso
que autoridade você tem perante eles ?

DJ

Tive ordens do gerente para escrever sobre melhorias e mais importantes do que tudo, sou um membro da equipe e sou um programador também, dado que eu fui o que mais usei esse software e o que mais vai para a linha de produção, quem melhor do que eu para propor melhorias?

quem melhor do que eu para propor melhorias?

Alguem mais qualificado ,né.

Estamos falando de funcionamento e usabilidade, a opinião que importa é de quem usou o programa.

Implementar padrões sempre gera atritos. Por exemplo, eu sempre desenho resistores usando aquele símbolo retângulo. Se quiser me tirar do sério, me manda usar aquele símbolo zigue-zague, que eu acho ridículo. Só que muito pior é ter numa mesma empresa símbolos diferentes, e na empresa que estou atualmente só usam esse zigue-zague maldito. E eu estou desenhando com ele (e estou conseguindo sobreviver).
Agora, se alguém me mandar indentar o código diferente e não usar as chaves em uma linha só prá ela... melhor nem pensar na possibilidade.

A questão é que a ordem deve vir de cima: cria-se um padrão, e o dono do boteco impõe a ordem. 80% da equipe vai reclamar de várias coisas, mas foda-se, o dono mandou.

Muitas das questões abordadas são definidas por normas técnicas sejam elas Brasileiras, Americanas. Europeias etc a principio como brasileiros devemos adotar as normas ABNT.
Estas normas definem a simbologia o formato e outras características dos desenhos e documentos.
A empresa deve definir quais as normas seguir e nos casos omissos definir sua própria normativa.
Melhorias do quadro funcional depende das condições oferecidas pela empresa, simplesmente falar que isto ou aquilo podia ser melhor não resolve.
Investir em treinamento adequado na área especifica e nas áreas correlacionadas e no desenvolvimento humano.
O auto desenvolvimento deve ser incentivado e fazer parte dos critérios de avaliação do funcionário.
" Nada adianta fazer aquele curso de C avançado, pelo salário que ganho o que sei tá bom demais."

Resumindo, todos os colegas do fórum e profissionais que conhecem, gostam de apenas de uma coisa, chicote.
Recomendações e conversas não são bem vindas, ainda mais de quem não tem poder, disso, deve-se pisar na cabeça do inferior e é isso que os colegas desejam, muito bem.

Não é primeira vez que me deparo com esse gosto das pessoas pela a dor e pelo o sofrimento, porem não esperava isso nesse ramo de pessoa inteligentes.

Mastk, quem disse que eu uso Android?

mastk escreveu:Resumindo, todos os colegas do fórum e profissionais que conhecem, gostam de apenas de uma coisa, chicote.
Recomendações e conversas não são bem vindas, ainda mais de quem não tem poder, disso, deve-se pisar na cabeça do inferior e é isso que os colegas desejam, muito bem.

Não é primeira vez que me deparo com esse gosto das pessoas pela a dor e pelo o sofrimento, porem não esperava isso nesse ramo de pessoa inteligentes.

Ainda existem profissionais que não são tão resistentes à mudanças de metodologia, padrão ou tecnologia.

Provavelmente são profissionais que não tem dificuldade com mudança de padrões e não hesitam em ficar trocando de linguagem de programação, processador ou de emprego.