Ce complot mondial des hackathons

Mon ami Liam a récemment jeté un pavé dans la mare avec ce billet au sujet des hackathons et introduisant son nouveau concept de coding in the dark.

Je n’ai pas souvenir d’avoir lu déjà (si vous avez de bonnes ressources, je suis preneur) de point de vue similaire à ce sujet, et une telle vérité sans masque ni hypocrisie:

Let’s face it. Hackathons suck. I’ve been to about a dozen of them, as a developer, as a mentor, as a jury member, and as press. Here’s what I’ve noticed.

Developers just want to code, but they have to pitch a business at the end. Juries just want to meet developers, but they get stuck with some B-School student talking about viral engagement and the mobile revolution. And Sponsors – well, Sponsors, after a weekend of hocking your company, you get the stiff reward of knowing that the 3rd place winner and the runner up for best UX used your API. Congratulations.

Pour avoir participé / suivi / sponsorisé des rendez-vous de la sorte, au bout d’un certain temps je suis arrivé à un constat similaire. Ces hackathons, qui, sur le papier, sont une bonne initiative pleine de bonne volonté et éventuellement de potentiel fun, business, etc. sont à mon sens souvent une perte de temps pour les participants et une bonne intention maladroite de la part des organisateurs.

Les bonnes idées/valeurs sur le papier du hackathon :

  • Se sortir les doigts du c** et taffer pour faire des rencontres et gagner en XP, en apprendre plus sur soi même en équipe et temps limité
  • Valider une idée business, faire adhérer des personnes / adhérer à une idée business et travailler dessus avec des personnes
  • Rencontrer de potentiels co-founders de tous horizons
  • Apprendre : en général et sur soi-même

Et je dois en oublier quelques unes.

Les (plus réelles) vérités de la plupart des hackathons :

  • Des teams bancales (90% de devs ou 90% de biz/produit)
  • Des sites statiques (limite powerpoint) qui ne prouvent rien niveau techno ou produit
  • Du crappy code spaghetti qui a juste fait perdre un week end à des devs et qui ne leur a rien appris
  • Des bizguys persuadés de tenir l’idée du siècle et qui perdurent des mois sur l’idée bancale trouvée du week end (et qui sortent le sempiternel “go viral” pitch)
  • Une horde de rapaces qui gravitent au sein de l’écosystème startup et qui cherchent de nouveaux pigeons à encadrer / mentorer dans leur projet et projets futurs (moyennant finance, parts de boite, etc..)
  • Des serials hackathoniens drogués qui se font leur fix et que l’on retrouvera au prochain sur une idée nouvelle (et peu évolué entre les deux)
  • De la fatigue, du bruit et pas de tant de fun que cela

Et je dois en oublier à nouveau quelques unes.

Et tous les gens qui auront perdu leur week end diront le lundi matin à leurs collègues qu’ils ont taffé sur un truc énorme, avec une team sympa, une organisation en or, des gens très intéressants et intéressés par eux et leurs projets avec qui ils ont gardé contact: et rejoindront ainsi le complot mondial des hackathons..

Bon, ok, je force un peu le trait.. Tous les hackathons ne sont pas tous mauvais, bien entendu :)

Les hackathons sont sur le papier une bonne idée, mais chaque personne doit en amont bien cibler son hackathon en fonction de ce qu’il recherche et de son niveau de connaissance startup / technique, sous peine de ne pas trouver ce qu’il recherche et perdre son temps.

  • Pour les tous novices, un petit hackathon “général” (startup weekend, bemyapp..) est un bon moyen de rentrer dans le bain startup. Pour des bizguys tous frais et des devs troglodytes, c’est l’occasion de se frotter un peu les uns aux autres et de faire connaissance, de voir comment travailler ensembles. Mais ce n’est pas là que vous trouverez (sauf exception) votre prochaine team et idée startup. N’en abusez pas, un ou deux suffisent, après c’est de la pure perte de temps. Sortez différemment.
  • Pour les plus expérimentés et pour les profils plus techno/produit, les hackathons plus “spécifiques/spécialisés” (hackathon sur une techno donnée, sur une API donnée organisés par une boite (Eg: Twitter, Dropbox, Foursquare), sur un framework donné) seront eux l’occasion d’apprendre réellement plus et d’aller plus loin: pour le coup, des possibilités réelles d’embauches sont là à la clé et une bonne émulsion techno / produit au rendez-vous avec des gens moins novices. On rentre plus dans le sujet.. Par contre ça ne sera pas là que vous rencontrerez le plus de variété de profils, et bizguys vous risqueriez de vous ennuyer un peu.
  • Enfin, fuyez comme la peste tous les hackathons mercantiles à la “Meilleur développeur de France” et consorts qui ne seront que perte de temps et d’argent !

