Discussion :

[Markand]

Les dinosaures qui :

1. Refusent de se mettre à jour en pensant tout savoir
2. Refusent d'accepter que des plus jeunes peuvent aussi avoir raison

[LapinGarou]

Les TPE (certaines PME aussi d'ailleurs) qui pensent que
- parce qu'on utilise un développement agile
- parce qu'on est que 3 ou 4 développeurs (chacun sur une spécialité: web, desktop, bigdata)
on n'a pas besoin de spécifier les choses dans un cahier des charges, et qu'ensuite, conséquence, ça ne colle pas vraiment à ce que veut le client (ça répond au besoin mais pas forcément de la façon qu'il voulait)

les demandes pour hier

+1

[psykokarl]

Les collègues développeurs. J'ai eu à gérer les egos surgonflés. Ah, les prima donna qui penses tout savoir et qui n'écoutent qu'eux ! Et en plus, incapables d'avouer qu'ils se trompent ou même de partager leurs connaissances (c'est vrai on est trop c..s pour certains).
Honnêtement, je préfère travailler avec quelqu'un d'un peu plus limité techniquement mais qui voudra s'aligner et faire des efforts plutôt qu'avec des gens qui ont un trop haute-estime d'eux-mêmes et qui ne sont connus... que d'eux-même.

Qui voudra s'aligner sur qui ?

Le "Directeur Technique Expert Docteur en Informatique" qui te dit à quoi bon utiliser un SGBD quand on peut le coder nous-même "en plus simple" pour une base de plusieurs milliers d'entrées et que les primary keys ne servent à rien. Véridique. Conséquence : il n'est plus mon patron.

Ça rejoint @GLDavid: les égos-surdimensionnés qui pensent tout savoir, experts en tout.

C'est une question pertinente, même si elle parait con.
Savoir argumenter sur le pourquoi du choix d'une techno est un bon moyen de justifier son expertise (avec un argument autre que "c'est la communauté fait le boulot" svp). Cela permet accessoirement d'éviter les effets de mode et de voir si on a à faire à un technicien capable de "penser hors du cadre" ou à un technico-commercial qui va essayer de te refourguer la "soluce" qu'on lui a vendu lors de sa formation ou dont il aura pris connaissance lors de la lecture d'un article promotionnel sur le web. Le plus important est peut être que le jeu des questions/réponses permet de mieux cerner la problématique.

Ce qui m'agace le plus en tant que développeur ?
Ne pas avoir d'égo surdimensionné dans mon équipe parce que ça signifie que l'égo surdimensionné ... c'est moi.

[Matthieu Vergne]

Ce qui m'agace du fait de ma façon d'être :
La documentation, car j'aime pas en faire... Je passe un temps fou devant la feuille blanche comme on dit et j'ai l'impression de perdre mon temps et de faire du copier/coller des commentaires mis dans le code.

La doc est censée parler avant tout de la fonction dans son ensemble (boîte noire) alors que les commentaires sont censés parler du code à l'intérieur de celle-ci (boîte blanche). Si tu as l'impression de te répéter, c'est que tu n'as pas bien séparé ce qui devait faire office de commentaire et de documentation.

[TiranusKBX]

Moi pour les problèmes d'égo j'ai droit aux petits nouveaux qui n'utilise pas les ressources communes de la boite dans leur dev et quand ça doit passer en prod bizarrement ça marche pas
si je me suis fait chier à créer un objet pour les connexions aux bdd/sgbd(mysql,oracle,sqlserveur,postgresql et sqlite) pourquoi le petit nouveau utilise une interface dépréciée(sur son pc avec un vieux PHP) du coup bizarrement sur le PC de prod(ces des sites en ligne 2 semaines max ^^) avec un PHP à jour ça marche pas (alors qu'avec mon objet il suffit de le mettre à jour en cas de changement et pas tout le dev)
j'ai aussi eu sur un gros projet dans lequel l'un qui ma mit des ressources en pagailles en plus parce-que monsieur voulait mettre du bootstrap sur une page plutôt que se baser sur excellente base du site ou il suffisait d'ajouter max 15 lignes

[foetus]

Je vais faire original : les horaires et les heures de fermeture de la société.

Actuellement je suis en convention bureau d'études/ métallurgie. Et les horaires sont fixes: 9H - 12H 30, 13H 30 - 17H 30 (<- 16H le vendredi)
Et le soir je peux rester quasi sans aucun problème jusqu'à 19 Heures (17 Heures vendredi).
Au delà tu peux te faire dégager n'importe quand parce que le dernier qui connait le code de fermeture, part.

Le problème c'est que ton projet n'avance pas
Parce que je ne suis pas du matin (j'arrive toujours après 9 Heurs) et je suis actif à partir de ... midi - 15 Heures.
Mais, une fois actif, bien tu dois t'arrêter parce que ta journée est finie et tu ne peux pas trop rester.

Je m'aperçois, qu'il faut quitter pile-poil à l'heure et travailler le soir chez soi (et j'y arrive) pendant 2 à 5 heures
Et se coucher tôt à heure fixe: minuit - 1 heure (comme un robot )

Ce qui me gonfle le plus:
- Développer pour des technologies peu fiables (Bluetooth), mal documentées ou obsolètes
- Batailler avec les paramètres de l'EDI et les pbs de dépendances au lieu de me concentrer sur le coeur de métier
- Le débogage des erreurs aléatoires

C'est actuellement mon cas : je travaille avec Embarcadero C++ Builder Xe (2010) en C++ avec la bibliothèque VCL qui est une surcouche de la win32/ winapi [qui date de Windows 95]... mais tout en vanilla parce que ma boite n'a pas payé les X milles composants/ grilles/ connection base de données/ ... même les outils de débogage sont payants (sauf codeguard qui mémorise les allocations et te dit les fuites à la fin)

Et C++ Builder Xe qui n'arrête pas de supprimer les méthodes vides (déclaration et définition), n'ouvre pas ton fichier .h parce que ce n'est pas le bon "include guard", te rajoute dans ton chemin include, les chemins de tous tes fichiers de ton projet, ...
Le seul truc de bien : il supprime les espaces en fin de ligne et remplace les espaces en début de ligne par des tabulations.

C'est une tannée pour faire une IHM : tu n'as pas de transparence (que des bitmaps) pas d'animations, des threads avec CreateThread, pas de console (les développeurs Embarcadero l'ont désactivé), ...

Et win32/ winapi: rien qu'afficher un panel/ cadre tu as des scintillement [et c'est presque vrai]. Et je ne parle pas que dans 80% des cas, il faut d'abord afficher ton composant pour le rafraichir ou, par exemple, changer la couleur (si cela est possible) ...

