Pas compris, à moins que l'usage du subjonctif ne te gêne...Envoyé par 7gyY9w1ZY6ySRgPeaefZ
Au moins la conjugaison n'évolue pas
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pas compris, à moins que l'usage du subjonctif ne te gêne...Au moins la conjugaison n'évolue pas
Oups, c'est ça de répondre avant son premier café...
Avec la propagation des verbes du genre « croiver » et « sachier », je tire à boulet rouge sur tout le monde... avant de réfléchir.
Je croive que je vais prendre un pause pour commencer ma journée...
Que les conditions de réussite ou d'échec d'un projet sont avant tout humaines et politiques, et seulement en second lieu technologiques.
Bientôt 12 ans de dév et j'ai jamais mis les pieds dans une SSII
Et donc, pour rebondir, j'aurais bien aimé savoir avant si ça m'aurait plu de devenir une machine à transformer le café en code.Oups, c'est ça de répondre avant son premier café...
Le subjonctif est incorrect ici parce que le verbe de la principale, même s'il n'est pas répété à chaque énumération, est en fait le verbe savoir, qui n'est pas suivi du subjonctif parce que ce qu'on sait doit être vrai.
Ceci dit, ce n'est pas une erreur que j'eusse relevé si personne ne l'avait fait.
Perso, pour que j'eusse apprécié cette information à sa juste valeur, il eût fallu que je ne m'en branlasse point complètement.
Tu as foiré la blague mais d'une force
"Encore eût-il fallu que je le sachiasse" ou bien "Encore eût-il fallu que je le susse"
Déjà, ce n'était pas une blague : j'en ai vraiment rien à b... du subjonctif. Et ensuite, tu peux toujours courir pour que je le susse, ça ne m'intéresse pas.Tu as foiré la blague mais d'une force
"Encore eût-il fallu que je le sachiasse" ou bien "Encore eût-il fallu que je le susse"
[TROLL]Que les grosses SSII sont des marchands de viande.[/TROLL].Qu'auriez-vous aimer savoir avant de vous lancer dans une carrière de développeur ?
Ça dépend du type de boite.Ce que vous avez découvert dans le monde professionnel se rapproche-t-il de l'idée que vous aviez ?
Autant dans la SSII où j'étais, j'ai été très désagréablement surpris par la manière dont j'ai été traité (j'avais l'impression d'être là juste pour être là, j'y ai même perdu mon temps).
Autant dans la boite où je suis actuellement (un petit éditeur logiciel), l'ambiance, la culture et la mentalité était bien plus en accord avec l'idée que je me faisais du monde pro en Informatique (côté "startup").
Disons que je ne suis pas en désaccord.Que pensez-vous de la liste proposée par Ana Ulin ?
- Un bon développeur / Une bonne développeuse sait remettre en question ses choix.Quels éléments pourriez-vous ajouter ?
- Un bon développeur / Une bonne développeuse sait communiquer avec son ordinateur, mais aussi (et surtout) avec ses collègues.
- Un bon développeur / Une bonne développeuse fait de la veille techno.
- Un bon développeur / Une bonne développeuse apprend continuellement.
- Un bon développeur / Une bonne développeuse n'est pas un/une vulgaire pisseur/pisseuse de code.
- Un bon développeur est un développeur paresseux.
- Une bonne développeuse est une développeuse paresseuse.
- Savoir programmer -ou bien être très bon- dans un langage fait juste de vous quelqu'un de bon dans ce langage. Ça ne fait pas de vous un.e bon.ne développeur.se.
- Le métier de développeur est un métier de passionné.
- Certains développeurs sont tellement cons que sous prétexte qu'ils sont plus vieux, on ne devrait pas remettre en question leur choix techniques, même s'ils sont très mauvais (j'ai vécu ça).
- Les méthodes agiles ne se réduisent pas à Scrum.
- Être "agile", ce n'est pas juste appliquer une méthode, c'est aussi (et surtout) adopter une autre culture.
- Beaucoup de gens parlent des méthodes agiles, mais très peu ont lu le Manifeste Agile.
- Certain chefs de projet/managers se croient plus compétents en développement qu'un.e développeur.se dont c'est le métier.
- Certain chefs de projet/managers jugent bon d'expliquer à un.e développeur.se comment faire son métier (j'ai vécu ça), alors que ce sont deux métiers différents, nécessitant des compétences différents.
Qu'auriez-vous aimé savoir avant de vous lancer dans une carrière de développeur ?
* il y a plein de métiers parallèles qui sont intéressants, il n'y a pas que chef de projet comme avenir.
* la qualité du code n'est pas essentiel en soi.
* la personne qui a une grande gueule n'est pas meilleure que toi, elle a juste une plus grande force de persuasion et est souvent moins bonne que toi mais avancera plus vite en carrière.
* les employeurs ne sont pas près à investir dans un pc performant même si tu perds deux heures de travail par jour à cause d'une bécane pourrite !
* si tu veux changer quelques choses, montre des graphiques à ton boss, quitte à enjoliver du bord que ça t'arrange.
tout le monde est d'accord là-dessus mais comme je l'ai écris pour se mettre à la page des évolutions technologiques soit l'entreprise qui vous fait travailler vous paie une formation souvent coûteuse soit il faut payer de votre poche pour la formationQue les technologies évoluent constamment et qu'on doive sans arrêt tout réapprendre et sans arrêt se remettre en question, bon c'est à la fois un plus mais au bout d'un moment ça devient usant.
là je suis bien d'accord ; je suis bien plus productif chez moi qu'en entreprise et c'est dingue le nombre de lignes de code écrites sur des projets personnels.
En entreprise on n'est pas si productif que ça car il faut attendre toujours un truc soit des specs, soit des accords de la direction soit ceci-cela
la qualité du code ça dépend par ce que l'on entend par qualité du code.
S'il faut mettre 3 lignes de commentaires pour la moindre variable ou le moindre appel de fonctions le remède est pire que le mal.
Pour ce qui est des machines performantes ça c'est la faute aux vendeurs de solutions logiciels qui font des ERP et des frameworks de plus en plus lourds, gourmands en ressources, consommateurs en mémoire et CPU
Par qualité, j'entends la maintenabilité et la correspondance avec les specs : c'est souvent mieux vu de produire un code de merde en 1 jour qui fait vaguement ce qui est attendu et de le débugger pendant 5 jours que de passer 4 jours à faire un code qui répond aux attentes et qui passe les tests sans problèmes.
Il y a ça aussi, mais je fais plus allusion aux pcs qui ont pas loin de 10 ans et qui mettent plus d'un quart d'heure à booter et qui ont mal supporter la poussière de gypse des derniers travaux...
Les chefs qui rechignent à dépenser 1000 $ alors que tu perds plus d'une heure par jour, ce ne sont pas des grands comptables. C'est sûr que lorsque tu fais du excel à longueur de journée, n'importe quelle babasse fait l'affaire !
Dernière modification par Invité ; 13/11/2018 à 15h52.
1/4 d'heure à booter
Te plains pas, moi j'ai un PC récent qui met un quart d'heure à booter, mais là c'est parce que le DSI insiste pour que je mette tout dans le Roaming sous prétexte qu'il se pourrait qu'un jour je travaille sur un autre PC, et tant pis si les 800 Mo de cache de toutes mes applis se trouve dedans alors qu'un cache n'a rien à faire dans le Roaming...
J'aurais aimé savoir que les salaires de référence indiqués ça et là sont à diviser par 3 ou 4 quand on habite en province.
c'est plutôt un problème de maintenance que de performances...
on peut très bien utiliser des machines dernier-cri "puissantes" puis au bout de 6 mois elles finissent par ramer parce qu'il n'y a pas eu de défragmentation et que des tas de logiciels ont été installés.
Donc on ne cesse de le répèter mais comme on ne fait pas d'omelette sans casser des oeufs de toute façon pour utiliser du matériel informatique il faut du budget et des moyens financiers pour cela.
Par moyens financiers j'entends embaucher des personnes pour assurer la maintenance technique.
Comme ça ça fait baisser le taux de chômage des informaticiens.
Quel chômage des informaticiens ? Ah ouais... La France...
« À Montréal, tu traverses la rue et tu as une job ! »
Mais en contrepartie y'a l'accent...
Ou pas. ^^
C'est vrai pour des petits fichiers Excel, mais c'est loin d'être vrai pour tous malheureusement. Certaines boites ont des pans métiers complets qui fonctionne sous Excel avec des trucs plus ou moins performants, développés par des informaticiens plus ou moins professionnels (voir des non-informaticiens), qui ne tournent pas sur n'importe quelle babasse.
C'est d'autant plus visible dans des entreprises qui sont en pleine transition petite entreprise familiale / traditionnelle => entreprise industrialisée, elles géraient tout avec Excel, n'ont pas encore forcément les moyens d'investir dans de gros logiciels pro complets (et pour certaines, n'en ont pas encore vraiment besoin), du coup on automatise les fichiers Excel, et/ou on les modifie pour faire des espèce d'usine à gaz remplaçant des progiciels, avec des correctifs de correctifs de pansements sur des jambes de bois, pour absorber la monter en puissance de l'entreprise.
Le pire je crois, c'est tous ces "plannings" ou ces fichiers de "suivi de commandes", qui ont plusieurs dizaines de colonnes sur plusieurs centaines / milliers / dizaines de milliers de lignes, et où chaque cellule n'est en fait qu'une formule de liaison vers un autre "planning" / "fichier de suivi", et cela parfois à 2 ou 3 niveau de suite (déjà vécu).
Et pour le coup, pour peu que tu ais un SI qui fasse un peu de zèle, et qui fait tourner 150 services en tâche de fond pour tout surveiller (comme chez nous), tu as beau avoir une machine avec 8 Go de RAM, ça commence déjà à être plus que limite pour peu que tu ais plus d'un de ses gros fichiers Excel d'ouvert. ^^
C'est moins pire qu'à Marseille ou en Picardie.Mais en contrepartie y'a l'accent...
Répondre avec citation
Partager