Et vous, quelle est votre expérience / ressenti sur les hackathons que vous avez pu faire ? Faites vous partie du complot modial ?

3 ans de CTO, déjà !

Le 18 juin 2010, en milieu d’après midi, étaient déposés les status de la jeune startup Wisembly (originellement Balloon).

Voila 3 ans désormais (déjà ?), qu’@Andrei, @Romain et moi-même poursuivons la même vision : aider les gens à réfléchir et à mieux travailler ensemble lorsqu’ils se réunissent. Les réunions sont des moments clés dans la vie d’une entreprise, c’est là que les projets de demain sont présentées, que chacun a l’opportunité de changer son entreprise et que les plus grandes décisions sont prises. Notre mission est de mettre à disposition des solutions accessibles par tous, simples et efficaces pour libérer la parole, organiser le débat et connecter les intelligences.

3 jeunes fraichement diplômés en 2010, nous voici désormais une quinzaine de (plus ou moins ;)) jeunes fous avec plus de 250 entreprises clientes sur 5 continents. Quel changement !

Petit bilan de ces trois ans, au niveau du produit et de la team techno :

# Equipe

18 personnes se sont penchées de près ou de loin, il y a trois ans ou encore maintenant, sur le produit, sur la solution techno : 8 stagiaires, 2 apprentis et 8 CDI (pas mal le ratio CDI / stagiaire non ?).

# Technos

Bootstrappé en PHP4 procédural, avec un peu de jQuery et d’ajax à l’époque, la solution implique désormais plus de 10 technos et frameworks: PHP sous Symfony2, one page Backbone.js app, push server socket.io sur node.js, MySQL et Redis pour le storage, Python Bash et Java pour d’obscures moulinettes serveurs..

# Tests

D’une recette Excel faite à la main régulièrement par mes vaillants stagiaires, nous nous efforçons désormais de développer en TDD, avec phpunit, Behat et Mocha.js/sinon.js, en intégration continue sous Travis. Plus de 1000 tests nous aident désormais au quotidien à développer plus efficacement et à ne pas régresser toutes les deux lignes de code.

Cela fait pas mal de choses en 3 ans déjà ! Le futur nous réserve encore plus de surprises, maintenant que nous avons trois team bien établies (Back API, Front APP JS et Front UI/UX), des tests et des process, les développements et déploiements se voient raccourcis, plus fiables, et laissent entrevoir de belles améliorations produit nous rapprochant un peu plus de la vision que nous avons.

Merci à tous ceux qui nous ont aidé et fait confiance !

Un merci spécial à: Nico.P, @dator, “Gégé”, “Ptit Boudha”, Aymeric, Lucas, Jules, Ludo, Nico.C, Yo “Le brésilien”, Charles “La madeleine”, Maël, Rémy, Gab, Baptiste, Tristan et Mathieu :)

Recherche devs spécialistes, et non de couteaux-suisses techniques

Aujourd’hui, petit billet à dominante recrutement, cela faisait bien longtemps tiens :)

Chez Wisembly, nous recherchons en permanence des personnes talentueuses pour rejoindre nos équipes. Souvent en postant des offres bien précises, parfois, au détour d’un chemin, par pur hasard, au grés des rencontres.

Et si je n’ai toujours pas changé d’avis sur l’inutilité d’un CV académique sans projets perso et / ou profile Github (ou Dribble, Pen.io, Stackoverflow..), je me rends compte que trop de candidats à mon goût se présentent à moi comme véritables “couteaux-suisses” techniques sachant tout faire, indispensables pour ma startup.

