La différence entre un bon et un mauvais programmeur...
105 réponses
korchkidu
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;)
Non, le bon programmeur passe par les phases réflexion, documentation et tests.
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++.
Je ne suis pas sur que les critères qui font un bon programmeur changent suivant le language (hormis la connaissance du langage et de ces principaux concepts).
Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre...
Utiliser un mot pour un autre fait perdre des points. Affirmer des contre-vérités d'un air décidé aussi.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <41f901ba$1@epflnews.epfl.ch>, korchkidu wrote:
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Non, le bon programmeur passe par les phases réflexion,
documentation et tests.
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++.
Je ne suis pas sur que les critères qui font un bon programmeur
changent suivant le language (hormis la connaissance du langage
et de ces principaux concepts).
Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Utiliser un mot pour un autre fait perdre des points.
Affirmer des contre-vérités d'un air décidé aussi.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;)
Non, le bon programmeur passe par les phases réflexion, documentation et tests.
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++.
Je ne suis pas sur que les critères qui font un bon programmeur changent suivant le language (hormis la connaissance du langage et de ces principaux concepts).
Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre...
Utiliser un mot pour un autre fait perdre des points. Affirmer des contre-vérités d'un air décidé aussi.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
flure
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne degenere...;)
Le bon programmeur : - écrit du code en respectant la norme et les conventions de codage de son équipe, - commente correctement son code - utilise un outil pour générer la documentattion à partir des commentaires (cf. Doxygen ou Natural Docs) - gère les erreurs correctement, - fait tout particulièrement attention aux problèmes d'allocation mémoire - écrit un code réutilisable au maximum et ne réinvente pas la roue - n'optimise pas de manière prématurée - optimise l'algorithme en premier - utilise des const ou des enum pour les constantes numériques - sait s'autoformer sur de nouveaux outils et technologies - sait trouver de la documentation tout seul - sait écrire une documentation pour le client - travaille réellement 8h/jour plutôt que 1h code/2h internet ... - ...
-- Florent "flure" C. http://flure.free.fr
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Le bon programmeur :
- écrit du code en respectant la norme et les conventions de codage de
son équipe,
- commente correctement son code
- utilise un outil pour générer la documentattion à partir des
commentaires (cf. Doxygen ou Natural Docs)
- gère les erreurs correctement,
- fait tout particulièrement attention aux problèmes d'allocation mémoire
- écrit un code réutilisable au maximum et ne réinvente pas la roue
- n'optimise pas de manière prématurée
- optimise l'algorithme en premier
- utilise des const ou des enum pour les constantes numériques
- sait s'autoformer sur de nouveaux outils et technologies
- sait trouver de la documentation tout seul
- sait écrire une documentation pour le client
- travaille réellement 8h/jour plutôt que 1h code/2h internet ...
- ...
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne degenere...;)
Le bon programmeur : - écrit du code en respectant la norme et les conventions de codage de son équipe, - commente correctement son code - utilise un outil pour générer la documentattion à partir des commentaires (cf. Doxygen ou Natural Docs) - gère les erreurs correctement, - fait tout particulièrement attention aux problèmes d'allocation mémoire - écrit un code réutilisable au maximum et ne réinvente pas la roue - n'optimise pas de manière prématurée - optimise l'algorithme en premier - utilise des const ou des enum pour les constantes numériques - sait s'autoformer sur de nouveaux outils et technologies - sait trouver de la documentation tout seul - sait écrire une documentation pour le client - travaille réellement 8h/jour plutôt que 1h code/2h internet ... - ...
-- Florent "flure" C. http://flure.free.fr
Fabien LE LEZ
As-tu lu le thread "Controle de la qualité d'un code : y'a-t-il de bons softs ?" ?
-- ;-)
As-tu lu le thread "Controle de la qualité d'un code : y'a-t-il de
bons softs ?" ?
As-tu lu le thread "Controle de la qualité d'un code : y'a-t-il de bons softs ?" ? Oui.
K.
Fabien LE LEZ
On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu :
Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier coup (sauf fautes de frappe), et ça ne plante pas.
-- ;-)
On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu <korch_ki_du@yahoo.fr>:
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il
réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier
coup (sauf fautes de frappe), et ça ne plante pas.
Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier coup (sauf fautes de frappe), et ça ne plante pas.
-- ;-)
Olivier Azeau
flure wrote:
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Le bon programmeur : - écrit du code en respectant la norme et les conventions de codage de
son équipe, Oui
- commente correctement son code Tout dépend du 'correctement' : il en faut ni trop, ni trop peu
Il est d'ailleurs préférable de faire comprendre une intention directement dans le code que d'utiliser des commentaires pour expliciter un code un peu trop illisible
- utilise un outil pour générer la documentattion à partir des commentaires (cf. Doxygen ou Natural Docs) Tout dépend des besoins
- gère les erreurs correctement, et, surtout, documente les cas d'erreur, idéalement avec des scenarios
de test correspondant a ces cas
- fait tout particulièrement attention aux problèmes d'allocation mémoire
Oh oui...
- écrit un code réutilisable au maximum et ne réinvente pas la roue
Ne jamais tomber dans un exces : il faut écrire le code qui répond au besoin, pas le code qui répond au besoin de réutilisabilité que l'on aura peut un jour dans 2 ans...
- n'optimise pas de manière prématurée Oui
- optimise l'algorithme en premier Pourquoi ?
- utilise des const ou des enum pour les constantes numériques Un enum ? C'est quoi ?
- sait s'autoformer sur de nouveaux outils et technologies I'm a poor lonesome cowboy...
- sait trouver de la documentation tout seul I'm a long long way from home...
Non sans dec' c'est quand meme plus important de savoir dialoguer avec les membres de son équipe non ?
- sait écrire une documentation pour le client
Savoir tout simplement communiquer avec les intervenants extérieurs a son équipe, c'est deja pas mal...
- travaille réellement 8h/jour plutôt que 1h code/2h internet ... Et usenet c'est permis ?
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura (environ) 100 descriptions différentes de 'bon programmeur' Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
flure wrote:
Le mauvais programmeur, il code, il compile, il exécute et ca
plante.
Le bon programmeur, il code, il compile, il exécute, ca plante
mais
c'est un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens
qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur,
je
serais curieux de connaitre les criteres sur lesquels vous vous
bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un
entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on
ne
sait jamais ce qu peut nous arriver....) de passer ce genre
d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la
discussion ne
degenere...;)
Le bon programmeur :
- écrit du code en respectant la norme et les conventions de codage
de
son équipe,
Oui
- commente correctement son code
Tout dépend du 'correctement' : il en faut ni trop, ni trop peu
Il est d'ailleurs préférable de faire comprendre une intention
directement dans le code que d'utiliser des commentaires pour
expliciter un code un peu trop illisible
- utilise un outil pour générer la documentattion à partir des
commentaires (cf. Doxygen ou Natural Docs)
Tout dépend des besoins
- gère les erreurs correctement,
et, surtout, documente les cas d'erreur, idéalement avec des scenarios
de test correspondant a ces cas
- fait tout particulièrement attention aux problèmes d'allocation
mémoire
Oh oui...
- écrit un code réutilisable au maximum et ne réinvente pas la
roue
Ne jamais tomber dans un exces : il faut écrire le code qui répond au
besoin, pas le code qui répond au besoin de réutilisabilité que l'on
aura peut un jour dans 2 ans...
- n'optimise pas de manière prématurée
Oui
- optimise l'algorithme en premier
Pourquoi ?
- utilise des const ou des enum pour les constantes numériques
Un enum ? C'est quoi ?
- sait s'autoformer sur de nouveaux outils et technologies
I'm a poor lonesome cowboy...
- sait trouver de la documentation tout seul
I'm a long long way from home...
Non sans dec' c'est quand meme plus important de savoir dialoguer avec
les membres de son équipe non ?
- sait écrire une documentation pour le client
Savoir tout simplement communiquer avec les intervenants extérieurs a
son équipe, c'est deja pas mal...
- travaille réellement 8h/jour plutôt que 1h code/2h internet ...
Et usenet c'est permis ?
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura
(environ) 100 descriptions différentes de 'bon programmeur'
Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Le bon programmeur : - écrit du code en respectant la norme et les conventions de codage de
son équipe, Oui
- commente correctement son code Tout dépend du 'correctement' : il en faut ni trop, ni trop peu
Il est d'ailleurs préférable de faire comprendre une intention directement dans le code que d'utiliser des commentaires pour expliciter un code un peu trop illisible
- utilise un outil pour générer la documentattion à partir des commentaires (cf. Doxygen ou Natural Docs) Tout dépend des besoins
- gère les erreurs correctement, et, surtout, documente les cas d'erreur, idéalement avec des scenarios
de test correspondant a ces cas
- fait tout particulièrement attention aux problèmes d'allocation mémoire
Oh oui...
- écrit un code réutilisable au maximum et ne réinvente pas la roue
Ne jamais tomber dans un exces : il faut écrire le code qui répond au besoin, pas le code qui répond au besoin de réutilisabilité que l'on aura peut un jour dans 2 ans...
- n'optimise pas de manière prématurée Oui
- optimise l'algorithme en premier Pourquoi ?
- utilise des const ou des enum pour les constantes numériques Un enum ? C'est quoi ?
- sait s'autoformer sur de nouveaux outils et technologies I'm a poor lonesome cowboy...
- sait trouver de la documentation tout seul I'm a long long way from home...
Non sans dec' c'est quand meme plus important de savoir dialoguer avec les membres de son équipe non ?
- sait écrire une documentation pour le client
Savoir tout simplement communiquer avec les intervenants extérieurs a son équipe, c'est deja pas mal...
- travaille réellement 8h/jour plutôt que 1h code/2h internet ... Et usenet c'est permis ?
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura (environ) 100 descriptions différentes de 'bon programmeur' Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
korchkidu
Fabien LE LEZ wrote:
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier coup (sauf fautes de frappe), et ça ne plante pas. Je ne suis pas sur que ca suffise... On peut facilement trouver des gens
qui code comme ca, et dont le code est illisible. Je pense que la lisibilite est aussi importante dans cette histoire. Enfin j'espere...
K.
Fabien LE LEZ wrote:
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il
réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier
coup (sauf fautes de frappe), et ça ne plante pas.
Je ne suis pas sur que ca suffise... On peut facilement trouver des gens
qui code comme ca, et dont le code est illisible. Je pense que la
lisibilite est aussi importante dans cette histoire. Enfin j'espere...
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier coup (sauf fautes de frappe), et ça ne plante pas. Je ne suis pas sur que ca suffise... On peut facilement trouver des gens
qui code comme ca, et dont le code est illisible. Je pense que la lisibilite est aussi importante dans cette histoire. Enfin j'espere...
K.
M. B.
"Olivier Azeau" a écrit dans le message de news:
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura (environ) 100 descriptions différentes de 'bon programmeur' Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
Meditons sur ces bonnes paroles.
MB
"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de
news:1106847082.082754.62300@c13g2000cwb.googlegroups.com...
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura
(environ) 100 descriptions différentes de 'bon programmeur'
Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
Tout ca pour dire que si on prend 100 'programmeurs' au hasard, on aura (environ) 100 descriptions différentes de 'bon programmeur' Ca s'appelle la diversité culturelle et ce n'est pas si mal que ca...
Meditons sur ces bonnes paroles.
MB
Olivier Azeau
Fabien LE LEZ wrote:
On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu :
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il
réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier
coup (sauf fautes de frappe), et ça ne plante pas.
Tu as oublié : il sait expliquer a son patron pourquoi il réfléchit autant ;-)
Fabien LE LEZ wrote:
On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu <korch_ki_du@yahoo.fr>:
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit,
il
réfléchit, il réfléchit, il réfléchit, il code, ça compile du
premier
coup (sauf fautes de frappe), et ça ne plante pas.
Tu as oublié : il sait expliquer a son patron pourquoi il réfléchit
autant ;-)
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Le bon programmeur, il réfléchit, il réfléchit, il réfléchit, il
réfléchit, il réfléchit, il réfléchit, il code, ça compile du premier
coup (sauf fautes de frappe), et ça ne plante pas.
Tu as oublié : il sait expliquer a son patron pourquoi il réfléchit autant ;-)
Sayajin
"korchkidu" a écrit dans le message de news: 41f901ba$
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne degenere...;)
Un bon programmeur fait beaucoup de conception avant de coder, faut pas se jeter directe sur son IDE pour taper du code sans réfléchir. Au final on doit "coder bêtement" !
"korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message de news:
41f901ba$1@epflnews.epfl.ch...
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est
un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases pour
decider de ca dans le cas du C++. Par exemple, lors d'un entretien, qu'est
ce qui peut faire gagner des points et qu'est ce qui peut en faire
perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait
jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un
avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Un bon programmeur fait beaucoup de conception avant de coder, faut pas se
jeter directe sur son IDE pour taper du code sans réfléchir. Au final on
doit "coder bêtement" !
"korchkidu" a écrit dans le message de news: 41f901ba$
Le mauvais programmeur, il code, il compile, il exécute et ca plante. Le bon programmeur, il code, il compile, il exécute, ca plante mais c'est un bon programmeur...;) Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui doivent decider si quelqu'un est un bon ou un mauvais programmeur, je serais curieux de connaitre les criteres sur lesquels vous vous bases pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien, qu'est ce qui peut faire gagner des points et qu'est ce qui peut en faire perdre... Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires, K. PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne degenere...;)
Un bon programmeur fait beaucoup de conception avant de coder, faut pas se jeter directe sur son IDE pour taper du code sans réfléchir. Au final on doit "coder bêtement" !
