Chronicles of an introvert remote worker

03 January 2020

Tags: remote work introversion


This post is the translation in English of the most popular blog post I wrote in October, 2019, which was originally posted in french. Lots of folks commented they found it useful and that they recognized themselves in the description so I decided to translate it to English.

The other day I was listening to Les Cast Codeurs podcast which mentioned the topic of remote working.

Some comments made me raise an eyebrow, this post is going to talk about my own experience. This post is mostly about me and being an introvert.

Remote working and being an introvert

I’ve been almost full-time remote worker for almost 10 years. I’m saying almost because in practice, I’m moving from time to time for profesional reasons (conferences, meetings). However, for my daily job, everything is done from home. Before being a remote worker, I was driving a lot: my job was in Nantes, around 45km from home. That was about ~90km a day, but more importantly between 2 and 3 hours of commute a day. The day I switched jobs, working for VMware on the Groovy language, the first shock was that I was recovering those 2 to 3 hours a day. That’s a lot of time to spend with your kids (dropping them at school, driving them to sports, …) or doing housekeeping (fixing, gardening, sports, …). I won’t come back to those advantages because they are mostly known, the only real drawback to me is being capable of handling your own work hours, that is to say, contrary to the belief, not working too much.

The thing I want to talk about is this comment from Antonio Goncalvés who said:

Dump your coffee maker, go out, see people, it’s important to see other human beings!

This made me react so I wanted to come back to this topic.

First, this advice only works if you live in a city, which is not my case. I (intentionally) live in the countryside, 5kms from the town center. A "small coffee break" turns into an expedition in those conditions.

But let’s come to the core of the topic: "It’s important to see and talk to human beings", which relates to the necessity not to be alone. This is a topic I care about and resonates with a question I often answered when I’m talking about remote work:

But aren’t you tired of being alone and not seeing anybody?"

Honest answer: no.

I understand people who need this, but don’t think everybody works like you and need to see other people. Some folks like me live perfectly well without seeing anybody. I can spend days alone, without me going mad or missing any social relationship.

I’m part of this population called the introverts.

  • An introvert, contrary to the popular belief, isn’t antisocial, selfish or without any kind of empathy.

  • An introvert is someone whose energy is drained by the crowd, by social relationships. It’s the opposite of an extravert who needs to see people to recover energy.

  • An introvert is someone who can’t stand smalltalk, because they don’t bring anything to him/her except from draining their energy.

  • An introver is someone who can talk hours on a topic (s)he’s passionate about because it’s worth their energy.

When I was a kid I already avoided being in a group of people. I didn’t have many friends (but the friends I had back then I still have them today).

I always freaked out at the idea of being in a group where I knew nobody, be it at school, at sport or even family parties. Even if I knew someone, being in a group, having to entertain social relationships was of extreme difficulty (and it still is today, to some extent). Everything I cared as a child about back then was being "excellent" at school and my parents be proud of me. This caused me to get some nicknames ("the nerd"), being hassled or even get some not so nice words written on the back of my classroom photographs, for a large part of my childhood.

As an example, I always refused to go to summer camps (the only experience I got, a week in a stud farm, was so painful to me I still remember it). I also refused going to snow camps. However, I did accept going to England, Ireland and Spain with school, not without fighting myself, because I knew I could learn something out of it, but also because I knew I would be in a small group with a friend.

Similarly, having to stand in front of the rest of the classroom to recite a poem, or worse, sing, was pure torture to me. On the contrary, I loved being at the University of Science in Nantes, where I could spend some time with 2 or 3 friends max at the coffee shop, discussing with them. I didn’t like much the software engineering school I joined to after that, where I had to be extremely creative to avoid the student integration parties, after-work parties and all those driking games most students were fond of: it was incredibly difficult to be recognized as a person without being excluded because I didn’t participate in those events.

Let’s talk about those "integration" parties. What’s fun for some, being drunk, "gently" humiliating others, was just disgust and fear for me.

Now that I think about it, few people know it, but I spent my whole scolarity in Nantes, not because everything was available there (it was, really), but because I was petrified at the idea of beling "alone" in a new University, an engineering school, somewhere else at the other end of France, … I remember a teacher who blamed me for not going in a well known French school despite I had the "capacity" do it. In retrospect I don’t think it was a big mistake, I’m quite happy where I am today!

I would never hire someone like you!

Everything I explained may sound surprising from someone who, today, gives talks at conferences, sometimes in front of hundreds of people, which sounds a bit irrealistic. So what’s the difference?

Well the difference is that when I talk to you in a such a context, I understand the topic (or at least I think I understand it ;)). I can talk to you openly because I know the questions I will get are directly related to the topic I’m talking about. There’s almost no room for the unknown.

That’s also for this reason that it’s still very difficult to me, even today, to reach out to others. I am still completely incapable of doing small talk. This goes even beyond that: I’ve traveled abroad a number of times, multiple times in the US for example, but I never went outside alone to visit (at best I can walk an hour or two in the neighorhood). That’s because doing this drives me outside of my comfort zone: having to talk to people I don’t know, ordering a meal, asking for directions: all this is draining my energy. It’s always easy to say you should go out of your comfort zone when doing this is not a trial for you.

However, if I know one or two people and that they kindly ask me to join them, in most cases it will be fine and I would appreciate visiting! Everybody’s telling me I’m incredibly lucky to travel. Well, maybe, but I, for one, hate this, at least I hate it if I have to do this without my family… Even going to Paris, realizing how many people live there, feeling like an ant in the anthill, remind me how much I hate this!

As a consequence, I avoid as much as I can "parties" like speaker dinners or corporate events. They are often described as the must do of networking. While it’s true that you can learn a lot in those events, they are also incredibly stressful to me. When I join them, most of the time I’m trying to identify someone I know, stick with them but I would often leave early and I have to go to my hotel room alone to recover. I wouldn’t necessarily sleep, as some people think I do: often I would work late in my hotel room, I just need to be alone. The most terrifying thing to me in those parties is when conversations become extra-professional which is something I have no "skill" for. Some would say I’m a boring guy, that there’s no interest in talking to me and that’s probably right if you’re looking for someone with an extraordinary life, mine is not that much :)

A natural conclusion that some people draw from this is that of course I can’t be a good team player. In fact I think that’s quite the opposite: I value trust like no one else and I think you can trust me. One shouldn’t mix my incapacity to have simple inter-personal relationships with my capacity to have useful professional interactions, which is another totally different dimension.

As I explained, I’m regularly giving talks and I love more than anything else sharing knowledge and information, helping others. I also enjoy working with people more competent than me so that I can continue to learn and make progress: in this context working in a team is extremely effective.

Also, it’s not because you’re working remotely that you don’t see anyone and that, effectively, you work alone. It’s quite the opposite: we work as a team. As other teams we do daily standups (via hangouts or Slack), we organize work. Sometimes we even do face to face meetings or leverage conferences to meet together and do some work. So it’s not because you’re an introvert that it’s a problem: I think my colleagues would tell you that it works pretty well actually.

In short, don’t be afraid of this aspect: being alone is not a problem for everyone. Maybe it is for you, but definitely not for everyone. On the opposite, being alone can also boost productivity: no interruption, no useless meetings, ability to focus on a problem for hours etc… Being introvert doesn’t mean either that someone is not capable of working in a team: it doesn’t prevent at all from helping others, colleagues or customers. On the contrary, the professional relationship is focused.

So how does it work in practice? At Gradle, almost everybody is working remotely. For the socializing aspect, we have an optional weekly meeting, called "coffee time", that anyone willing to can join and chat about extra-work topics. Some need this, I don’t: the good thing is that we recognize not everybody’s the same. Actually I would be in difficulty to join this meeting and know what to talk about. Sometimes I even try to avoid being the first one joining a remote call to avoid having to do some small talk because I’m so uncomfortable with this.

However, again, talk to me about a topic I know about or that I’m passionate about. Ask me about a problem to solve, ask me about helping others and I’ll be happy to do so because there’s no room for the unknown.

Similarly if we meet in person at a conference and that you wish to talk to me, go ahead: it’s very likely I will enjoy our conversation: I had several times the opportunity to talk to very famous folks of the Java community (James Gosling, Brian Goetz, Mark Reinholds, …) and so many others but I just couldn’t, it was, physically, impossible to me.

In fact I have so much difficulties coming to someone and opening a discussion that if you do the first step it’s much easier.

So: don’t be surprised if I walk the area 3 times in a row without asking for directions. Don’t be surprised if I don’t phone or text you. I’m not ignoring you.

Don’t be ashamed of being an introvert but make others understand what it means

Last, in a Tweet I was saying that I was "healing myself". That’s both true and false at the same time. It’s true because I’m aware of the importance of the ignorance of a lot of people about this condition of mine, so I try to work, for example, speaking with others in different contexts. I am for example the secretary of my karate club, which forces me to talk to people I don’t know. I am also the coach of my younger boy’s (10 yo) basketball team, which I enjoy very much doing: it’s an activity which allows both spending time with my kid, requires some public communication skills and is very gratifying (seeing kids happy to play, win a match, share this with their parents etc…).

Last but not least it’s also a message for my son who I know feels very much like me: he also has difficulties speaking to others and I know he works hard to get accepted. He’s also so proud when he gets recognition from his community.

It took me years to put a name on what I am: I’m an introvert and often I have to fight myself not to be ashamed of this.


Gradle myth busting: scripting

03 November 2019

Tags: gradle maven groovy kotlin

I don’t particularly enjoy Twitter as a medium for debating (no surprise my bio mentions "this is not a support channel"). This happened again this week, I got caught in a Maven vs Gradle debate, one more, after I replied to Lukas Eder that his tweet was a call for FUD. And it did happen: no surprise, when you submit something like that, the only answers you’ll get are either people going in your direction "oh yeah, Gradle sucks and here is my personal experience" or similar, this is just human nature.

The good old debate

In the end, most of the answers cycle around the same, good old, debate: Gradle uses scripting (Groovy or Kotlin) vs Maven uses declarative. You’ll aways find people telling you that XML is better because it locks you down, its fully declarative (is it, really?) and everybody is forced to do the same. I don’t counter those arguments, this is a strength of Maven, but it also comes with a number of drawbacks.

I promised some of the folks in the conversation some answers (please look down for direct answers to tweets), so here they are. I’m answering on a blog post because again Twitter is not good for this, it’s causing a lot of misunderstandings, because you get into multiple, parallel conversations with different people who accidentally get mentioned, and get scuds fired at you without even having time to answer… Even a blog post is not enough, there’s so much to say on this topic.