Dans mon cas, ainsi que celui de nombreuses startups, je pense que c’est totalement faux. Je vais essayer de détailler un peu ici pourquoi.

Tout d’abord, ce qui nous différencie nous startups du reste du monde à mon sens, c’est la capacité à concevoir et délivrer de nouveaux produits ou usages comblant de la façon la plus élégante / efficace qu’il soit un cruel manque business.

Pour ce faire, il ne suffit pas d’aligner superficiellement quelques lignes dans deux trois langages et frameworks différents et pusher le tout sur un serveur. Il faut (et ceci est le rôle du CTO normalement) étudier quel est le meilleur mix techno à adapter pour mener à bien son développement produit, composé normalement de quelques techos “standards / classiques” mais aussi de techos plus méconnues, innovantes et qui évoluent rapidement.

Dans ce contexte là, il faut:

  • être capable de maitriser et pousser dans ses retranchements chaque techno employée, pour en tirer sa quintessence, gagner en performance, efficacité de développement et expérience utilisateur.
  • connaitre sur le bouts des doigts ses technos pour les agencer efficacement et avoir une archi robuste mais souple qui permet de shipper vite, pivoter aisément et iterer agilement sur ses features.
  • savoir placer ses meilleurs ressources sur du front, d’autres sur du back, d’autre sur de l’algo, d’autres sur ceci ou cela

Je pense que pour être le meilleur compétiteur dans son domaine technique / business, il faut être le plus exigeant et le plus perfectionniste tout en restant le plus efficace / performant possible (rien que ça!). Dans le monde de la technique, cela ne peut venir sans expériences et kilométrage au compteur dans le code en général, et dans quelques techno en particulier. Bien que ce billet sonne très vrai, et qu’un excellent codeur dans un langage donné peut être tout aussi bon dans plein d’autres, je suis convaincu qu’une personne faisant à longueur de journée du front, du back, du js et du dev ops sera juste moyen en tout et excellent en rien.

Attention, ne me faites pas dire ce que je n’ai pas écrit. Il est important d’être pluridisciplinaire et de pouvoir mixer les sensibilités / technos: c’est une preuve d’ouverture d’esprit qui ne peut qu’être bénéfique !

Mais lorsque je rencontre un candidat et que l’entretien tourne ainsi:

- “Bonjour, c’est quoi ton kiff dans le code au quotidien, au boulot ou le soir chez toi ?”
- “Alors moi ce que j’aime, c’est faire du Python sous Django et du Symfony2 en PHP, tout en faisant du javascript MVC sous Ember ou Angular, en utilisant HTML boilerplate et Bootstrap en less. Parfois du Saas”
- “Ah, très bien, et tu préfères travailler plus sur quoi? Du gros back, du gros js ou de la UI/UX ?”
- “Ah mais j’aime tout moi !”
- “Bon, et du coup, tu te vois plus travailler dans une team back, js ou front ?”
- “Bah, comme vous voulez, je sais tout faire et j’aime tout faire”
- “Bon… t’as des projets à me montrer ?”
- “Oui, 5 sites, avec des potes à chaque fois, j’ai un peu touché à tout, j’adore ça hihihi”
- “Très bien, on se rappelle !..”

Et bien ça ne va pas être possible mon garçon. Pour moi en tout cas.

Peut-être qu’au sein d’une startup sans CTO ce genre de profil peut faire l’affaire, peut-être qu’au tout début d’une startup en employé dev n°1 ou n°2 cela peut passer. Mais rapidement je pense il faut veiller à former des teams par technos / compétences afin de les pousser à l’excellence, et ce genre de profil “indécis”, non “spécialisé” aura difficilement sa place.

Et vous qu’en pensez-vous ? Quelles sont les teams que vous avez constitué ? Recruteriez-vous ce genre de profil et dans quels cas ?

7 conseils pour plomber techniquement votre startup web

C’est l’été, il fait beau, les oiseaux chantent, ça sent bon la fin du mois de mai !

Oui, cela fait aussi peut-être un an que je n’ai rien posté ici, j’ai décidé (pour combien de temps ?) de reprendre les choses en main. Aujourd’hui, je vous propose une petite réflexion et 7 conseils tirés de mon expérience personnelle pour bien plomber votre startup niveau techno. Allons-y gaiement:

