Una lista di programmatori che sono bravissimi a scrivere codici a pagamento e non cazzeggiano - pagina 12
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Mi dispiace, non sto facendo un gran casino, sono contro la quotazione non dimostrata. Hai voluto e messo una persona sulla lista, e pensi che vada bene. Ho scritto che bisogna argomentare per l'inclusione, ma questa è una resa dei conti rumorosa. Non è un argomento oggettivo.
Penso che un buon argomento sarebbe il numero di sceneggiature pubblicate. Penso che un buon programmatore condividerebbe almeno qualcosa.
E quali sono i vostri successi (dalla lista di cui sopra) nei campionati mondiali di auto-trading?
Intendo in pratica, in condizioni reali. Vorrei sapere con chi avete a che fare?
Sono interessato a scrittori esperti e teorici solo per i principianti.
Sono interessato ai principianti che possono essere attirati dalle belle immagini disegnate dai tacchini.
No, la redditività degli EA non è assolutamente un criterio. Nessuna delle "mega leggende" sui forum in lingua russa è mai arrivata tra le prime tre. Spero che nessuno si offenda se ho inavvertitamente sottovalutato qualcuno.
Inoltre, le condizioni erano tutt'altro che reali.
No, la redditività degli EA non è assolutamente un criterio.
La redditività da sola non è sicuramente un criterio. Precisione e completezza del codice nei dettagli - questo è un criterio più importante, ma purtroppo, solo... un altro programmatore :) La redditività è nell'idea, l'EA è nel codice. Sono cose diverse.
Inoltre, i programmatori possono avere buone ragioni per non inviare i loro EA nelle competizioni.
Penso che il numero di sceneggiature pubblicate sia un buon argomento.
La quantità non è la qualità. Ho visto alcuni EA con errori terrificanti... mi è caduta la mascella.
Penso che il miglior criterio sia ancora il feedback del cliente. Il cliente può valutare da solo i seguenti punti:
1. Il lavoro è stato fatto in tempo?
Il codice era annotato e leggibile?
3. Sono stati presi in considerazione tutti i desideri fattibili del cliente?
4. Se qualche desiderio non viene soddisfatto o non è realizzabile, l'esecutore è stato in grado di spiegarne il motivo al cliente in modo comprensibile?
5. L'esecutore ha aiutato il cliente a capire l'uso del consulente fornito (indicatore, script ...), accompagnato da parole di addio, consigli?
Tutto questo è ciò di cui il cliente ha bisogno.
"1. Il lavoro è fatto in tempo?" - quanti casi in cui sembra essere d'accordo e poi il cliente è qualcos'altro contribuisce ... e la scadenza si sposta.
"2. il codice è commentato e leggibile? "Se il cliente non capisce la codifica, non gli interessa molto.
La sola discussione dei ToR può essere più lunga della codifica. Ci vuole tempo per capire cosa vuole veramente. A volte bisogna usare le pinze.
"4. Se qualche richiesta non viene soddisfatta o non viene attuata, l'esecutore è stato in grado di spiegare al cliente il motivo a un livello comprensibile?" - e a p.5. è chiaro che ogni normale. proger spiega (a volte è così necessario spiegare che il cervello bolle)
Dagli un voto da 0 a 10 e non preoccuparti.
1. ci sono volte in cui la scadenza viene posticipata di comune accordo a causa delle esigenze del cliente. Ma non è di questo che stiamo parlando qui, stiamo parlando di un palese dinaema.
2. Potrebbe non capire la codifica. Ma, "sul rompiballe" - non sono d'accordo. In primo luogo, può essere un fenomeno temporaneo - non capisce ora e capirà più tardi. In secondo luogo, il codice può essere aggiornato più volte in futuro e deve essere adatto a questo. Altrimenti ci sono un paio di programmatori nel mio dipartimento - quando guardano il codice che hanno scritto mezzo anno fa, all'inizio esclamano per una settimana: "Porca puttana, COSA ho scritto qui?!" Ma devi lavorare, non puoi farci niente.
4. Io stesso sono un programmatore molto esperto, lo so. Tuttavia, un buon programmatore si distingue da uno cattivo per il fatto che può spiegare sul cerchio cosa è cosa. Un cattivo programmatore ha solo un argomento: "non puoi, perché non puoi". In altre parole, il cliente dovrebbe essere soddisfatto (non arrabbiato), anche se non ha ottenuto quello che voleva. Naturalmente, non mi riferisco a casi di psicopatologia da parte del cliente - succede anche questo. Ma in generale, i clienti sono di solito persone sane di mente e, se spiegato correttamente, capiranno.
Per quanto riguarda il punteggio da 0 a 10 - naturalmente. Ho solo dato i criteri con cui il cliente può valutare il lavoro di un programmatore.
Consiglio di scrivere una serie di regole per comunicare con noi alla lista dei programmatori.
Il programmatore dovrebbe spiegare perché è così e non così.
Anche se, nella mia pratica di scrittura peritale, valuto la redditività o non redditività dell'idea del cliente solo leggendo TOR, se l'idea non è complicata, se è complicata, allora faccio un paio di controlli e dico anche il risultato approssimativo. Se il cliente ha pensato alle informazioni pronte per ordinare lo sviluppo, iniziamo a discutere i dettagli del TOR.
Spesso i clienti non solo non conoscono i concetti, ma non distinguono un ordine da una posizione. E a volte usano una terminologia tale che bisogna cercare le parole nei dizionari.
I nostri clienti esprimono i loro pensieri in modo chiaro e comprensibile, e usano meno colloquialismi possibili.
Un esempio di stringhe di TOR che il programmatore non capisce.
Questo è un segnale è venuto, così abbiamo aperto, stop e dove il profitto deve essere chiuso devo regolarlo io stesso in opzioni. Tutti sono entrati nel mercato e aspettano. Dobbiamo aspettare e aspettare, e poi l'esperto deve chiudere l'affare redditizio da solo.
In questo modo nessuno dei programmatori capirà esattamente, con quali regole aprire un affare, cosa aspettarsi, come chiudere....
"Come se fosse arrivato un segnale, quindi apriamo, ci fermiamo e dove si chiude il profitto lo devo impostare io stesso nelle impostazioni. Tutti sono entrati nel mercato e aspettano. Aspettiamo, aspettiamo, e poi l'expo chiude da solo l'affare redditizio.
Questo è esattamente il modo in cui nessuno dei programmatori capirà, con quali regole aprire un affare, cosa aspettare, come chiudere....
Su questa domanda al mio profilo il link al libro in Ozone (Structure of Magic).
4. Io stesso sono un programmatore, con un solido curriculum, lo so. Tuttavia, un buon programmatore si distingue da uno cattivo per il fatto che può spiegare sul cerchio cosa è cosa. Ma un cattivo programmatore ha solo un argomento - "non si può, perché non si può". In altre parole, 1. il cliente dovrebbe essere soddisfatto (non arrabbiato), anche se non ha ottenuto quello che voleva. Naturalmente, non mi riferisco a casi di psicopatologia da parte del cliente, anche questo succede. Ma in generale, i clienti sono di solito persone sane di mente e, se spiegato correttamente, capiranno.
Per quanto riguarda la valutazione da 0 a 10 - naturalmente. Ho appena citato i criteri con cui il cliente può valutare il lavoro del programmatore.
Con questo approccio da parte del cliente dobbiamo pensare a come garantire che anche il programmatore sia soddisfatto. Di solito c'è l'80% di psicoanalisi e solo il 20% di programmazione e il costante "cosa non è chiaro qui"("un semplice tacchino gratis"). Le istruzioni non vengono cronicamente lette.