Une liste de programmeurs qui excellent dans l'écriture de codes payants et qui ne font pas de bêtises - page 12

 
prostojparen >> :

Je suis désolé, je ne fais pas d'histoires, je suis contre la liste non fondée. Vous avez voulu et mis une personne sur la liste, et vous pensez que c'est bon. J'ai écrit que vous devez argumenter pour l'inclusion, mais c'est une épreuve de force bruyante. Ce n'est pas un argument objectif.

Je pense qu'un bon argument serait le nombre de scripts publiés. Je pense qu'un bon programmeur partagerait au moins quelque chose.

 

Et quels sont vos succès (parmi la liste ci-dessus) dans les championnats du monde d'auto-trading ?

Je veux dire en pratique, dans des conditions réelles. J'aimerais savoir à qui vous avez affaire ?

Je ne m'intéresse aux experts-écrivains et aux théoriciens que pour les débutants.

Je m'intéresse aux débutants qui peuvent être attirés par les belles images dessinées par les dindons.

 

Non, la rentabilité des EA n'est absolument pas un critère. Aucune des "méga légendes" des forums russophones ne s'est jamais hissée dans le top 3. J'espère que personne ne sera offensé si j'ai sous-estimé quelqu'un par inadvertance.

De plus, les conditions étaient loin d'être réelles.

 
Mathemat писал(а) >>

Non, la rentabilité des EA n'est absolument pas un critère.

La rentabilité en soi n'est certainement pas un critère. Exactitude et rigueur du code dans les détails - il s'agit d'un critère plus important, mais malheureusement, seul... un autre programmeur :) La rentabilité est dans l'idée, l'EA est dans le code. Ce sont des choses différentes.

En outre, les programmeurs peuvent avoir de bonnes raisons de ne pas envoyer leurs AE dans les concours.

zfs a écrit >>

Je pense que le nombre de scripts publiés est un bon argument.

La quantité n'est pas la qualité. J'ai vu des EAs avec des erreurs terrifiantes... ma mâchoire est tombée.

Je pense que le meilleur critère reste le retour d'information du client. Le client peut évaluer lui-même les points suivants :

1. Les travaux ont-ils été effectués à temps ?

Le code était-il annoté et lisible ?

3. Tous les souhaits réalisables du client ont-ils été pris en compte ?

4. Si certains souhaits ne sont pas satisfaits ou ne sont pas réalisables, l'artiste interprète a-t-il pu en expliquer la raison au client de manière compréhensible ?

5. L'interprète a-t-il aidé le client à comprendre l'utilisation du conseiller fourni (indicateur, script...), en l'accompagnant de mots de conclusion, de conseils ?

Tout cela, c'est ce dont le client a besoin.

 

"1. Le travail est-il fait dans les temps ?" - combien de cas où il semble être d'accord et où le client est autre chose contribue ... et l'échéance se déplace.

" 2. Le code est-il commenté et lisible ? "Si le client ne comprend pas le codage, il ne s'y intéresse pas vraiment.

La discussion sur les TdR à elle seule peut être plus longue que le codage. Il faut du temps pour saisir ce qu'il veut vraiment. Parfois, il faut utiliser des pinces.

"4. Si une demande n'est pas satisfaite ou n'est pas mise en œuvre, l'artiste interprète a-t-il été en mesure d'en expliquer la raison au client à un niveau compréhensible ? et à la page 5, il est clair que chaque proger normal explique ( parfois il est tellement nécessaire d'expliquer que le cerveau bout)

Donne-lui une note de 0 à 10 et ne t'en fais pas.

 

1. il arrive que le délai soit reporté d'un commun accord en raison des besoins du client. Mais ce n'est pas ce dont nous parlons ici, nous parlons d'un dynaème flagrant.

2. Il peut ne pas comprendre le codage. Mais, "sur le bummer" - je ne suis pas d'accord. Tout d'abord, il peut s'agir d'un phénomène temporaire - il ne comprend pas maintenant et comprendra plus tard. Deuxièmement, le code peut être mis à jour plusieurs fois à l'avenir et il doit être adapté à cela. Sinon, il y a quelques programmeurs dans mon département - quand ils regardent le code qu'ils ont écrit il y a six mois, ils s'exclament d'abord pendant une semaine : "Putain de merde, qu'est-ce que j'ai écrit là ?" Mais vous devez travailler, vous ne pouvez pas vous en empêcher.

