Julien Dollon

Management, Ingénierie & Science de l'informatique

Je change d’equipe dans Amazon!

He bien voilà, comme d’habitude j’aurai tenu 2 ans et demi dans la même équipe. Ça peut paraître peu pour vous (si je me rappelle bien, en France c’est mal vu) mais ici le marché et la dynamique veut que les gens bougent chaque année ! Chaque 7 mois un ingénieur à Amazon change d’équipe (ou quitte), 1 an et demi chez Google ou Microsoft…. Alors autant dire que moi et mes 2 ans et demi j’étais un vétéran, et un des seuls restants d’une ancienne génération.   Chez AWS, j’ai participé à la création d’expériences et services pour EC2, Service […]

FacebookLinkedIn

Les 6 conseils de carrière que j’aurais voulu entendre plus jeune.

Cet article est destiné aux jeunes passionnés d’informatique, je ne pense pas qu’un professionnel ait quoi que ce soit à apprendre de cet article.   J’ai toujours voulu faire du logiciel. J’ai commencé à l’âge de 12 ans (ou 9 ans, ça dépend ce qu’on appelle « commencer »). Mon premier langage a été le HTML, puis directement le C++, puis le PHP etc… Ça fait donc presque 20 ans que je fais du logiciel, dont presque 10 ans professionnellement (9 pour être précis !).   Le logiciel, c’est la passion de ma vie. Mon cerveau a grandi avec la logique de construire […]

FacebookLinkedIn

The laws of Software Development

  Software Development is a recent discipline; we are just at the beginning of finding out how to build good software. 1 years ago, “serverless” system was unknown, 5 years ago we were all working on relational database, 10 years ago nobody was writing unit tests, 15 years ago we were working with waterfall processes instead of agile. We, developers, are writing the history of Software Development. It is so exciting to be at the beginning of a new science. As I read books and Wikipedia, I discover laws and I wanted to compile them into one big list. Let […]

FacebookLinkedIn

What am I looking for during a code review?

  I’m an experienced code reviewer. It’s my passion and it’s probably what I enjoy the in my engineering career. I love it even more than writing code myself. CR helps to maintain high quality software, to grow engineers, to force consistency across the source code and to have a chance to catch hidden technical debt before it’s too late. Code reviews also can be used as a change management (CM) mechanism.   All human beings make mistakes, the absence of code reviews is a big sign demonstrating a manager’s neglect for their engineer’s personal growth and reluctance to avoid […]

FacebookLinkedIn

Autoévaluez votre niveau : quelques exemples entre ingénieur junior et expérimenté

Mon équipe à Amazon AWS Les titres de SDE (Software Development Engineer) sont très disparates entre les entreprises. Google démarre à SDE II, Microsoft propose un SDE II très accessible, Uber donne le titre senior avec seulement 1 ou 2 ans d’expérience… Bref on s’en fou un peu des titres, cela change trop d’une entreprise à une autre.   Même si être dans les GAFA est souvent un gage de qualité, les équivalences entre les entreprises du top 5 ne sont pas officiellement écrites noir sur blanc. J’avais déjà expliqué que la différence de niveau entre un ingénieur I (apprentis) et III (senior) […]

FacebookLinkedIn

Qu’est ce que l’under et l’over design ?

image de la cafeteria Amazon, tout est dessiné a la craie Le design est un processus intellectuel que l’on utilise pour un algorithme, une data structure, une application, un site web, un system distribué… afin de définir une certaine structure. Le but de cette structure est d’améliorer la maintenance, la performance et ou la réutilisabilité de ce que vous êtes entrain de concevoir. L’over design, c’est quand on en fait trop. En faire « trop » c’est mauvais pour deux raisons : 1/ ça coûte de l’argent (== temps) et parfois 2/ cela augmente la dette technique (plus dur à maintenir). L’under design, […]

FacebookLinkedIn

When is it appropriate to write a design document/technical spec?

In Software engineering, it is common to argue on writing a technical spec (or design doc). Some people, like me, are Taliban against those kind of docs, but some others love documentation and ask to write one for any changes that needs to happen in the system. So where is the bar? What is the trigger that make you think “I need a design doc”. The first thing I would like to do is to detach the notion of designing from writing a document. It is possible to express design on a board, to have a thoughtful process with yourself […]

FacebookLinkedIn

La dette technique

La dette technique c’est une dette qui accompagne tous les projets logiciels. Je ne parle pas des bugs, mais plutôt des défauts de conception ne permettant pas au logiciel de se maintenir ou d’évoluer simplement. Pour comprendre ce qu’est la dette, il faut revenir a la base. Un projet informatique c’est quoi ? Le mix entre la science de l’informatique, l’ingénierie informatique et la sociologie. C’est la partie « ingénierie » qui cause une dette, car l’ingénierie c’est l’art des compromis, l’art d’utiliser son propre jugement pour concevoir un système. De ce fait, quand vous architecturez un logiciel, ou à plus bas niveau […]

FacebookLinkedIn

Ma liste de livres à lire [pour developpeurs] et quelques tips

Beaucoup d’entre vous me réclame cette liste depuis longtemps. Voici chose faites ! Je la tiendrai régulièrement à jour, pour chaque livre que je lis et que j’aime. Car oui, je fais un gros tri pour ne garder que mes préférés. Certains sont pour débutants (même la plupart, surtout ceux que j’ai aimé et qui m’ont fait grandir), d’autres pour un public plus averti. Je suis surtout focalisé sur l’ingénierie logiciel, mais je lis parfois aussi sur la psychologie, l’économie, le management… Comme vous le savez peut être, je suis un gros lecteur. En moyenne un livre par semaine, toute l’année. Je […]

FacebookLinkedIn