First, on the so called "declarative vs imperative" model, I will always disagree on this dichotomy. I disagree that Gradle isn’t declarative. It’s as declarative as you want it to be. Take this build file I wrote recently, which is an Asciidoctor Reveal.js presentation template (it allows writing slide decks with Asciidoctor and reveal.js). Here’s what my build file looks like:

plugins {

presentation {

dependencies {

tasks {
    asciidoctor {


I wouldn’t particularly say this is imperative. It looks very declarative to me. Concise too. The fact it uses an imperative language is orthogonal, but it does, however, create the ability to write imperative code in the build. Note, however, that a dependency was declared for asciidoctor. This is a major, and probably the most important, difference with Maven: compile or runtime doesn’t make sense here. We declare a dependency for asciidoctor rendering. There’s no Java library being built here, it’s a presentation. Gradle lets you model precisely what you build.

So, in the end, I think what matters is not declarative vs scripting. I think what people really want is to reduce the risks of writing bad things. Locking down using XML is one way to achieve this, but it’s not the only one. For example, Gradle build scripts may be linted. In other words, you can apply on a Gradle build the same tooling you are used to work with when dealing with your own code: checkstyle, findbugs, … You don’t have to, but you can.

The consequence is that yes, there are many different ways you can layout your build with Gradle. This is not different from how you can layout your code in a project: we don’t tell you in which package you should put your beans, services, … However, there’s a big misconception that I’d like to fight:

By default, for a Java project, Gradle follows the same conventions as Maven.

That’s as simple as that. Sources will be in src/main/java. Tests will be in src/test/java. Gradle gives you the freedom to diverge from this convention, but this is not encouraged, and to be honest, I’ve almost never seen any build diverging from those conventions. On rare occasions, those were actually builds migrated from other build systems (in particular Ant) where at the time there wasn’t any convention. Gradle offers the flexibility to reuse an existing layout without much hassle.

Gradle is too flexible?

All in all, the argument that "Gradle is too flexible" is a fallacy. It’s all about good engineering practices, putting the right tools in place, and this is nothing different from any engineering work we do everyday. If you can do it for your code, you can do it for your build. The interesting thing is why you think you shouldn’t have the same quality expectation levels for your build as you have for your code. Often the answer is just "I don’t care much about the build, I’m writing code, this is what I’m paid for".

And this is where the discussion becomes interesting, because I think this is a bias that lots of developers have. They don’t even realize how much time they are losing.

Tell me, how likely is it that you change your build scripts, compared to the number of times you’re effectively going to run mvn clean install or gradle test? The reality is that you’re running the build much more often that you change it. Therefore, correctness, incremental builds, incremental compilation, compile avoidance, task output caching, are far more important to developer productivity than the declarativeness aspect.

Sure pure declarativeness is a good thing and this is why I encourage Gradle users to write nice, synthetic build files, but this is not the most important aspect for developer productivity.

My point is therefore that if you only focus on the surface, that is to say the language used to express the build (XML vs Groovy/Kotlin), then you’re missing the most important part to me, which is the underlying Gradle model, far more advanced than what you have in other tools. The Gradle API surfaces this model and has a number of advantages:

  • A task can be seen as a function. It declares inputs and outputs. For the same inputs, the output are always the same: this provides up-to-date checking and cache-ability.

  • A task inputs can be another task outputs. This provides implicit dependencies: Gradle knows that if you want to run "test", you have to compile first, but it also knows that whatever else is an input to the tests need to be executed.

As a consequence, I already wrote about why it’s wrong to think that Gradle doesn’t have lifecycle tasks. In fact, Gradle has them, but is also significantly more precise. The "phase" approach of Maven is way to coarse: it’s doomed to execute too much, prevents smart parallelism, and leads to dirty workarounds (-x .... on the CLI to avoid things you know are not necessary).

Similarly, say you want to test your application on different JDKs and have a single build execute tests for all target JVMs, which is different from the JVM which runs the build tool. With a scripting approach like Gradle, this is totally doable. I won’t say easy because we can definitely do better to make this use case better, but the underlying model makes it quite simple. You don’t want to rebuild your application for each target VM. All you want is to test on different platforms, and therefore the only step should be a different target VM for test execution. Tools like Maven force you into arbitrary things like defining Maven profiles, and force you into rebuilding everything. This is a giant waste of time for something you don’t need!

In a different topic, this is no surprise that Gradle can build for different ecosystems: Java, Scala, C++, Kotlin, Kotlin Native, Python, … The underlying infrastructure makes it possible. Even for a single ecosystem, Gradle can declare what the difference between a Java Library, a Java Platform or an application is.

I could talk hours about why it’s important to model properly software, and actually with the release of Gradle 6 we’ll have a series of blog posts explaining why we think it’s a game changer in terms of dependency management. If you’re tired of having to fix the same "multiple slf4j bindings" in each and every project, tired of Guava being upgraded from jre to android, frustrated by incompatibilities of Scala 2.11 and 2.12 dependencies, tired of not knowing which of those Maven optional dependencies is important for you to add, you’ll understand what I mean.

Direct answer to some tweets

I’ll try to answer more direct questions in this section. Sorry if I missed yours, I got quite a few comments/answers…

I would sacrifice caches, dependency locks and better plugins to version to have a declarative build process instead of an imperative one. Give me a declarative Gradle and I will love it.

Again, I think this is the wrong tradeoff. Given that you run the build way more often that you change it, declarativeness (that you can have with Gradle) shouldn’t be the goal. Your goal should be to reduce your build times, make your build reproducible, improve your developer productivity. Declarativeness is not a goal, it’s at best a mean, but not sufficient by itself. A declarative Gradle, whatever that means, would help you reduce the cognitive overhead, but wouldn’t help you better model what your application needs.

make a one liner the ability to publish on different repos the snapshot and release artifacts. The way it was done on Gradle 4.x was broken on 5.x and the only way we found to do it is a horrible hack

Here’s a webinar about publishing. Publishing is not complicated with Gradle. It used to be poorly documented, and the old publishing plugins didn’t help. But publishing to a snapshot repository should be trivial already.

Some people will prefer to do their own way, some people will prefer to have a less expressive tool that will produce similar build processes on their projects. Gradle give you the former, Maven the latter. As I say, a matter of taste.

A less expressive tool reduces the risks of writing bad builds. It doesn’t help, however, in developing correct, reproducible, fast builds. An, again, I disagree that Gradle leads to "custom builds" everywhere. Most people stick to the defaults and are very happy with them. The more complex builds you find in the wild are those which have indeed very specific needs, or need to be tweaked for performance, producing more artifacts, combinations of artifacts or testing. Things that you can’t easily do with Maven profiles, for example, because profiles are adhoc solutions which do not combine well.

Gradle tries to create a fake sense of declarativeness, but it is just an illusion.

It’s not an illusion. Gradle has a clear separation between its configuration model and execution model. All tasks have declared inputs. The plugins create either new tasks or conventions. This is not an illusion, this is the reality. Now, because you can write if or loops doesn’t mean it’s not declarative, it’s imperative-declarativeness. And yes, you can end up with giant build scripts with "code" inside. If you have, do yourself a favor, refactor your build like you would with your code, because no one should tolerate this. Use buildSrc, this is your friend.

I think library dependencies is not correctly supported by IDEs and Java modules are better.

That’s not correct. We’ve been using the native Gradle IntelliJ support for years at Gradle, with api and implementation separation, and it works exactly like it should. Implementation dependencies are hidden from consumers, like they should. If you don’t see this, either you didn’t declare the dependencies or you have a bug in the IDE, in which case it needs to be reported.

Even worst, Gradle don’t have an official plugin to deal with module-info. there was an old post that says it is not necessay with Gradle because lib dependencies were better (they don’t)

I don’t think anyone said you don’t need module-info. There are different things in play:

  • separation of API and implementation: Gradle supports this, and it maps to requires vs requires transitive

  • declaration of public API packages: Gradle used to have this with the deprecated "software model". It still has to be backported to the current configuration model. For this, module-info works fine but it forces you into using the "modular world", which a lot of libraries, frameworks and IDEs are not ready for.

  • declaration of services: Gradle doesn’t support this.

Can you use modules with Gradle? Yes, there’s a quite good plugin to do it. We are planning to support modules and modularity in general better in Gradle, but not short term, because we have bigger pain to solve for our users first. It doesn’t mean we don’t consider this important.

I don’t get why Gradle allow you to explain what your app is better than Maven. In fact I think it is more difficult to explain it on a script that descriptivelly.

I think the question is what Gradle models better than Maven. A good example here is api vs implementation dependencies. Because Maven uses the same descriptor (pom.xml) for the producer and the consumer, a dependency declared in the <compile> scope ends up on the compile classpath of the consumers. This is leaking internal implementation details to consumers, which is very bad because it makes it very hard to evolve libraries, because changing an internal dependency would break consumers which accidentally started depending on your own transitives. This is just an example of course, there are many other differences (like, why we consider that exclude is a bad workaround in general, more on this topic in Gradle 6, if you want to read our docs).

The builds I’ve seen have been very spaghettish and clearly copy-and-pasted together un-understood recipes from SO.

Yes, there are bad builds out there. With Gradle it’s frequent for quite old builds from early adopters. More recent builds tend to be much cleaner, because we made a significant effort in guides, getting started samples, documentation. You’ll always find bad things, and it should be encouraged to fix. On this topic, tools like build scans really help. And copy/pasting from SO is indeed a bad thing. If you copy and paste without understanding what it does, well, bad things can happen… That said I’ve seen very scary Maven builds too, and believe me or not, some of our customers wouldn’t be proud to show you their Maven builds. It’s the "personal experience fallacy". I’ve experienced very clean Gradle builds, you’ve experienced very bad Gradle builds. I’ve also written bad Gradle builds, which I dramatically improved, making them more correct, faster, … Gradle is like any other technology: learn it and you can understand what it brings.

Gradle performance/caching are very attractive but the scripting possibility is a deal breaker. A « declarative-only » Gradle would be perfect for people like me.

Again I think "declarative" is the wrong term here. Locked down to reduce the risks of doing bad things is what you want. It doesn’t matter if it’s Kotlin, Groovy, XML or whatever else. It doesn’t matter if you can use if or for loops. What matters is what you can express, and what should be limited. It’s all good engineering that we must share within the industry, find the best patterns, discourage the bad ones. There are quite a few things in the Android world (which uses Gradle) in this direction. We, at Gradle, should do more, but it’s always a matter of priorities: fixing the most important user pain first. By the way, we provide a Maven build cache with Gradle Enterprise. That is to say, the ability to cache Maven builds using Gradle Enterprise. However, this is limited to "clean builds" (which Maven users are used to do in any case), because of the limitations of the Maven execution model (no knowledge of what each plugin or mojo does, where it writes files, …).

IMHO the biggest feature of Gradle that Maven doesn’t have is the ability to change the version of the project

Well, this is just an accidental example of the interest of having access to the API in a build script. It offers a number of options for the release process, but that’s not the only one.

My only complain about @gradle is how it is unnecessarily complex to deploy a multi-module project to central. Too much copy & paste, or you need to make an init script, which I still haven’t managed to do.

Technically the problem is not "how to deploy a multi-module project to Central", but rather, how do I avoid duplicating configuration between scripts. This is what buildSrc is for. As soon as you have repetition, then, it means a plugin makes sense. buildSrc can be seen as "local plugins", and this is where you should write your common code. Then each project applies a plugin to publish. This is a composition model, as opposed to the inheritance model of Maven.

I like all those (caching, incrementality, …) , in theory, but for my needs they are more complexity than feature

I don’t think those are complexity. A task declares its inputs. If you do, you benefit from up-to-date checking, and with a bit more configuration, caching. You don’t have to. If you don’t declare the inputs/outputs, you’re back to the "Maven" approach where the build tools knows nothing about what a task does, at the difference that Gradle knows that it knows nothing, so can be a bit smarter. As soon as you start declaring your inputs, you benefit from more. It’s more work, for sure, but it’s not that complex and the benefit is huge.


Chroniques d’un introverti en télétravail

29 September 2019

Tags: télétravail introversion

L’autre jour j'écoutais le podcast Les Cast Codeurs qui abordait le sujet du télétravail. Quelques remarques m’ont fait tiquer, je m’en vais donc ici vous raconter mon expérience, mais surtout vous parler de moi et de l’introversion.

Le télétravail et l’introversion

Voici maintenant presque 10 ans que je suis presque à 100% en télétravail. Je dis presque, parce qu’en pratique, j’ai quelques déplacements professionnels (conférences, meetings) de temps en temps, mais pour mon boulot de tous les jours, c’est tout à la maison. Avant de faire du télétravail, je roulais beaucoup: mon emploi était sur Nantes, à 45km de chez moi. Ca faisait donc 90km par jour, mais surtout entre 2 et 3h de transport par jour (eh oui, j’avais la chance de devoir traverser le pont de Cheviré, pour ceux qui connaissent…). Bref, le jour où j’ai changé d’emploi, pour passer chez VMware pour travailler sur le langage Groovy, le premier choc pour moi ça a été de récupérer ces 2 ou 3 heures par jour. C’est autant de temps qu’on peut passer à s’occuper de ses enfants (les déposer à l'école, les emmener au sport, …) ou à faire des activités à la maison (jardinage, sport, …). Je ne reviendrais pas sur ces aspects, parce qu’ils sont largement connus, le seul "inconvénient" pour moi étant surtout d'être capable de maîtriser ses horaires, c’est à dire de ne pas, contrairement à ce qu’on pense, faire trop d’heures !

Non, ce sur quoi je veux revenir, c’est cette remarque d’Antonio Goncalvés, qui, en conseil, dit en substance:

"Balancez votre cafetière, sortez dans les bars, voyez des gens, c’est important de voir des êtres humains!"

Et ceci m’a fait réagir, j’aimerais donc revenir sur le sujet. Tout d’abord, revenons sur le fait que ce conseil ne fonctionne que si vous habitez en ville, ce qui n’est pas mon cas. Je suis en campagne, à 5km du bourg, donc faire une "pause café", ça prend du temps dans ces conditions.

Mais revenons surtout sur le fond du sujet: "C’est important de voir des êtres humains", ou ce besoin de ne pas être seul. C’est un sujet qui me tient à coeur et qui résonne avec une des questions que j’ai souvent lorsque je parle du télétravail:

"Mais tu n’en as pas marre d'être tout seul, de ne voir personne ?"

Alors, répondons franchement: non.

Autant je comprends les personnes qui en ont besoin, autant, ne croyez pas que tout le monde fonctionne comme vous et a besoin de voir du monde. Certaines personnes, comme moi, vivent très bien sans voir personne. Je peux passer des journées entières seul, sans que celà ne me pose le moindre problème, ni ne me cause le quelconque manque de relations humaines.

Je vais partie de cette catégorie de population qu’on appelle les introvertis.

Un introverti, contrairement à une croyance populaire, ça n’est pas un associal, un égoïste ou quelqu’un sans empathie.

Un introverti, c’est quelqu’un dont l'énergie sera drainée par la foule, par les relations inter-personnelles, c’est l’opposé d’un extraverti qui a besoin de monde pour regagner de l'énergie.

Un introverti, c’est quelqu’un qui ne supportera pas les conversations de comptoir, parce qu’elles ne lui apportent rien d’autre qu’une perte d'énergie.

Un introverti, c’est quelqu’un qui pourra vous tenir une conversation passionnée sur un sujet qui l’intéresse, parce qu’il en retire quelque chose: l’interaction en vaut la chandelle.

Déja tout petit, j'évitais les groupes, je n’avais pas beaucoup d’amis (mais ceux que j’avais à l'époque, je les ai toujours). J’ai toujours eu une peur bleue de me retrouver dans un groupe où je ne connaissais personne, que ce soit à l'école, au sport, … Mais même si je connaissais quelqu’un, se retrouver dans un groupe, à devoir cultiver des relations proches, extra "professionnelles", était d’une extrême complexité pour moi (et ça l’est toujours). Tout ce qui m’importait à l'époque, c'était d’apprendre, être "fort" à l'école, ce qui m’a valu d'être traité "d’intello", parfois chahuté, ou d’avoir des remarques pas particulièrement gentilles d’autres élèves au dos de ma photo de classe, ceci pendant une grande partie de mon enfance…

Par exemple, j’ai toujours refusé les camps de vacances (ma seule expérience, une semaine à faire du cheval, fût tellement une horreur pour moi que je m’en souviens encore). J’ai aussi refusé toutes les classes de neige. En revanche, j’avais accepté d’aller en voyage scolaire en Angleterre, en Irlande, en Espagne, non sans lutter contre moi-même, parce que je savais que je pouvais en tirer quelque chose, mais aussi parce que j’avais la garantie de me retrouver en petit nombre, avec un copain, dans une chambre…

Dans la même veine, devoir se retrouver au tableau pour réciter une poésie, ou, pire, chanter, tenait de la torture. J’ai adoré la fac' de sciences, parce que je pouvais passer du temps au "café" avec 2/3 potes maximum, à discuter. J’ai détesté mon école d’ingénieur, où j’ai du rivaliser d’astuces pour éviter les soirées d’intégration, tonus et autres dont étaient friants 95% des étudiants: se faire reconnaître sans se faire exclure (mais j’ai encore trouvé quelques bons amis que je tiens de cette époque).

Aaah, les soirées d’intégration: ce qui est marrant pour certains, se bourrer la gu…, humilier "gentilement" les autres, c'était juste pour moi quelque chose d’horrible. Tiens, d’ailleurs, peu le savent, mais j’ai fait toute ma scolarité à Nantes, non pas parce que tout était disponible là bas (c'était le case), mais parce que j'était terrifié à l’idée de me retrouver seul dans une FAC, une école d’ingénieur, à l’autre bout de la France… Certains profs m’avaient reproché de ne pas tenter une "Grande Ecole", mais je pense qu’au final, je m’en suis plutôt bien sorti !

Jamais je n’embaucherais quelqu’un comme vous!

Ceci pourrait vous paraitre surprenant pour quelqu’un qui, aujourd’hui, donne des conférences devant, parfois, des centaines de personnes. Mais alors, quelle est la différence ?

La différence, c’est que lorsque je vous parle dans un cadre professionnelle, je maîtrise mon sujet (ou je pense le maîtriser, ah ah !). Je peux vous parler ouvertement, parce que je sais que les questions qu’on va me poser seront sur ce sujet. Il n’y a que peu de place à l’inconnu.

C’est aussi pour celà qu’il m’est très difficile, encore aujourd’hui, d’aborder des gens que je ne connais pas. Je ne sais pas faire de "small talk", comme on dit. Mais ça va plus loin: j’ai fais pas mal de déplacements à l'étranger, aux US par exemple, mais JAMAIS, je ne suis sorti seul pour visiter (au mieux je marcherai une heure ou deux dans les alentours). On rentre dans cette zone d’inconnu qui me met tellement mal à l’aise : devoir s’adresser à des gens, qui plus est à l'étranger, pour commander un plat, pour demander son chemin: celà me demande trop d’efforts, me draine trop. En revanche, si je connais une ou deux personnes et qu’elle me proposent de les accompagner, ça se passera bien: j’apprécie fortement une sortie en "petit comité". Tout le monde me dit que j’ai tellement de chance de partir voyager, voir du pays, mais moi, je déteste tellement voyager, en tout cas sans ma famille… Rien qu’aller à Paris, me rendre compte du nombre de personnes qui vivent là bas, me sentir étouffer, qu’est-ce que j’ai horreur de ça !

La conséquence, c’est que je fuis comme la peste les "soirées" comme les speaker dinner, les événements d’entreprise, … Souvent, on les présente comme des incontournables du "réseautage", et c’est vrai qu’on y apprend souvent des choses intéressantes, mais elles sont extrêmement stressantes pour moi. La plupart du temps, j’essaie de trouver une tête connue et je "m’accroche", mais je ne fais jamais long feu. Ce qui me terrorise s’est d’en arriver à des sujets extra-professionnels, là où je n’ai AUCUNE "compétence". Certains diront que je suis chiant, que je n’ai aucun intérêt, et c’est probablement vrai si vous recherchez quelqu’un à la vie extraordinaire, la mienne n’est pas ultra passionnante :)

Si vous en arrivez là, vous devez vous dire que je ne dois pas être un très bon "team player", comme on dit. Paradoxalement je ne pense pas que ce soit le cas. En effet, il ne faut pas confondre mon incapacité à avoir des relations inter-personnelles "simples" avec la capacité d'échange, d’interaction professionnelle, qui est sur une toute autre dimension.

Comme je vous l’ai expliqué, je donne régulièrement des talks, et j’adore plus que tout partager ces connaissances, aider les autres. J’aime aussi travailler avec des gens plus compétents que moi pour avoir l’autre face de la pièce: apprendre, comprendre de nouvelles choses, progresser. Et dans ce contexte, travailler en équipe aide énormément.

Alors, ce n’est pas parce qu’on est en télétravail et qu’on ne voit personne qu’on travaille seul. Non, on est en équipe. On fait des "daily standup" (via Hangout/Slack), on s’organise, on fait des petites réunions "face to face" de temps en temps, bref, je pense, mes collègues vous le diront si ça n’est pas le cas, que ça se passe plutôt bien.

Bref, n’ayez pas peur de cet aspect: la solitude n’est pas, pour tout le monde, un problème. Elle peut, au contraire, aider à la productivité: pas de réunionite inutile, capacité à se focaliser sur un problème des heures durant, … Elle n’est pas, non plus, signe de quelqu’un qui ne peut pas travailler en équipe: ça n’empêche en RIEN d’aider ses collègues, ses clients, bien au contraire: puisqu’on sait que la relation est professionnelle, elle est focalisée et bien plus efficace.

Pour vous donner une idée, chez Gradle, tout le monde est en télétravail. Mais pour cet aspect "socialisation", nous avons une réunion hebdomadaire, facultative, appelée "coffee time" où chacun peut rejoindre la réunion et parler de sujets extra-professionnels. Certains en ont besoin, pas moi. Au contraire, j’aurais du mal à arriver à cette réunion et savoir de quoi parler. Pire, j'évite au maximum d’arriver en premier à une réunion de peur de ne pas savoir engager une conversation…

Mais encore une fois: parlez moi d’un sujet que je maîtrise, demandez moi d’expliquer un problème, de chercher une solution, d’aider quelqu’un: il n’y aura aucun problème, parce qu’il n’y a aucune place à l’inconnu. Il est même fort probable que j’apprécie énormément une conversation entre nous: si je ne viens pas vous voir, ça n’est pas que je ne souhaite pas vous parler, c’est que même si je vous connais, engager une conversation reste quelque chose de très compliqué pour moi. Venez me voir, engagez la conversation et tout se passera bien ! :D

Alors, ne vous étonnez pas si je vais trois fois le tour du quartier plutôt que de demander mon chemin. Ne vous étonnez pas si je ne téléphone jamais, ne texte jamais.

Mais si vous faites partie de mes amis, vous avez énormément de chance: c’est que je tiens beaucoup à vous et vous tiens en haute estime !

N’ayez pas honte d'être introvertis, faites comprendre ce que c’est

Je terminerais pas une remarque: dans mon Tweet original, je disais que je "me soignais". C’est vrai et c’est faux à la fois. Quand je dis que c’est vrai, c’est parce que conscient de l’importance et de la "non reconnaissance" de cette difficulté par les autres, j’essaie de travailler, notamment la prise de parole. Je suis, par exemple, secrétaire du club de Karaté, ce qui me force à communiquer avec des gens que je ne connais pas. Je suis aussi le coach de l'équipe de basket de mon fils de 10 ans, ce que j’adore faire: c’est une activité avec son enfant, qui est à la fois publique, mais aussi tellement gratifiante, voir ces enfants heureux de jouer, gagner, … et ça me permet de travailler sur les relations avec les parents !

Et surtout, c’est aussi un message pour mon fils, qui a 10 ans donc mais me ressemble tellement: il a lui aussi beaucoup de mal à parler aux gens, mais je qu’il travaille dur pour se faire accepter. Lui aussi est si fier lorsqu’il a la reconnaissance de ses pairs… Il m’a fallu des années avant de mettre un nom à ce que je suis, un introverti, et aujourd’hui encore, je lutte pour ne plus en avoir honte.


Dependency Management at Gradle

11 July 2019

Tags: gradle dependency management

Opinions are my own, not those of my employer

I joined Gradle 4 years ago, and I spent the last 2 years almost exclusively working on dependency management. The more I work on this topic, the more I am frustrated by the state of our industry. In this blog post I will mostly illustrate my points with Java, which I’m mostly familiar with, but a lot of them stand true whatever the ecosystem (Javascript, Python, Go, …).

Soon, we should release Gradle 6 (fall 2019, no promise, as always, this is software). This version will be the first one to turn the spotlights on dependency management. This will be for me the achievement of 2 hard years of work (not alone, of course) but this is just the beginning. Gradle probably has the most advanced dependency engine of the market (forgive me if I’m wrong, let me know). But what makes it so different is not that it has powerful features like dependency substitution, customizable resolution, dependency locking, alignment, etc… No, what makes it different it’s that we put a lot of emphasis on semantics: model software correctly so that you, as a developer, have less to handle.

Often, folks "from the outside" are considering us arrogant, because we don’t immediately support things that other engines do (eg. "you don’t want to implement optional dependencies, look, Maven has it for years you s***"). While I understand the frustration, it doesn’t mean that we don’t hear. In fact, we hear you loud, but the time it takes to land is just the consequence of willing to implement the correct solution to a problem.

For example, what does an optional dependency mean? A few months ago, I read this from the Yarn documentation which got me scared, and, to be honest, a bit despaired too:

optional deps yarn

This looks like total non-sense to me. Because we needed the infrastructure, it took some time but we implemented what we think is a better solution. In a nutshell, optional dependencies are not optional. They are things that you need if you use a particular feature of a library. So it means that if you depend on something, and that this something has optional features, you can say what features you need and Gradle would give you the correct dependencies for this. We called that feature variants. Granted, the name isn’t cool, but it’s a matter of time until we refactor the documentation to make it easier to discover.

Similarly, we implemented back in Gradle 3.4 the separation of API and implementation dependencies for the Java world. In fact, that’s one of the reasons the compile configuration has been "soft deprecated" for years now, and that we’re going to nag you starting from Gradle 6. I still hear people claiming they don’t need this and that it’s hard to understand but I stand by the fact they deperately need them.

Why is it important? Because if you are a library author, you know that there are things that are "your internal sauce": things which are implementation details, not part of the public API, and that should never be exposed to consumers. This is the very reason Java 9 shipped with the module system: strong encapsulation. However, how does it work for dependencies? There are also dependencies which are part of your API and others which are not. Say you use Guave internally. None of the Guava classes are visible on your public API, and it would be an error to do so. Then it means that Guava is an implementation dependency of your library. When you do this, you should be allowed to replace Guava with something else at any time, without breaking any of your consumers. The horrible reality is that if you use the Maven <compile> scope, those dependencies are going to leak to the consumers, and they could accidentally start using Guava just because it’s available on the classpath (yeah, IDEs love this, the class is available for completion you know!).

This is a problem with Maven because the POM file is used for 2 distinct purposes:

  • representing the point of view of the producer, where <compile> means "I need this on my compile classpath"

  • representing the point of view of the consumer, where <compile> semantics are there broken: it means "add this to your compile classpath", but it means you leak dependencies which should have been on the <runtime> scope!

With the Gradle Java Library plugin, those issues go away: we model those correctly, and when we generate a POM file, it has dependency declarations which make sense for the consumer. I’ve been battling to explain this in conferences for years, yet, lots of people don’t get how harmful to the whole ecosystem that design decision from Maven was: it just prevents smooth dependency upgrades, and contributes to the "classpath explosion".

In other words, you, as a developer, should always know what you directly use (your first level dependencies).

As another example, we’ve been yelling for years how bad exclusions are, but we did a really bad job at explaining why. The problem is also that we didn’t have all the tools we needed to workaround them, so we said "yeah it’s bad" but didn’t really say that you can still use them in some cases.

In a nutshell, an exclusion is bad because the dependency resolution engine doesn’t know why you excluded a dependency:

  • is it because the producer had bad metadata, that the dependency should have been "optional", or just absent altogether?

  • is it because you don’t use a specific code path of a dependency and you just want to slim down the size of your distribution?

  • is it because something breaks if you use this dependency?

  • is it because it’s yet another logger on the classpath and this is not the one you use?

Well, again, for all those use cases, the solutions are different. The logging use case is an illustration of this: how many of you have faced this infamous problem of having multiple SLF4J bindings on the classpath? How do you fix that with Maven? Exclude of course!

But wouldn’t it better if you could express that "between all those logger bindings, this is the one I choose". Wouldn’t it better if, as a producer of a logger binding, you could say "I implement this logger API, and it doesn’t make sense to have multiple logger bindings on the classpath at the same time". Well, this is what Gradle offers you, as a producer and as a consumer.

Modeling software is important, because it makes the industry better as a whole. By explaining why instead of how, the dependency management engine can take better decisions. It can fail if things are incompatible, it can ask you to choose between different implementations.

Do you need another example? Look at all those "Maven classifiers". How many times did you got multiple conflicting implementations of the same thing just because they had different classifiers (looking at you, Guava!).

The reality is that a classifier is a workaround for a bad model, incapable of expressing that you have different things published at the same coordinates. Sometimes I read comments like "Gradle is just Maven with a Groovy DSL". This is wrong at so many levels: Gradle empathizes on strong modelling of software. We need to think in terms of components ("this is a library", "this is a Boot application", "this is a Gradle plugin"), not in terms of conventions. Models are orthogonal to conventions: conventions are just a tool to make modelling easier to implement, but what matters is the model. The DSL also doesn’t matter: Groovy, Kotlin, whatever. What makes Gradle powerful is that it understands what you build.

This is one of the reasons we came with Gradle Module Metadata, which is going to be enabled by default in Gradle 6.

We, at Gradle, think that we can save a lot of developer time by simply putting more sense in those things we publish. It’s a waste of time and energy that we all have to fix, constantly, those conflicts between libraries.

And can we talk about ethics? It’s beyond me we can tolerate, as developers/engineers, repeated approximations, errors, just because Maven does it this way? I don’t really care that we’re not compatible with Maven, as long as we solve the problem and that we move towards well designed, better solutions. Sometimes we have to make tradeoffs, but we can’t compromise on reproducibility, correctness and performance. Of course, we do our best to provide Maven compatibility, and again, sometimes make it even better in some situations (the Java Library plugin).

My goal is that we, as a whole, move towards a better software delivery world.

The good thing is that what we’re not alone. This, is the result of years of experience from the team with very large builds, from customers of small to very large organizations, and discussions with talented open-source developers (special thanks from me to Andy Wilkinson from the Spring team).

I posted this earlier this month on Twitter, this is a real dependency graph, from an organization I have the opportunity to work with:

real dependency graph

This is not uncommon, this is the reality we live in.

And when you have such a dependency graph, you desperately need more modelling. Does it mean that Gradle is perfect? Hell, no. We’re going to make mistakes, we already have and we will continue, but what matters is that we’re moving towards our goal.

There are lots of good things coming in Gradle 6, stay tuned. In the meantime, a lot of what I discussed here has been presented in a couple of webinars:

Another webinar is planned after summer, around multi-repository development.

Hope you’ll enjoy!


If you like this blog or my talks, consider helping me acquire astronomy equipment

Older posts are available in the archive.