4. Je suis moi-même un programmeur très expérimenté, je sais. Cependant, un bon programmeur se distingue d'un mauvais programmeur en ce qu'il est capable d'expliquer sur le cerceau ce qui est quoi. Alors qu'un mauvais n'a qu'un seul argument - "vous ne pouvez pas, parce que vous ne pouvez pas". En d'autres termes, le client doit être satisfait (et non en colère), même s'il n'a pas obtenu ce qu'il voulait. Bien sûr, je ne parle pas des cas de psychopathologie de la part du client - cela arrive aussi. Mais en général, les clients sont des personnes saines d'esprit et si on leur explique bien, ils comprendront.

En ce qui concerne la note de 0 à 10 - bien sûr. J'ai seulement donné les critères selon lesquels le client peut évaluer le travail du programmeur.

 

Je recommande d'écrire un ensemble de règles pour communiquer avec nous à la liste des programmeurs.


Le programmeur doit expliquer pourquoi il en est ainsi et pourquoi il n'en est pas ainsi.

Bien que, dans ma pratique de la rédaction d'expertises, j'évalue la rentabilité ou la non-rentabilité de l'idée du client en lisant uniquement les RPT, si l'idée n'est pas compliquée, si elle est compliquée, alors je ferai quelques vérifications et dirai également le résultat approximatif. Si le client a réfléchi aux informations et est prêt à commander le développement, commencez à discuter des détails du RPT.


Souvent, non seulement les clients ne connaissent pas les concepts, mais ils ne font pas la différence entre un ordre et une position. Et parfois, ils utilisent une telle terminologie qu'il faut chercher les mots dans les dictionnaires.


Nos clients expriment leurs pensées de manière claire et compréhensible, et utilisent le moins de termes familiers possible.


Un exemple de chaînes de TOR que le programmeur ne comprend pas.


C'est un signal venu, donc on ouvre, on arrête et où le profit doit être fermé, je dois l'ajuster moi-même dans les options. Tout le monde est entré sur le marché et attend. Nous devons attendre et attendre, puis l'expert doit conclure l'affaire rentable par lui-même.


De cette façon, aucun des programmeurs ne comprendra exactement, selon quelles règles ouvrir une affaire, ce à quoi s'attendre, comment la conclure.....

 
Là-bas, ça pourrait être utile.
Dossiers :
fxd.rar  633 kb
 
HIDDEN писал(а) >>

"Par exemple, un signal est entré, alors nous ouvrons, nous arrêtons et nous déterminons où le profit se termine, je dois le configurer moi-même dans les paramètres. Tout le monde est entré sur le marché et attend. Nous attendons, nous attendons, et puis l'expo conclut d'elle-même l'affaire profitable.

C'est exactement la façon dont aucun des programmeurs ne comprendra, selon quelles règles ouvrir une affaire, ce qu'il faut attendre, comment fermer.....

Sur cette question à mon profil le lien vers le livre dans Ozone (Structure of Magic).

 
Shaitan писал(а) >>

4. Je suis moi-même un programmeur, avec un dossier solide, je sais. Cependant, un bon programmeur se distingue d'un mauvais programmeur en ce qu'il est capable d'expliquer sur le cerceau ce qui est quoi. Mais un mauvais programmeur n'a qu'un seul argument : "vous ne pouvez pas, parce que vous ne pouvez pas". En d'autres termes, 1. le client doit être satisfait (et non pas en colère), même s'il n'a pas obtenu ce qu'il voulait. Bien sûr, je ne fais pas référence aux cas de psychopathologie de la part du client, cela arrive aussi. Mais en général, les clients sont des personnes saines d'esprit et si on leur explique bien, ils comprendront.

En ce qui concerne la notation de 0 à 10 - bien sûr. Je viens de citer les critères selon lesquels le client peut évaluer le travail du programmeur.

Avec cette approche de la part du client, nous devons réfléchir à la manière de garantir que le programmeur soit lui aussi satisfait. En général, il y a 80% de psychanalyse et seulement 20% de programmation et le constant "qu'est-ce qui n'est pas clair ici"("une simple dinde gratuite"). Les instructions ne sont chroniquement pas lues.