Julien Dollon

Management, Ingénierie & Science de l'informatique

What I learned from being a tech lead #4

  I’ve been a manager for close to 3 years, every time I’m writing down when I learn things from a big milestone. Previous posts: ·     https://www.linkedin.com/pulse/what-i-learned-my-last-project-tech-lead-3-julien-dollon?trk=mp-reader-card ·     https://www.linkedin.com/pulse/what-i-learned-my-last-project-tech-lead-2-julien-dollon?trk=mp-reader-card ·     https://www.linkedin.com/pulse/what-i-learned-my-last-project-tech-lead-julien-dollon?trk=mp-reader-card It is interesting how I’m still learning my job year after year. I wonder when I will be good enough to considerate myself an experienced manager. It will probably take ten years like it did for the engineering part of my career. Here are the things I recently learned as I joined Woot.com:   1. Being a manager is like being a coach for a soccer team I like using this examples […]

FacebookLinkedIn

Partir de AWS m’a fait beaucoup apprendre

Comme vous le savez peut-être, je viens de quitter mon équipe chez AWS après 2.5 ans. Les raisons de mon départ sont multiples, principalement car j’avais envie de changement et parce que je voulais évoluer dans un environnement plus petit, plus « startup ». Ce fut une décision dure à prendre car cette équipe est comme une petite famille pour moi. Je ne regrette pas mon choix d’aller à Woot. Vous ne connaissez surement pas Woot en France mais ici c’est assez connu. Pour vous donner un ordre d’idée : plusieurs millions de visiteurs par semaine, plusieurs millions de dollars par semaine en […]

FacebookLinkedIn

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

Is scaling up a software engineering organization the right solution to increase velocity of innovation?

As an engineer, I’ve been working for a while for high tech giant like Microsoft or Amazon. I also worked a lot with SMB. The first things I noticed as I joined those big structure is how slower big companies are compare to small structures when it comes to shipping Software. After 5 years of observation, I think I can explain it with multiple reasons. First, the business is often running at a higher scale which force the technical bar to be higher: going through an operation readiness review at Amazon Web Services or a Gold Build Image Readiness at […]

FacebookLinkedIn

What I learned in my last project as a tech lead #3

Every time I’m close to ship a new product, I do a retrospective on myself and the top 10 things I’ve learn as a technical leader. I did it for Service Catalog and for AWS Marketplace Cluster support. For now, the summary of things I learned are: Dependencies is where shit happens Do not wait to go full continuous deployment Building a new service is not free Always be customer obsessed Have a vision and share it to your team Do not increase too much the complexity of your data-flow because of ownership Go in beta AS SOON as possible […]

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