[Invité]

C'est sans doute parce que je ne suis qu'étudiant, mais j'ai comme l'impression au vu des choix proposés que la plupart des problèmes des dev ce résume ... à leurs collègues/patrons/responsables.
Les collègues sont soit pas assez rigoureux soit trop prétentieux, les patrons ne pigent rien, mais en demande plus et les responsables avec.
C'est triste de faire un métier ou personne, y compris nos collègues, ne comprend ce qu'on fait je devrais peut être changé de branche

Plus sérieusement je pense que mes plus gros soucis viennent de mes propres capacités, mais en même temps je suis encore en formation donc j'ai du taf avant de m'inquiéter du travail des autres

[Iradrille]

Ce qui m'agace le plus ?

Dans le code les "accordéons" sont TOUJOURS réduits. Quelqu'un s'amuse à systématiquement tous les réduire avant de commit.

(Ce genre de truc: )

[Fabiani]

C'est peut-être paradoxal ou hors-sujet, mais je ne supporte pas les grossières fautes de
français sur du code commenté... ni sur les forums d'ailleurs.

Salutations.

[FERDIKAM]

Bon voici la liste des choses qui m'exaspère le plus dans le métier et dans l'ordre du plus exaspérant au moins énervant

1. Le cahier des charges qui change tout le temps
2. Mon patron qui fait les tests la veille de la mise en prod(et le soir en plus) alors qu'il à eus une ou deux semaines pour le faire

[kilroyFR]

