Reprise du message précédent :

mais ouais, modifions directement tout sur les serveurs sans re-mettre les modifs dans le code des scripts d'instantiation des machines. De toutes façons il peut rien arriver au serveur, les alertes aléatoires c'est pas inquiétant. Le fait qu'il soit sur 2 distrib ubuntu de retard non plus.
on a qu'à faire du SCP de fichiers de 480Mo sans utiliser de compression, c'est tellement malin et plus rapide pour toucher la deadline.
 
on à qu'à foutre les scripts de backups sur les serveurs mirroir eux-même, parce que mirrorer un serveur sur lui même c'est complètement normal.
 
et ça c'est que le fonctionnel, parce que le code est à chier aussi.

Si t'es le chef, pourquoi personne respecte tes consignes ?

note que personne a dit que c'était inutile en soi.

oui voilà c'est exactement ce que je disais
 
 je dis juste: il y a un juste milieu.

là on est largement dans le rouge.

ça c'est une bonne question. Parce qu'il s'en foutent ? Parce que quand je donne une consigne, il font exactement le minimum de l'interpretation minimale pour dir qu'elle est respectée.
 
Genre l'autre jour je voulais que le nouvel employé ouvre son mac neuf lui-même, le temps que j'arrive le truc avait été ouvert par un autre mec (pour faire des install initiales d'outils). J'envoie un mail incendiaire en expliquant que je veux que les nouveaux ouvrent leur truc eux-même par ce que c'est sympa d'ouvrir un mac dernier model soi-même.  
Le mec qui avait ouvert le mac me propose de remettre le mac à zéro. Il a fait semblant de pas avoir compris le mail.
 
En fait je pense qu'il y a un truc dans ma personnalité qui dit : "on s'en fout de ce que ce mec pense ou dit". Un manque de charisme ou de je ne sais quoi.
Je songeais à faire des coupes dans cette équipe aussi, mais à force de virer du monde autour de moi, je me dit que le pb ne vient peut-être pas des autres.  
 
Peut-être que c'est normal ce que je découvre à chaque fois que je mets le nez dans un truc. Mais je m'y habitue pas. Et j'en ai marre d'envoyer des mails incendiaires à l'équipe.

Ouais enfin un mail incendiaire pour un gars qui a pas pu ouvrir son mac lui-même, bon... y a pas de quoi grimper aux rideaux non plus. Pour ce genre de truc, c'est pas plus simple d'aller voir le type et lui dire "tu sais, j'aurais préféré que Jean-Michel ouvre son mac lui-même, splus sympa" ?

 
 
Tu compute autre chose que "putain" et "enculé" ?

ça c'est quand il arrive avant moi
 
en fait je crois que je dirige un train wreck ....

T'es sérieux là ?

EDIT : C'est une et même personne qui fait ce genre de choses ? Vous avez un admin désigné ou pas ? Je veux dire, les tâches sont clairement et explicitement définies ou pas ?

le mail incendiaire apres coup aide vraiment pas. Mais j'ai pas de solution à proposer.

heu ... Ta bande, c'est un remake des pieds nickelés ? Ou tu forcis le trait ?

tu veux que je fasse quoi ? j'en ai parlé avant, ce mec devait probablement pas être là et voilà.
 
Mais c'est pareil pour moi, j'en ai un peu plein le cul et je reste chez moi à bosser de plus en plus souvent.
 
J'ai juste échoué à créer une équipe qui sait sortir un soft de qualité. J'ai fait tout ces recrutements moi-même et ils sont pas suffisants. Le seul en qui j'ai vraiment confiance c'est 0x90. Il faut cloner ce mec (on virera l'allergie à l'alcool au passage).

dites, je pose un fichier sur une machine distante, et j'aimerai qu'un programme sur la machine distante le traite, comment je programme ça ?
genre je peux faire un cron toutes les minutes mais ça me fait chier de poller là-dessus, je peux faire un SSH mais ça va bloquer la machine qui expédie le fichier (et je voudrais des logs genre cron, dans syslog). Y'a pas un genre de cron qui réagit sur les fichiers plutôt que sur le temps ?

http://manpages.ubuntu.com/manpage [...] tab.5.html

donc ouvrir vi dans le répertoire /etc/incron.d/ provoque la création de tables incron à cause des fichier .swp, intéressant

 
Les tables sont des fichiers, en fait
Chaque modif dans l'endroit où sont stockés les tables, provoque une réaction de la part de incrond

ouais, mais ils auraient peut-être pu virer les fichiers cachés.

Déjà, il faut choisir tes batailles. T'arriveras pas à leur faire faire tout ce que tu veux. L'époque des hackers fous qui adorent leur truc, c'est fini. L'info et le process sont ta passion, tant mieux, mais c'est pas le cas de tout le monde. Du coup, c'est important aussi que tu laisses passer tous les petits trucs pas important. C'est pas à toi de contrôler que le dernier qui a fait café en remette en route, ou que chacun tire la chasse d'eau dans les chiottes. Vraiment.
 
 
Perso, j'ai eu les mêmes soucis de rigueur ou de volonté dans mes 2 dernières équipes.  
 
Dans la première, les gars avaient juste aucun fierté du produit. Aucune expérience d'une équipe où ça marche bien (du coup, nos processes foireux devenaient la norme pour eux). Aucune idée de comment maintenir un produit au long cours (bah oui, quand on change de mission tous les 9 mois, on voit pas grand chose). Aucune envie de faire mieux. Et aucune idée de comment s'organiser pour faire mieux.  
 
Une des solutions dans ce genre de cas, c'est que l'équipe s'approprie elle-même la façon de mesurer le succès. Tu définis les objectifs, et toute l'équipe met au point les métriques de mesure. Au lieu de partir du bas avec des métriques toutes pourries ("combien de lignes de code écrites par jour" ), tu pars du haut: "je veux mesurer la prédictibilité d'un déploiement" -> combien de clics pour faire un déploiement. "je veux être réactif" -> Combien d'heures entre une demande de déploiement et sa visibilité finale et sûre sur le serveur". Et tu tiens des graphes de tout ça.  
 
L'autre solution, c'est d'aller puiser dans les méthodes agiles. Je suis pas fan de scrum et de tout son vocabulaire lénifiant. Mais y a vraiment du bon à prendre. En stand-up meeting, tu ne dis pas: il faut faire X. Tu demandes comment faire Y, jusqu'à ce que le consensus soit qu'il faudrait faire X. Ou pas. Si consensus il y a mais que ce n'est pas le même avis que tu avais, bah tant pis. Comme on dit: "On ne motive pas des gens, on les laisse se motiver".
 
 
D'autre part, si tu veux t'améliorer, il faut des process rigoureux. A chaque fois qu'une merde se produit, il faut trouver LES raisons, et LES actions correctives. Et ça, c'est un effort continu. Je vais prendre un exemple: quand Mars Polar Orbiter s'est planté la gueule à cause de la conversion imperial/metric, la NASA n'a pas juste cherché la ligne de code foireuse: ils ont aussi inspecté tout le processus, la communication, le management, et tout ce qui a pu impliquer ça. Contrairement à la croyance populaire, le résultat de l'investigation n'a pas été que de passer tout le code en système métrique.  
 
Dans ton cas, c'est pareil. Que se passe-t-il si un serveur crame ? Bah faites le test, pour voir. Et mettez en place les procédures qui vont bien pour corriger le tout.
 
 
Dans mon équipe actuelle, il y 8 quants et 2 techniques. Sur les 8 quants, j'en ai 3 qui n'en ont rien à foutre de comment on fait du logiciel. C'est pas des informaticiens pur-jus, et ils ne le seront jamais. Qu'à cela ne tienne, je passe 1/3 de mon temps à tout faire pour les empêcher préventivement de faire des conneries (processus de pre-commit ultra simplifié, intégration continue ultra-réactive, framework de code bête et méchant), et 1/3 du temps à tout vérifier de façon auto (valgrind, code-coverage, analyse statique de code, la totale), avec plein d'alarmes dans tous les sens. Bah tu sais quoi ? 2 ans après, j'en ai ENCORE qui viennent me voir à chaque fois que clang râle, en me disant: "je comprends pas, sur mon PC (visual studio), ça marche". Bah j'arriverai jamais à les changer. Par contre, je suis capable de détecter ce genre de conneries très vite. Et pour que tout marche au poil, on mène une politique de fenêtre cassée: si un truc passe au jaune, t'arrêtes ce que tu fais et tu corriges.
 
Est-ce que ça me ravit ? Non. J'aurais préféré bosser avec des purs informaticiens comme on en trouve plein sur hackernews ou stackexchange. On arrive pas à faire de code-reviews par exemple. Est-ce que la situation est désespérée ? Non. Les gars sont plutôt bon informaticiens pour des purs matheux, ils sont très rigoureux sur la partie math. Et avec tout notre processus, on arrive réellement à s'améliorer petit à petit. En parallèle de ça, on continue à augmenter notre couverture fonctionnelle de façon plus que satisfaisante.
 

Genre, juste après un paté.

mouais, j'ai vu tout ça, mais je sais pas.  
J'ai pas envie de les torcher, je les paye comme des ingénieurs, pas comme des techniciens.

preum's

putain, il est long ce déploiement !

Le deuxième point de mon mail est "on bosse avec des êtres humains".  C'est p-ê le point que j'aurais dû mettre en premier. Le mail incendiaire était ici malvenu, le gars a cru bien faire en faisant gagner du temps au nouveau et en cherchant à standardiser les outils. Si tu le plombes pour ça, tout ce que tu risques, c'est de plomber l'ambiance dans l'équipe et que tu perdes ta crédibilité parce que tu ne fais pas la part des choses.
Par contre, pour ce qui est de la légèreté de l'industrialisation de la mise en prod, il est évident que tu ne peux pas laisser passer, et au minimum un mail s'impose. Mais un mail d'instructions, pas un mail d'engueulade du style "vous avez encore fait de la merde". Si c'est uniquement un pb de rigueur qui est arrivé une fois, tu pourras t'appuyer dessus la prochaine fois que tu vois du travail de goret. Si la mise en prod est régulièrement foirée, c'est que manifestement, ça ne se fait pas sur un claquement de doigts, donc comme pour le reste, il faut dégager du temps et planifier le boulot d'automatisation. Pour ma part, comme Lam's je fais le gros de ce type de boulot moi-même, mais on n'a pas les mêmes sortes de contraintes.

Ca franchement, c'est pas une bonne remarque.
Tu as plus d'expérience qu'eux, c'est à toi de leur montrer ce que tu veux. A priori, si tu les as embauchés, c'est que ce ne sont pas des idiots, mais comme dit Lam's, ce ne sont pas non plus des gars qui font ça 18h/24, et c'est parfaitement normal. Donc ils n'ont pas la science infuse, et il faut leur donner les bonnes habitudes (en évitant de les infantiliser) OU mettre en place l'outillage (les deux, c'est mieux). Mais rester sur le strict nécessaire et leur lâcher la grappe sur les trucs du style "installation du mac".

Le script qui va poser le fichier appelle ton programme à distance, par exemple ?

vous nfaites pas le pont

Si mais comme toi, on se lève tôt
(J'ai un train à prendre dans 1h30)
 
Bon, et sinon, il est pas beau mon nuage ?
PS: c'est pas du Photoshop, apparemment

http://www.theverge.com/2012/9/18/ [...] line-robot

J'achète (16000 euros)

Jubijub, uriel, j'ai un collègue de la prod qui a besoin de faire de logger ses pb de prod et de faire du datamining dessus pour améliorer son process d'indus. Vous connaissez les technique/outils pour ça ?
edit: Un truc comme bugzilla + http://www.junauza.com/2010/11/fre [...] tware.html ?

boulanger qui essaye de me refiler un edge led 50 pouces a 2500€ comme étant le must du must ....

Le salaire, ça ne sert qu'à 2 trucs:
- les empêcher d'aller chez la concurrence
- les motiver à faire des trucs dont ils ont pas envie.
 
Tu penses vraiment que tes gars sont plus payés que les mecs de mon équipe qui ne savent même pas c'est quoi "une solaris" ?
 
D'autre part, tu ne souhaites pas les payer pour faire des trucs qu'ils aiment pas. Ce que tu veux, c'est qu'ils aiment ce qu'ils font. C'est pas le salaire qui va agir dessus. En fait, le salaire agit sur très peu de choses dans nos métiers. Tu peux vraiment oublier ça comme variable d'ajustement.

autant tes exemples d'avant c'était grave, autant là...

Y'a jamais un nouveau qui a fait une remarque du genre "c'est quoi cette boite, ils sont même pas foutus de préparer mon matos avant que j'arrive" ?

C'est peut être aussi parce qu'ils ne sont pas encore ingénieurs?

Ils ont combien d'ancienneté, dans quel genre d'environnement?

A te lire, j'ai l'impression que t'as 2 problèmes...premièrement, tu demandes voudrais que ton équipe soit talentueuse techniquement, passionnée par ce qu'elle fait, et rigoureuse sur le plan de la qualité et de l'industrialisation... Je sais pas, hein, mais ça ressemble pas à la majorité des mecs qui font de l'informatique.. En tout cas pas tous les critères à la fois, surtout en début de carrière.

Les 2 derniers points sont quand même rarement là quand les mecs n'ont pas l'expérience d'avoir repris un projet foireux, ou n'ont vu que des environnements de SSII en missions courtes, ou n'ont jamais parlé à un client qui hurle parce que son serveur est planté parce qu'on a uyn effet de bord à la con, etc.

De mon temps, en tout cas, ça s'apprenait pas à l'école ça. Je sais pas si ça se fait maintenant, mais ça m'étonnerait un peu. Bref. Si t'as des mecs qui manquent de bouteille, tu peux pas attendre ça d'eux sans leur apprendre. Et BTW, leur dire ce qu'il faut faire, c'est pas leur apprendre.

Deuxièmement, tu ne donnes pas l'impression de graduer les choses : les problèmes de process de prod (ton histoire de serveur mirroré, là), et l'ouverture du mac, c'est quand même pas le même degré. Si le second truc donne lieu à un mail incendiaire, on fait quoi au mec qui met la sauvegarde de la priod en péril? On l'émascule? Je veux dire.. Si tu laisses jamais RIEN passer, même une erreur qu'a fait un mec en pensant raisonnablement faire gagner du temps à la boite, d'abord t'as intérêt à être complètement irréprochable, mais surtout, tu peux pas t'attendre à ce qu'ils prennent le moindre risque en faisant preuve d'initiative. Et brider leur initiative, ça va pas du tout avec le profil de mecs que tu cherches. En plus, en faisant ça, ils peuvent réagir en faisant le minimum de ce qui permet d'être dans les clous pour pas risquer d'emmerdes.. Donc ils n'auront jamais ta confiance, donc ça tourne en rond.

Voilà voilà, my 2 cents qui valent probablement moins dans la mesure où je connais pas l'environnement et les mecs

 
Deux fois que je suis d'accord avec lam's, ça ne va pas du tout.
 
Quoi qu'il en soit, le truc le plus dur à apprendre c'est de faire le tri : ce sur quoi on peut fermer les yeux, au moins temporairement, et l'absolument nécessaire. Et surtout, expliquer pourquoi ce qui te semble nécessaire l'est : les gars sont pas aussi rigoureux que toi, mais à priori ils sont adultes, donc prendre le temps de détailler les conséquences, les implications si certains trucs sont pas mis en place, ça aide vachement.
Expliquer les enjeux de l'équipe, aussi, donner de l'importance à leur travail, ça aide à ce qu'ils ne fassent pas un truc "parce que tu le leur as demandé", mais parce que "ça va servir à ça et à ça". Ca aide à donner du sens à leur taf. C'est con, mais c'est bien plus motivant que "tu es payé pour faire ça", surtout que la vaste majorité des gens faisant ce métier ne le font pas par passion.
 
Ils sont adultes, mais en même temps, ce sont des enfants. Pour le coup du mac, si tu envoies un mail incendiaire sur un sujet pareil, ça veut dire pour eux qu'un mail incendiaire de ta part n'est sans doute pas très grave, ils relativisent : ben oui, le sujet est sommes toutes assez mineur. Tu ne gueules donc que parce que "tu es comme ça", pas parce que "c'est important".
Mais si tu n'envoies jamais de mail incendiaire, le jour ou tu en fais partir un, ça fait réfléchir les destinataires : ils sont choqués parce que ça ne te ressemble pas.
 
Perso je préfère les points de recadrage, en solo avec la personne concernée, et je lui explique ce qui pour moi ne va pas. Y a même des techniques pour ça. Et peut-être qu'il te dira que, pour lui, déballer un mac n'est pas comme recevoir un jouet à noël, que c'est chiant, qu'il faut se pallucher les cartons, le polystyrène, et l'installation des softs. Et qu'il voulait donc faire gagner du temps au nouvel arrivant pour lui épargner cette galère, et plutôt l'accueillir en lui parlant de l'équipe plutôt que de le faire installer son poste de travail. Et le pire, c'est que tu n'as pas d'argument valable contre cela : il a finalement peut-être raison.

Tiens entre 2 recadrages de NRaynaud
 
quelqu'un s'est déjà vu proposer des BSPCE (BONS DE SOUSCRIPTION DE PARTS DE CREATEUR D’ENTREPRISE) en plus de son salaire pour un nouveau job ?
 
Ce genre de 'salaire complémentaire' est-il vraiement intéressant ? Y a t-il des pièges à éviter ? Thx
 

C'est bien cette histoire, ça fait des posts intéressants par rapport à d'habitude

Logstash/graylog2/solution perso à base de hadoop et hdfs

c'est le nom des stock options en France.
il faut regarder le planning de vesting, normalement on propose pas ça aux ingénieurs qui sont là depuis longtemps, je suis étonné.

pour le datamining, on utilise Spotfire maintenant mais c'est pas gratuit.  
Knime dans la liste que tu donnes je l'utilise aussi mais pas pour ça.

 
C'est exactement très très vrai et je renvoie à cet excellent TED talk sur les ressorts de la motivation au travail : http://www.ted.com/talks/dan_pink_on_motivation.html

j'ai probablement plus lu et vu de trucs comme ça que tout le monde ici, mais ça change pas le pb.