[Voilà un article fort intéressant trouvé sur codeclimber, que je m’empresse évidemment de traduite et d’adapter… cela me rappelle tellement de situations déjà vécues…]
Note de moi: C’est une traduction quasi littérale, je laisserais mes commentaires en fin d’article…

Il y a environ une semaine j’ai été contacté par une connaissance qui avait une proposition pour moi.
“Hey, j’ai entendu dire que tu étais développeur! C’est super, parceque moi et mon pote on a une super idée de business. Tout ce qui est important est déjà prêt, et tout ce qu’on a besoin c’est d’un développeur pour concrétiser tout ça.”

En surface rien de vraiment iraisonnable à cela, ces gars savent ce qu’ils veulent pour leur application, ils ont “juste” besoin d’une personne avec les connaissances nécessaires pour l’implémenter. Pour éviter toute fâcherie, et toute parole dépassant ma pensée, j’ai tenté une réponse raisonnable.

“Et bien je suis déjà occupé sur d’autres projets en ce moment, mais je suis toujours disponible pour jeter un oeil à de nouvelles choses et voir si ça pourrait éventuellement marcher. Si vous voulez le faire dans un rapport purement purement cash contre travail, je devrais problablement prendre environ X$ de l’heure. Si d’un autre côté vous n’avez pas encore d’argent à dépenser, nous pouvons nous arranger contre une part du futur capital, une part de X% de la future compagnie devrait pouvoir faire l’affaire (ceci évidemment à condition que j’estime que le business semble viable)”.

Bien que je n’attendais pas de lui une réponse positive immédiate, je m’attendais plus à une contre offre ou une indication qu’ils s’attendaient plutôt à Y qu’à X. La réponse que j’ai obtenu m’a pour le moins surpris.

“Hey, nous ne sommes pas encore prêts à payer. En fait il n’y a pas grand chose à faire, juste un site PHP avec une base MySQL, j’avais espéré que tu puisses nous le faire comme une faveur. Pas grave, merci quand même.”

J’y ai réfléchi une minute et j’ai réalisé que se cachait dans cette conversation des faits trompeurs par rapport au métier de développeur.

1. “Il n’y a pas grand chose à faire” = une application est facile à écrire
2. “Tout ce qui est important est déjà prévu” = le développement et donc l’application, c’est juste la cerise sur le gâteau.
3. “On a juste besoin d’un développeur” = Les développeurs sont comme des rouages d’une machine, des éléments interchangeables d’une ligne d’assemblage.

[l’article continu et développe sur ces différents trois points, mais vous avez compris le principe, sinon allez comme des grands lire la suite…]

J’ai personnellement assisté bien des fois à ce genre de situation, ou en tente (de façon volontaire ou non) de dénigrer le travail ô combien important de développeur. Combien de fois avez dû vous battre pour tenter d’expliquer que cette fameuse modification “mineure” remet en cause la totalité du workflow de l’application que vous avez codé à 93% ? Combien de fois vous a-t-on dit que le petit cousin de machin pouvait le faire en deux jours…
Ce qui est important aussi dans les différents points soulevés est la pseudo-interchangeabilité des développeurs. Chaque développeur à sa logique, qui correspondra plus ou moins au fonctionnel, sa façon de coder, ses qualités, ses défauts… changez de dev et tout change (en bien ou en mal)
Enfin, une idée trop souvent répandue est que l’idée est la base du succès, particulièrement sur le web et par expérience je peux dire que c’est complètement faux. Certes il faut une idée (pas spécialement originale d’ailleurs), mais c’est l’exécution de cette idée (et son marketing, etc…) proprement et dans des délais raisonnables qui fera de votre géniale application un succès ou un flop.

Et vous, vous en pensez quoi?

Hier, j’étais à la très sympathique réunion Blogueurs, Codeurs & Geeks #2
Une petite dizaine de personnes (dont Dame Tartine évidemment toujours prêt… mais que je le connaissais déjà donc ça compte pas).
On a parlé framework javascript avec Clément (JQuery, Mootools, Scriptaculous, etc…), plateforme de blog avec Godrfroye (et je compte tester d’ici peu sa plateforme de blog qui a l’air très sympa), de Mac/Ubuntu/Windows avec Kevin et fais la connaissance d’un geek breton Yannick (et une visite éclair de Richard Ying).
On a pas mal parlé de boulot, recrutement, expérience (comme on était les deux vieux chnocs avec Dame Tartine, donc on est passé en mode vieux con qui raconte ses déboires et anecdotes rigolotes) syndicat, etc…
On a comparé nos ordis (ça fait un peu concours de zizi je sais, mais j’assume): eeePC contre MacBook Pro… rigolo

Rencontré des gens intéressants et passionnés, on reviendra c’est sûr.
A quand la prochaine?

Un petit résumé en vidéo (Haute Qualité via Vimeo):

TDW @ Blogueurs, Codeurs & Geeks #2 from babozor on Vimeo.

La même vidéo dispo en qualité un peu inférieur sur dailymotion…

[Article extrèmement intéressant, très juste, que je m’empresse de traduire et d’adapter…]

Qu’est ce qui fait vraiment un bon développeur? Certains diront une attitude positive, d’autres diront une bonne dose de sucre et de caféine, alors que d’autres parieront pour une absence de lumière et autant d’écran qu’un bureau peu supporter.
Tout le monde a des anecdotes avec des développeurs avec lesquels ils ont travaillé qu’ils trouvaient brillants. Malheureusement, la plupart du temps, ce jugement n’était pas basé sur la qualité du code produit, ou le fait de respecter les deadlines, mais sur des critères bien moins importants, comme le fait que le développeur connaissait le nom de ses collègues, le nombre de lignes de code qu’il était capable de produire ou combien ils semblaient professionnel en parlant de leur travail.
Malheureusement, les meilleurs développeurs sont une race difficile à apprivoiser. Voici donc une liste, qui n’est certes pas applicable à tous, mais qui pourrait vous aider à repérer un bon développeur.

Pessimiste
Les bons développeurs son toujours pessimiste par rapport à leur travail. Cela ne veut pas dire qu’ils sont abattus, sans vie ou même ronchons, mais juste qu’ils pensent toujours aux choses qui iront de travers et comment gérer cela.
Ils estiment qu’à un moment ou un autre ils devront casser une partie du code déjà effectué, que le hardware risque de crasher, que la sécurité risque d’être compromise, et que de façon ultime le bureau risque de partir en cendres. Les plus brillants penseront à tous ces événements arrivant en même temps. Et ils ne seront pas content avant d’avoir un plan spécifique, mis en action et testable pour contrer tous ces problèmes. Même avec ça ils ne seront toujours pas complètement tranquille.
Les développeurs pessimistes seront ceux qui trouveront toujours des défauts dans les idées, et la chose importante en travaillant avec eux à se rappeler c’est qu’ils ne le font pas pour ruiner votre merveilleuse idée, ils le font pour s’assurer que l’idée qui se transformera en projet a bien été pensée et que la plupart des problèmes possibles ont été anticipés. Cette attitude névrotique, paranoïaque et pessimiste est exactement ce que vous devez chercher chez un développeur, si vous chercher un code robuste, sûr et fiable.
Au contraire, un développeur optimiste sera enclin à penser que le code fonctionnera correctement, ou qu’il est sûr et vous donnera une deadline pour votre projet sans se soucier des problèmes qui l’attendent au tournant.

Feignant
La feignantise n’est jamais vu comme une qualité, et la plupart du temps ce n’est pas le cas. Ce qui par contre est désirable est la personne qui ne veut pas des tâches répétitives, ou gaspiller du temps à faire ce qu’une machine pourrait faire à sa place, ou encore écrire du meilleur code maintenant pour éviter d’y retoucher plus tard. Un développeur feignant est celui qui construit une librairie de code réutilisable, ou veut un processus de fabrication automatisé, plutôt qu’une série de copier/coller, ou encore des procédures de test unitaires rapides et simples, ou écrire du code surchargeable même si ce n’était pas demandé (plutôt que d’avoir à le refaire plus tard).
En bonus, en général un développeur feignant est celui qui essayera de garder le projet dans les rails et centré sur son objectif principal.
Par exemple, en designant une structure de catégorie, un développeur feignant assumera une structure 1-N (ou N-N), même si pour l’instant les besoins sont de type 1-1. Pourquoi? Parceque cela peut arriver un jour, et c’est plus simple de le faire maintenant que de le modifier après.