1 – N’utilisez pas de framework

Je pense que ce point est de loin le plus essentiel. Les frameworks, c’est bien trop hype et sur-évalué. Cela ne sert strictement à rien d’embarquer des milliers de lignes de code dans son projet, et encore plus des milliers de lignes de codes d’inconnus ! De plus, ces frameworks vont vous faire perdre votre précieux temps à coder propre et bien, alors qu’en deux trois coups de cuillère à pot, quelques variables globales et boucles imbriqués bien placés, vous pouvez sortir la vue web qui va bien ! D’ailleurs, c’est sûr que vous coderez mieux avec vos petits doigts boudinés ce que des inconnus ont érigé en plusieurs mois.

2 – N’utilisez pas git (et à fortiori, Github)

Quelle perte de temps que de devoir apprendre des commandes obscures dans votre terminal (heu, c’est quoi un terminal d’abord ?), brancher, forker, rebaser à tout va, plutôt que de vous concentrer à ce qui compte vraiment, votre code, au sein de votre IDE ! De toutes façons, vous êtes en startup, à deux ou trois, débrouillards, vous pouvez bien vous envoyer les fichiers modifiés par email, c’est bien plus pratique ! En plus, en se débrouillant bien, vous n’aurez même pas à travailler en même temps sur les mêmes fichiers. Github, c’est vraiment pour les bobos hipsters du code qui veulent se faire mousser ! FTP FTW sur mon serveur !

3 – Ne perdez pas de temps à écrire des tests

Vous aussi vous avez entendu parler de ces gens qui passent bien 20-25% de leur temps à écrire des tests ?! Parfois même avant d’entamer leur code ? Dingue, non ? Il y en a qui n’ont vraiment que ça à faire. Autant aller travailler dans une SSII s’ils ont autant de temps à perdre ! Allez, zou, un peu de code, une bonne feuille Excel avec quelques tests fonctionnels à refiler à ses stagiaires, et c’est parti, ça marche super bien !

4 – Ne vous souciez pas de la sécurité

La sécurité, c’est pour Facebook ou la NASA. En startup, on en a pas besoin. Qui irait se soucier de nous et nous chercher des noises ? Il est important de ne pas se soucier de la sécurité pour avancer en codant vite. J’ai vu ce tweet circuler hier, qui parlait d’injections SQL en PHP. C’est un mythe ça, ça n’arrive jamais “en vrai”. Imaginez tous ces gens (qui d’ailleurs sont tombés dans le panneau du conseil n°2), s’ils devaient (suivez mon conseil n°1) coder leur ORM ou préparer / sanitizer leurs requêtes. Ils n’avanceraient jamais !

5 – N’utilisez pas de scripts de déploiement

Pour les mauvais élèves du conseil n°2, faites directement un git fetch en prod. Et à la rigueur exécutez quelques scripts / commandes sur la PROD. Mais je ne vous félicite pas ! La vraie solution miracle, c’est le FTP. FTP FTW sur mon serveur. Tellement plus facile de filer les accès à toute votre startup pour aller éditer en live et rapidement ce qui ne va pas sur votre serveur. C’est aussi facile d’envoyer que quelques fichiers remplacer les existants pour fixer vos bugs ou améliorer vos features. En plus, ça marche sur tous les serveurs le FTP, même les hébergements mutualisés ! :)

6 – Ne mettez pas de cache, alignez plutôt des serveurs / instances

Comme pour n°4, le caching, c’est pour Facebook ou Twitter. Franchement, pourquoi s’embêter et se casser la tête à réfléchir à de complexes stratégies de cache alors que ça coute presque plus rien les serveurs ? Commencez avec un petit Kimsufi (2Go de RAM), et si ça ne passe plus, prenez plus gros. Toujours plus gros. En plus, si vous avez bien suivi le conseil n°5, d’un coup de FTP, le tour est joué pour passer sur le nouveau serveur !

7 – Ne travaillez qu’avec des stagiaires ou des agences

