Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.
Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
le principe est simple : "un module = une responsabilité". Et inversement.
Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.
C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))
(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Technique n°2 — se limiter strictement au cahier des charges
Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Il ne faut surtout pas écrire de script de setup. A moins de vraiment savoir ce qu'il faut faire (et encore) c'est probablement pas quelques heures et probablement un script sur lequel il faudra revenir.
Maintenant sur le besoin je suis parfaitement d'accord. Mais il ne faut surtout pas réinventer la roue. Utiliser ansible, chef, puppet ou, celui que je préfère, terraform. Du Terraform, une ou plusieurs machines sous CoreOS, des containers et ça en devient juste super agréable tout ça pour un coût limité, une très bonne répétabilité et un démarrage rapide.
Si certains veulent essayer voici un exemple qui montre par exemple comment faire tourner facilement un ElasticSearch en container sur un CoreOS via Terraform. C'est un exemple comme un autre mais je trouve qu'il montre plutôt bien l'intérêt de ces solutions.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
De manière plus générale, tu essaie de vendre l'idée que la qualité c'est simple, que ça ne prend pas de temps, etc et je ne te rejoins pas du tout là dessus.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
Faire de la qualité c'est compliqué, sinon tout le monde le ferais. Non seulement c'est compliqué, mais en plus c'est long à mettre en place.
On est d'accord :)
C'est un mensonge de commercial d'affirmer qu'on peut faire de la qualité en un minimum de temps à coût 0.
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je ne trouve pas du tout évident que la méthode 3 soit la plus coûteuse ou la plus lente. Partir sur un projet sans architecture et sans conception (en supposant que le projet soit assez simple pour le permettre) maximise les coûts très rapidement à cause du nombre de choses à faire et refaire, du nombre de bugs ou des mauvaises performances.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
de valider ou d'invalider des hypothèses,
dans le cas où on commercialise, de rentrer de l'argent et prendre des parts de marché.
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Par exemple le module pour integrer piwik est a plus de trente balle
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
(alors que c'est un truc ultra simple et que je parie que leur sonde n'est meme pas compatible cross canal (lan, wan, tor)).
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
En plus des modules proprio, voila quoi… > (Je prefere le systeme de bounty*1 d'autres cms)
*1 un site ou tu fais une annonce genre "j'ai besoin de telle fonctionnalité je met 50, 100, 200 euro" et le premier qui la code empoche le bounty et la fonctionnalité reste libre
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
certains marchands ont des configurateurs en ligne pour associé Carte mere/proc/ram qui sont le plus difficile à gerer.
ensuite SSD, carte video, carte son, ce sont des accessoires à mettre dans la machine, pour la compatiblité video/son, il faut fouiller sur le net.
Demande au support commercial materiel.net. ils taident à faire des choix, par mail, et sont sérieux et compétents. J'achète quasi tout mon matos pro chez eux
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le principe de la politique n'est-il pas d'organiser la société ? Peut-on parler d'organisation si le pouvoir est entre les mains de court-termistes ? Dans ces conditions, si le système actuel n'est pas en mesure de favoriser le pouvoir des gens qui "réfléchissent" ou qui ont une vision long terme, c'est peut-être que le système politique est inadapté, non ?
Personnellement, plus le temps passe et plus je me dis que la démocratie n'est pas adaptée car basé sur la séduction (des électeurs) donc ça finit tôt ou tard de manière court-termiste.
Pour faire un parallèle avec le monde économique, c'est un peu comme la gestion d'une entreprise cotée en bourse ou une entreprise familiale. Les investisseurs (les électeurs) veulent des résultats à court terme, là où une direction "plus forte" peut faire des sacrifices à court terme pour un meilleur rendu à long terme.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Si les "non populistes" n'ont pas compris les techniques qui fonctionnent, il serait temps qu'ils les comprennent. Si ils les ont comprises, pourquoi ne les appliquent-ils pas ?
(merci de ne pas répondre "parce que ça ne se fait pas" ou "parce que ça n'est pas éthique" : ils sont exceptionnels ceux qui ne font rien qui ne soit pas éthique/moral/légal/raisonnable… et il ne sont quasiment jamais dans la course à la présidentielle)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Et pour répondre à ta question :
Un système de "validité" de l'annonce devrait être mis en place, par envoi de mail à la personne qui à publiée l'annonce.
Chaque semaine par exemple, si pas de réponse … re mail au bout de 4 jours puis 2 jours puis fin de l'annonce
A condition que l'interface soit sécurisée et ergonomique et que cela ne dure que quelques secondes.
En fait on ne publie pas directement d'annonces sur pyjobs : c'est un agrégateur, donc on ne peut pas contacter l'annonceur
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suite au commentaire de Pol'Ux ci-dessus, question à ceux d'entre vous qui cherchent un taff (de manière passive ou active) :
vous préférez louper des opportunités ou avoir du bruit dans les annonces que vous identifiez ?
à partir de quel "vieillesse" vous considérez qu'une annonce est "morte". Exemple : une annonce qui a 1 an n'est très probablement plus pertinente, une annonce qui a une semaine est probablement encore pertinente… mais où situez-vous le seuil ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le sujet que tu soulèves c'est le fait d'accepter des faux-positifs ou d'accepter des faux-négatifs. Intégrer Pôle Emploi ou de ne pas l'intégrer, c'est exactement la même question.
Par exemple, si tu cherches sur Grenoble et jusqu'à 25km aujourd'hui, tu as une annonce pour un développeur ERP Python (boite : Objectif PI) qui est une vraie annonce (et que tu trouves a priori seulement sur Pole Emploi et sur Developpez.com)
Est-ce qu'on veut louper ce type d'annonce ? Je dirais que non.
Est-ce qu'il n'y a pas moyen d'améliorer les choses par rapport au cas que tu remontes ? C'est certain qu'il y a matière. Par exemple en proposant une fonctionnalité de signalement d'une annonce erronée / invalide.
Je pense qu'un dév qui cherche du boulot préfère avoir du bruit que de louper une bonne opportunité (en tout cas c'est comme ça que je réagissais à l'époque où je cherchais) ; je peux me tromper, ça ne me me pose pas de problème :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je te rejoins sur le fait que j’ai des collègues qui ne mettront pas de commentaire à cause de l’élitisme… c’est dommage, il vaut mieux se tromper et apprendre quelque chose que de se taire.
La question posée est de savoir comment avoir plus de contributions, pas de savoir si les gens ont raison de se réagir comme ils réagissent :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Un collaborateur que j'ai embauché en janvier dernier a écrit un journal sur son simulateur de fourmies qui a reçu un accueil vraiment très bon. Pourquoi il l'a écrit ? Parce que je l'ai "tanné" ; il doutait de la bonne perception par le public et peur du "linchage". Le pb c'est que :
si tu écrits un truc qui a bonne presse, tu veux que ton identité numérique y soit associée
si ton article n'a pas bonne presse tu aimes autant ne plus y être associé.
Dans le doute, tu t'abstiens.
Est-ce qu'il ne faudrait pas un mécanisme pour pouvoir écrire en anonyme mais se le réattribuer en cas de succès ? Genre une sorte de double identité et qu'on puisse basculer un article / un journal de l'une à l'autre.
Un des freins, également c'est l’âpreté des discussions dans les commentaires. C'est un frein également (après, j'avoue que je ne sais pas trop comment on pourrait faire pour "limiter" ça)
Un aspect plus global, à mon avis, c'est que le contenu de LinuxFR n'est plus tant "linuxfr" que "logicielslibresfr" voire "informatiquelibrefr" (dont musique, électronique, openhardware, business, etc). Peut-être que l'identité de LinuxFR devrait évoluer ?
Par ailleurs je pense comme dit plus haut que des news courtes devraient faire leur apparition. Dans un journal comme le dauphiné libéré (exemple pris parce que je suis de ce coin là du monde;), il y a des articles détaillés, des articles intermédiaires et des faits divers. On torche le truc, ceux qui aiment lisent, ceux qui n'aiment pas ne lisent pas.
Chacun devrait pouvoir proposer des dépêches longues ou courtes (une dépêche n'étant pas un journal qui est plutôt un "vis ma vie").
Ces idées n'engagent que moi et celles/ceux qui y croient :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Mais ton code est partiel, avec des renommages de variables et/ou troncage de code, et le symptôme que tu remontes "pb le fichier n'est pas copié" est un symptome genre "et ça marche pas". Autant dire que ça manque d'infos pour nous aider à t'aider à résoudre ton problème.
Si tu veux donner un peu plus de matériel et/ou de précision, ça pourrait bien être utile.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Parce que pour tous les professionnels de terrain, c'est une caractéristique qui est un put*** d'argument. Tu as un téléphone esthétique et en même temps étanche. Je ne parle pas de révolution, mais de pragmatisme et d'adaptation au marché, et ça c'est un sacré avantage.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
On l'oublie assez souvent, mais l'objectif d'une annonce c'est pas de "recruter un gars". Ca c'est l'objectif global. Mais le rôle de l'annonce, c'est de recevoir des CVs intéressants, et si possible le moins de CV inadaptés (ou avec un critère de filtrage facile pour les écarter rapidement).
De la même manière, quand on rédige un CV, il ne faut pas avoir en tête "de présenter le meilleur CV", mais de présenter "le CV qui va donner au recruteur envie de rencontrer le candidat".
C'est à l'entretien qu'on va vraiment recruter quelqu'un, mais avant ça, c'est de la drague.
Note : ça ne veut pas dire qu'il faut mentir ou tout enjoliver, mais il faut savoir à qui on s'adresse, ce qui l'intéresse et donc communiquer sur ces éléments.
Par exemple, si tu postes une annonce sur LinuxFR, il faut que tu parles de logiciels libres, de causes sociales ou de haute-technicité. Parce que c'est ce qu'attend (en majorité) le public ici. Si tu mets une annonce sur le site de l'APEC et que tu veux un mec ou une nana plutôt "haut de panier", bah il va falloir que ton critère "salaire" soit bien positionné parce que tu es en concurrence avec des boîtes qui ont de la maille (et les bons candidats le savent).
Par exemple quand je recrute je me positionne pas sur l'aspect financier parce que je suis sur Grenoble et que je ne peux pas concurrencer les boîtes qui vont recruter ceux qui valent le plus cher (je ne tire pas les salaires en bas non plus, mais c'est un argument ni pour ni contre, je suis "dans le ventre mou"). Par contre on fait du logiciel libre et ça toutes les boîtes ne le proposent pas. Et on bosse dans une ambiance décontractée parce que j'ai jamais été en mode "on se prend trop au sérieux" (ça veut pas dire qu'on glande, mais on peut faire du très bon boulot sans se prendre pour les meilleurs de la terre et tout en ayant des moments détendus à raconter de la m…)
Il faut savoir ce qui intéresse tes candidats potentiels. Dans ton annonce tu parles de ce que tu veux toi, mais tu oublies qu'en face, les candidats ont des envies et des aspirations. (et tu n'as pas les moyens de les attirer juste par la rémunération).
Pour ton cas particulier, tu as besoin d'un dév compétent sur un projet sur 4 ans. On s'en fout qu'il connaisse Angular et CakePHP, ce qu'il faut c'est qu'il connaisse le principe des applis client/serveur en mode "single page", qu'il ait déjà bossé sur des API Rest, qu'il ait la tête bien faite pour comprendre les problèmes, qu'il ait fait du PHP et du JS pour pas être tout à fait à la rue au tout début, et qu'il ait envie de venir bosser dans ta petite boîte à la campagne.
Recrute un développeur web curieux et souhaitant s'investir et prendre des responsabilités (et des parts?) dans une petite structure en plein développement. En discutant avec tes candidats tu verras ceux qui savent s'adapter (suffit de les mettre en situation et de les observer), ceux qui essaient de fuir la question parce qu'ils sont pris en défaut. Tu leur demande ce qu'ils attendent en candidatant pour un poste situé "à la campagne" (question ouverte, tu verras ce qu'ils te répondent), tu leur demandes comment ils se maintiennent à jour au niveau technologique.
5 ans d'expérience, c'est difficile à recruter car les candidats commencent à bien gérer les entretiens et à savoir ce qu'il faut répondre (et donc parfois ils vont juste répondre ce que tu attends au lieu de répondre ce qu'ils pensent). C'est pour ça qu'il faut un maximum de sujets ouverts pour échanger librement (et ça vaut pour toi aussi, parce que les mecs expérimentés qui en ont dans la cervelle vont aussi te jauger - surtout si tu es dans un premier temps leur seul collaborateur, et leur supérieur et patron).
p.s : désolé si je parle de "mecs" et "nanas" (et parfois juste de "mecs"), j'ai écrit à haute voix ;)
p.p.s : bon courage pour le passage d'indépendant à responsable d'équipe. Ca te change beaucoup la vie :)
p.p.p.s : je ne suis pas "consultant en recrutement" mais je sais plutôt bien recruter des profils techniques (et en particulier déceler des profils "sur qui miser") ; je peux t'aider si tu veux.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 10.
Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 4.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 6.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
On est d'accord :)
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 8.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Cette explication est assez simpliste, mais c'est la réalité (alors bien sûr l'enjeu est aussi en général de lever des fonds mais à fonds levés égaux, celui qui prendra le premier la place sur un marché sera souvent celui qui survit. Je t'invite à lire l'article suivant : http://www.newyorker.com/tech/elements/in-silicon-valley-now-its-almost-always-winner-takes-all
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: En bas ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Empêcher Libreoffice de masquer/afficher les barres d'outil de manière intempestive. Évalué à 2.
Je voudrais éviter une config spécifique à cette application - sur toutes les autres les barres d'outils sont en haut.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas anormal
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Que pensez-vous du comportement de Prestashop?. Évalué à 2.
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: lolix-v2
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lolix down ?. Évalué à 8.
Dans une phase de creux de mon activité, j'avais contacté Rodolphe pour proposer de contribuer à prix coûtant. Je n'avais eu aucune réponse.
Ca m'avait du coup "un peu" blasé d'avoir contribué financièrement…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Autre "avantage" que j'ai oublié de mentionner...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Stage de fin d'étude en pré-embauche - développeur backend python/go sur Grenoble. Évalué à 2.
On est abonné aux magazines des éditions Diamond : Linux Magazine France, Linux Pratique, Misc et Hackable.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: des pistes
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message De nomade à sédentaire, je cherche un PC à tout faire!. Évalué à 2.
Demande au support commercial materiel.net. ils taident à faire des choix, par mail, et sont sérieux et compétents. J'achète quasi tout mon matos pro chez eux
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# celery + rabbitmq
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Réagir à des données expirées (date) en DB. Évalué à 5.
A la creation de ton événement, tu ajoutes une tache dans rabbitmq qui devra s'exécuter à la date d'expiration.
Ca marche bien, c'est fait pour ça, et celery/rabbitmq s'intègre très bien dans django.
J'ai mis en place ces technos pour envoi/expiration automatique de notifications.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La vraie victoire...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Élections américaines. Évalué à 2.
Le principe de la politique n'est-il pas d'organiser la société ? Peut-on parler d'organisation si le pouvoir est entre les mains de court-termistes ? Dans ces conditions, si le système actuel n'est pas en mesure de favoriser le pouvoir des gens qui "réfléchissent" ou qui ont une vision long terme, c'est peut-être que le système politique est inadapté, non ?
Personnellement, plus le temps passe et plus je me dis que la démocratie n'est pas adaptée car basé sur la séduction (des électeurs) donc ça finit tôt ou tard de manière court-termiste.
Pour faire un parallèle avec le monde économique, c'est un peu comme la gestion d'une entreprise cotée en bourse ou une entreprise familiale. Les investisseurs (les électeurs) veulent des résultats à court terme, là où une direction "plus forte" peut faire des sacrifices à court terme pour un meilleur rendu à long terme.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La vraie victoire...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Élections américaines. Évalué à 2.
Si les "non populistes" n'ont pas compris les techniques qui fonctionnent, il serait temps qu'ils les comprennent. Si ils les ont comprises, pourquoi ne les appliquent-ils pas ?
(merci de ne pas répondre "parce que ça ne se fait pas" ou "parce que ça n'est pas éthique" : ils sont exceptionnels ceux qui ne font rien qui ne soit pas éthique/moral/légal/raisonnable… et il ne sont quasiment jamais dans la course à la présidentielle)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Pyjobs intègre un annuaire de sociétés (il faut le remplir… en mode collaboratif en partie) ; effectivement faire le lien est une bonne idée :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 3.
En fait on ne publie pas directement d'annonces sur pyjobs : c'est un agrégateur, donc on ne peut pas contacter l'annonceur
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Suite au commentaire de Pol'Ux ci-dessus, question à ceux d'entre vous qui cherchent un taff (de manière passive ou active) :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Sympa, mais ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Le sujet que tu soulèves c'est le fait d'accepter des faux-positifs ou d'accepter des faux-négatifs. Intégrer Pôle Emploi ou de ne pas l'intégrer, c'est exactement la même question.
Par exemple, si tu cherches sur Grenoble et jusqu'à 25km aujourd'hui, tu as une annonce pour un développeur ERP Python (boite : Objectif PI) qui est une vraie annonce (et que tu trouves a priori seulement sur Pole Emploi et sur Developpez.com)
Est-ce qu'on veut louper ce type d'annonce ? Je dirais que non.
Est-ce qu'il n'y a pas moyen d'améliorer les choses par rapport au cas que tu remontes ? C'est certain qu'il y a matière. Par exemple en proposant une fonctionnalité de signalement d'une annonce erronée / invalide.
Je pense qu'un dév qui cherche du boulot préfère avoir du bruit que de louper une bonne opportunité (en tout cas c'est comme ça que je réagissais à l'époque où je cherchais) ; je peux me tromper, ça ne me me pose pas de problème :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Le haut niveau d'exigence effraie...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 5.
La question posée est de savoir comment avoir plus de contributions, pas de savoir si les gens ont raison de se réagir comme ils réagissent :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Le haut niveau d'exigence effraie...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 10.
Un collaborateur que j'ai embauché en janvier dernier a écrit un journal sur son simulateur de fourmies qui a reçu un accueil vraiment très bon. Pourquoi il l'a écrit ? Parce que je l'ai "tanné" ; il doutait de la bonne perception par le public et peur du "linchage". Le pb c'est que :
Dans le doute, tu t'abstiens.
Est-ce qu'il ne faudrait pas un mécanisme pour pouvoir écrire en anonyme mais se le réattribuer en cas de succès ? Genre une sorte de double identité et qu'on puisse basculer un article / un journal de l'une à l'autre.
Un des freins, également c'est l’âpreté des discussions dans les commentaires. C'est un frein également (après, j'avoue que je ne sais pas trop comment on pourrait faire pour "limiter" ça)
Un aspect plus global, à mon avis, c'est que le contenu de LinuxFR n'est plus tant "linuxfr" que "logicielslibresfr" voire "informatiquelibrefr" (dont musique, électronique, openhardware, business, etc). Peut-être que l'identité de LinuxFR devrait évoluer ?
Par ailleurs je pense comme dit plus haut que des news courtes devraient faire leur apparition. Dans un journal comme le dauphiné libéré (exemple pris parce que je suis de ce coin là du monde;), il y a des articles détaillés, des articles intermédiaires et des faits divers. On torche le truc, ceux qui aiment lisent, ceux qui n'aiment pas ne lisent pas.
Chacun devrait pouvoir proposer des dépêches longues ou courtes (une dépêche n'étant pas un journal qui est plutôt un "vis ma vie").
Ces idées n'engagent que moi et celles/ceux qui y croient :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# J'aurais bien aimé t'aider ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message client serveur par socket en clientThread. Évalué à 6.
Mais ton code est partiel, avec des renommages de variables et/ou troncage de code, et le symptôme que tu remontes "pb le fichier n'est pas copié" est un symptome genre "et ça marche pas". Autant dire que ça manque d'infos pour nous aider à t'aider à résoudre ton problème.
Si tu veux donner un peu plus de matériel et/ou de précision, ça pourrait bien être utile.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Le téléphone est vraiment IP67 ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tout simplement E P I Q U E. Évalué à -2.
Parce que pour tous les professionnels de terrain, c'est une caractéristique qui est un put*** d'argument. Tu as un téléphone esthétique et en même temps étanche. Je ne parle pas de révolution, mais de pragmatisme et d'adaptation au marché, et ça c'est un sacré avantage.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Peut-être en changeant la forme / ajoutant des informations plus vendeuses ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Trouver un développeur. Évalué à 10.
On l'oublie assez souvent, mais l'objectif d'une annonce c'est pas de "recruter un gars". Ca c'est l'objectif global. Mais le rôle de l'annonce, c'est de recevoir des CVs intéressants, et si possible le moins de CV inadaptés (ou avec un critère de filtrage facile pour les écarter rapidement).
De la même manière, quand on rédige un CV, il ne faut pas avoir en tête "de présenter le meilleur CV", mais de présenter "le CV qui va donner au recruteur envie de rencontrer le candidat".
C'est à l'entretien qu'on va vraiment recruter quelqu'un, mais avant ça, c'est de la drague.
Note : ça ne veut pas dire qu'il faut mentir ou tout enjoliver, mais il faut savoir à qui on s'adresse, ce qui l'intéresse et donc communiquer sur ces éléments.
Par exemple, si tu postes une annonce sur LinuxFR, il faut que tu parles de logiciels libres, de causes sociales ou de haute-technicité. Parce que c'est ce qu'attend (en majorité) le public ici. Si tu mets une annonce sur le site de l'APEC et que tu veux un mec ou une nana plutôt "haut de panier", bah il va falloir que ton critère "salaire" soit bien positionné parce que tu es en concurrence avec des boîtes qui ont de la maille (et les bons candidats le savent).
Par exemple quand je recrute je me positionne pas sur l'aspect financier parce que je suis sur Grenoble et que je ne peux pas concurrencer les boîtes qui vont recruter ceux qui valent le plus cher (je ne tire pas les salaires en bas non plus, mais c'est un argument ni pour ni contre, je suis "dans le ventre mou"). Par contre on fait du logiciel libre et ça toutes les boîtes ne le proposent pas. Et on bosse dans une ambiance décontractée parce que j'ai jamais été en mode "on se prend trop au sérieux" (ça veut pas dire qu'on glande, mais on peut faire du très bon boulot sans se prendre pour les meilleurs de la terre et tout en ayant des moments détendus à raconter de la m…)
Il faut savoir ce qui intéresse tes candidats potentiels. Dans ton annonce tu parles de ce que tu veux toi, mais tu oublies qu'en face, les candidats ont des envies et des aspirations. (et tu n'as pas les moyens de les attirer juste par la rémunération).
Pour ton cas particulier, tu as besoin d'un dév compétent sur un projet sur 4 ans. On s'en fout qu'il connaisse Angular et CakePHP, ce qu'il faut c'est qu'il connaisse le principe des applis client/serveur en mode "single page", qu'il ait déjà bossé sur des API Rest, qu'il ait la tête bien faite pour comprendre les problèmes, qu'il ait fait du PHP et du JS pour pas être tout à fait à la rue au tout début, et qu'il ait envie de venir bosser dans ta petite boîte à la campagne.
Recrute un développeur web curieux et souhaitant s'investir et prendre des responsabilités (et des parts?) dans une petite structure en plein développement. En discutant avec tes candidats tu verras ceux qui savent s'adapter (suffit de les mettre en situation et de les observer), ceux qui essaient de fuir la question parce qu'ils sont pris en défaut. Tu leur demande ce qu'ils attendent en candidatant pour un poste situé "à la campagne" (question ouverte, tu verras ce qu'ils te répondent), tu leur demandes comment ils se maintiennent à jour au niveau technologique.
5 ans d'expérience, c'est difficile à recruter car les candidats commencent à bien gérer les entretiens et à savoir ce qu'il faut répondre (et donc parfois ils vont juste répondre ce que tu attends au lieu de répondre ce qu'ils pensent). C'est pour ça qu'il faut un maximum de sujets ouverts pour échanger librement (et ça vaut pour toi aussi, parce que les mecs expérimentés qui en ont dans la cervelle vont aussi te jauger - surtout si tu es dans un premier temps leur seul collaborateur, et leur supérieur et patron).
p.s : désolé si je parle de "mecs" et "nanas" (et parfois juste de "mecs"), j'ai écrit à haute voix ;)
p.p.s : bon courage pour le passage d'indépendant à responsable d'équipe. Ca te change beaucoup la vie :)
p.p.p.s : je ne suis pas "consultant en recrutement" mais je sais plutôt bien recruter des profils techniques (et en particulier déceler des profils "sur qui miser") ; je peux t'aider si tu veux.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo