Discussion :

[Blackhorn]

Tout a fait daccord avec toi. Je suis en premier année d'informatique, et je suis assez deçu. Je pensais qu'il y aller avoir plus de "geek" que ca. Au premier semestre on a fait du C; 3 dans une classe de 30, le connaisait. Cela devait faire environ 2 ans que j'etais a l'aise pour l'utiliser. Donc à la place d'ecouter les cours, je fessais des programmes (pas enormement utile/qui existe deja) pour m'exercer...

Par définition, un autodidacte est quelqu'un qui s'instruit seul, sans maître. Les vrais autodidactes sont rares, et je pense que peu d'étudiants auraient les qualités requises pour faire de vrais autodidactes, même s'ils ont la faculté indéniable de se documenter sur les sujets qu'ils ne connaissent pas (mais je dirais que ça a fait partie de leur formation ).

Pour preuve que peu d'étudiants sont de vrais autodidactes: beaucoup d'étudiants arrivent en première année sans notion de ce qu'est véritablement un ordinateur, d'autres connaissent 1 ou 2 langages de programmation (des choses simples comme Basic ou Pascal) mais peu connaissent des notions beaucoup plus avancées.

[gangsoleil]

Bonjour,

Je travaille dans une équipe composée, entre autre, de prestataires (choix de la direction, pas le nôtre, mais peu importe), et je suis plus que surpris lorsque je lis ca :

...et puisqu'on parle des sociétés de service, le bon développeur doit savoir se vendre et gagner des contrats, bref le bon développeur doit être aussi commercial.

Les entretients que nous faisons passer sont techniques et un tout petit peu relation humaines, mais ce n'est absolument pas le rôle du développeur d'être commercial ou quoi que ce soit. D'ailleurs, s'il commence à partir sur ce sujet pendant un entretient, on va vite le recadrer vers la technique, qui est le seul point intéressant.

Une fois en place, le bon développeur se met à produire des programmes en quantité et répondant à deux critères: 1) contenir suffisamment de fonctionnalités pour que le client soit satisfait du travail accompli, 2) ne pas implémenter ces fcontionnalités jusqu'au bout pour laisser de la place pour les contrats de maintenance et de correction de bug

J'en choppe un qui fait ca, je t'assure qu'il va passer un mauvais quart d'heure, et son commercial aussi.
Je te rappelle par ailleurs qu'il existe des contrats avec certaines garanties : tous les bugs introduits par un employé de la SSII sont corrigeables aux frais de la dite SSII.

[pcaboche]

Les entretients que nous faisons passer sont techniques et un tout petit peu relation humaines, mais ce n'est absolument pas le rôle du développeur d'être commercial ou quoi que ce soit.

Et pourtant les entretiens chez les clients sont monnaie courante dans les SSII. Non seulement il faut convaincre le recruteur de la SSII qu'on est prêt à tout accepter pour satisfaire le client, mais en plus il faut convaincre le client qu'on est l'homme de la situation.

Pire: quelqu'un sur ce forum racontait que lors d'un entretien chez un client, le commercial de SSII faisait croire au client que le développeur en question travaillait depuis 3 ans chez eux et était un spécialiste du domaine (il aurait même écrit un livre sur le sujet) alors que le développeur n'était même pas encore embauché par la SSII.

Autre pratique (révélée lors d'un entretien chez une SSII Lyonnaise): la prime d'espionnage pour rester à l'écoute de ce qu'il se passe dans l'entreprise cliente et des opportunités de contrat pour la SSII.

Si ce n'est pas mâcher le boulot du commercial, qu'est-ce que c'est ?

J'en choppe un qui fait ca, je t'assure qu'il va passer un mauvais quart d'heure, et son commercial aussi.

Concernant ce deuxième point, c'était pour faire écho à ce que disait JohnDoeBrother car je trouve sa théorie intéressante. En effet, un programme parfait et sans bug (s'il existait) ne serait pas intéressant pour une SSII qui réalise le plus gros du chiffre d'affaires sur la maintenance et la correction de bugs.

Autre phénomène: quand on est jeune diplômé, on se dit qu'on a encore beaucoup à apprendre auprès de développeurs plus expérimentés. Or, force est de constater que certaines dérives de programmation se retrouvent dans des programmes écrits par des développeurs expérimentés. Les principales raisons de ces dérives: le manque de temps, le manque de moyens, les spécifications qui changent sans arrêts, ce qui oblige le développeur expérimenté à parer au plus urgent pour livrer dans les temps, au détriment d'une bonne conception.

Quelque part, c'est assez frustrant pour le jeune diplômé avide de connaissances. Aussi, quand un commercial de SSII fait les yeux doux à un jeune diplômé plein de potentiel en lui affirmant qu'il va acquérir énormément d'expérience en travaillant sur un projet précis, le jeune diplômé est en droit d'émettre de sérieux doutes quant à la véracité des propos du commercial. Si, parallèlement, le jeune diplômé a reçu d'autres propositions, son choix de mission se fera généralement sur d'autres critères (notamment géographiques et financier).

Si, comme affirmé plus haut, les problèmes de conception sont liés au manque de moyens (temps, argent), à priori ont devrait trouver les projets les mieux conçus chez les entreprises que s'en donnent le plus les moyens et rémunèrent le mieux les développeurs. Au pire, on produira de la merde mais on sera mieux payé...

Bien sûr, ce ne sont là que des hypothèses, mais je trouve la conclusion intéressante (et pas du tout planifiée au moment où j'ai commencé à écrire ces lignes).

[nourydean]

Salut tout le monde,

je suis situé à Montreal (QC) et je suis à la recherche d'un developpeur Web, surtout flash et java. Quelcun peut-il m'aider. merci

[pcaboche]

Salut tout le monde,

je suis situé à Montreal (QC) et je suis à la recherche d'un developpeur Web, surtout flash et java. Quelcun peut-il m'aider. merci

Pour les annonces, c'est par là que ça se passe:
http://www.developpez.net/forums/forumdisplay.php?f=47

[Mat.M]

. Imaginez par exemple un bon informaticien qui ne maîtrise que les langages, les methodes et outils qu'il a appris dans sa formation académique et qui pour, développer une appli de gestion, utilise le C, alors qu'il suffirait peut être de paramétrer tout simplement Excel pour atteindre le même resultat 20 fois plus rapidement et avec un dégré de fiabilité 20 fois supérieur!!!.

Là c'est pas l'informaticien qui est à blamer c'est le gestionnaire du projet informatique qui a mal choisi le mauvais outil informatique.
A moins qu'on ne partage pas la même notion d'informaticien..
Est-ce que tu dois participer à des sessions de recrutements , toi-même sélectionner des candidats ?

Bref la technologie évolue tellement vite en informatique que, quelqu'un peut avoir beaucoup d'année d'expérience sur des technologies dépassées.

Qui a dit que la technologie avançait ?

*Cobol et technologies pour grands systèmes sont toujours en demande largement
*Java ça date de 1995 déjà et avec .NET, Microsoft a largement repompé dessus.
*Quant à C/C++ c'est comme tout le monde le sait plus ancien..

En définitif entre la culture informatique, la formation académique et l'expérience professionelle quelle qualité privilegiée le plus?

C'est un peu comme le sketch des Inconnus et la différence entre le bon et le mauvais chasseurs ( le bon chasseur c'est celui qui tire )
Tout dépend du type de projet : si tu dois gérer un petit projet vaut mieux prendre des personnes opérationnelles immédiatement qui savent répondre rapidement et monter un projet rapidement.
Si c'est pour un gros projet pour un gros client évidemment vaut mieux des profils "académiques" quoique...

[paul92]

Avant d'avoir un bon développeur, il faut un bon chef de projet.
Qui sait communiquer, s'exprimer et se faire comprendre.

Beaucoup cherchent des développeurs télépathes ou médium qui doivent savoir ce qu’on ne leur a pas dit.

Il y a 2 test à faire: le test technique sur les technologies utilisées, qu'il ait une expérience pratique et bonne dessus.

Et le test de communication.
Travailler en équipe et recevoir des instructions. (Qu’il faut lui donner).
Soit il sait écrire et faire un bon rapport de ce qu'on lui dit et ensuite le réaliser.
Soit il sait lire et comprendre un cahier des charges.