Enfin, si vous arrivez à respecter tous les conseils précédents, faites vous ce cadeau: ne prenez que des stagiaires ou des agences à la rigueur. Mais ne perdez pas de l’argent à payer cher des développeurs qui se prennent pour des rockstars du code, qui ne comprennent rien au business, et qui vont vous faire perdre du temps à configurer des environnements de travail, retoucher des alignements et fixer des virgules ! Hop hop hop, ni une, ni deux, un cahier des charges, un feuille de recette (conseil n°3), un accès FTP à votre serveur de dev (ou prod?) (conseil n°5), et roulez jeunesse !

Voila, c’est tout. Je crois qu’avec ça, vous allez être parés désormais pour bien bien looser dans votre startup, et pouvoir dormir sur vos deux oreilles ou boire des coups avec vos associés en shippant rapidement du garbage tout en contentant vos clients ou utilisateurs à court (voire très court) terme.

Disclamer: ce billet n’est pas une fiction. Je suis moi-même passé par une bonne partie de ces points, et pu constater les autres au sein de startups de connaissances. Malgré le ton léger, ce billet est bien entendu à comprendre à l’envers (sinon, je vais avoir toute la profession et les associations sur le dos), et je vous encourage à partager vos expériences à ce sujet dans les commentaires.

Enfin, ceci doit probablement être mon premier billet depuis de longs mois (années ?) d’inactivité, veuillez m’excuser pour cette absence. Et si par ailleurs, vous avez des idées de sujets à traiter que je pourrais éventuellement couvrir, n’hésitez pas à m’en faire part dans les commentaires ou par email. Merci ! :)

Ne vous souciez pas des performances de votre solution web (pensez-y juste)

A ne pas s’y tromper, les performances de votre solution SaaS sont cruciales pour votre startup:

  • d’un point de vue front, l’application est fluide, dynamique, il n’y a pas de chargements de pages intempestifs, quand il y en a cela se fait rapidement, sur ordinateur comme sur tablette ou smartphone
  • du côté back, chaque utilisateur sur votre application ne consome pas grand chose comme ressources serveur, et 1000 (voire 100 000) utilisateurs connectés simultanément ne font pas tomber ou ralentir votre infrastructure

Il s’agit là du cas parfait, ne nous leurrons pas. C’est rarement ainsi au début de votre startup, car il y a bien d’autres combats à mener qu’améliorer les perfs (débugger par exemple?) et de toutes façons pas autant d’users sur la solution (ou alors vous êtes vraiment très forts!)

La question est donc la suivante: doit-on se soucier des performances de son application? Si oui, quand et comment s’en soucier? 

Continue reading

7 bonnes raisons pour quitter votre job en SSII ou Web Agency et rejoindre une startup

Aujourd’hui, un petit billet dans la série de co-écriture que nous avons entamé avec Guilhem il y a quelques jours. Ce coup-ci, c’est lui aux manettes pour le gros du billet!
La dernière fois que nous nous sommes croisés, nous avons pas mal discuté recrutement, code et ninjas, vaste sujet, assez critique pour une startup web. Je déplorais la “perte” de bons éléments (stagiaires, collègues, connaissances) en milieu SSII ou WebAgency quand nous est venu cette idée de billet qui fera peut-être grincer des dents certaines boites: 7 bonnes raisons pour tout plaquer et venir travailler dans une chouette startup!

A toi Guilhem!
**********
Bonjour à tous!
Ce n’est pas un secret : en France, on a un problème avec nos ingés et développeurs.
C’est vrai, ils font des écoles, des stages, tous les horizons leur sont ouverts, sont plutôt bons par rapport à leurs homologues étrangers… et patatras, les voilà qui se réfugient à 90% dans des SSII. Forcément, du point de vue de l’entrepreneur que je suis (et apparemment, je ne suis pas le seul), c’est frustrant, surtout lorsque l’on est persuadé que nos chers développeurs seraient bien plus heureux… dans nos startups !