Les developpeurs qui ne cherchent qu'a se faire plaisir dans la techno/langage en se foutant de la finalité, maintenabilité etc
(bref des developpeurs qui ne connaissent pas le principe du KISS). C'est comme ca qu'on a coulé plusieurs projets chez nous.
Peur de dire non a un developpeur gourou d'une nouvelle techno (WPF/SL pour ne pas la citer) et se retrouver 5 ans apres avec un projet d'une complexité infame, inmaintenable (meme si soi disant codé dans les regles de l'art - quand je pense que ce meme gourou refaisait du refactoring a outrance (pour la "beauté du code") et repassait derriere tout le monde) - au final un logiciel beau esthetiquement mais techno obsolete (la moindre techno ne devient plus la mode au dela de 5 ans), fonctionnellement passé a coté (evidemment le fonctionnel ne l'interessait pas, par contre passer a C#6 pour ecrire 2 lignes de code au lieu de 3 là il y avait du monde...).
Notre hierarchie n'est pas conne non plus, elle commence juste maintenant a se rendre compte qu'on ne termine pas plus vite les logiciels, qu'ils ne sont pas plus fiables qu'avant (malgré les budgets explosés pour coder des tests unitaires), malgré les IDE ultra puissants, intellisense et autres.
Le developpeur qui code pour coder sans s'impliquer dans le metier pour moi c'est bani. D'ailleurs dans les entretiens d'embauches que je realise c'est le critere de selection desormais.
Mieux vaux quelqu'un de "moins bon" techniquement qu'un gourou qui va vouloir faire la revolution (et exploser les budgets). Apres 25 ans de boite, tous les gourous qui sont passés n'ont laissé une trace que pour des projets ayant explosé les budgets.
Heureusement qu'on est une grosse boite et qu'on arrive a encaisser ce genre de conneries, mais ca ne dure qu'un temps.

[Florian_PB]

C'est sans doute parce que je ne suis qu'étudiant, mais j'ai comme l'impression au vu des choix proposés que la plupart des problèmes des dev ce résume ... à leurs collègues/patrons/responsables.

J'ai été à ta place il y a encore quelques mois, et lors des travaux de groupe il m'arrivait déjà d'avoir ces soucis de coordinations avec mes collègues, tu verras que les problèmes présentés dans ce posts sont présents dès notre formation à ce métier. J'espère que tu auras plus de chance que moi sur ça d'ailleurs.

[herve4]

Pour moi, ne pas être invité au démarrage d'un nouveau projet
Ensuite, me dire "fais le programme comme ca et cherche pas à comprendre".
Pour enfin, voire les utilisateurs d'expliquer que ce que mon code ne marche pas parce que je n'ai pas compris le cahier des charges.
Je ne suis pas violent mais franchement dès fois ...

[bclinton]

1 - le manque de rigueur (de moi ou des autres) qui fait perdre du temps en corrections
2 - la mode des open spaces trop bruyants, consomme autant de place qu'autant de bureaux pour 2 ou 3 personnes
3 - les cahiers des charges mal rédigés (voire inexistants) et le "métier" qui ne sait pas définir ses besoins précisément
4 - les commentaires en mauvais anglais, autant les mettre en bon français si on ne maîtrise pas la langue de Britney Spears

[Cincinnatus]

4 - les commentaires en mauvais anglais, autant les mettre en bon français si on ne maîtrise pas la langue de Britney Spears

Il fut un temps où on parlait de la langue de Shakespeare. Les textes n'étaient pas du même niveau littéraire...

[bclinton]

Il fut un temps où on parlait de la langue de Shakespeare. Les textes n'étaient pas du même niveau littéraire...

C'était un sujet trolldi, j'aurai dû mettre un smiley.

[Hhissen]

quand au boulot tu sors un bout de code qui fait quelque chose de sympa et kon te demande d'expliquer chaque ligne de code oui ca passe, mais le pire est c'est quand tu es convaincus que les gars n'ont rien compris mais tu te force kan mm a leur expliquer

[sebbod]

- Refaire des choses qui ne fonctionne pas alors qu'on pouvait prédire à 90% quelle ne marcherais pas avant de les commencer (car fait par des stagiaires ou des débutants dans une techno sans encadrement d'un pair ou revus de code hebdomadaire voir journalière)
- Corriger les erreurs et bugs des autres ou les miens mais qui date de plus de 6 ou 12 mois car fonctionnalité non testé lors de la phase de test des utilisateur (parce que corriger des bugs durant la phase de dev d'un projet ça ne me dérange pas)
- l'open space : être dérangé par les conversations des autres, les sonneries de téléphones des autres.
- devoir faire des choses provisoires (qui ne vivrons pas plus d'un an) ça me donne l'impression de perdre mon temps et j'aime pas ça ;-)

[Hizin]

De mon côté, ce qui m'exaspère surtout ce sont les setups projets pourraves.
Ceux pour lesquels la documentation n'a pas été mise à jour depuis la création (quand il y en a une), quand on te donne les infos (outils, versions, frameworks...) au compte goutte parce qu'on "à trop la tête dans le guidon" et que tout est à télécharger avec une connexion 56K, qu'il faut une configuration poste par poste avec un autre développeur (et malheur si personne n'est dispo...)...
Bref, les setups projets foireux qui prennent du temps

[Invité]

J'ai été à ta place il y a encore quelques mois, et lors des travaux de groupe il m'arrivait déjà d'avoir ces soucis de coordinations avec mes collègues, tu verras que les problèmes présentés dans ce posts sont présents dès notre formation à ce métier. J'espère que tu auras plus de chance que moi sur ça d'ailleurs.

Des soucis sur des projets avec des collègues plus ou moins efficaces j'en ai déjà eu sur des projets, ceci dit j'ai envie de croire que quand je passerais pro je me plaindrais d'autre chose que de mes collègues