Curieux
Les bons développeurs s’ennuient souvent avec des tâches répétitives (cf Feignant) et passent une partie de leur temps à tenter de trouver des problématiques intéressantes à résoudre.
Les développeurs curieux seront constamment à la recherche de nouveaux problèmes à résoudre, et de meilleurs moyens pour résoudre d’anciens problèmes. Ils seront ceux qui encourageront à utiliser de nouvelles façons de travailler et transformeront constamment les systèmes existants. Ce seront aussi les plus conscients des problèmes actuels dans leur environnement de travail, et essayant de corriger ces problèmes. Les développeurs curieux ont en général une grande connaissance, pas seulement dans leur domaine ou langage, mais aussi de langages, solutions ou technologies alternatives.
La curiosité engendre souvent la créativité, un point aussi très désirable chez un développeur. Un profond désir de trouver des voix alternatives à un problème quand toutes les façons conventionnelles ont été usées est toujours utile. C’est ce genre de mentalité qui engendre “une pensée en dehors de la boîte” et du code créatif.

Méticuleux
Beaucoup de bons développeurs s’attachent aux détails. Ils demanderont de la constance dans leur travail, en particulier dans leur équipe (ils prennent en main par exemple, les standards et conventions de nommage par exemple). Ils voudront des tests unitaires et une revue de code régulière. Ils voudront que tout le monde dans l’équipe documente et annote son code. Ce seront ceux aussi qui vous embêteront avec les messages de log sous SubVersion (ou un autre logiciel de versionnning).
Ils seront aussi les plus pointilleux dans la communication, n’hésitant pas à poser des questions paraissant évidentes, juste pour être sûr de bien avoir compris la problématique. C’est d’autant plus vrai dans les rapports de bug par exemple. Même si ils ne sont pas souvent des communicants passionnés, ils sont souvent capables d’expliquer les concepts de façon clair et précise. Cette clarté est un avantage indéniable dans un environnement de production, en particulier si l’apprentissage est encouragé.

Article merveilleux qui résume toutes les qualité d’un bon développeur (en tout cas pour moi).
Par expérience, la bonne maîtrise d’une technologie ou d’un langage ne suffit pas, c’est surtout l’approche de la personne face au travail ou à certaines problématiques qui font de cette personne est très bon développeur.

Et vous vous en pensez quoi de cette définition?

Décidément Twitter (vous pouvez me suivre ici!) est une source infinie d’informations… après des liens vers des framework php ultra cool (mais qui ne rentrent pas vraiment dans ce qu’on cherche malheureusement), voici une réunion de geek qui me semble bien sympatique: Blogeur, Codeurs & Geek (deuxième édition), ça a lieu au StarBucks Bercy Village de 19 à 21h.

Aucune idée de ce que c’est vraiment, mais je vais aller jeter un oeil ce soir… ça tente quelqu’un d’autre?

Voilà un article fort intéressant de Codding Horror que je ne m’empêcher de traduire, tellement les conseils sont selon moi avisés…
[ces conseils proviennent d’un livre: Facts and Fallacies of Software Engineering (Agile Software Development)]

Les gens
1. Le facteur le plus important dans le développement est la qualité des développeurs.
2. Les meilleurs programmeurs peuvent être jusqu’à 28 fois meilleurs que les pires programeurs.
3. Ajouter des gens à un projet déjà en retard ne l’accélère pas.
4. L’environnement de travail a un impact profond sur la productivité et la qualité.

Outils et techniques
5. Les modes (pour les outils et technologies) sont un cancer pour le développeur.
6. Les nouveaux outils et techniques créent une perte initiale de productivité et de qualité.
7. Les développeurs parlent beaucoup d’outils mais les utilisent peu.

Estimation
8. L’une des deux causes pour un projet en déroute est une mauvaise estimation.
9. L’estimation arrive le plus souvent au mauvais moment.
10. L’estimation est faite la plupart du temps par les mauvaises personnes.
11. Les estimations ne sont la plupart du temps pas corrigés durant l’avancée du projet.
12. Ce n’est pas une surprise que les estimations soient mauvaise. Mais ce sont elles qui nous font vivre ou mourir demain!
13. Il y a une déconnexion entre les managers et les développeurs.
14. La réponse à une étude de faisabilité est quasiment toujours “oui”.

Ré-utilisation
(je dois dire que j’ai eut du mal à traduire ce morceau là… pas évident du tout à traduire, pour les anglophiles mieux vaut se fier à la version originale)
15. Ré-utiliser ponctuellement du code peut résoudre votre problème.
16. Ré-utiliser globalement du code ne résoudra pas vraiment votre problème.
17. La ré-utilisation globale marche mieux dans une famille ou un système similaire.
18. Les éléments ré-utiliables sont trois fois plus dur à construire et devraient être testés dans trois environnements différents.
19. La modification d’un code ré-utilisé est particulièrement source d’erreurs.
20. La ré-utilisation de Design Patternes est une solution pour résoudre le problème de ré-utilisation du code.

Besoins
23. L’une des deux causes de déroute d’un projet est des besoins instables (fonctionnalités demandées).
24. Les changement des besoins (et donc de fonctionnalité) sont les plus coûteux durant la production.
25. Les besoins manquants sont les fonctionnalités les plus dures à corriger.

Design
26. Les conditions explicites ‘explosent’ alors que les conditions implicites pour une solution évoluent.
27. Il y a toujours une solution de design triviale pour un problème logiciel.
28. Le design est un processus itératif complexe. Le design initial est le plus souvent mauvais et pas optimal.

Code
29. Les ‘fondamentaux’ des designers vont rarement de pair avec les ‘fondamentaux’ des développeurs.
30. COBOL est un langage vilain, mais tous les autres sont bien pires.

Supprimer les erreurs
31. Supprimer les erreurs est le processus le plus long du cycle de vie d’un programme.

Tester
32. Une application est souvent testée au mieux sur 55 à 60% de son tout.
33. Tester 100% de son application est tout de même loin d’être suffisant.
34. Tester les outils est essentiel, mais rarement fait.
35. Les tests automatiques sont rarement mis en place. La plupart des tests ne peuvent pas être automatisés.
36. Un mode-debug créé par un développeur, se doit d’être rajouté dans la liste des outils à tester.

Reviews et Inspections
37. Une inspection rigoureuse peut enlever jusqu’à 90% des erreurs avant même le premier test.
38. Une inspection rigoureuse ne doit pas remplacer les tests.
39. Des rapports post-livraison, postmortem et rétrospectifs sont important et peu ou jamais fait.
40. Les rapports sont techniques et sociaux, les deux facteurs se doivent d’être présents et adaptés.

Maintenance
41. La maintenance consomme entre 40 et 80% du coût de votre application. C’est sans aucun doute la phase du cycle de vie de votre application la plus importante.
42. Les améliorations représentent en gros 60% des coûts de maintenance.
43. La maintenance est une solution - pas un problème.
44. Comprendre le produit existant est la tâche de maintenance la plus difficile.
45. De meilleurs méthodes amènent plus de maintenance et non moins.

Qualité
46. La qualité est une somme d’attributs.
47. La qualité n’est pas la satisfaction de l’utilisateur, la satisfaction des besoins, rentrer dans les coûts et le planning ou la fiabilité.

Fiabilité
48. Il y a des erreurs que la plupart des développeurs font.
49. Les erreurs ont tendance à se condenser.
50. Il n’y a pas qu’une seule approche pour la résolution d’un problème.
51. Les erreurs résiduelles resteront persistentes. Le but doit être de minimiser ou éliminer les erreurs sévères ou critiques.

Efficacité
52. L’efficacité vient plus souvent d’un bon design que d’un bon code.
53. Un langage de haut niveau peut être à 90% aussi efficace qu’un code similaire en assembleur.
54. Il y a un gouffre entre optimiser le temps de réponse et optimiser l’espace occupé.

Recherche
55. La plupart des chercheurs tentent de convaincre plutôt que d’investiguer.

Après ces 55 faits, l’auteur nous présente donc 10 erreurs communes, qui ont l’apparence de la vérité…

1. Vous ne pouvez manager ce que vous ne pouvez mesurer.
2. Il est possible de suivre la qualité d’une application.
3. La programmation n’est pas une question d’ego.
4. Outils et techniques: un pour tous.
5. Les applications ont besoin de plus de méthodologies.
6. Pour estimer le coût et les délais, estimez d’abord le nombre de lignes de code.
7. Des tests au hasard est un bon moyen d’optimiser les tests.
8. “Given enough eyeballs, all bugs are shallow”. (celui là j’ai pas vraiment réussi à le traduire correctement donc je le laisse comme ça)
9. Pour prédire les futurs coûts de maintenance, il faut regarder dans les projets antérieurs.
10. Vous apprenez aux gens à programmer en leur montrant comment écrire du code.

Aucun doute il me FAUT ce livre… apparemment pas encore traduit en français, mais qui liste une bonne partie des problèmes qui existe dans notre profession.
Evidemment certains de ces faits sont difficilement praticables (surtout dans un contexte web), mais c’est cela que tout bon développeur et travailleur du web doit tendre.

Des réactions?