Alors je m’adresse à vous, développeurs et jeunes padawans encore sur les bancs de l’école, en vous proposant quelques arguments pour vous aider à faire le grand saut, et à quitter (ou refuser de rejoindre) le monde affreuxxxxxxxxxx des SSII (beurk) :
  • L’argent ne fait pas tout. C’est sûr que de prime abord, les SSII ont une proposition de valeur assez alléchante : un bon salaire. Alors OK, en sortant des études, c’est sympa d’avoir un chouette niveau de vie, de pouvoir se refaire une garde-robe (ah, ah), et se payer des bières sans compter à la dépense. Pour ceux pour qui l’argent est le seul et unique critère, la SSII semble le bon endroit pour s’épanouir. Pour les autres, vous pouvez continuer la lecture et surtout, demandez-vous si, en-dehors de l’aspect salarial, le compte y est dans votre situation actuelle.

Ne codez pas des oeuvres d’art (mais bâtissez des cathédrales)

Quand j’ai vu tourner cette image sur Twitter ce week end, cela m’a fait gentiment sourire car c’est un peu le sentiment que j’ai eu lorsque j’ai effectué mon tout premier stage à la DSI de Louis Vuitton à la fin de mes études.

Quelle ne fut pas ma déception lorsque derrière le strass et les paillettes il y avait  en fin de compte un bonne majorité de vieux programmes d’une dizaine d’années faisant tenir la boite et nécessitant des experts vieux de la vieille pour maintenir ces pachydermes ancestraux en bon état de fonctionnement. Idem pour mon amie qui se retrouve au département technique d’un grand groupe français de paris en ligne et qui désespère de voir du code mort ou du code répété joncher les lignes de la solution en très forte proportion..

C’est là où je veux en venir justement. Des exemples comme ceux-ci je suis persuadé qu’il y en a des millions. Dans les grosses boites du CAC, même chez Google, Facebook ou dans toute startup à la mode. Et c’est qu’il y a une raison, qu’on ne saisit pas à la sortie de l’école, des étoiles plein les yeux songeant que l’on va travailler au quotidien sur un chef-d’oeuvre de code: le code que vous produisez ou que les équipes produisent pour votre solution doit avant tout être fonctionnel et servir votre business.

Continue reading

Qu’est ce qu’un Lead Dev (en startup)

Il arrive un temps dans une startup, plus ou moins tôt en fonction du profil des associés, de leur niveau et appétence technique, où il devient nécessaire de recruter un Lead Developeur (comprenez en français, “développeur en chef”. Oui, c’est beurk).

C’est mon cas actuellement. Et avant que de poster une offre, il convient de se poser et de réfléchir aux points suivants, afin d’avoir les idées claires:

  • À quoi correspond ce poste exactement? Quelles sont ses caractéristiques, comment s’insère-t-il par rapport aux postes existants?
  • Une fois ceci défini, de quel profil j’ai besoin au juste? De qui ai-je besoin?

Mon expérience personnelle m’a donné à réfléchir à ces points en deux fois, par une période d’essai d’intervalle..

Continue reading

La traite des stagiaires (dev, en startup)

Ces derniers temps, plusieurs signes fugaces, diffus mais bien présents ne m’ont pas échappé: sur Twitter des “stage développement en startup non rémunéré, excellente ambiance” tandis que sur Linkedin, Remixjobs ou autre job board des “recherche stagiaire(s) expérimenté(s)” ou encore “stagiaire excellente connaissance en [remplacez ici par votre techno]” éclosent deci delà. A ne pas s’y méprendre, la saison 2012 des stages abusés est désormais ouverte!

Continue reading

Apprenez à vos associés à coder (un peu)

Petite mise en situation:

- J’ai vendu une super presta aujourd’hui, ça va être top, mais il va y avoir quelques développements à faire!

- Ah bon, quels développements?

- Bah, rien de très compliqué! Grosso-modo, on passe tout le site en temps réel, on rajoute de la sémantique qui détecte et tri le contenu et on fait une jolie interface pour le mobile dynamique et tout.

- ….

- Ah par contre, le client m’a demandé si c’était possible de modifier la couleur et la police du site, c’est possible ça, j’ai pas su lui répondre…

- ….

Si ce genre de discussion vous est déjà arrivé, rassurez-vous, rien n’est perdu. Il est encore temps d’apprendre les rudiments de la programmation et offrir un succédané de culture informatique à votre/vos associé(s)! Continue reading