Première augmentation, au bout d'un an.

Répondre
Partager Rechercher
Citation :
Publié par Caneton la poule
Waoh, donc quand on vient me voir pour des bugs bloquants ou urgents, il faut que je sois le sosie de mon collègue qui se met en panique autant que le commercial ou la direction pour résoudre le problème plutôt que de le prendre calmement. Je pense qu'ils savent très bien qu'ils n'auront pas à revenir me voir vu comment ça s'est terminé.
Tu t'es fais friendzonné

C'est quand même beau les entreprises où le rapport humain est mis en avant ^^.



Citation :
Publié par Caneton la poule
  • Exploiter une des offres qu'on me propose et leur laisser l'appli développée en cours de déploiement chez la majorité de nos clients, en sachant que personne a été formée dessus, je suis le seul à en connaître son fonctionnement ainsi que le langage utilisé, j'ai eu le temps de faire que très peu de docs, donc en gros les foutre dans la merde / en retard sur cette partie.
Personne n'est indispensable.
Ça aura un léger impact à court terme le temps que quelqu'un d'autre reprenne le bazar (ou qu'ils partent sur autre chose tout simplement), mais le coup du "je suis le seul à XXX" ça vaut rien.
Citation :
Publié par Epic
Personne n'est indispensable.
Ça aura un léger impact à court terme le temps que quelqu'un d'autre reprenne le bazar (ou qu'ils partent sur autre chose tout simplement), mais le coup du "je suis le seul à XXX" ça vaut rien.
J'ai pas dis le contraire, mais c'est le temps qu'ils trouvent quelqu'un qui reprenne le projet qui va les handicaper.
Je leur ai pas sorti l'excuse du "je suis le seul qui connait ça dans cette boîte", ils le savent très bien.

La vraie question c'est : Ce genre de discours donne vraiment à des gens un boost de motivation ?
Citation :
Publié par Epic
Tu t'es fais friendzonné

C'est quand même beau les entreprises où le rapport humain est mis en avant ^^.





Personne n'est indispensable.
Ça aura un léger impact à court terme le temps que quelqu'un d'autre reprenne le bazar (ou qu'ils partent sur autre chose tout simplement), mais le coup du "je suis le seul à XXX" ça vaut rien.
Ça peut juste coûter horriblement cher. J'ai déjà vu des gens retourner dans leur ancienne boîte au tarif consultant. C'était devenu la solution la moins chère pour régler le bordel
prends les au jeu, avance dans tes démarches à côté, tu préviens une fois que t'as une promesse d'embauche que tu te casses dans X mois et que t'es dispo s'ils veulent organiser une passation.

Bisou-bye au suivant quoi.
Citation :
Publié par Caneton la poule
La vraie question c'est : Ce genre de discours donne vraiment à des gens un boost de motivation ?
Après c'est juste un argument pas ne pas t'augmenter, histoire de ne pas simplement dire "non".

Mais tu as aussi beaucoup de personnes qui ont peur de changer de boites (peur du changement, peur de ne pas arriver à s'adapter ailleurs, peur de ne pas avoir le niveau attendu, etc ...), et qui du coup s'en contenteront.

J'imagine que ce n'est pas la conclusion que tu attendais, mais au moins maintenant tu sais l'importance qu'ils t'accordent derrière la façade "on est une entreprise humaine"
Message supprimé par son auteur.
Citation :
Publié par Epic
Après c'est juste un argument pas ne pas t'augmenter, histoire de ne pas simplement dire "non".

Mais tu as aussi beaucoup de personnes qui ont peur de changer de boites (peur du changement, peur de ne pas arriver à s'adapter ailleurs, peur de ne pas avoir le niveau attendu, etc ...), et qui du coup s'en contenteront.

J'imagine que ce n'est pas la conclusion que tu attendais, mais au moins maintenant tu sais l'importance qu'ils t'accordent derrière la façade "on est une entreprise humaine"
Ils savent que ce n'est pas mon cas car c'est ce que j'ai fais dans ma boîte précédente pour venir chez eux.
Oui effectivement on a pu se dire nos 4 vérités tout en restant cordiale, faire semblant comme ils aiment
Yep fuis. Tu vas perdre ton temps avec eux. En plus si tu bosse sur des technos obsolètes, ta valeur sur le marché du travail va en prendre un coup.
Prends l'une des autres offres si ça t'intéresse.

A minima ça te fera plus de thunes le temps de chercher autre chose.
En tout cas, ça t'as permis de voir leur vrai visage, c'est plutôt positif.

Et ensuite l'argument de "t'es mieux payé que tes collègues" c'est incroyable de sortir ça car si leur mec le mieux payé se faire déjà enfler par rapport au marché du travail (même de province) j'imagine même pas les autres.
Du coup c'est un peu comme si ils t'avaient dit "On est des enfoirés avec tout le monde mais un peu moins avec toi alors sois reconnaissant".
Du coup pas à avoir de scrupules... et surtout la question de former quelqu’un pour reprendre la main c’est pas ton problème dans le cas présent.
Pour faire un contrepoint, j'ai déjà eu gars qui est parti "parce que la techno était pas très intéressante" (il n'en maîtrisait clairement pas les raffinements) et les projets "un peu limités techniquement" (sur le seul challenge "technique" de son projet en cours il s'était ramassé en en faisant qu'à sa tête malgré les guidelines fournies - sa conclusion "limitation de la techno", totalement lié au point 1 donc, maintenant que j'y pense huhu). Il est donc parti en étant le seul dev sur un projet en chantier (bon soyons honnête il ne restait réellement que ZE BUG LIMITE DE LA TECHNO et 2/3 trucs mineurs), je l'ai repris et c'était fini en une semaine, big deal.

Bref on a qu'un point de vue pour rappel.
Et pour le salaire ça parait difficile de juger de loin bien sûr. Après on est sur JOL où la base c'est d'avoir AU GRAND MINIMUM "le salaire moyen" . Statistiquement c'est problématique quand même

Après bon si tu penses n'être pas être trop biaisé (on l'est tous) dans ton vécu de la situation, ouais c'est probablement mieux de chercher à bouger là.
Oui je ne jugerai pas forcément l'aspect techno. Par contre, là où on a pas besoin de 2 versions différentes c'est sur son salaire et ce qu'un dev dans sa techno devrait toucher. Il n'atteint même pas la fourchette la plus basse. Il est payé comme un junior.
Citation :
Publié par La Hutt Finale
Oué alors ca, on verra après ton évaluation. Je te souhaite le meilleur mais c'est souvent à la première demande d'augmentation que les sourires se figent. Donc n'y va pas en pensant aller chez tes potes non plus.
Qui c'est qui avait raison mmh ?

Des arguments que tu relaies, je retiens qu'ils sont la liste argument_bateau_liste_01 sortis par des managers incapables de donner une justification réelle (autre que "l'argent, il est pas pour toi"): ils sortent des paramètres subjectifs pour se tirer d'affaire.

Conclusion: ils te prennent pour un teubé. Commence à préparer tes valises si tu souhaites améliorer ton revenu à l'avenir.

Citation :
Après c'est juste un argument pas ne pas t'augmenter, histoire de ne pas simplement dire "non".
Vaut mieux dire "non" en fait. Parce que la, en plus de se prendre un "non", tu te fais insulter: les mecs pensent que t'es assez con pour gober une excuse bidon. Je préfère "lol tu crois que l'argent il est pour les larbins ?" qu'un "tu compreeeeends, les temps sont duuuuuuurs" avec des miyyons de benef'.

Dernière modification par La Hutt Finale ; 11/09/2020 à 19h38.
Si tu as deux offres d'emploi en plus plus intéressantes il n'y a pas vraiment à tergiverser.

Par contre pour moi : "pas eu le temps de faire de la doc", c'est un manque de compétence du développeur qui signifie non seulement pas de doc écrite mais en plus code pas clair.
Citation :
Publié par Zangdar MortPartout
Si tu as deux offres d'emploi en plus plus intéressantes il n'y a pas vraiment à tergiverser.

Par contre pour moi : "pas eu le temps de faire de la doc", c'est un manque de compétence du développeur qui signifie non seulement pas de doc écrite mais en plus code pas clair.
J'ai fais les docs principales, comment récupérer le projet, comment il fonctionne dans les grandes lignes et surtout comment compiler / commit etc ... Car personne sait faire.
Mais je suis pas rentré dans le détail dans des documentations technique, le code reste commenté par contre.

Chose qu'ils vont sûrement me demander maintenant car sinon ça va être compliqué pour la suite, vu que personne des devs actuels veut/peut reprendre le projet, après discussion avec eux aujourd'hui.
Citation :
Publié par Zangdar MortPartout
Je déteste le code commenté
Dans un monde parfait la doc est build automatiquement à partir des commentaires du code de toutes façons, ahum... (en même temps que les tests exhaustifs qui te sortent un beau coverage à 98% sur ton TDB...)
Citation :
Publié par (0)Draki
Ca a l'air trop bien ton pays ou le code du travail est respecté a la lettre.
Tu va faire quoi si ton patron paye mieux ton collègue parce qu'il le trouve plus sympa que toi ? Le foutre au prud'homme ?

Quand t'a du mal a recruter et que les seul candidats qui se présente demandent 200€ de plus (1900b au lieu de 1700b) je fait comment ? je donne 200€ a tout le monde ?
Je te pose la question parce que c'est un cas réél qu'on a avec notre service hotline là, tout le monde fait le même taf, et on galère a trouver des gens, du coup ceux qui tente la nego bah on les prend.
Il faudrait augmenter 20 personne parce que y'en a une qui gagne 100 et une autre qui gagne 200 de plus ?

Légalement oui, mais dans la réalité bah ce n'est pas le cas, chez nous les gens l'on appris, on fait un caca nerveu, et c tout.

Donc t'a pas le droit, mais franchement y'a rien qui t'en empêche

C'est comme la discrimination a l'embauche, si tu veux pas une ethnie particulière, tu le justifie autrement, c'est tout.
Ca serait agreable si tu prenais la peine de lire les liens fournit... Le cas d'ecole mis en lien (que tu as cite) couvre EXACTEMENT ce scenario. Donc le ton péremptoire comme quoi tu ne peux pas payer un collaborateur plus cher meme si tu as des difficultes a embaucher tombe un peu a l'eau... Il a l'air beau ton pays ou on sort des arguments qui sont totalement caducs...

Extrait du lien mis plus haut:
Les circonstances de l'embauche peuvent légitimer des différences de rémunération entre des salariés effectuant le même travail.

Donc si, tu as le droit de payer plus un collaborateur pour le faire venir chez quoi puisque les conditions et le contexte d'embauche est un element factuel influant sur la remuneration.



Citation :
Publié par Caneton la poule

Du coup deux solutions :

  • Faire semblant que le travail me plait à 100% h24, dès qu'il y a un bug ou quoi chez un client, s'y jeter dessus et y mettre toute son âme (alors que mon job à la base n'est même pas de prendre en charge les bugs, mais uniquement les nouveaux développement, bref.
  • Exploiter une des offres qu'on me propose et leur laisser l'appli développée en cours de déploiement chez la majorité de nos clients, en sachant que personne a été formée dessus, je suis le seul à en connaître son fonctionnement ainsi que le langage utilisé, j'ai eu le temps de faire que très peu de docs, donc en gros les foutre dans la merde / en retard sur cette partie.
solution 2.
Tu te barres. Tu as deja fait valoir que la concurrence t'avais fait des offres, ils ne s'alignent pas. Si tu reste, tu perds toute credibilite et les negos futures vont etre d'autant plus difficile.
C'est a ton management de s'assurer de la continuite de service en cas de demission, maladie ou autres... Ils te laissent seul sur un projet/techno? Ils ne t'ont pas alloue de temps pour mettre a jour la documentation, faire un transfert de connaissance etc... ? C'est leur faute, pas la tienne. Ils vont avoir de 1 a 3 mois pour le faire (ie. duree de ton preavis).
La culpabilisation pour faire rester un salarie, c'est une technique connue mais c'est suppose etre couvert par la periode de preavis ou tu va (theoriquement) la passer faire du transfer de connaissance.
Citation :
Publié par Assurancetourix
Dans un monde parfait la doc est build automatiquement à partir des commentaires du code de toutes façons, ahum... (en même temps que les tests exhaustifs qui te sortent un beau coverage à 98% sur ton TDB...)
Dans un monde parfait la doc ne s'adresse qu'aux utilisateurs de l'API et le code est lisible. Et on a plein de tests effectivement

Mais dans notre monde il semble que les compagnies adorent payer 1.000x le prix pour régler un bug chez le client plutôt que in house et avoir du code non maintenable
Citation :
Publié par Zangdar MortPartout
Je déteste le code commenté
Amen, la seule vraie source d'information est le code. Il ne peut qu'etre a jour. Les commentaires, on sait jamais trop si ils sont sync avec le code.
Perso j'aime bien quand le code est auto documenté. ie. que le nom des fonctions, et ses arguments sont assez clair pour que des commentaires soient redondants. Je documente quand je dois faire des trucs un peu sioux pour contourner un bug dans une API (link vers l'issue, un post SO, etc.), ou si j'implemente un algo (je link le white paper)
Citation :
Publié par Zangdar MortPartout
Dans un monde parfait la doc ne s'adresse qu'aux utilisateurs de l'API et le code est lisible. Et on a plein de tests effectivement

Mais dans notre monde il semble que les compagnies adorent payer 1.000x le prix pour régler un bug chez le client plutôt que in house et avoir du code non maintenable
On est dans un monde, en tout cas là où je travaille, où tout est à faire pour la veille.
Ils en ont rien à foutre des tests unitaires ou quoi que ce soit, ils ne savent même pas ce que c'est, tant que le travail est fait rapidement.

Attend tu ne vas quand même pas prendre 2h de plus pour faire un truc propre et qu'on peut tester facilement, déjà que ça te prend une journée !
Citation :
Publié par N° 44 636
Amen, la seule vraie source d'information est le code. Il ne peut qu'etre a jour. Les commentaires, on sait jamais trop si ils sont sync avec le code.
Perso j'aime bien quand le code est auto documenté. ie. que le nom des fonctions, et ses arguments sont assez clair pour que des commentaires soient redondants. Je documente quand je dois faire des trucs un peu sioux pour contourner un bug dans une API (link vers l'issue, un post SO, etc.), ou si j'implemente un algo (je link le white paper)
En fait tu appliques la bonne méthode du Comment WHY and not HOW
Citation :
Publié par N° 44 636
Amen, la seule vraie source d'information est le code. Il ne peut qu'etre a jour. Les commentaires, on sait jamais trop si ils sont sync avec le code.
Perso j'aime bien quand le code est auto documenté. ie. que le nom des fonctions, et ses arguments sont assez clair pour que des commentaires soient redondants. Je documente quand je dois faire des trucs un peu sioux pour contourner un bug dans une API (link vers l'issue, un post SO, etc.), ou si j'implemente un algo (je link le white paper)
C'est pour ca que je prefere largement un commit msg bien fait qu'un commentaire dans le code. Tu as a la fois le contexte historique du code, l'ensemble des changements lies, et theoriquement la raison du changement/ajout ainsi que l'ensemble des autres infos (lien vers le ticket/tache, etc...) sans polluer le code avec des infos qui risquerait de preter a confusion da l'avenir quand le code aura change et/ou son utilisation etendue.
Citation :
Publié par N° 44 636
ou si j'implemente un algo (je link le white paper)
Je suis d'accord que le code de la baseline n'a jamais tort.
Mais je comprends pas cette phrase : pour moi coder c'est forcément implémenter des algos ?
Tu fais la diff entre appeler à la chaîne des méthodes de librairie vs faire un truc plus compliqué c'est ça ?

Si oui en fait j'étais tjs dans le second cas en fait.
Citation :
Publié par Ex-voto
Je suis d'accord que le code de la baseline n'a jamais tort.
Mais je comprends pas cette phrase : pour moi coder c'est forcément implémenter des algos ?
Tu fais la diff entre appeler à la chaîne des méthodes de librairie vs faire un truc plus compliqué c'est ça ?

Si oui en fait j'étais tjs dans le second cas en fait.
Le dev web, tu peux pas test..
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés