La théorie du partage est bien belle mais il me semble que le problème c'est que si elle s'applique facilement aux emplois non-qualifiés ca me semble beaucoup plus douteux pour des emplois qualifiés.
Distribuer un travail pénible, répétitif avec un coût de formation faible est une bonne idée. Sauf que c'est justement ce type de métier qui tant à disparaitre.
Un travail qualifié se distribue beaucoup plus difficilement:
Une distribution fine n'a aucun sens. Tu ne peux pas mettre un mec différent par jour.
Une distribution aux 6 mois n'a pas plus de sens. C'est le temps qu'il faut pour devenir productif et comprendre un peu ce que tu fais.
Une distribution tous les 5 ans, tu retombes sur le problème du travail qualifié: formation et compétences. Tu peux objecter que pendant le temps libre tu peux faire ce que tu veux, mais tu vas retomber exactement sur le problème actuel. Ceux qui ont accrochés le wagon contre les autres qu'il n'y a plus de raison objective de faire travailler. Retour à la case départ.
Bref il reste la solution de travailler très peu de temps dans sa vie puis de faire autre chose. Mais la on retombe sur le problème du financement des innactifs. Ou alors que ceux qui veulent travailler (les emplois devenant de plus en plus qualifié ca exclue de plus en plus de monde) acceptent de financer les autres. Bref la vision "il suffit de travailler moins" me semble malheureusement un peu simpliste.
Comment peut-on être capable d'écrire un logiciel serveur pour gérer les transactions fiscales sans savoir ajouter une journalisation des connexions exploitable à fins de statistiques ?
Je ne comprends pas pourquoi on peut vouloir externaliser ça.
Pourquoi tu parles forcément de compétences ? Tu peux tout construire c'est vrai.
Après tu as ton coeur de métier, des choix, des priorités, des deadlines et tu composes en fonction. Il y a des choses ou clairement tu ne veux pas mettre les pieds dedans. Construire du soft ca prend longtemps, tu choisis comment l'utiliser.
Après on peut discuter de ce choix particulier sur deux axes:
Est-il acceptable que ce service de l'état fuite quelque information que ce soit à un prestataire privé quelqu'en soit le motif
Quelle est la nature exacte de la prestation qu'offre Xiti
Pour avoir bossé dans le domaine de l'analytics et du profiling, la phrase "exploitable à fins de statistiques" peut être à la fois tout à fait juste ou totallement naïve. Et vu qu'on ne connait pas les besoins fonctionels difficile d'avoir un avis sur le deuxième axe…
Je ne prends personne de haut. Je mets en balance la vision de "ca marche jamais".
Si tu veux un truc rock solid alors Fedora n'est peut etre pas pour toi
Si tu fais les upgrades le lendemain d'une release alors tu maximises les risques de problemes
Apres si tu combines ne pas connaitre grand chose, utiliser une distrib qui ne vise clairement pas le grand publique, à date fixe, qui bouge à toute vitesse, et faire une upgrade le lendemain alors tu maximises tes chances d'emmerdes. Faut juste être rationnel des fois.
Pour la QA ca ne demande aucune competence. Juste de faire ce que tu as fait et de rapporter ton probleme avant la release. Si personne ne le fait bin ca sort buggé. Il n'y a pas de magie.
Donc oui des problèmes il peut en avoir ca arrive. Comme pour tout,attendre une ou deux semaines peut éviter pas mal d'ennuis. Maintenant si tu as systematiquement des problèmes ca reste très très louche.
Depuis que je suis sur fedora (la 13, je crois), j'ai toujours eu une bonne raison de refaire une install complète.
Si tout n'est pas rose sur ce point chez Fedora, tu devrais tout de même te poser quelques questions je pense.
Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.
Il suffit de deux choses: lire la doc correctement et éventuellement ne pas upgrader 2h après l'annonce histoire que les éventuels bugs restant soient trouvés. Quand tu utilises Fedora tu es prévenu du deal à l'avance.
Et si tu penses que la QA c'est de la merde, tu les as testé les beta ?
Merci pour le lien. Malheureusement l'explication est clairement NIH ou CADT:
What steered us away from this approach was our criteria for conversations over threading, fast search, and a lightweight UI and backend.
Une simple critère d'UI mérite clairement de jeter 10 ans de dev et toutes les features qui vont avec pour répartir à 0:
Le fast-search génial, sauf que part defaut ca marche uniquement sur les deux dernières semaines. Quand tu le fais bosser sur toute la mbox il meurt.
C'est lightweight par ce que ca fait rien. On en reparle dans 10 ans quand il saura faire quelque chose
The suggestion was flatly rebuffed: use an extension. For us, that’s an unsatisfying answer.
Clair que ca vaut le coup de tout jeter par ce qu'on aime pas n'être qu'une extension. Si c'était pas possible techniquement, il manque l'argumentation.
Evolution is 900,000 lines of code, and includes many features we did not want to take on. Its fifteen years of development also bring with it what Federico Mena Quintero succinctly calls “technical debt”.
Il vaut mieux des features en trop ou aucune ? C'est sur aussi qu'en réécrivant tout les deux ans ont à pas de technical debt, mais on a un produit de merde jamais fini aussi.
In comparison, Geary stands at 30,000 lines of code today.
Après 3 ans super génial ! Sauf que ça fait rien. Ça sait même pas afficher tous les messages d'une mailbox, choisir la langue du dictionnaire, faire un filtre, un raccourci clavier.
Donc Vala est aussi utilisé dans des grosses applications, mais peut-être qu'ils s'en mordront les doigts plus tard
Vu que certaines parties du bureau Linux semblent condamnées à rester au stade du CADT et que geary fait parti de ce cirque est ce vraiment important ?
Il faudrait avant dépasser l'étape du proof-of-concept qui ne fait rien tout en réussissant à la fois à avoir l'une de ses trois fonctionnalités qui dépend de gmail (dans ce cas pourquoi l'utiliser ?), et à crasher en permanence. Mais d'ici là une nouvelle réécriture de 0 d'un client mail sans aucune fonctionnalité aura eu lieu…
Une qualité de pacman provient de AUR, c'est un bel ensemble de logiciel facile à installer.
Tu voulais dire un bel ensemble de paquets vite fait mal fait, créés par Jean-Kevin puis maintenu 45 secondes par toto avant d'être laissé à l'abandon dans ce gigantesque tas de caca ?
Non sérieux, j'arriverai jamais à expliquer qu'on cite AUR comme un avantage et qu'on puisse l'utiliser. C'est le skyblog des dépôts ce truc…
Par contre que ce soit bash ou python le cote lent c'est surtout l'appel git donc cela ne change rien ou si peu.
Si je pose la question c'est pas pour rien.
Le fait que les differents modules puissent etre lent et que certains doivent être desactivés selon l'environement c'est une évidence (j'ai "contribué" le module le plus lent de liquidprompt).
Par contre, contrairement à ce que tu dis, forker un python à chaque PS1 ca à un coup non négligable sur du vieux matos. Essaie sur le premier eeepc par exemple, tu vas voir la réactivités du truc. La question c'est à partir de quel hardware ca ne gène plus ton flot de travail. Sachant que si avec une approche sheel tu es obligé de virer tout les modules intéressant sur une petite config, autant pas se faire chier à utiliser une techno compliquée vu que de toute facon tu gagnes rien…
On peut aussi imaginer une approche hybrique avec un processus résidant et faire de l'IPC pour éviter le cout de lancement de l'interpreteur.
Liquidprompt c'est cool, mais quand tu compares le code à celui d'un powershell-line tu te dis qu'il y a un monde. C'est pas très grave vu que c'est petit et que ca bouge pas trop. Mais techniquement ca m'intéresse si quelqu'un y a déjà réfléchi.
Avez vous regardé un peu l'écart de perf entre l'approche de liquiprompt de tout faire en shell et les choix fait par d'autres projets similaires de lancer un script python ou autre pour générer le PS1 ?
Pour avoir lu le code des deux, l'approche shell est beaucoup plus complexe et bordelique, mais sur des petites config je me demande la différence de confort à l'usage. Sur une machine actuelle lancer du python ne pose aucun soucis. Donc tout se joue sur les vieux trucs pourris.
pv n'aurait-il pas fait l'affaire ? C'est un bon couteau suisse pour ce genre de chose.
L'approche est differente puisqu'il faut specifier ce que tu veux monitorer alors que toi tu pars a la peche aux infos, mais ca merite au moins d'etre connu.
En même temps, un salaire de plus de 100k€/mois pour une personne technique, c'est de la SF en France.
Ca a existé dans certaines boîtes. Des techos salariés a 80-120K j'en ai croisé. Par contre c'est pas des embauches récentes et maintenant tu peux bien te grater.
Oui bien sur, il faut lire le tu comme impersonnel.
Ta vision du marché Francais me semble assez bonne. C'est à dire pas folichon mais sans tomber dans la caricature que certains veulent en faire. Y'a du mauvais, beaucoup de médiocre et des trucs corrects. Ton 60K semble réaliste (je connais mal le marché parisien mais les salaires semble pas très loin d'en province…). Bref tu peux faire des trucs intéressant, sans contrainte forte, en étant dans le 90 percentile des salaires sans être un tueur. Ca tire vachement moins la larme que la vision smic, larbin, pousser des cartons, entretien difficiles pour rien…
Pour les entretiens en France c'est généralement beaucoup plus faible que ce que font les boîtes anglosaxonnes, ce qui fait que c'est plus facile de passer. La contrepartie c'est qu'il faut bien vérifier où on met les pieds.
Mais encore une fois si quand on pense que son travail vaut 100..150K au coût de vie max. Il suffit de se déplacer, il n'y a pas de fatalité a être à 30K ET faire de la merde quand on a les compétences. Ne pas voir ca, c'est se foutre de la gueule de tout ceux qui ont vraiment des problèmes.
Je ne suis pas aux USA mais en province française.
Oui beaucoup de boîtes font n'importe quoi et offrent de la merde, tu n'as clairement pas le marché des US ou de Londres, mais à l'inverse beaucoup de gens n'ont rien à faire dans le métier. Alors ça va clairement pas te tomber tout cuit dans la bec, 100K pour un techos ca n'existe plus, y'aura des compromis à faire etc.
Mais le discours "y'a pas de taf, ou que de la merde payée 30K alors que je suis super bon" j'achète pas. Simplement par ce que du taff y'en a. Que puisque les entretiens sont merdiques tu passes partout sans aucun soucis, donc qu'est ce que tu fous à 30K quitte à faire de la merde ? Et qu'avec de la patience tu peux trouver des choses intéressantes, des bons et des bons taff y'en a dans presque toutes les boites.
Après tu peux pleurer par ce que tu veux pas passer 3h en entretient, par ce que c'est trop dur d'essayer de comprendre ce qu'on attend de toi, ou penser que c'est partout pourri donc à quoi bon etc. Mais c'est un choix. L'autre c'est d'être malin et pro pour faire des trucs cools, donc augmenter ton employabilité, donc ton salaire, donc faire des trucs plus cool… Sortir du lot n'est pas très compliqué, suffit de brancher son cerveau pour comprendre ce que le business veut et bosser à côté si besoin (combien de métiers offrent cette possibilité pour évoluer ?).
Et pour ceux qui pense que c'est tout pourri ici, il suffit de prendre un billet d'avion. Se plaindre en étant software engineer je trouve ca osé, le monde nous déroule le tapis rouge. Pour je ne sais quelle raison…
Bien souvent c'est plus ou moins pour "pousser des cartons" : si tu vas jusqu'au bout du processus, c'est que tu es suffisamment soumis pour faire ce qu'on te demande sans broncher.
Tu veux dire que PbPg pousse des cartons ? En comparaison il doit être vachement intéressant ton job…
C'est gens la ne s'intéressent pas à toi, ils te mettent juste dans des boites. Quand on recrute comme ça, on n'a rien d'interessant.
Ca me parait très rationnel d'un côté de se plaindre qu'il n'y a que des taffs de merde et qu'on est très mal payé, et de l'autre côté de chier sur les boîtes qui s'investissent dans leur processus de recrutement et à traiter correctement leurs employés pour ce qu'ils offrent.
Tu trouves pas ça un peu ridicule ton message en parlant d'une boîte qui fait ses recrutement consciencieusement et professionnellement, qui te rembourse billets d'avions, hôtel et tous tes frais, qui fait des entretiens intéressants (que tu les rates où non), qui investi dans ses employés et qui paye 2-4x plus que ce que les gens se plaignent d'avoir…
Non par ce que les méthodes de recrutement que tu critiques, c'est juste grosso modo celles qu'appliquent toutes les boîtes qui sélectionnent précieusement leur employés, et qui donc leur offre un boulot sympa pour un salaire sympa pour ce qu'ils savent la valeur de leur équipe. Des mastodontes MS/Google/Amazon aux petites startup qui se créées consciencieusement leur petite équipe technique pour tout gérer à 10.
Tu veux pas passer une journée qui ne te coûte rien à échanger avec des gens et essayer de leur montrer qui tu es, comment tu te comportes et montrer ce que tu sais faire ? C'est ton choix… T'es pas capable de faire la distinction entre un marchant de viande et une boite correcte ? Dommage…
je regarde de très loin les annonces d'emploi de temps en temps et je vois des salaires (ou des fourchettes de salaires) qui sont juste lol pour le niveau de compétences
En même temps si tu regardes sur Monster ou autre c'est pas étonnant que tu n'ai que de la merde. Mais tu dois pas bien connaître le sujet si effectivement tu te bases sur les salaires que tu vois passer… Par ce que statistiquement le salaire est extrêmement rarement indiqué, et encore plus dans les entreprises qui investissent dans leur recrutement.
Perso j'ai très rarement eu ne serait ce qu'une fourchette avant d'être passé en entretient. Mais lors du screening le niveau d'attente des deux parties apparaît rapidement et permet de s'arrêter maintenant si ça colle clairement pas (un mec qui postule à 60K pour un poste lambda, une boîte qui cherche un bon à 35K, une boite qui dit chercher un bon mais à clairement le recrutement d'une SSII etc.).
D'ailleurs, tu m'attaques la dessus, il est combien le salaire proposé pour le poste de lead architecte ? dans les 35 KF plus avantage ?
Comme tu dis "lol". Aucun poste précis et surtout pas de "lead architect". Un mec qui est bon et qui est à 35K, il suffit qu'il se réveil et qu'il se bouge…
Maintenant je vis peut être dans un microcosme unique sur terre, j'en suis désolé crois le bien, mais des entretiens d'embauche j'en ai fait quelques un, ca m'a coûté des sous et parfois je me retrouvais en face de recruteurs qui n'avaient aucune idée de ce qu'il fallait pour le poste, j'en ai même qui m'ont demandé si je ne connaissait pas quelqu'un qui serait intéressé par le poste et qui pourraient convenir.
Mais pourquoi tu te déplaces alors ? Bordel on peut passer son temps à se plaindre et à blâmer les autres. Mais avant de faire un truc qui te coûte tu t'assures que ça en vaut la peine. Déjà un mec pas prêt à te payer un billet de train ou d'avion c'est un mec qui s'en fou de toi et c'est très mauvais signe. Maintenant si tu décides de le faire tu t'assures que c'est pas pour rien.
Notre métier c'est du bon sens, de la technique, et des relations…
Tu as 10000 approches possibles. De entrient code Google où t'es au white-board avec un homme-machine qui trouve tes typos plus vite qu'un compilo. A celui qui en fait veut juste voir si comment tu fais tes choix et que tu as grosso modo le niveau. D'ailleurs la plupart des boites font différents type d'interview.
Je n'arrive pas à comprendre comment vous pouvez émettre des jugements sans aucune information. J'ai passé des dizaines d'entretiens et y'en a pas un qui se ressemblait. Certains étaient mauvais, d'autres excellents; mais sans le vivre je serais incapable de prédire si c'est bon ou mauvais.
Le seul point commun aux bons était que les mecs étaient la pour trouver un mec avec lequel ils avaient envie de bosser, et non pas de piéger les gens. Ca donne des discutions intéressantes pour les deux personnes. Ceux où j'ai appris le plus de choses sont ceux ou j'ai été refusé. Et j'ai appris des choses à des gens qui m'ont refusé. L'entretient n'est pas un examen. Si tu pars avec cette idée de quelque côté que tu soit du bureau, ca me semble un mauvais départ.
Je me fou de qui a besoin du job. Ce qui m'intéresse c'est d'avoir quelqu'un qui est capable de le faire bien.
C'est bêtement offre/demande. On travail dans domaine ou il est facile de se former, d'évoluer et de prouver ce qu'on sait faire. Il suffit de se sortir les doigts. Quand je vois des mecs 6 mois en intercontrat qui préfèrent aller sur youtube plutot que de se former ou de pousser sur github, tu te dis que les gens sont juste stupides…
que la personne auquel tu fait un entretien d'embauche se comporte de la même manière que si il était hors période d'essai, t'est mal barré.
Je n'ai jamais supposé ca.
Le but c'est de deviner si le mec à des compétences techniques, un cerveau qui marche et l'attitude qui va avec. C'est l'objectif. Après personne n'a le filtre magique.
Mais note que les deux derniers critères impliquent que ne soit pas un robot en entretient et soit capable de s'interroger sur ce qu'on lui demande. On passe pas le bac…
Avec certains recruteurs, si tu commence à discuter ou à poser des questions, c'est déjà fini pour toi. T'est censé répondre aux questions et c'est tout
Bha tu te casses et tu t'en fou par ce que tu veux pas bosser chez eux.
eh, moi je suis d'accord, mais pas dans un poste à smic +10% avec évolution salariale inférieur au coût de la vie.
Y'a que toi qui est sur ton refrain en boucle mechante boite, mechant patron… Qu'est ce que tu connais de la situation ? D'ailleurs si le mec qui t'interview le fait correctement et est competent, tu penses vraiment qu'il est paye smic +10% ?
Mais encore une fois la question de la remuneration vient souvent après cette etape. Avant tu n'as aucune info. Tu peux facilement avoir des propositions avec 10-20K d'écart selon les avis apres interview. Après le refrain des ingés mal payé, franchement vu le niveau général et les contraintes je trouve que c'est plutôt bien payé quand tu compares aux autres domaines… Pour les bons, oui ca suit pas forcément.
Pour finir tu penses que les personnes qui parlent ici sont dans la case, recruteur bidon, mechante boite qui cherche des petites pour le smic ? Une question, tu as recruté combien de mecs ces dernieres annees ? Pour combien d'interview ?
Est ce que tu l'a dit au candidat ? Tout me laisse à penser que non. Et même moi en tant que candidat je pourrai pas réfléchir à ce que veut vraiment l'examinateur en ayant la tête dans le guidon, j'aurai quand même tendance à vouloir faire du code propre et maintenable, du type de ceux dont les gens sont près à me payer pour faire. Toi tu t'attendait à du code torché en 1h40 qui va aller à la poubelle avant la fin de la journée.
Bordel, on cherche pas des robots mais des devs expérimentés !
Ton job ca va être d'analyser et de comprendre. De discuter avec le business pour deviner ce qu'ils attendent. La tête dans le guidon à un entretient ? Ca va donner quoi le jour où tu troobleshoot la prod qui s'est écrasé, que tu dois concevoir des hotfix, ou que tu vas gérer la direction d'un produit ? Ce qu'on cherche c'est justement des gens qui n'ont pas la tête dans le guidon.
En entretient l'important c'est d'adapter ton approche et surtout de discuter et d'expliquer. C'est souvent vachement plus important que de pondre du code correct. Tu peux raisonnablement faire beaucoup de choix, mais c'est expliquer ta démarche, pourquoi et comment qui est importe vraiment.
Par exemple un mec te file un ordi et te dit "J'ai besoin d'une implémentation d'un ring buffer borné".
Si tu commences à coder une structure adhoc comme un bourrin, à écrire les tests, la doc, optimiser. Tu as tout faux. Tu n'as aucune idée de ce qu'attend le gars.
Commence par lui demander dans quel contexte ca va être utiliser, essaies de tater le terrain pour voir ce qu'il attend et sur quoi il va être pointilleux. En général tu fais bien chaque chose une fois, en expliquant ce que tu es en train de faire puis tu peux demander si tu dois maintenir le même niveau pour la suite ou si c'est bon.
Cette démarche est vraiment importante pour les deux côtés. Pour la boîte ca permet d'essayer de détecter les mecs bons techniquement mais où le reste ne suit pas ainsi que d'avoir des critères plus objectifs que le résultat produit en entretient. Au final la démarche du mec est vachement plus intéressante.
Pour le candidat, comme dans la vraie vie, c'est la seule facon de faire ce que l'autre attend de toi. Il faut savoir collecter les informations nécéssaires à ton travail et ne pas partir tête baissée. Tu peux avoir un mec qui va vouloir que tu codes une strucuture adhoc parfaite au tableau sans possibilité de compiler ou TU et va te dégager à la moindre typo ou bug. Et un autre qui voulait simplement que tu lui demandes et comprennent le contexte pour décider qu'au final le seul truc que tu avais besoin de faire c'est définir une interface minimaliste et faire de la composition sur une strucuture déjà existante. Il s'en fou pas mal du code ou que t'écrive des tests si tu lui demandes. Ce choix découle d'une démarche rationnelle basé sur les informations disponibles, et il est évolutif. C'est le meilleur à faire, aujourd'hui.
Dans tout les cas, si tu ne cherches pas à comprendre le but de l'exercice et les attentes de l'autre. C'est un très mauvais point pour toi. L'entretien c'est un échange. Si tu ne cherches pas à comprendre ce que l'autre attend, et à expliquer systématiquement et clairement tout tes choix, tu as tout faux.
Donc peut être que le code que tu fais et qui te semble parfaitement génial, poussé dans ses retranchements blablabla, sera considéré par un autre mec d'une autre boite comme une bouse immonde.
Non. J'ai le même constat que lui. 80% des mecs qui poussent la porte avec "senior" arrivent à leur limite quand tu leur demande de faire la différence entre overriding et overloading, la différence entre passage par valeur et par référence ou autre trivialité sans aucun piège. Bref niveau première année d'étude.
Et le code qu'ils écrivent est en adéquation. Il n'y a rien de subjectif la dedans. Ils ne devraient même pas être autorisé à toucher un clavier. Le truc le plus étonnant c'est qu'au final ils trouvent un taff… Le niveau en informatique est ridiculement bas pour un salaire relativement élevé…
Le coté un peu moins objectifs : peut être que le poste que tu proposes, le triplet (boite, lieu, salaire), n'attire que des mauvais.
Heu tu peux déjà lever le salaire du triplet, en général ça commence à se discuter après. Avant soit t'es à l'aveugle, soit la fourchette est tellement large qu'elle ne veut rien dire.
Enfin, proposer au débotté de faire du code à un mec, moi je l'aurais pas fait, car je ne te connais pas assez pour être certain que le code que tu me demandes n'est pas un code dont tu as besoin et que tu ne sais pas faire ou que tu cherches à avoir un code meilleur que le tien, sans être certain de ne pas être juste un pigeon que l'on va faire travailler gratos.
Oui bien sur, ça coûte vachement moins cher et c'est mieux de se faire chier à organiser des interviews pour faire pisser du code critique à un mec que t'as jamais vu que de payer un freelance pour une journée…
Merde j'ai du me faire exploiter par les boîtes qui demandaient grosso une bonne journée de boulot pour un mec bon, simplement pour décrocher son billet d'avion et rentrer dans le processus d'interview. Je suis sur que le code est maintenant au cœur de leur infra. C'est absolument impossible qu'ils s'en servent pour filtrer les mecs qui n'ont rien à faire là et se consacrer sur ceux qui ont quelque à offrir…
Heu et puis se tirer sur la nouille en criant objet objet objet pour un truc qui est en client/serveur déconnecté, je veux bien discuter des avantages.
Si t'es un peu moins con que ce que tu veux montrer, et que tu avances des arguments cohérents, y'a même une chance que ca joue en ta faveur… Comprendre ce que le mec veut voir et ouvrir la discussion dans cette direction.
En général on demande juste des gens techniquement compétents, qui sont capable d'analyser et de comprendre les problèmes (rare) et d'apporter des solutions adaptées à ces problèmes, ni plus ni moins (très rare).
il y a un autre truc : quel est l'utilité de faire un beau code (en doublant le temps de travail) sur une fonctionnalité qui va servir 4 fois par an à 3 personnes, sur une machine qui iddle 99.99% de son temps avec une pointe à 2% processeur ?
Du beau code c'est du code qui fait le job en ayant la complexité minimale correspondant aux attentes business… C'est pas du code fait pour se palucher.
[^] # Re: Rien de nouveau à l'horizon
Posté par ckyl . En réponse au journal Google Robotics. Évalué à 2.
La théorie du partage est bien belle mais il me semble que le problème c'est que si elle s'applique facilement aux emplois non-qualifiés ca me semble beaucoup plus douteux pour des emplois qualifiés.
Distribuer un travail pénible, répétitif avec un coût de formation faible est une bonne idée. Sauf que c'est justement ce type de métier qui tant à disparaitre.
Un travail qualifié se distribue beaucoup plus difficilement:
Bref il reste la solution de travailler très peu de temps dans sa vie puis de faire autre chose. Mais la on retombe sur le problème du financement des innactifs. Ou alors que ceux qui veulent travailler (les emplois devenant de plus en plus qualifié ca exclue de plus en plus de monde) acceptent de financer les autres. Bref la vision "il suffit de travailler moins" me semble malheureusement un peu simpliste.
[^] # Re: Xiti pour madame Michu
Posté par ckyl . En réponse au journal Les impôts en ligne et la fuite de données. Évalué à 5.
Pourquoi tu parles forcément de compétences ? Tu peux tout construire c'est vrai.
Après tu as ton coeur de métier, des choix, des priorités, des deadlines et tu composes en fonction. Il y a des choses ou clairement tu ne veux pas mettre les pieds dedans. Construire du soft ca prend longtemps, tu choisis comment l'utiliser.
Après on peut discuter de ce choix particulier sur deux axes:
Pour avoir bossé dans le domaine de l'analytics et du profiling, la phrase "exploitable à fins de statistiques" peut être à la fois tout à fait juste ou totallement naïve. Et vu qu'on ne connait pas les besoins fonctionels difficile d'avoir un avis sur le deuxième axe…
[^] # Re: Utilisateur lambda...
Posté par ckyl . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 5.
Je ne prends personne de haut. Je mets en balance la vision de "ca marche jamais".
Apres si tu combines ne pas connaitre grand chose, utiliser une distrib qui ne vise clairement pas le grand publique, à date fixe, qui bouge à toute vitesse, et faire une upgrade le lendemain alors tu maximises tes chances d'emmerdes. Faut juste être rationnel des fois.
Pour la QA ca ne demande aucune competence. Juste de faire ce que tu as fait et de rapporter ton probleme avant la release. Si personne ne le fait bin ca sort buggé. Il n'y a pas de magie.
Donc oui des problèmes il peut en avoir ca arrive. Comme pour tout,attendre une ou deux semaines peut éviter pas mal d'ennuis. Maintenant si tu as systematiquement des problèmes ca reste très très louche.
[^] # Re: Utilisateur lambda...
Posté par ckyl . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 2.
Si tout n'est pas rose sur ce point chez Fedora, tu devrais tout de même te poser quelques questions je pense.
Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.
Il suffit de deux choses: lire la doc correctement et éventuellement ne pas upgrader 2h après l'annonce histoire que les éventuels bugs restant soient trouvés. Quand tu utilises Fedora tu es prévenu du deal à l'avance.
Et si tu penses que la QA c'est de la merde, tu les as testé les beta ?
[^] # Re: Val(hal)a
Posté par ckyl . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 10. Dernière modification le 15 décembre 2013 à 20:02.
Merci pour le lien. Malheureusement l'explication est clairement NIH ou CADT:
Clair que ca vaut le coup de tout jeter par ce qu'on aime pas n'être qu'une extension. Si c'était pas possible techniquement, il manque l'argumentation.
Il vaut mieux des features en trop ou aucune ? C'est sur aussi qu'en réécrivant tout les deux ans ont à pas de technical debt, mais on a un produit de merde jamais fini aussi.
Après 3 ans super génial ! Sauf que ça fait rien. Ça sait même pas afficher tous les messages d'une mailbox, choisir la langue du dictionnaire, faire un filtre, un raccourci clavier.
Bref les enfants ne faites pas ça…
[^] # Re: Val(hal)a
Posté par ckyl . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 9. Dernière modification le 15 décembre 2013 à 13:40.
Vu que certaines parties du bureau Linux semblent condamnées à rester au stade du CADT et que geary fait parti de ce cirque est ce vraiment important ?
Il faudrait avant dépasser l'étape du proof-of-concept qui ne fait rien tout en réussissant à la fois à avoir l'une de ses trois fonctionnalités qui dépend de gmail (dans ce cas pourquoi l'utiliser ?), et à crasher en permanence. Mais d'ici là une nouvelle réécriture de 0 d'un client mail sans aucune fonctionnalité aura eu lieu…
[^] # Re: Pourquoi légiférer ?
Posté par ckyl . En réponse à la dépêche Surveillance de l'internet : la polémique enfle. Évalué à 2.
Ça dépend de la rapidité des pompiers à arriver et évacuer. En occurrence 31 jours, ca commence à faire long…
[^] # Re: Pacman
Posté par ckyl . En réponse au journal Frugalware, une distribution pas comme les autres.. Évalué à 2.
Tu voulais dire un bel ensemble de paquets vite fait mal fait, créés par Jean-Kevin puis maintenu 45 secondes par toto avant d'être laissé à l'abandon dans ce gigantesque tas de caca ?
Non sérieux, j'arriverai jamais à expliquer qu'on cite AUR comme un avantage et qu'on puisse l'utiliser. C'est le skyblog des dépôts ce truc…
[^] # Re: ça bouge chez BSD
Posté par ckyl . En réponse à la dépêche DragonFly BSD 3.6. Évalué à 6.
C'est clair que quand tu pars de loin tu as plus de chemin à parcourir ;)
[^] # Re: Perf
Posté par ckyl . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 4.
Si je pose la question c'est pas pour rien.
Le fait que les differents modules puissent etre lent et que certains doivent être desactivés selon l'environement c'est une évidence (j'ai "contribué" le module le plus lent de liquidprompt).
Par contre, contrairement à ce que tu dis, forker un python à chaque PS1 ca à un coup non négligable sur du vieux matos. Essaie sur le premier eeepc par exemple, tu vas voir la réactivités du truc. La question c'est à partir de quel hardware ca ne gène plus ton flot de travail. Sachant que si avec une approche sheel tu es obligé de virer tout les modules intéressant sur une petite config, autant pas se faire chier à utiliser une techno compliquée vu que de toute facon tu gagnes rien…
On peut aussi imaginer une approche hybrique avec un processus résidant et faire de l'IPC pour éviter le cout de lancement de l'interpreteur.
Liquidprompt c'est cool, mais quand tu compares le code à celui d'un powershell-line tu te dis qu'il y a un monde. C'est pas très grave vu que c'est petit et que ca bouge pas trop. Mais techniquement ca m'intéresse si quelqu'un y a déjà réfléchi.
# Perf
Posté par ckyl . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 6.
Avez vous regardé un peu l'écart de perf entre l'approche de liquiprompt de tout faire en shell et les choix fait par d'autres projets similaires de lancer un script python ou autre pour générer le PS1 ?
Pour avoir lu le code des deux, l'approche shell est beaucoup plus complexe et bordelique, mais sur des petites config je me demande la différence de confort à l'usage. Sur une machine actuelle lancer du python ne pose aucun soucis. Donc tout se joue sur les vieux trucs pourris.
# pv
Posté par ckyl . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 3.
pv n'aurait-il pas fait l'affaire ? C'est un bon couteau suisse pour ce genre de chose.
L'approche est differente puisqu'il faut specifier ce que tu veux monitorer alors que toi tu pars a la peche aux infos, mais ca merite au moins d'etre connu.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Tu sais que le pré-condition n'est pas requise ?
Je ne vois pas ce que le salaire change. Si poster ici c'est de la merde, bha c'est de la merde gros salaire ou smic…
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 5.
Ca a existé dans certaines boîtes. Des techos salariés a 80-120K j'en ai croisé. Par contre c'est pas des embauches récentes et maintenant tu peux bien te grater.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Oui bien sur, il faut lire le tu comme impersonnel.
Ta vision du marché Francais me semble assez bonne. C'est à dire pas folichon mais sans tomber dans la caricature que certains veulent en faire. Y'a du mauvais, beaucoup de médiocre et des trucs corrects. Ton 60K semble réaliste (je connais mal le marché parisien mais les salaires semble pas très loin d'en province…). Bref tu peux faire des trucs intéressant, sans contrainte forte, en étant dans le 90 percentile des salaires sans être un tueur. Ca tire vachement moins la larme que la vision smic, larbin, pousser des cartons, entretien difficiles pour rien…
Pour les entretiens en France c'est généralement beaucoup plus faible que ce que font les boîtes anglosaxonnes, ce qui fait que c'est plus facile de passer. La contrepartie c'est qu'il faut bien vérifier où on met les pieds.
Mais encore une fois si quand on pense que son travail vaut 100..150K au coût de vie max. Il suffit de se déplacer, il n'y a pas de fatalité a être à 30K ET faire de la merde quand on a les compétences. Ne pas voir ca, c'est se foutre de la gueule de tout ceux qui ont vraiment des problèmes.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 9.
Je ne suis pas aux USA mais en province française.
Oui beaucoup de boîtes font n'importe quoi et offrent de la merde, tu n'as clairement pas le marché des US ou de Londres, mais à l'inverse beaucoup de gens n'ont rien à faire dans le métier. Alors ça va clairement pas te tomber tout cuit dans la bec, 100K pour un techos ca n'existe plus, y'aura des compromis à faire etc.
Mais le discours "y'a pas de taf, ou que de la merde payée 30K alors que je suis super bon" j'achète pas. Simplement par ce que du taff y'en a. Que puisque les entretiens sont merdiques tu passes partout sans aucun soucis, donc qu'est ce que tu fous à 30K quitte à faire de la merde ? Et qu'avec de la patience tu peux trouver des choses intéressantes, des bons et des bons taff y'en a dans presque toutes les boites.
Après tu peux pleurer par ce que tu veux pas passer 3h en entretient, par ce que c'est trop dur d'essayer de comprendre ce qu'on attend de toi, ou penser que c'est partout pourri donc à quoi bon etc. Mais c'est un choix. L'autre c'est d'être malin et pro pour faire des trucs cools, donc augmenter ton employabilité, donc ton salaire, donc faire des trucs plus cool… Sortir du lot n'est pas très compliqué, suffit de brancher son cerveau pour comprendre ce que le business veut et bosser à côté si besoin (combien de métiers offrent cette possibilité pour évoluer ?).
Et pour ceux qui pense que c'est tout pourri ici, il suffit de prendre un billet d'avion. Se plaindre en étant software engineer je trouve ca osé, le monde nous déroule le tapis rouge. Pour je ne sais quelle raison…
[^] # Re: Choisis le plus sympa.
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Tu veux dire que PbPg pousse des cartons ? En comparaison il doit être vachement intéressant ton job…
[^] # Re: Choisis le plus sympa.
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 5.
Ca me parait très rationnel d'un côté de se plaindre qu'il n'y a que des taffs de merde et qu'on est très mal payé, et de l'autre côté de chier sur les boîtes qui s'investissent dans leur processus de recrutement et à traiter correctement leurs employés pour ce qu'ils offrent.
Tu trouves pas ça un peu ridicule ton message en parlant d'une boîte qui fait ses recrutement consciencieusement et professionnellement, qui te rembourse billets d'avions, hôtel et tous tes frais, qui fait des entretiens intéressants (que tu les rates où non), qui investi dans ses employés et qui paye 2-4x plus que ce que les gens se plaignent d'avoir…
Non par ce que les méthodes de recrutement que tu critiques, c'est juste grosso modo celles qu'appliquent toutes les boîtes qui sélectionnent précieusement leur employés, et qui donc leur offre un boulot sympa pour un salaire sympa pour ce qu'ils savent la valeur de leur équipe. Des mastodontes MS/Google/Amazon aux petites startup qui se créées consciencieusement leur petite équipe technique pour tout gérer à 10.
Tu veux pas passer une journée qui ne te coûte rien à échanger avec des gens et essayer de leur montrer qui tu es, comment tu te comportes et montrer ce que tu sais faire ? C'est ton choix… T'es pas capable de faire la distinction entre un marchant de viande et une boite correcte ? Dommage…
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
En même temps si tu regardes sur Monster ou autre c'est pas étonnant que tu n'ai que de la merde. Mais tu dois pas bien connaître le sujet si effectivement tu te bases sur les salaires que tu vois passer… Par ce que statistiquement le salaire est extrêmement rarement indiqué, et encore plus dans les entreprises qui investissent dans leur recrutement.
Perso j'ai très rarement eu ne serait ce qu'une fourchette avant d'être passé en entretient. Mais lors du screening le niveau d'attente des deux parties apparaît rapidement et permet de s'arrêter maintenant si ça colle clairement pas (un mec qui postule à 60K pour un poste lambda, une boîte qui cherche un bon à 35K, une boite qui dit chercher un bon mais à clairement le recrutement d'une SSII etc.).
Comme tu dis "lol". Aucun poste précis et surtout pas de "lead architect". Un mec qui est bon et qui est à 35K, il suffit qu'il se réveil et qu'il se bouge…
Mais pourquoi tu te déplaces alors ? Bordel on peut passer son temps à se plaindre et à blâmer les autres. Mais avant de faire un truc qui te coûte tu t'assures que ça en vaut la peine. Déjà un mec pas prêt à te payer un billet de train ou d'avion c'est un mec qui s'en fou de toi et c'est très mauvais signe. Maintenant si tu décides de le faire tu t'assures que c'est pas pour rien.
Notre métier c'est du bon sens, de la technique, et des relations…
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 6.
Qui a dit que c'était le cas ?
Tu as 10000 approches possibles. De entrient code Google où t'es au white-board avec un homme-machine qui trouve tes typos plus vite qu'un compilo. A celui qui en fait veut juste voir si comment tu fais tes choix et que tu as grosso modo le niveau. D'ailleurs la plupart des boites font différents type d'interview.
Je n'arrive pas à comprendre comment vous pouvez émettre des jugements sans aucune information. J'ai passé des dizaines d'entretiens et y'en a pas un qui se ressemblait. Certains étaient mauvais, d'autres excellents; mais sans le vivre je serais incapable de prédire si c'est bon ou mauvais.
Le seul point commun aux bons était que les mecs étaient la pour trouver un mec avec lequel ils avaient envie de bosser, et non pas de piéger les gens. Ca donne des discutions intéressantes pour les deux personnes. Ceux où j'ai appris le plus de choses sont ceux ou j'ai été refusé. Et j'ai appris des choses à des gens qui m'ont refusé. L'entretient n'est pas un examen. Si tu pars avec cette idée de quelque côté que tu soit du bureau, ca me semble un mauvais départ.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Je me fou de qui a besoin du job. Ce qui m'intéresse c'est d'avoir quelqu'un qui est capable de le faire bien.
C'est bêtement offre/demande. On travail dans domaine ou il est facile de se former, d'évoluer et de prouver ce qu'on sait faire. Il suffit de se sortir les doigts. Quand je vois des mecs 6 mois en intercontrat qui préfèrent aller sur youtube plutot que de se former ou de pousser sur github, tu te dis que les gens sont juste stupides…
Je n'ai jamais supposé ca.
Le but c'est de deviner si le mec à des compétences techniques, un cerveau qui marche et l'attitude qui va avec. C'est l'objectif. Après personne n'a le filtre magique.
Mais note que les deux derniers critères impliquent que ne soit pas un robot en entretient et soit capable de s'interroger sur ce qu'on lui demande. On passe pas le bac…
Bha tu te casses et tu t'en fou par ce que tu veux pas bosser chez eux.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 4.
Y'a que toi qui est sur ton refrain en boucle mechante boite, mechant patron… Qu'est ce que tu connais de la situation ? D'ailleurs si le mec qui t'interview le fait correctement et est competent, tu penses vraiment qu'il est paye smic +10% ?
Mais encore une fois la question de la remuneration vient souvent après cette etape. Avant tu n'as aucune info. Tu peux facilement avoir des propositions avec 10-20K d'écart selon les avis apres interview. Après le refrain des ingés mal payé, franchement vu le niveau général et les contraintes je trouve que c'est plutôt bien payé quand tu compares aux autres domaines… Pour les bons, oui ca suit pas forcément.
Pour finir tu penses que les personnes qui parlent ici sont dans la case, recruteur bidon, mechante boite qui cherche des petites pour le smic ? Une question, tu as recruté combien de mecs ces dernieres annees ? Pour combien d'interview ?
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 9.
Bordel, on cherche pas des robots mais des devs expérimentés !
Ton job ca va être d'analyser et de comprendre. De discuter avec le business pour deviner ce qu'ils attendent. La tête dans le guidon à un entretient ? Ca va donner quoi le jour où tu troobleshoot la prod qui s'est écrasé, que tu dois concevoir des hotfix, ou que tu vas gérer la direction d'un produit ? Ce qu'on cherche c'est justement des gens qui n'ont pas la tête dans le guidon.
En entretient l'important c'est d'adapter ton approche et surtout de discuter et d'expliquer. C'est souvent vachement plus important que de pondre du code correct. Tu peux raisonnablement faire beaucoup de choix, mais c'est expliquer ta démarche, pourquoi et comment qui est importe vraiment.
Par exemple un mec te file un ordi et te dit "J'ai besoin d'une implémentation d'un ring buffer borné".
Si tu commences à coder une structure adhoc comme un bourrin, à écrire les tests, la doc, optimiser. Tu as tout faux. Tu n'as aucune idée de ce qu'attend le gars.
Commence par lui demander dans quel contexte ca va être utiliser, essaies de tater le terrain pour voir ce qu'il attend et sur quoi il va être pointilleux. En général tu fais bien chaque chose une fois, en expliquant ce que tu es en train de faire puis tu peux demander si tu dois maintenir le même niveau pour la suite ou si c'est bon.
Cette démarche est vraiment importante pour les deux côtés. Pour la boîte ca permet d'essayer de détecter les mecs bons techniquement mais où le reste ne suit pas ainsi que d'avoir des critères plus objectifs que le résultat produit en entretient. Au final la démarche du mec est vachement plus intéressante.
Pour le candidat, comme dans la vraie vie, c'est la seule facon de faire ce que l'autre attend de toi. Il faut savoir collecter les informations nécéssaires à ton travail et ne pas partir tête baissée. Tu peux avoir un mec qui va vouloir que tu codes une strucuture adhoc parfaite au tableau sans possibilité de compiler ou TU et va te dégager à la moindre typo ou bug. Et un autre qui voulait simplement que tu lui demandes et comprennent le contexte pour décider qu'au final le seul truc que tu avais besoin de faire c'est définir une interface minimaliste et faire de la composition sur une strucuture déjà existante. Il s'en fou pas mal du code ou que t'écrive des tests si tu lui demandes. Ce choix découle d'une démarche rationnelle basé sur les informations disponibles, et il est évolutif. C'est le meilleur à faire, aujourd'hui.
Dans tout les cas, si tu ne cherches pas à comprendre le but de l'exercice et les attentes de l'autre. C'est un très mauvais point pour toi. L'entretien c'est un échange. Si tu ne cherches pas à comprendre ce que l'autre attend, et à expliquer systématiquement et clairement tout tes choix, tu as tout faux.
[^] # Re: qui sait
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 8. Dernière modification le 20 novembre 2013 à 22:36.
Non. J'ai le même constat que lui. 80% des mecs qui poussent la porte avec "senior" arrivent à leur limite quand tu leur demande de faire la différence entre overriding et overloading, la différence entre passage par valeur et par référence ou autre trivialité sans aucun piège. Bref niveau première année d'étude.
Et le code qu'ils écrivent est en adéquation. Il n'y a rien de subjectif la dedans. Ils ne devraient même pas être autorisé à toucher un clavier. Le truc le plus étonnant c'est qu'au final ils trouvent un taff… Le niveau en informatique est ridiculement bas pour un salaire relativement élevé…
Heu tu peux déjà lever le salaire du triplet, en général ça commence à se discuter après. Avant soit t'es à l'aveugle, soit la fourchette est tellement large qu'elle ne veut rien dire.
Oui bien sur, ça coûte vachement moins cher et c'est mieux de se faire chier à organiser des interviews pour faire pisser du code critique à un mec que t'as jamais vu que de payer un freelance pour une journée…
Merde j'ai du me faire exploiter par les boîtes qui demandaient grosso une bonne journée de boulot pour un mec bon, simplement pour décrocher son billet d'avion et rentrer dans le processus d'interview. Je suis sur que le code est maintenant au cœur de leur infra. C'est absolument impossible qu'ils s'en servent pour filtrer les mecs qui n'ont rien à faire là et se consacrer sur ceux qui ont quelque à offrir…
Si t'es un peu moins con que ce que tu veux montrer, et que tu avances des arguments cohérents, y'a même une chance que ca joue en ta faveur… Comprendre ce que le mec veut voir et ouvrir la discussion dans cette direction.
En général on demande juste des gens techniquement compétents, qui sont capable d'analyser et de comprendre les problèmes (rare) et d'apporter des solutions adaptées à ces problèmes, ni plus ni moins (très rare).
[^] # Re: FizzBuzz
Posté par ckyl . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 9.
Du beau code c'est du code qui fait le job en ayant la complexité minimale correspondant aux attentes business… C'est pas du code fait pour se palucher.