Dernier point: le mouton à 5 pattes n'existe pas.

Moi j'ai été développeur et chef de projet.
J'en ai vu des individus très variés et souvent très sur d'eux même.
Cette assurance n'était des fois pas partagée.

Certains chefs de projet ne comprennent pas que s'ils n'ont pas 5 minutes pour bien s'exprimer et rédiger, le développeur va mettre beaucoup plus de temps pour faire le travail et des fois mal.
Prendre son temps c'est bien.
Ah j'en ai vu des projets qui avaient un mois de retard avant d'avoir commencés. Manque de temps.
Ils devaient finir quelques mois après.
Et curieusement ces projets ne sont jamais arrivés à terme.
Et oui, être trop pressé ne permet pas d'aller plus vite mais souvent d'arriver nulle part. :-)

[paul92]

Voilà un débat intéressant: autodidacte VS étudiant?

moi j'etait étudiant et autodidacte.
avec des études au Cnam.
J'ai transpiré quand j'ai fait mon 1er (vrai) programme à la fin des études.

pas le programme bidon de rapport de stage ou d'atelier de quelques centaines de lignes. Non le programme réel d'entreprise avec plusieurs milliers de lignes.

Une fois aprés une expérience de plusieurs années dans un langage, j'ai été en contact avec un étudiant en 1ere année d'informatique qui m'a dit qu'il était un expert et maitrisait ce même langage, plus mieux que moi.

Il a du en faire à tout casser 2 mois à temps plein, mais il était sur de lui.
c'était facile.
J'ai oublié de lui demander combien de milliers de ligne de code faisait son plus gros programme.
Surement 0,1 ou 0,2 :-)
Mais c'était un bon.

[paul92]

Mais la solution est simple pour embaucher un bon développeur.
Le faire recuter par un autre bon développeur.

ça se fait dans d'autres domaines techniques, pourquoi pas en informatique.

Les développeurs recrutés par des chasseurs de têtes ou des commerciaux (SSII) ? bon, ben , comment qu'ils savent qu'il est bon ?

[pcaboche]

Non le programme réel d'entreprise avec plusieurs milliers de lignes.

J'ai horreur des gens qui mesurent les programmes en nombre de lignes de code.
Le nombre de lignes de code, ça sert surtout à mesurer si un programme est une usine à gaz.

Une fois, lors d'un entretien, on m'a demandé "combien de lignes de codes faisaient le programme que vous avez écrit ?". Je crois que j'ai répondu un truc du genre: "5 fois moins que s'il avait été écrit par un autre candidat".

Le vrai défi, pour un informaticien, c'est de pouvoir faire un maximum de trucs en un minimum de lignes et de manière flexible (mais cela prend du temps, donc ce n'est pas "productif" si on ramène tout en lignes de code). Parce que si le but c'est juste de produire des lignes de code, ben il suffit d'outsourcer en Inde, ça revient moins cher...

Les développeurs recrutés par des chasseurs de têtes ou des commerciaux (SSII) ? bon, ben , comment qu'ils savent qu'il est bon ?

Surtout que j'ai déjà vu des entretiens de SSII sans aucune question technique...

[B.AF]

Il y a une quantité de poncifs et banalités énorme...

Un "bon développeur" , ça n'existe pas.

Il y a les pros et il y a les autres.

Le pro c'est déjà celui qui sait pourquoi il se pointe à un recrutement et c'est pas celui qui pleure de ne pas pouvoir gagner plus en voulant rester au chaud sans prendre de risque.

Maintenant, comme dans toutes les branches; les pros ne font pas la majorité.
C'est aussi ce qui fait leur prix.

[javamine]

Surtout que j'ai déjà vu des entretiens de SSII sans aucune question technique...

Ah les test techniques...belle connerie ça aussi.
Faut arrêter de croire qu'on recherche des geek en permanence.
J'ai déjà eu l'occasion de côtoyer des développeurs qui n'y connaissait rien, mais alors absolument rien (limite faut lui expliquer comment allumer un pc). Pourtant au bout de quelques semaines ça a été le seul à faire exactement ce qu'on lui disait sans se permettre des petites folies parce que mÔssieur s'y connait (soi disant...). Au final, le seul à produire un code maintenable et cohérent avec le reste de l'application. Pourquoi? parce qu'il connaissait son niveau et se contentait de voir comment c'était fait ailleurs pour apprendre.

En gros, un bon développeur est celui qui s'intègrera le mieux dans votre équipe, et non pas celui qui va connaître telles ou telles subtilités d'un langage.
Bien sur les compétences techniques restent importantes, mais le facteur humain l'est d'autant plus (envie d'apprendre, motivation, ambition ...). Et pour juger de ça lors d'un entretien, bon courage au recruteur .

[B.AF]

Disons plutôt en écho qu'aujourd'hui le recrutement, c'est comme les projets :
On ne cherche pas à trouver un profile adéquat, on cherche à justifier la sélection d'un profil.

Donc aujourd'hui, la plupart des entretiens et autres ne servent qu'au recruteur (en gros, si ça ne le fait pas, ça ne sera pas de sa faute, il aura suivi une méthodologie). Donc forcèmment, celui-ci ayant une profonde aversion au risque, il ne va pas chercher si la personne colle au job, mais si la somme des critères qu'il lit colle au job.

Et c'est comme ça qu'on fait rester des gens 8 ans à l'école avec 2 ou 3 diplomes pour leur dire à la fin "vous avez encore tout à apprendre".

Le problème des recruteurs, c'est rarement les candidats, c'est surtout leur égo et lur incapacité à accepter leurs limites.

[javamine]

De toute façon les recruteurs, il y en a des bons et mauvais, comme les développeurs.
Après faut voir le côté SSII, les recruteurs s'en fichent de qui ils recrutent, du moment qu'ils ont un client pour le développeur. C'est même souvent le client qui finalise la procédure d'embauche...
Alors pourquoi ils s'embêteraient avec des tests et tout et tout?
Pour un rh de SSII, un bon développeur est celui qui a une bonne tête pour être envoyer chez un client

[el_slapper]

Ah les test techniques...belle connerie ça aussi.
Faut arrêter de croire qu'on recherche des geek en permanence.
J'ai déjà eu l'occasion de côtoyer des développeurs qui n'y connaissait rien, mais alors absolument rien (limite faut lui expliquer comment allumer un pc). Pourtant au bout de quelques semaines ça a été le seul à faire exactement ce qu'on lui disait sans se permettre des petites folies parce que mÔssieur s'y connait (soi disant...). Au final, le seul à produire un code maintenable et cohérent avec le reste de l'application. Pourquoi? parce qu'il connaissait son niveau et se contentait de voir comment c'était fait ailleurs pour apprendre.

En gros, un bon développeur est celui qui s'intègrera le mieux dans votre équipe, et non pas celui qui va connaître telles ou telles subtilités d'un langage.
Bien sur les compétences techniques restent importantes, mais le facteur humain l'est d'autant plus (envie d'apprendre, motivation, ambition ...). Et pour juger de ça lors d'un entretien, bon courage au recruteur .

amen. Je me rapelle d'une diplômée en économie qui s'est faite virer de mon ancienne boite parceque les geeks la trouvaient lente. Sauf que quand je suis passé derrièrre, son code à elle fonctionnait, et qu'en plus il était lisible. alors que le code des geeks était un assemblage d'horreurs faites à la va-vite, bourrées de vices cachés.

Mais ça, c'est difficille à vendre, et un commercial qui n'y connait rien va se faire bluffer par le geek qui va lui expliquer la configuration réseau de sa dernière LAN-party.....genre de compétences qui sont importantes en architecture, mais en développement pur, non.

[pcaboche]

Faut arrêter de croire qu'on recherche des geek en permanence.
(...)
En gros, un bon développeur est celui qui s'intègrera le mieux dans votre équipe, et non pas celui qui va connaître telles ou telles subtilités d'un langage.

Mouaif...

C'est bien mignon de recruter des jolis petits moutons qui font exactement ce qu'on leur dit (en plus, c'est facile, il y en a plein !) et qui savent se vendre chez le client, mais au bout d'un moment il faut quand même penser à recruter des gens un minimum compétents pour comprendre pourquoi le programme est lent, pourquoi la base de données sature de requêtes et pourquoi le système plante lamentablement. Bien sûr, c'est une tâche ingrate parce qu'on a tout le monde à dos (utilisateurs et développeurs), mais il faut bien que quelqu'un le fasse...

[javamine]

Mouaif...

C'est bien mignon de recruter des jolis petits moutons qui font exactement ce qu'on leur dit (en plus, c'est facile, il y en a plein !) et qui savent se vendre chez le client, mais au bout d'un moment il faut quand même penser à recruter des gens un minimum compétents pour comprendre pourquoi le programme est lent, pourquoi la base de données sature de requêtes et pourquoi le système plante lamentablement. Bien sûr, c'est une tâche ingrate parce qu'on a tout le monde à dos (utilisateurs et développeurs), mais il faut bien que quelqu'un le fasse...

Tout a fait, mais un bon développeur expérimenté, il n'y en a pas des masses! Des développeurs sachant faire tout ce qu'on leur demande j'en ai croisé plein (mais attention à la crise cardiaque quand vous passez derrière...), mais des développeurs de talent, qui ne font pas de bidouilles, qui savent s'adapter à un projet et ne pas partir dans leur délire perso, je n'en ai rencontré qu'un seul... Pas terrible le ratio .
Cependant je suis d'accord avec toi, un bon senior sera toujours mieux qu'un petit jeune. Mais vu la difficulté pour en trouver, et vu la quantité de projet qui ne demande pas un savoir faire énorme, il y a du bon à travailler avec des juniors (mais pas des geek ).

[zifox]

"Un bon développeur" ça dépend de ce que tu cherches.

Pour une SSII c'est un gars qui sait vendre, qui code vite même si mal, et qui aura un bon contact avec le client.
Pour une boite dont le métier n'est pas l'informatique, c'est quelqu'un qui sera capable de gérer les outils info de la boite.

Pour un éditeur de logiciel, là encore ça dépend du contexte.
- Ca peut etre un mouton qui code exactement ce qu'on lui dit.
- Ca peut etre soit un mec capable de faire face à son chef de projet et lui faire comprendre qu'il va dans le mur.

Chacun a sa vision du bon développeur. Personnellement pour moi un bon développeur c'est quelqu'un qui pond du code organisé, compréhensible en 1 ou deux lectures, capable de s'adapter à n'importe quel langage: apprendre à programmer n'est pas apprendre un langage.
Globalement je rejoins ce qui a été dit avant, l'info évoluant assez vite, il faut quelqu'un qui s'adapte très bien.

[Didom]

"Un bon développeur" ça dépend de ce que tu cherches.

Pour une SSII c'est un gars qui sait vendre, qui code vite même si mal, et qui aura un bon contact avec le client.
Pour une boite dont le métier n'est pas l'informatique, c'est quelqu'un qui sera capable de gérer les outils info de la boite.

Pour un éditeur de logiciel, là encore ça dépend du contexte.
- Ca peut etre un mouton qui code exactement ce qu'on lui dit.
- Ca peut etre soit un mec capable de faire face à son chef de projet et lui faire comprendre qu'il va dans le mur.

Chacun a sa vision du bon développeur. Personnellement pour moi un bon développeur c'est quelqu'un qui pond du code organisé, compréhensible en 1 ou deux lectures, capable de s'adapter à n'importe quel langage: apprendre à programmer n'est pas apprendre un langage.
Globalement je rejoins ce qui a été dit avant, l'info évoluant assez vite, il faut quelqu'un qui s'adapte très bien.

+1!

Bon résumé!

[B.AF]

Non il y a une grande différence entre les SSII et les éditeurs de soft.

Les éditeurs de soft vendent
- Un produit standard
- Une connaissance approfondie du métier (sans laquelle l'application serait caduque)

Les SSII vendent du projet et du dev sans spécialisation particuliére

Il y a bien ces notions de cp, moa etc,etc, dans l'édition de soft, mais elles sont une façade purement client.