Uma lista de programadores que são ótimos em escrever códigos de pagamento por desempenho e que não fazem besteiras - página 12
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Desculpe, não estou fazendo um grande alarido, sou contra a listagem não fundamentada. Você queria e colocou uma pessoa na lista e acha que está tudo bem. Eu escrevi que você tem que argumentar pela inclusão, mas isto é um showdown barulhento. Não é um argumento objetivo.
Acho que um bom argumento seria o número de roteiros publicados. Acho que um bom programador ao menos compartilharia algo.
E quais são seus sucessos (da lista acima) em campeonatos mundiais de auto-comercialização?
Quero dizer, na prática, em condições reais. Eu gostaria de saber com quem você está lidando?
Estou interessado em escritores especializados e teóricos apenas para iniciantes.
Estou interessado em iniciantes que podem ser atraídos por belos quadros desenhados pelos perus.
Não, a rentabilidade dos EAs não é definitivamente um critério. Nenhuma das "mega lendas" dos fóruns em língua russa conseguiu chegar aos três primeiros lugares. Espero que ninguém se ofenda se eu inadvertidamente subestimar alguém.
Além disso, as condições estavam longe de ser reais.
Não, a rentabilidade dos EAs não é definitivamente um critério.
A rentabilidade por si só não é definitivamente um critério. Precisão e rigor do código em detalhes - este é um critério mais importante, mas infelizmente, apenas... outro programador :) A lucratividade está na idéia, a EA está no código. São coisas diferentes.
Além disso, os programadores podem ter boas razões para não enviar seus EAs em competições.
Acho que o número de roteiros publicados é um bom argumento.
A quantidade não é a qualidade. Vi alguns EAs com erros aterrorizantes... meu maxilar foi deixado cair.
Acho que o melhor critério ainda é o feedback do cliente. O cliente pode avaliar os seguintes pontos por conta própria:
1. O trabalho foi feito a tempo?
O código foi anotado e legível?
3. Todos os desejos viáveis do cliente foram levados em consideração?
4. Se algum desejo não for realizado ou não for viável, o artista foi capaz de explicar o motivo ao cliente de uma forma compreensível?
5. O artista ajudou o cliente a entender o uso do conselheiro fornecido (indicador, roteiro ...), acompanhado de palavras de despedida, conselhos?
Tudo isso é o que o cliente precisa.
"1. O trabalho é feito a tempo?" - quantos casos em que parece concordar e então o cliente é algo mais que contribui... e o prazo se move.
"2. O código é comentado e legível? "Se o cliente não entende a codificação, ele não se importa realmente com ela.
A discussão dos ToR sozinha pode ser mais longa do que a codificação. Leva tempo para entender o que ele realmente quer. Às vezes é preciso usar um alicate.
"4. Se algum pedido não for atendido ou não for implementado, o artista foi capaz de explicar ao cliente o motivo em um nível compreensível?" - e para a p.5. é claro que todos os normais. proger explica ( às vezes é necessário explicar para que o cérebro ferva)
Basta dar-lhe uma nota de 0 a 10 e não se preocupe com isso.
1. há momentos em que o prazo é adiado por acordo mútuo por causa das necessidades do cliente. Mas não é disso que estamos falando aqui, estamos falando de um distúrbio gritante.
2. Ele pode não compreender a codificação. Mas, "no aborrecimento" - eu não concordo. Em primeiro lugar, pode ser um fenômeno temporário - ele não entende agora e entenderá depois. Em segundo lugar, o código pode ser atualizado várias vezes no futuro e deve ser adequado para isso. Caso contrário, há um par de programadores em meu departamento - quando eles olham o código que escreveram há meio ano, a princípio eles exclamamam por uma semana: "Puta merda, O QUE eu escrevi aqui?!" Mas você tem que trabalhar, você não pode evitar.
4. Eu mesmo sou um programador muito experiente, eu sei. No entanto, um bom programador difere de um mau programador porque ele pode explicar no aro o que é o quê. Enquanto um mau tem apenas um argumento - "não se pode, porque não se pode". Em outras palavras, o cliente deve estar satisfeito (não irritado), mesmo que ele não tenha conseguido o que queria. Claro, não me refiro a casos de psicopatologia por parte do cliente - isso também acontece. Mas, em geral, os clientes são geralmente pessoas sãs e, se devidamente explicados, eles entenderão.
Com relação à classificação de 0 a 10 - claro. Dei apenas os critérios pelos quais o cliente pode avaliar o trabalho do programador.
Recomendo escrever um conjunto de regras de comunicação conosco para a lista de programadores.
O programador deve explicar por que é assim e não assim.
Embora, em minha prática de escrita especializada, avalie a rentabilidade ou a inutilidade da idéia do cliente apenas lendo os Termos de Referência, se a idéia não for complicada, se for complicada, então farei algumas verificações e também direi o resultado aproximado. Se o cliente pensou nas informações prontas para encomendar o desenvolvimento, começamos a discutir os detalhes dos Termos de Referência.
Muitas vezes os clientes não só não conhecem os conceitos, como também não distinguem uma encomenda de uma posição. E às vezes eles usam tal terminologia que você tem que procurar palavras em dicionários.
Nossos clientes, expressam seus pensamentos de forma clara e compreensível e utilizam o menor número possível de coloquialismos.
Um exemplo de cordas de TOR que o programador não entende.
Este é um sinal que veio, então abrimos, paramos e onde o lucro deve ser fechado eu mesmo tenho que ajustá-lo em opções. Todos entraram no mercado e esperam. Temos que esperar e esperar, e então o especialista tem que fechar o lucrativo negócio por conta própria.
Desta forma, nenhum dos programadores entenderá exatamente, por quais regras abrir um negócio, o que esperar, como fechar....
"Como se um sinal entrasse, assim nós abrimos, paramos e onde o lucro está fechando, eu mesmo tenho que instalá-lo nos ambientes. Todos entraram no mercado e esperam. Esperamos, esperamos, e então a exposição fecha o negócio lucrativo por si só.
Esta é exatamente a maneira que nenhum dos programadores vai entender, por quais regras abrir um negócio, o que esperar, como fechar....
Sobre esta questão em meu perfil o link para o livro em Ozônio (Estrutura da Magia).
4. Eu mesmo sou programador e sei disso. No entanto, um bom programador difere de um mau programador porque ele pode explicar no aro o que é o quê. Um mau programador tem apenas um argumento - "você não pode, porque não pode". Em outras palavras, 1. o cliente deve estar satisfeito (não irritado), mesmo que ele não tenha conseguido o que queria. Naturalmente, não estou me referindo a casos de psicopatologia por parte do cliente, isto também acontece. Mas, em geral, os clientes são geralmente pessoas sãs e, se devidamente explicados, eles entenderão.
Com relação à classificação de 0 a 10 - claro. Acabo de citar os critérios pelos quais o cliente pode avaliar o trabalho do programador.
Com esta abordagem da parte do cliente, devemos pensar em como garantir que o programador também fique satisfeito. Normalmente há 80% da psicanálise e apenas 20% da programação e a constante "o que não está claro aqui"("um simples peru de graça"). As instruções são cronicamente não lidas.