Bonjour 'nal,
J'ai pris ma plume voilà plusieurs semaines pour poser sur papier quelques pensées sur le métier de développeur (j'en suis un) et sur la construction d'un logiciel d'une manière générale. L'idée initiale était de prendre un peu de recul sur quelques comportements qui me semblaient essentiels pour faire du bon boulot, que j'ai observés ou bien que je m'efforce de suivre, puis de partager le résultat avec mes confrères afin de connaître leur opinion et apprendre ce qui est essentiel de leur point de vue.
Très rapidement ce qui devait être un petit document d'une page s'est transformé en une dizaine de pages. Alors j'ai dû mettre un peu d'ordre dans le tout et je l'ai publié sous la forme de cinq articles sur Medium. Si je t'écris aujourd'hui, que je porte ces articles à ton attention, c'est pour recevoir les précieux retours de tes lecteurs. Car, soyons honnêtes, où se trouve l'élite technique si ce n'est sur LinuxFr ?
L'ensemble avant éclatement en plusieurs parties devait s'appeler How to be a desirable developer. Tu as deviné, tout est rédigé en anglais, alors prépare-toi avant de cliquer sur les liens des cinq parties ci-dessous:
Be a leader, not a hero Jusqu'à il y a quelques années encore je programmais comme pour montrer que j'étais cap'. J'avais envie d'être sur toutes les parties du code, c'était super stimulant au point de me retrouver à coder jusqu'à quatre heures du matin. Aussi, le fait d'écrire le code m'évitait d'avoir à discuter de la solution des autres. C'était super stupide. Aujourd'hui je suis de plus en plus intéressé par la discussion technique et les solutions trouvées en équipe. J'aime toujours coder les solutions mais j'aime aussi faire la revue du code d'un collègue. Cette première partie parle de ces comportements.
Be reliable Vous est-il déjà arrivé d'annoncer « j'arrive dans vingt minutes » pour n'arriver que trente minutes plus tard ? Vous est-il déjà arrivé d'annoncer « j'ai presque fini mon code » et d'être encore à le modifier trois jours plus tard ? Cela me met assez mal à l'aise quand ça m'arrive, et ça arrive assez facilement si on ne fait pas attention. On donne une estimation de la tâche d'un point de vue macro, puis quand on rentre dans les détails, le temps de se lever, de mettre un manteau, de fermer la porte, démarrer la voiture, faire le trajet, se garer, marcher, on a finalement prit dix minutes de plus. Pendant ce temps, les autres attendent. Cette deuxième partie traite de ce problème de sous estimation par les développeurs et de la tendance du « presque prêt ».
Be precise, be meticulous Quand j'apprenais la programmation et que je n'avais aucune idée de comment fonctionnait un ordinateur je me retrouvais à régler mes boucles et testant toutes les combinaisons de bornes : on part de 0 ou 1 ? et on s'arrête à n ou n-1 ? je testais bêtement jusqu'à avoir le résultat attendu, sans comprendre, c'était de l'approximation au plus bas niveau. C'était une époque ou j'osais nommer mes variables jeNeSaisPasCommentNommerCetteVariable… Maintenant je n'ai plus de problème avec mes boucles et j'essaie d'être clair partout : dans mes noms de variables, dans l'organisation de mes fonctions, de mes fichiers, de mon projet. J'essaie de construire l'ensemble de manière à ce que mes relecteurs n'aient jamais à se demander ce qu'ils sont en train de lire. Cette partie parle de l'importance d'être précis et soigneux dans son travail ainsi que de l'intérêt d'étendre cela à nos relations de travail.
Keep focus on the feature Vous souvenez-vous ? Il y a plus de dix ans, je venais sur LinuxFr pour vous parler du jeu Plee the Bear que je développais avec un ami. À l'époque nous pensions qu'il nous faudrait deux ans pour le terminer. Huit ans après nous avons arrêté en pensant toujours qu'il ne restait plus que deux ans de travail pour le terminer. A posteriori je me rends compte que nous avons passé toutes ces années à coder sans cesse des trucs géniaux qui devaient nous permettre d'aller plus vite ou d'autres trucs cools qui donnaient une autre dimension au jeu. Tout sauf dessiner, construire des niveaux et coder le gameplay. C'était clairement très formateur et j'y ai pris beaucoup de plaisir, mais ça n'a jamais donné ce que l'on peut appeler un jeu vidéo. Cette quatrième partie parle de l'importance de se restreindre à coder les fonctionnalités attendues afin de maîtriser la progression du projet, de savoir résister à l'envie de faire des à côtés tout de suite sous prétexte que ça à l'air génial ou que ça pourrait être utile un jour.
Write your ideas down Cette partie est le pendant de la précédente, elle aborde la question du traitement des besoins et envies qui surgissent pendant la construction du logiciel. Le fait de se restreindre à la fonctionnalité est efficace autant que frustrant. Ici il est question de la priorisation et de l'intégration dans le flux de travail de toutes ces idées géniales et outils indispensables afin de répondre aux envies des uns et des autres. Cette partie se termine sur une liste d'articles et de livres que j'ai particulièrement appréciés.
Et toi, cher lecteur, que penses-tu de ton métier ? Qu'est-ce qui qualifie un « bon » dans ton domaine ? Et dis-moi, qui sont tes modèles ?
Et pour finir, as-tu des des recommandation lecture à nous faire ? En ce moment j'hésite à me lancer dans The Pragmatic Programmer ou Programming Pearls. Qu'en penses-tu ?
# jeNeSaisPasCommentNommerCetteVariable
Posté par Anonyme . Évalué à 7.
toi tu utilise JAVA !!
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par redo_fr . Évalué à 9.
toi tu
utilisesubis JAVA !!Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Ça aurait pu ! En l'occurrence c'était du Visual Basic…
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Marotte ⛧ . Évalué à 2.
^^Pour ce qui est du choix des noms des variables, ou d’une classe… des fois on sait très bien que le nom est pourri mais pour coder (un code testable…) on est bien obligé de choisir un truc… un identifiant.
Pour ma part je suis partisan de coller le plus au backend en reprenant par exemple les titres des colonnes du résultat d’une requête dans un SGBD… Ensuite je m’efforce d’utiliser une convention de nommage selon l’object : variable globale* → FULL CAPS, fonctions → camelCase, variables locales → lowercase_only…, etc…
C’est clair que c’est pas facile de mettre toute une équipe de développeurs d’accord, en phase, avec des décisions… personnelles et arbitraires…
*Ou membre public d’une classe parente…En tous cas moi c’est comme ça que je m’y retrouve, enfin… comment j’espère m’y retrouver… dans ce que je code moi-même :)
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à 3.
Tu ne devrais donc jamais avoir de FULL CAPS dans ton code.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par _kaos_ . Évalué à 3.
Salut,
Parce que tu penses que des assesseurs mal utilisés c'est mieux ? Ou qu'un mutex ça n'existe pas ?
Même si j'évite les globales, bah dès fois c'est "incontournable" sans faire des pieds et des mains.
Le full caps de mon côté, je le réserve cependant aux constantes/membres d'une énum. La globale étant italisée et lowercase dans mon IDE.
Matricule 23415
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à 2.
Et tu fais comment avec des langages qui n'acceptent pas les variables globales ?
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par _kaos_ . Évalué à 2.
Salut,
La réponse va paraître un peu "con-con" mais si mon besoin est d'avoir une variable globale parce que j'en ai besoin, je change de langage.
Ça peut être en utilisant une API me permettant de changer de language si elle existe, par exemple. Selon la taille du projet et le but final, ça peut être tout recoder (ce qui en soit n'est qu'un constat de mauvais choix de langage initial du coup). Si le langage permet les assesseurs et les variables statiques (pas forcément globales), alors peut-être des pieds et des mains, comme je disais. En espérant m'y retrouver avec des noms « explicites » comme "instance()" (Oups ! :) ).
Cependant, dans le cas de mutex par exemple, un langage qui ne fournit pas cela, c'est plus un langage jouet pour moi (probablement très bien pour l'apprentissage, hein !) et pas quelque chose d'exploitable. J'utilise ce type de variables pour mes besoins en attaquant l'API de l'OS sous-jascent, et je considère qu'il s'agit bien d'une variable globale ; voir même plus puisque partageable par différentes instances d'un même programme.
Maintenant, des exemples de langages sans globales, ça doit se trouver. Je doute qu'ils soient utilisés sur des projets autres qu'éducatifs de manière aussi imposante que les langages majoritairement utilisés. En connais-tu ?
Matricule 23415
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Bruno Michel (site web personnel) . Évalué à 7.
C'est très réducteur : tous les langages n'ont pas les mêmes abstractions. Pour les mutex, il me semble qu'Erlang n'en a pas et ça ne l'empêche pas d'être très très bon dans la gestion de la concurrence. OTP est même ce qui considéré comme ce qu'il se fait de mieux actuellement dans ce domaine. Erlang est très utilisé dans les Télécom et part des sociétés comme Amazon, Facebook, Github et WhatsApp. Bref, c'est tout sauf un langage jouet.
Un lien intéressant à ce sujet : Why Erlang matters.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par _kaos_ . Évalué à 2.
Salut,
Merci pour les liens.
En cherchant un peu, il semble cependant qu'en faisant des "pieds et des mains", il soit possible de créer des globales en Erlang. Du coup le côté parallèle dans un unique processus se fait sans besoin de recourir à une API si on sait y faire.
Ma question revient donc la même : un langage sans API pour accéder à l'OS ou sans globales, ça s'utilise (même un peu) ?
Matricule 23415
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à 2.
Ou as-tu vu une variable globale là dedans ?
Ne détourne pas la question : on parle de variable globale. Et en erlang, il n'y en a pas.
Concrètement, il n'y a que dans quelques cas particuliers de programmation bas niveau que tu peux avoir besoin de variable globale. Par contre avec un langage objet, tu peux toujours te débrouiller pour gérer ta variable globale et ses mutexes dans une classe (dixit des développeurs Java bien plus compétent que moi dans leur domaine qui ont écrit ce genre de choses dans des bouquins,, mais je ne retrouve plus la référence).
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par lasher . Évalué à 3.
Je n'ai jamais fait d'Erlang, donc je dis sans doute une connerie. En supposant qu'on parle de langage fonctionnel pur (ce qu'est censé être Erlang si je me souviens bien), il n'y a généralement pas de « vraie » variable, et uniquement des « valeurs ». Du coup, il y a uniquement des affectations uniques, et si l'on « modifie » la valeur, alors en réalité on crée une nouvelle valeur qui est visible pour l'appelant ou bien pour la portée lexicale « inférieure ». Du coup une valeur créée « tout en haut » de l'arbre de visibilité syntaxique sera visible de tous, mais ne pourra être modifiée (puisqu'il s'agit d'une valeur et pas d'une variable).
Il n'y a donc peut-être pas de variable globale à proprement parler en Erlang, mais il y a des valeurs globales (et en demandant à un moteur de recherche comment créer des variables globales en Erlang, on tombe sur différentes réponses qui proposent de créer un process/serveur pour gérer l'état de la/des variables, ou bien de passer par un équivalent de table associative, ou bien…).
Plus généralement, j'essaie d'éviter les globales comme la peste (parce que je code des logiciels très bas niveau et lourdement parallèles, mais aussi que d'un point de vue génie logiciel, c'est pas top), mais pouvoir créer/modifier un état global à tous les threads, à certains niveaux du programme, oui, c'est utile. À noter que je compte une variable de classe comme une globale, et idem pour une variable déclarée dans un namespace en C++ par exemple. mes variables « totalement » globales sont généralement en lecture seule.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par barmic . Évalué à 5.
Alors il y a quelques amalgames :)
Quel est le problème des variables globales ? J'en vois personnellement 3 :
errnoet pour l'utiliser tu dois réinitialiser la variable, appeler la fonction, puis vérifier la valeur de cette variable (je ne sais même pas comment ça se passe avec de la programmation parallèle)il y en a probablement d'autres.
L'utilisation de process/serveur erlang permet de contrôler, l'accès de cette variable : le refactoring est largement simplifié.
L'utilisation de données static à une classe (non publique), limite fortement le scope de ta variable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à 2.
la lisibilité
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par lasher . Évalué à 3.
En général je pense que nous sommes d'accord : une variable globale non contrôlée, c'est mal. L'utilisation d'agents ou d'objets pour encapsuler la variable, ou bien limiter sa portée est évidemment une bonne pratique.
Plus spécifiquement, concernant
errno, j'ai pas de doc sous la main (et la flemme, il est près de 5h du mat ici, et au lieu d'aller pioncer je te réponds… :-P) mais il me semble que dans les systèmes POSIX modernes, il y a une transformation deerrnoen mode TLS (thread-local storage), histoire que chaque thread ait sa copie. Évidemment, c'est pas standard pour le langage C (et pas sûr que C11 ait adopté la pratique), mais ça permet quand même d'éviter tout plein de trucs chiants.L'important c'est donc de bien spécifier les modes d'accès aux variables globales : soit complètement globales « lexicalement », soit globales sous un espace de nom, de classe, etc., mais qui peuvent quand même risquer un accès concurrent. Dans un soft que je maintiens vaguement, j'ai rajouté tout un ensemble de variables globales qui servent principalement à l'initialisation au tout début du programme. Certes, ces variables se trouvent dans un espace de nom, mais bon, si tu utilises mon truc, tu vas vite arriver à faire un
using namespace tartempion;parce que sinon ça devient vite relou : ces variables sont souvent lues (et uniquement lues) par les threads générés ensuite. Bref. Oui, il faudrait que je prenne le temps d'écrire des fonctions qui vont se charger d'accéder à la variable, et au minimum garantir qu'elle sera mise à jour « atomiquement ». Mais en pratique, lemainvérifie quelle valeur donner à ces variables une fois pour toutes et tous les threads vont ensuite simplement les lire, et si par malheur un utilisateur les modifiait, ben, ça ne changerait sans doute pas grand chose (oui, ça pourrait provoquer des bugs, mais ce serait quelque chose d'assez aisé à traquer).… Et oui, je m'invente des excuses pour ne pas mieux encapsuler mes variables globales (parce que c'est du code de recherche avec grosso-modo 5 utilisateurs qui savent ce qu'ils font).
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par shbrol . Évalué à 3.
D'après http://stackoverflow.com/questions/1694164/is-errno-thread-safe c'est le comportement standard depuis POSIX.1c (cf la 1ere réponse).
Sur certains systèmes, il faut bien préciser au compilateur que le programme a besoin de la fonctionnalité, sinon on obtient un
extern int errnoclassique (cf la 2eme réponse avec -D_REENTRANT ou -D_XOPEN_SOURCE).[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à 1.
Erlang n'est pas un langage fonctionnel pur.
J'ai un peu de mal à comprendre ce que tu veux dire, mais j'ai l'impression que tu te compliques la vie : une variable en Erlang est comme une variable en C/Java, à quelques différences près :
- tu ne peux pas déclarer de variable en dehors d'une fonction
- tu ne peux affecter qu'une seule valeur à une variable.
Erlang étant un langage plutôt "déclaratif", il n'y a pas de sens à affecter plusieurs fois une valeur à une variable.
J'ai l'impression que tu cherches à tout prix à avoir raison. Tu peux tourner les choses dans le sens que tu veux, il n'y a pas de variable globale en Erlang.
Les variables globales ne sont qu'un moyen sale de gérer les états : mis à part dans certains cas de programmation bas niveau (et encore … ), ça ne devrait jamais être utilisé, sauf cas exceptionnel (les seuls cas à ma connaissance qui peuvent le nécessiter sont des cas de programmation assez bas niveau, et encore : on peut souvent s'arranger autrement).
Je n'ai jamais dit le contraire, je suis seulement d'avis qu'utiliser une variable pour ça est une mauvaise idée. La Lisibilité du code est une raison (qui pour moi est suffisante à elle seule).
compromis raisonnable à mon avis, quand on ne peut pas faire autrement.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par lasher . Évalué à 4.
En préambule, notons que je ne suis pas la personne à qui tu répondais au début. Je ne cherche pas à « avoir raison » à tout prix, mais simplement il y a tout un tas de gens qui utilisent des langages non déclaratifs, non fonctionnels, et qui ont un réel intérêt à utiliser des globales dans ce contexte.
Ben, « valeur » = variable à affectation unique. C'est peut-être un peu pédant comme terminologie, mais c'est celle qui est utilisée par une bonne partie des gens qui font des langages et de la compilation (« single assignment »). Le fait que tes variables soient aussi confinées à l'intérieur d'une fonction fait aussi que tes fonctions semblent devenir pures. Du coup, j'aimerais savoir ce qui te fait dire qu'Erlang n'est pas un langage fonctionnel pur1.
Absolument pas. Je suis intervenu dans la discussion parce que s'il n'y a pas de variable globale, je me demande comment on fait pour passer un (ensemble d')état(s) entre différents processus. Internet me dit « passage de message », ce qui implicitement indique une sérialisation des valeurs en cas de « conflit » (si 2 processus veulent modifier la même valeur qui est rendue accessible/visible par un processus Erlang).
Et comme d'habitude, tout dépend du contexte. :-) _kaos_ donnait l'exemple d'un mutex globalement accessible. Bon, perso, je créerais quand même une structure de données pour encapsuler le machin, mais c'est parce que j'aime pas les gros verrous qui deviennent potentiellement de gros points de contention dans une appli. Mais son exemple est parfaitement sûr : la sémantique-même d'une variable d'exclusion mutuelle impose de passer par des fonctions qui garantissent l'accès exclusif. Donc un mutex déclaré globalement, à défaut d'être performant, est sûr.
Note qu'évidemment, n'importe quel langage fonctionnel, même pur, doit pouvoir opérer des effets de bord, sinon on n'écrirait jamais « définitivement » en mémoire. ↩
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par barmic . Évalué à 8.
Ce qui est surtout tordu c'est de dire que tu souhaite une implémentation plutôt que résoudre un problème. C'est comme si tu nous expliquez qu'un langage sans pointeur est un langage jouet parce que de ton expérience, tu n'a jamais vu d'autres solution pour avoir des données dans le tas (ou pour autre chose).
C'est le problème qui est mal posé aucune réponse ne peut être pertinente ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Firwen (site web personnel) . Évalué à 1.
Tout va bien donc, ce n'était pas réellement un programme.
Visual Basic étant à la programmation, ce que McDonald est à la cuisine
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par totof2000 . Évalué à -4.
Je pense la même chose de python, qui est le visual basic du libre.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Firwen (site web personnel) . Évalué à 0.
Merde -1 pour un truc aussi gros. Le trollage du Vendredi sur DLFP n'est plus ce qu'il était.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par DL . Évalué à 0.
Tu as été pessimiste trop rapidement, ton souhait à largement été exaucé ensuite
ps : énorme je me suis poilé ,)
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Jiel (site web personnel) . Évalué à 2.
Pourquoi ? Qu'est-ce qui t'a fait penser que c'était du Java ?
# «l'élite technique»
Posté par rewind (Mastodon) . Évalué à 10.
Vil flatteur ! Du coup, j'ai été obligé de tout lire !
# La différence entre un bon et un mauvais programmeur...
Posté par jigso . Évalué à 4.
"Talk is cheap. Show me the code"
L. T.
# Conseil lecture
Posté par Dr BG (site web personnel) . Évalué à 10.
Ma lecture du moment (que je recommande) : Refactoring de Martin Fowler.
[^] # Re: Conseil lecture
Posté par Dr BG (site web personnel) . Évalué à 10.
D'autres titres sympa :
[^] # Re: Conseil lecture
Posté par kna . Évalué à 10.
[^] # Re: Conseil lecture
Posté par Anthony Jaguenaud . Évalué à 7.
Tu as oublié une partie du titre : « …without understanding »
# Comment rendre ces propos percutants ?
Posté par Jiehong (site web personnel) . Évalué à 8.
C'est à peut près comme tout dans la vie : ce sont nos erreurs qui nous enseignent le plus.
D'ailleurs, ce genre d'article est assez fréquent sur HN par exemple, et à la lecture de ce type d'article il y a deux types de réactions :
Dans le deuxième cas, on ne fait que lire ce que l'on sait déjà, alors que dans le premier, on se dit que c'est bien, mais les conseils, on ne les suit pas toujours. Il faut souvent faire l'erreur pour apprendre que ce conseil-ci ou ce conseil-là est vraiment à suivre. Mais la prochaine personne suivra probablement le même chemin malgré les conseils en ligne.
Quand je donnais encore des cours de mathématiques, j'ai toujours cru que le point de départ c'était d'utiliser la tendance naturelle à ne pas suivre les conseils. On est pas toujours prêt à les recevoir. L'idée étant de dire : « alors voilà, on a A, et on souhaite faire B. Comment tu ferais ? ».
Ensuite il faut pointer ce qui ne vas pas, et durant la recherche de solutions, amener les conseils qui l'on voulait donner, puisqu'ils tombent maintenant à pic.
Ça marche plutôt bien, mais tout seul, c'est plus difficile à faire.
[^] # Re: Comment rendre ces propos percutants ?
Posté par mickael . Évalué à 5.
Il y a mon avis aussi une réaction intermédiaire dans lequel c'est intéressant: j'ai un peu d’expérience, je reconnais certaines situations, et du coup l'article permet de pointer ces situations et de donner des éléments pour les faire progresser. C'est vrai que tant qu'on a pas rencontré la situation, c'est moins parlant.
En tout cas, c'est bien écrit, intéressant, et ça colle pas mal à ce que je vis au boulot. Merci.
# Vu que l'informatique c'est un monde de mec ...
Posté par Christophe B. (site web personnel) . Évalué à 1.
Blonde, 95 60 90, des talons hauts
ça doit encore le faire ?
ok je sors …
[^] # Re: Vu que l'informatique c'est un monde de mec ...
Posté par DL . Évalué à 0.
oui là, c'est pas top : tu aurais pu au moins mettre la photo qui va bien!
# Plus simple
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Prendre une douche tous les matins, se coiffer, se raser et s'habiller avec classe selon les conventions sociales en vigueur: chemise et veste pour les hommes, à peu près tout pour les femmes sauf un jogging ou un sac de patate.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# La réponse d'un vieux con
Posté par Christophe B. (site web personnel) . Évalué à 10.
Bonjour,
en 2016 cela me fera 30 ans d'expérience en informatique professionnelle, essentiellement en SSII, mais par contre j'ai pu faire de tout : poser et souder des câbles, faire des démos, coder, analyser, réparer (même des imprimantes !), vendre, auditer paramétrer etc …
pour finir en haut de la chaîne alimentaire : SysAdmin DBA (précisions : Linux Oracle)
Fin de l'introduction condescendante …
Ce que tu nous racontes dans ce journal ce n'est ni plus ni moins qu'être un professionnel.
S'impliquer dans un projet, avec en premier lieu , faire son boulot, mais aussi ne pas hésiter à aider les autres, ont est une équipe.
Etre fiable, rien de plus pénible que le mec qui te plante régulièrement, ou quand il faut vérifier constamment leur boulot. Et si tu as un problème, préviens pas au dernier moment, anticipes.
Précis et méticuleux, tout les jours on me demande d'installer le truc sur le machin pour faire des tests, j'ai finis par écrire une terminologie.
Nécessaire pour les non techniciens comme les autres.
Qui connais la différence entre Dossier de Test / Environnement de Test ?
Parfois il faut être chiant et même paranoïaque si cela touche la sécurité.
Conseil d'amis : tout écrire ne serait ce que par mail … et garder une copie
Garder le cap, ce n'est pas toujours facile et cela dépend des "partenaires" certains sont incapables de garder leur sérieux, un peu de bonne humeur n'est pas désagréable.
mais il faut savoir rester "pro".
Si tu as la chance de participer à des réunions ou le chef de projet qui dirigent la réunion coute plusieurs centaines d'euros à l'heure, tu vois très vite la différence.
Pour les projets libres et sans contraintes, c'est dur voir même très dur, tout le monde rêve d'être le prochain Linux Torvalds mais il faut reconnaître qu'il faut avoir la niaque pour y arriver.
Difficile de finir un projet sans d'autres contraintes que les siennes.
Écrire ses idées : bien très bien et cela te fais rire quand tu relis tes notes, journals intimes des années plus tard
Conseils : gardez bien ces notes, dans ma jeunesse j'avais commencé une bible avec des millions de trucs divers et variés sur des machines qui n'existent plus … disparue … dommage (pas pour la technique mais pour moi)
Conclusion :
Au delà des réseau sociaux, des forums des livres, revues et autres ils existent une dimension parallèle et inévitable encore de nos jours : le contact humain
L'expérience et le vécu que l'on peut transmettre et expliquer passe mille fois mieux que la lecture d'un livre ou d'un site.
L'écoute d'une personne, l'appréciation des ses conseils, sa manière de voir les choses (forcément différente de la votre) peuvent vous apprendre énormément, bien souvent c'est enrichissant pour tout le monde.
Je ne sais pas pour vous, mais coder n'est qu'un partie d'un ensemble. une application cela s'analyse, se code, se modifie , se débogue s'améliore.
il faut pisser du code en sachant que dans 6 mois/1 an tu devras peut être revenir dessus ou que d'autres devront le faire et jugeront ton travail.
Pour moi le code "maintenable" a plus de valeur que le code hyper pointu difficile à comprendre ce qu'il fait.
La simplicité est souvent ce qui se fait de mieux.
Quelqu'un de "bon" c'est une personne qui trouve une solution simple et compréhensible à un problème.
C'est trop facile de se cacher derrière une usine à gaz.
Conseils de lecture : Loi de Murphy
et l'application de ces axiomes (entre autre):
Axiome 1:
Il y a 2 types d'admin : ceux qui ont fait une connerie en étant root et ceux qui vont faire une connerie en étant root
Axiome 2 :
L'erreur est humaine, mais pour faire de vraie catastrophe il faut un ordinateur
Bon week end
[^] # Re: La réponse d'un vieux con
Posté par Jiel (site web personnel) . Évalué à 5.
Tout à fait d'accord avec toi, c'est simplement être professionnel !
PS : La qualité de la langue (orthographe, grammaire) aussi ça compte (parce que si le contenu de ton post est intéressant, c'est bourré de fautes).
# pas faux
Posté par passant·e . Évalué à 8.
Je suis assez d'accord avec Christophe B. On dirait qu'être professionnel c'est quelque chose d'incroyable.
Le mieux est l'ennemi du bien
j'ai bossé avec pas mal de développeurs qui n'arrivaient pas à se dire "ok pour cette release les performances sont bonnes". Le problème c'est que pour obtenir un gain de perf de 10% cela demandait un investissement en temps de plusieurs semaines. C'est toujours possible d'améliorer et d'intégrer le dernier papier sur une optimisation algorithmique qui tue mais il faut savoir lâcher du lest passer un développement en prod.
Accumulation de framework à la mode
Trop de framework tu le développement. Bon je dois être un vieux râleur mais quand chaque jours on me propose une nouvelle librairie pour permettre de résoudre un problème pour éviter de coder 10 lignes je deviens fou. D'autant plus qu'après cette librairie s'ajoute à la dette technique et qu'il faut rajouter un suivis pour être certaines qu'elle ne casse rien
Jouer les optimistes
Faire croire que tout prend 10 minutes à réaliser c'est s'assurer d'avoir des emmerdes quand une tâche similaire (au yeux du client) demandera 1 journée de boulot. Pour avoir une deadline précise il faut estimer le temps minimum de la tâche (de l'analyse à la validation finale), multiplier par le nombre d'emmerdes potentielles et rajouter 30 minutes
les paroles s'envolent, les écrits restent
C'est la version jolie de "faire gaffe à ses miches / assurer ses arrières". Il faut tenir des PV, envoyer des mails et garder une copie de tout. Car si une fois quelque chose se passe mal ce n'est pas celui qui a fait faux qui se fera plomber mais celui qui n'arrive pas prouver que ce n'est pas sa faute. Si on reçoit un ordre par téléphone il faut demander une confirmation écrite ou juste envoyer un mail disant "je vais faire selon notre conversation". Cela peut paraître pénible mais au final cela ne prend pas tant de temps et cela évite beaucoup de problème.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: pas faux
Posté par Kerro . Évalué à 10.
Un expert comptable qui fasse le job de manière convenable, ça ne court pas les rues.
Un bon garagiste, ce n'est pas la majorité de ceux qu'on trouve.
Un bon dentiste idem (sauf que là, un fois la dent tuée pour rien, il ne suffit pas d'en racheter une neuve).
Etc.
Pour les informaticiens de tous poils (développeurs/admin/etc) c'est kif-kif, il y en a beaucoup qui ne sont pas pros du tout, un paquet qui n'ont pas le niveau, et les autres sont souvent dans des structures qui font qu'au final ils travaillent dans des conditions franchement pas terribles pour sortir des résultats pas supers.
Les informaticiens font partie des quelques métiers où on est responsable de tout, sans que ce soit indiqué sur le contrat de travail ni sur la feuille de paie. Donc forcément sans la capacité à investir dans une sauvegarde correcte, ou la sécurité, ou un développement acceptable, etc. On se retrouve donc à être « coupable » lorsque l'entreprise est bloquée à cause d'un serveur en carafe, alors que c'est la direction qui décide des investissements informatiques.
Ce n'est pas pro du tout, et c'est notre lot quotidien.
[^] # Re: pas faux
Posté par mh-cbon . Évalué à -10.
où comment motivé tout les petits codeurs en herbes voulu par l'état aux joies de l'informatique en entreprise. En même temps ils s'en foutent les
crèves la dallesans-dentschômeurs defaire-ça-bientravailler avec passiond'être des professionnels responsable sous payés, ils ontfaimun ou deux crédits sur le dosbesoinde payer des impôts en augmentationde vivre, alors faut que ça marche… Je suis bien évidemment d'accord avec le commentaire précédent ! Surtout le dernier passage.[^] # Re: pas faux
Posté par passant·e . Évalué à 3.
C'est fataliste ton discours. ça prend quelques minutes pour se faire recommander un bon indépendant auprès de proches ou sur des sites web : qqn proposait un comptable sur LinuxFR dernièrement. Peut-être que des gens compétents ça ne cours pas les rues mais ça se trouve.
Ce serait un point à ajouter dans le journal "arrêter de jouer à l'homme orchestre". Une entreprise qui n'est pas capable de fixer un cahier des charges lors de l'embauche est à éviter autant que possible. Accepter toutes les tâches parce que t'es informaticien généraliste ça dépanne mais c'est aussi le meilleur moyen de ne plus pouvoir être à fond dans une tâche.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: pas faux
Posté par Bruno Michel (site web personnel) . Évalué à 10.
+1. Pour moi, une caractéristique essentielle d'un bon développeur est de savoir travailler en équipe.
Pour les freelances, c'est très compliqué, il faut souvent faire un peu de tout (de la gestion de projet au graphisme en passant par les parties commerciales/contractuelles). Mais de mon expérience, ce ne sont pas les meilleurs développeurs, ils sont très polyvalents mais moins capables quand il faut rentrer dans les détails. Bien sûr, il y a des exceptions, mais c'est globalement mon impression.
À l'inverse, les très bons développeurs vont souvent travailler dans une équipe qui leur permet de se concentrer sur ce qui est important : écrire du code qui apporte des fonctionnalités et améliore l'expérience de l'utilisateur. Ça veut dire savoir se reposer sur un chef de projet ou un product owner qui est capable de prioriser les bonnes fonctionnalités et de fournir les éléments qui vont bien. Ou ne pas essayer de faire le design graphique mais s'appuyer sur des graphistes et designers pour ça.
[^] # Re: pas faux
Posté par wilk . Évalué à 3.
C'est relatif, de mon côté (indep qui ne travaille que très rarement en équipe) j'observe plutôt l'inverse. Ma tâche c'est le développement, mais du fait de gérer aussi le système ça me permet de bosser dans un environnement aux petits oignons et donc de ne pas perdre de temps à m'adapter à un système moins adapté ou que je ne maîtrise pas. Et quitte à être coupable, autant prendre les devants !
[^] # Re: pas faux
Posté par mh-cbon . Évalué à -9. Dernière modification le 10 avril 2016 à 15:09.
oui, c'est pour cela que je n'ai volienter le journal (ok avec les deux commentaires qui me précèdent). Dans tout projet informatique qui veut concrétiser, il y a cette partie PM.
Comment être un
développeurPM désirable me semble un titre plus approprié.[^] # Re: pas faux
Posté par Kerro . Évalué à 8.
Tu confirmes donc qu'il est nécessaire de se faire recommander un bon, car sinon c'est risqué. Ce qui veut dire que les bons ne sont pas courants.
[^] # Re: pas faux
Posté par passant·e . Évalué à 0.
As tu lu le paragraphe que tu cites en entier?
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: pas faux
Posté par GuieA_7 (site web personnel) . Évalué à 8.
Oui, mais le défaut opposé, à savoir préférer tout écrire soi-même en pensant que le boulot des autres est mauvais, est aussi très répandu.
J'ai un pote qui est l'archétype du PHPiste qui n'a jamais essayé d'aller plus loin dans ses connaissances théoriques ; il affirme qu'il n'utilisera jamais de framework (parce que c'est des "gros tas de merde"), mais il ne faut pas discuter très longtemps pour s'apercevoir de ses lacunes. Dernier exemple en date: alors que les bons frameworks web protègent plus ou moins automatiquement contre les failles CSRF, il n'en avait même jamais entendu parler ; l'excuse étant "je n'ai pas le temps de m'occuper de tout" ainsi que "comment je peux être au courant de ce genre de choses ?" (et oui forcément quand tu passes ton temps à - mal - réinventer la roue…).
Ah oui, c'est un professionnel, dans le sens où il est payé pour ça :)
[^] # Re: pas faux
Posté par Julien Jorge (site web personnel) . Évalué à 10.
Ton commentaire et celui de Christophe B. me font remarquer que je ne m'étais jamais demandé ce qu'était un professionnel en fait. Je suis loin des trente années d'expérience et à vrai dire j'avais plutôt le sentiment que le terme « professionnel » était un peu galvaudé aujourd'hui. Il me semble, mais mon regard est peut-être déformé, qu'on trouve assez facilement des gens avec ce libellé qui s'avèrent finalement être surtout de beaux parleurs dont les actes ne sont pas au niveau de leurs promesses ou bien dont le comportement est douteux.
Dans ma courte expérience je n'ai pas eu le sentiment que ces comportements que nous décrivons étaient attendus ou encouragés. Je les ai observés mais j'ai toujours eu l'impression que c'était plus le résultat d'une motivation individuelle que d'un désir commun ; comme s'ils étaient implicites. Cela me semble bizarre en particulier vis-à-vis des juniors qui entrent dans le métiers et qui se retrouvent à devoir deviner par eux-même quels sont les comportements qui agissent pour le bien commun et lesquels sont parasites. Pour prendre une analogie, c'est comme si on entrait dans le métier aux côtés de Linus Torvalds, Ulrich Drepper, Jeff Atwood et Robert C. Martin et qu'on nous disait « choisis ton modèle ». Quelle proportion de débutants comprendraient qu'on peut être d'un haut niveau technique tout en ayant des rapports humains intéressants ? J'ai personnellement le sentiment que l'on a tendance à négliger les retours positifs, ne serait-ce que « nous avons fait du bon boulot » ou « je trouve que l'équipe a bien fonctionné ».
Concernant ta remarque sur les paroles et les écrits, que Christophe B. et blabla ont l'air de rejoindre, je trouve, peut-être naïvement, que cela fait un peu vieille informatique. Peut-être est-ce un problème d'échelle de boîte car dans celles où j'ai travaillé, où les équipes sont de taille humaine et le patron est à n+1 et derrière une porte (toujours ouverte) dans la pièce d'à côté, je n'ai jamais vu quelqu'un chercher un coupable pour quoi que ce soit. Quand tout va bien c'est parce que nous avons tous assuré, quand tout va mal c'est parce que nous avons tous raté. Il y a évidemment parfois des désaccords, qui sont simplement évoqués dans les rétrospectives de sprint, puis tout le monde s'arrange pour trouver un compromis et s'y tient. Bien sûr ce n'est pas sans accrocs, il y a aussi des disputes, des démissions ou des licenciements, mais globalement j'ai le sentiment que tout le monde fait simplement de son mieux pour que ça se passe bien. C'est très différent du comportement défensif que blabla et toi décrivez. À nouveau, peut-être est-ce lié à l'échelle de la boîte ?
[^] # Re: pas faux
Posté par pasBill pasGates . Évalué à 6.
Non non, c'était la même chose à MS et c'est le cas aussi à Amazon. "Vieille informatique" je sais pas, je dirais plutôt "management à la française" perso, ou la hiérarchie / l'ancienneté et qui tu connais est plus importante que le reste. A peu près tous les français que je croise içi me disent que c'est la raison principale pour laquelle ils ne rentreront pas travailler en France. Pour la retraite peut-être, mais pas pour travailler.
[^] # Re: pas faux
Posté par claudex . Évalué à 5.
Du coup, ce serait intéressant de savoir comment ça se passe chez Amazon et MS en France.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas faux
Posté par Christophe B. (site web personnel) . Évalué à 4.
C'est peut être particulier à la SSII, je ne m'en rends pas compte vu que je baigne dedans depuis (trop) longtemps.
Quand un problème arrive :
le client sans service info veut une explication pas trop technique et parfois demande comment éviter que cela se reproduise.
Après cela dépend du service info, avec certains on s'aide pour remettre le système ordre de marche
sans se poser de questions, chacun s'occupe de sa ou ses parties
D'autres nous appellent même si il s'agit d'une partie que nous ne connaissons pas ou n'avons pas mis en place, soit par habitude parce qu'on s'occupe de tout, soit parce qu'on apparaît comme des magiciens extra lucides omniscient
Les pires (grand distrib par exemple) tu passes ton temps à prouver que tu n'es pas le fautif
et même si ce n'est pas ta faute de toutes façons par défaut tu lui dois de l'argent …
De plus sur un ERP pour l'utilisateur lambda-michu qui ne connait que son Client Lourd ou son navigateur, c'est l'ERP qui merde.
Et donc on est QUASIMENT toujours les premiers prévenus, parfois même AVANT le service infos, à nous de chercher l'origine du problème
La relation client / fournisseur même si elle s'étale sur de longues années est particulière
On oublie trop souvent que l'on ne parle que des problèmes jamais du fait que le système ronronne depuis 3 ans.
C'est fort probable, comme le dit pbpg en réponse un peu plus loin, que cela soit typiquement Français.
# The Pragmatic Programmer
Posté par Bruno Michel (site web personnel) . Évalué à 5.
J'ai lu The Pragmatic Programmer il y a de ça une dizaine d'années et j'ai beaucoup appris avec. Je recommande fortement sa lecture.
# Si tu veux être le couillon de service
Posté par blabla . Évalué à -10. Dernière modification le 10 avril 2016 à 13:04.
Pendant ce temps là les opportunistes, les carriéristes, etc. profiteront bien de toi.
Comme toujours sur LinuxFR on a un bon exemple d’idéalisme naïf totalement à l’ouest, déconnecté du monde du travail.
Quelques conseils, liste non exhaustive, en vrac dans le vrai monde (pas celui des Bisounours, l’autre) :
0/ Loi universelle : c’est toujours le grouillot en bas de l’échelle qui a tord
1/ Corollaire : si tu es le grouillot de base, protège toi en signalant par écrit que tu ne valides pas tel ou tel choix (mais tu le feras quand mềme — TU ES le grouillot)
2/ Ton chef tu ne remettras pas en cause, à la limite en privé, mais jamais au grand jamais avec des témoins (c’est ça qu’ils appellent l’esprit d’équipe : il faut SIMULER une loyauté à toute épreuve)
3/ Tu surestimeras le travail demandé en le doublant (tu peux être sûr qu’on se chargera de le réduire de moitié et dans le cas exceptionnel ou il te resterait du temps libre tu en profiteras pour faire la veille techno. l’autoformation qu’on ne t’autorise pas à faire autrement)
4/ Ne crois pas que te faire bien voir auprès de ta hiérarchie ou (exclusif…) de tes collègues te permettra d’avoir une meilleure reconnaissance au travail (et ne parlons même pas de salaires, de missions intéressantes en
SSIIESN, ou d’un simple remerciement oral)5/ Corollaire : n’hésite jamais à les envoyer balader si tu trouves mieux ailleurs
6/ Évidemment jusqu’à 4h du matin tu ne coderas pas (dans ma boîte c’est entre beaucoup d’autres sur les heures sup’ que les dév. se font bien arnaquer), fort heureusement il y a une limite de ce que dans mon domaine on ne peut pas dév. à n’importe quelle heure (sessions coupées).
Certains se font même une spécialité d’avoir des p’tits jeunes bien malléables, de leur faire miroiter un avancement, pour au final les jeter après en avoir bien profiter. Pour sûr le journal est typiquement dans cette veine là.
[^] # Re: Si tu veux être le couillon de service
Posté par Dr BG (site web personnel) . Évalué à 7.
Je ne vois pas trop le rapport entre ton commentaire et le journal.
Et puisque je connais Julien, je peux te dire :
- que ce n'est pas un grouillot ;
- qu'il dit clairement et sans détour ce qui ne lui plaît pas ;
- qu'il ne bosse pas dans une SSII ;
- qu'il ne manque absolument pas de reconnaissance ;
- qu'il ne se sent pas obligé de bosser en dehors de ses heures de travail.
Bref, tu me parais carrément à côté de la plaque en plus d'être condescendant (sans raison).
[^] # Re: Si tu veux être le couillon de service
Posté par blabla . Évalué à -10.
Ton commentaire me confirme…
[^] # Re: Si tu veux être le couillon de service
Posté par Dr BG (site web personnel) . Évalué à 7.
Sois plus explicite, il confirme quoi ?
[^] # Re: Si tu veux être le couillon de service
Posté par xcomcmdr . Évalué à 10.
Sa condescendance.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Si tu veux être le couillon de service
Posté par Marotte ⛧ . Évalué à 5.
Surtout s’il se la joue trop grammar nazi avec ses supérieurs ! Cependant je pense que tu as tort.
[^] # Re: Si tu veux être le couillon de service
Posté par GuieA_7 (site web personnel) . Évalué à 7.
Un développeur désirable pourra, s'il le souhaite, choisir en grande partie l'entreprise où il travaille, avec les avantages et inconvénients que chacune comporte ; tout étant une question de priorité au final.
Ton commentaire sent la frustration à plein nez (à moins que ça soit du troll).
[^] # Re: Si tu veux être le couillon de service
Posté par blabla . Évalué à -10. Dernière modification le 10 avril 2016 à 18:33.
7/ Une entreprise écologiquement ou socialement “responsable” ça n’existe pas
8/ Corollaire : la seule différence avec les autres, c’est qu’elles fournissent la vaseline…
Et la marmotte elle met le chocolat dans le papier d’alu ?
Le fouet ou le martinet ?
LinuxFR est quand même un des rares forums que je connaisse où les trolls ont la côte : ton commentaire c’est du bon gros troll, Dr BG c’est du troll, ce journal est un troll. Vous êtes en plein délire, concernant les réalités du marché du travail et du travail en lui-même.
#OnVautMieuxQueÇa[^] # Re: Si tu veux être le couillon de service
Posté par Nim . Évalué à 7.
On a bien compris ton expérience, tout le monde sait que cela existe.
Cela te rassure peut-être de penser que c'est la règle. Mais sérieusement arrête de te cacher derrière le « tous pourri », bouge toi, pose ta démission et va voir ailleurs.
Si tu n'es pas trop mauvais, tu auras des opportunités peut-être moins bien payées mais plus humaines.
[^] # Re: Si tu veux être le couillon de service
Posté par barmic . Évalué à 6.
On est dans un domaine où pour la plupart des gens c'est irrespectueux de prévaloir de se mot clef. Ça existe, mais c'est très loin d'être la règle, là où d'autres corps de métier sont bien plus touchés par des ignominies.
Encore une fois ça existe, mais quand tu dis par exemple qu'on a pas le choix d'entreprise, c'est vraiment du foutage de gueule. De mon expérience, je n'ai pas eu besoin de faire de recherche d'emploi pour trouver de travail qui me plaît. De ce que je vois autour de moi c'est soit des profils atypiques (des gens qui cherchent du travail assez précis) soit des gens qui cherchent avec assez peu d'entrain qui ne trouvent pas. Et encore, je ne parle pas de la région parisienne où la situation semble encore plus favorable aux demandeurs d'emploi en informatique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par blabla . Évalué à -10. Dernière modification le 11 avril 2016 à 20:47.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Si tu veux être le couillon de service
Posté par xcomcmdr . Évalué à 4. Dernière modification le 11 avril 2016 à 19:17.
Toi, t'en as gros.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Rappel des règles de modération
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Merci de rester courtois dans les échanges, conformément aux règles de modération en vigueur sur le site. Si tu te penses tellement supérieur(e) et tellement intéressant(e), je pense que tu devrais trouver un endroit plus à même d'accueillir la quintessence de ta prose et l'offrir à des gens plus susceptibles de l'apprécier, ailleurs.
[^] # Re: Si tu veux être le couillon de service
Posté par Julien Jorge (site web personnel) . Évalué à 7.
Mmmh j'ai un peu de mal à te suivre. J'ai pourtant l'impression d'être dans le monde du travail (le vrai, pas celui des Hainounours). Sans être un monde idéal il est loin du monde amer que tu décris où les hauts gradés veulent écraser les plus petits qui en retour sont sur la défensive.
Ce que tu nous décrit ressemble plus à l'image du monde de grand papy, où le travail était avant tout une corvée et où on bossait pour rien jusqu'à se faire virer. Enfin j'imagine, je n'ai jamais connu ça. Heureusement pour nous l'informatique est un domaine où on peut encore choisir son employeur et où beaucoup, beaucoup, de personnes sont passionnées ; ce qui fait qu'on peut facilement se trouver dans une équipe que l'on est content de rejoindre quotidiennement.
À vrai dire, dans la mesure où le travail consomme quasiment un tiers de notre temps, si quelqu'un se lève tous les jours pour faire quelque chose qui lui déplait et passer sept heures par jour sur la défensive et dans le conflit alors qu'il a la possibilité de simplement traverser la rue pour vivre autre chose, j'ai l'impression que le problème est chez cette personne, sûrement pas dans le métier. Je ne doute pas que certains sont coincés par une raison où une autre, mais dans l'absolu je doute que ça vienne du fait d'être dans l'informatique.
Ce principe du conflit par défaut entre les patrons et les salariés, dans l'informatique au moins, me semble éculé. Peut-être suis-je naïf et que je changerai d'avis si un jour un patron me fait un sale coup que je n'aurai pas vu venir. Peut-être serai-je alors incapable de lui dire « au revoir, et merci » pour partir chez un autre. En attendant aujourd'hui je vois partout des boites où il fait bon travailler et où on peut aller en souriant.
[^] # Re: Si tu veux être le couillon de service
Posté par blabla . Évalué à -10. Dernière modification le 10 avril 2016 à 18:34.
je vois partout des boites où il fait bon travailler et où on peut aller en souriant.
[^] # Re: Si tu veux être le couillon de service
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Tu n'a jamais demandé une augmentation?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Si tu veux être le couillon de service
Posté par Julien Jorge (site web personnel) . Évalué à 0.
Ah la négociation, les salaires, les primes :) je te retourne la question : as-tu déjà été tellement déçu de te voir refuser une augmentation que tu t'es mis à surestimer ta charge de travail et à prendre des notes pour pourvoir retourner les choses contre tes patrons ?
[^] # Re: Si tu veux être le couillon de service
Posté par barmic . Évalué à 10.
J'ai une approche assez particulière sur le sujet :)
Je n'en demande pas.
Si je considère que ma situation ne convient plus, que ce soit d'un point de vu financier, humain ou technique, je vais voir comment ça se passe ailleurs.
C'est pas à moi d'aller leur expliquer que l'inflation existe, que le salaire moyen pour mon profile est au dessus de ce qu'on me donne, d'aller quémander des info sur ce qui plaît ou pas dans ce que j'ai fait cette dernière année. 1
Pour le moment ça marche très bien (j'ai expérimenté la dem'), on verra si ça continue.
globalement j'ai l'impression que si tu as besoin de demander ce genre de chose c'est que tes supérieurs n'ont rien à faire de toi et ça se ressemble un tas d'autres choses, raison de plus pour aller voir si l'herbe n'est pas plus verte à coté ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Si tu veux être le couillon de service
Posté par barmic . Évalué à 3.
ça se ressent sur un tas d'autres choses
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Si tu veux être le couillon de service
Posté par Jiel (site web personnel) . Évalué à 3.
Cela montre particulièrement qu'il y a un problème du côté employeur, si les salariés se sentent obligés de chercher ailleurs quand un problème est rencontré.
[^] # Re: Si tu veux être le couillon de service
Posté par diorcety . Évalué à 9.
J'ai un sentiment mitigé, je pensais comme toi il y a quelques années, beaucoup plus contrasté maintenant.
On va dire que je me laisse pas faire, relativement franc et je ne peux pas faire le faux cul, autrement dit pas forcément le meilleur profil pour évoluer dans une entreprise. Et donc au finale tu vois les personnes qui ont un profil technique(alors qu'ils ont été embaucher pour faire la même chose que toi) à la ramasse mais qui arrive bien à faire les faux culs, courber l'échine et lécher des c***, te passer devant, tu relativise pas mal sur le fait qu'il suffit de faire correctement ton travail(à moins que la lèche soit pourquoi on t'ai embauché). Car essayer de faire avancer les choses c'est souvent des "conflits" alors que c'est ton boulot. Mais ça passera moins bien que la personne qui dit amen à tout(et qui à la fin trouvera une excuse ou reportera la faute sur quelqu'un d'autre au lieu d'assumer), ce qui revient à une personne qui ne fait pas correctement son boulot car il pense à son avenir et pas celle de sa boite. Donc tu fais ton boulot, mais tu fais trop de vague et certaines structures n'aiment pas du tout les vagues, même si malgré ça tu te donne à fond pour elle.
Je ne généralise pas, il y a certainement des boites géniales mais dire que ça se voit quand l'on fait l'entretien ou pendant la période d'essai, c'est un peu fort.
Bref au finale il faut trouver l'entreprise qui à la même définition de ce qu'est être professionnel dans son travail et pour savoir ça, il faut "l'essayer" et je pense que ça peut passer par quelques déceptions avant d'y arriver.
[^] # Re: Si tu veux être le couillon de service
Posté par Jiel (site web personnel) . Évalué à 10.
As-tu déjà bossé dans une SSII en France ? Si tu ne demandes rien, il n'y a effectivement pas de conflits (et tu te fais avoir).
Éculés, les managers qui mentent à tour de bras ? Les batailles pour obtenir ce qui est légalement dû dans les accords d'entreprise, dans la convention collective ou le code du travail (comme le rattrapage des heures supplémentaires ou le paiement des astreintes) ? Le respect de ses droits, comme ne pas travailler gratuitement en dehors de ses heures de travail, même si on est cadre ? Les gens qui ont peur de faire grève pour ne pas être mal vu ?
Le modèle de beaucoup de SSII est de presser les petits jeunes comme des citrons, en se basant sur leur naïveté, leur gentillesse et la méconnaissance de leurs droits, tout en leur promettant des supers trucs qu'on sait qu'on ne donnera pas. Et c'est le cas aussi dans pas mal de grandes entreprises françaises, même quand on est en interne. L'absence de conflit dans les TPME et les start up je veux bien, mais sinon, soit tu es naïf, soit tu es un expert quadragénaire dont le manager sait qu'un conflit serait très dommageable pour la boîte.
[^] # Re: Si tu veux être le couillon de service
Posté par blabla . Évalué à -10.
Ça j’y crois pas du tout. Typiquement les start up ça pue la machine à fabriquer du rêve à plein nez. Fondamentalement ça n’est rien de moi qu’une version pour “jeunes sur-diplômé” du loto de Mme Michu. La différence c’est que Mme Michu sait qu’elle achète du rêve.
Du temps où je cherchais j’ai même eu droit à une guedin qui s’attendait à ce qu’on bosse gratuitement pour elle…
[^] # Re: Si tu veux être le couillon de service
Posté par Julien Jorge (site web personnel) . Évalué à 5.
Effectivement je ne suis pas passé par les SSII, cela doit jouer. Les entreprises où j'ai travaillé étaient des éditeurs et plutôt petits.
[^] # Re: Si tu veux être le couillon de service
Posté par fearan . Évalué à 5.
Chez nous c'est dans la même veine, c'est un travail administratif à produire qui est long, avec des relance à refaire pour avoir finalement au bout de 3/4 mois notre du (ou au moins une partie). Récemment un jugement à l'Europe à validé le fait que le temps de trajet pour aller bosser devait être considéré comme du temps de travail lorsque le lieu de travail n'est pas le lieu habituel (pour une SSII, c'est le siège ou un de ses bâtiments).
On a donc eu un rappel d'un accord passé stipulant que dans le cas où la différence de temps de trajet (domicile siège, domicile lieu de travail) dépassait de 40 minutes / jour on était dédommagé (mais à un coût fixe indépendamment du salaire)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Si tu veux être le couillon de service
Posté par MCMic (site web personnel) . Évalué à 3.
On lit ça partout, mais ce que je comprends pas du coup c’est pourquoi les gens continuent d’aller travailler pour ces structures.
Chaque fois que quelqu’un dit du bien de son boulot ou du monde du travail sur linuxfr on lui rétorque «Toi, t’as pas bossé 5 ans en SSII (sous-entendu: tu vois pas ce que c’est le monde du travail)!». Ben non, évidemment qu’on est pas allé bosser en SSII, puisque justement c’est nul !
[^] # Re: Si tu veux être le couillon de service
Posté par j_m . Évalué à 9.
Humainement, là où je travaille c'est très bien. Surtout par contraste avec l'école. Si il fallait choisir entre le travail et l'école à réformer pour éviter le plus grand mal, pour moi ça serait l'école à 200%. Une succession de stress, de culpabilités et de léthargie.
Mais pour rebondir sur le côté politique, je ne serais pas contre l'idée de monter le salaire minimum dans les entreprises privées afin qu'elles meurent et que les coopératives reçoivent le monople de la liberté d'entreprendre.
[^] # Re: Si tu veux être le couillon de service
Posté par Papey . Évalué à 6.
Oui enfin quand on voit ce que sont devenues les grandes banques et assurances coopératives…
[^] # Re: Si tu veux être le couillon de service
Posté par j_m . Évalué à 4.
Je ne connais pas les détails. Les coopérateurs ont de mauvaises conditions de travail? Les bénéfices ne sont pas bien partagés ?
[^] # Re: Si tu veux être le couillon de service
Posté par Papey . Évalué à 3.
Que penses-tu des conditions de travail, de l'éthique et du sens du client de Axa (initialement Mutuelle de Rouen) ou de BPCE ?
Le modèle coopératif est intéressant, surtout pour les structures petites et moyennes. Il peut dériver quand les structures grandissent vers un modèle où le management n'est plus au service de l'ensemble des parties prenantes, et en particulier pas des clients, même quand ceux-ci sont sociétaires, ou des salariés. La parole de chacun devient trop diluée et les administrateurs se déconnectent du "terrain" comme dans les grandes entreprises actionnariales.
Il ne faut pas jeter le bébé avec l'eau du bain, mais dans certains cas l'eau est tellement croupie qu'on a du mal à reconnaître le bébé au milieu du bain.
# Hmmm, relativement d'accord sauf ...
Posté par LaBienPensanceMaTuer . Évalué à 4.
… sur ce point:
Je pense qu'il faut nuancer cette partie, juste un tout petit peu.
Etre focus sur les fonctionnalités, c'est cool et ça permet de sortir rapidement quelque chose.
Cependant, je suis convaincu qu'un peu de réflexion au préalable, voir de code "framework" peut permettre d'éviter un refactor ou bout de 5 versions parce que "merde, j'avais pas pensé au multijoueurs" (pour reprendre ton exemple sur le jeu vidéo).
Beaucoup de projets libre ont, je pense, obéit à la règle que tu énonces et se sont retrouvés, à un moment, bloqués "by design" pour certaines évolutions fonctionnelles.
De mon point de vue, il faut placer le curseur correctement: penser son code, tenter de prévoir le futur puis ensuite aller sur les fonctionnalités.
C'est cette phase "d'architecture logicielle" qui te garantira un code pérenne et évolutif.
# et les autres boulots aussi
Posté par Jiel (site web personnel) . Évalué à 4.
Je trouve cette synthèse excellente. D'autre part, tes points pourraient s'appliquer également à autres choses que du développement et presque à n'importe quel travail qui demande de s'appliquer.
# Livres qui m'ont le plus appris
Posté par swilmet . Évalué à 2.
Si je devais ne recommander qu'un seul livre, ce serait Code Complete. Oui, c'est édité par Microsoft Press, mais le livre n'a pas grand chose à voir avec Microsoft ou Windows. C'est avec ce livre que j'ai le plus appris, pour écrire du code propre et plus stable, plus maintenable, etc. J'ai écris cet article sur mon blog à propos de Code Complete.
Pour la programmation orientée objets, le livre qui m'a le plus appris est Object-Oriented Design Heuristics. J'ai aussi écris un article sur mon blog pour ce livre.
Voilà, j'ai lu beaucoup d'autres bouquins, mais ces deux-là, c'est ceux que je recommande le plus.
# Commentaire supprimé
Posté par alexben . Évalué à -1. Dernière modification le 16 mai 2016 à 15:34.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.