Inside the mind of a TechLead: dev or not dev ?

[This is the second article of a serie about my experience as a TechLead. The first one can be found here.]

This is one of the main questions that arises when starting to work as a TechLead inside a team, if this role is new to you: « Should I spend time coding with the team? But shouldn’t I also spend time not coding, and coaching the team? »

In fact, in my humble opinion, this question rapidly becomes obsolete. It may be a relevant one when you just start, and the TechLead role is brand new to you. But as time flies, this question becomes less and less relevant, because it is too simple. And also because everybody knows the answer: of course, you must spend time coding! And of course too, you must not spend all your time coding!

The real question is: how do you make my time the most fruitful for your team(s), and around it? The answer is: it depends. It depends on multiple factors, because in addition to take care of your own work inside a collaboration – your main concern as a developer – the TechLead must sense the outside of this collaboration on one side, and how the whole group is moving (is it moving fast/well enough, etc…) on the other side.

And sometimes, to let the team move better or faster, it is by coding. But what the key thing that has changed is this: you don’t code anymore to deliver yourself (as part of a team). Your coding activity becomes a tech-coaching activity: you must teach coding in the projects code. It’s time to produce your best code, in small chunks, in places where the team need to progress somewhere. It is also coding, but a lot more challenging. You won’t be able to come back a lot and re-think what you’ve written. Because it’s better to hand over it to your team.

Understanding Gravitational Waves in 4 steps

You want to understand Einstein’s gravitational waves in 4 steps? No picture, no equations? Easy. Here it is.

Step #1, Year 1905: Einstein publishes the theory of Special Relativity. It says, among other things, and for reasons too long to explain here, that ‘space’ and ‘time’ must not be considered separatedly (as we always do), but actually are the components of one thing, called the … ‘space-time’. Practically, it means you can’t just make computations with space or time. But you must consider both together. Especially if you have a speed close to the speed of light (which is not infinite). In this new theory, that speed of light has a peculiar role: it is absolute. When you measure your speed relative to the source, no matter where you look at (if you look right into the beam or along it), you always get the same value: the same speed of light. Always. Really, always. You simply can’t go faster than that.

Step #2, Year 1907, Berne: The famous « most thoughtful » idea of Einstein: acceleration is indistinguishable from gravitation. Physicists call this the Equivalence Principle. We all stand in out feet on Earth’s surface. We feel gravitation. In fact, this can be re-stated as feeling a permanent acceleration, since Earth physical surface prevent us to follow a free-fall trajectory in space… Astronauts, assuming they have the eyes closed and forget for a second that they are in space, and there is truly no air, follow in fact a free fall trajectory. They don’t feel the gravitation. They feel no acceleration. Hence gravitation, similary to linear motion, can be « cancelled » in the right reference frame. When you travel in a plane, you don’t feel the motion during all the flight right? But people looking at you see clearly you move. Same thing, for acceleration. Einstein imagined this that a man inside a closed elevator having an acceleration equals to the value of Earth gravitation will feel exactly the same as a man not moving, but on Earth standing on his feet. Gravitation is equal to acceleration. And vice-versa.

Step #3, Year 1911, Prague: Imagine the same man inside that elevator going up with a constant acceleration (hence its speed is constantly increasing). Imagine a small hole in the side of the elevator where a beam of light can enter. Since speed of light is not infinite, and size of the elevator is non zero, it takes some time (pretty small, but still) for the light to enter the elevator and reach the other side. Since the elevator is going up, the point reached by the light is thus lower than the entry point. Hence the trajectory of light inside the accelerated elevator is … curved. But remember that acceleration and gravitation are equivalent?

Well, that is General Relativity, ladies and gentlemen: gravitation is curved space-time, period. And space-time is curved because of the presence of matter. All dynamically, which makes things even more beautiful…

Step #4, 1916, : In particule physics we know that when we shake electrons, waves are created. Electromagnetic waves, the other name for « light ». Einstein predicted that when shaking masses, this should also create waves. Gravitational waves. That was the prediction of the existence of gravitational waves. But Einstein never thought possible to detect such waves. Since one must need an enormous, in fact ultra-giganomous, amount of energy released to produce these waves, and even then, the effect would be ridiculously small.

Guess what LIGO detected? A merging of two 30-solar-masses black holes, releasing as much energy in a few microseconds as all stars in the visible universe, and the effect detected on Earth is of the size of one 10 000th that of a proton!

You can’t beat science in the awesomeness.

If you like this post, tell me about it! I may be to prepare some more. This one in particular is a worked out and personnally twisted transcript of the explanations of  french scientist and educator, Etienne Klein. Here is the video (in french).

In the mind of a TechLead : kickoff

[This is the first article of a serie. The next one is here].

I started just a month ago to work as TechLead inside a developers team for a ambitious software project. This role isn’t entirely new to me, since I worked as « Head of Software » for a startup during 2 years (though I was overwhelmed with all operational aspects of the « research and development department » – that is, 90% of the company). This time I can focus on that interesting role.

I would like to take the occasion of this new adventure to share some of my thoughts, trying to explore as many apsects of it as I can. That is, technology, of course. But also, self-confidence, communication, architecture, career paths, mentoring, politics…

(Just a bit of context: I’m 44. I’ve been starting my carreer as an astrophysicist, then switched to software development in 2011, worked for small companies and startups, as well as larger organisation. I did quite a lot of scientific coding, modeling, image processing, but also a professional desktop app, iOS apps, scientific libraries, app components, REST APIs and a front-end webapp. Whatever the details, I’ve eaten quite a few langages, in quite a few contexts, and most importantly delivered in production quite a few products.)

The first idea that come up to me, when I look back to this short month is: a TechLead must have an acute sense of balance. A lot of rational and less rational expectations are put on the shoulders of that role, both from technical and non-technical people. That was particlarly true when I arrived: the project has a team of 6 juniors developers, a scrum master, an architect, two product owners (and a project manager), and was already working since about 3 months. But everybody in the development team and the management around it shared the feeling that the project strongly needed some « seniority », given the contrast between the juniority of the team, and ambition of the project (a subject on its own).

Thus I quite strongly experienced the need of balance between various things. But let’s focus on the most relevant one for this special moment that the few first weeks are.

I mostly felt the need of an acute sense of balance between the urge of fiting myself into the new organisation on one hand, and using my ignorance of the details to challenge existing hypothesis, on the other hand. With a very open-minded management (a thing that I can’t stress more the importance), people are very keen to hear you about what they could have done better or even wrong. This is a power you have during the first weeks, and there is only a very short supply of it. You have to use it wisely to speak out and share your impressions carefuly.

It is also the occasion to provide already what you think will be the overall direction of your action. The latter point don’t make you fit into the role right away, but at least it helps you fill it.

In other words, if you enter a mostly problematic working environment (as it was, in my case), you should rapidly reveal issues (but without exaggerating them!) and draw possible lines of solutions (without imposing them!). That’s a very fine balance. If you insist too much on problems, or appear to be too rapidly emotionaly involved in these problems, it’s easy to understand you might not fit for the role, or that you won’t simply be part of the solution. The risk exists of being pushed out of the project right at the start.

Moreover, if you try to impose solutions, you rapidly loose credit: how can you have a sense of the big picture already now? Problems that haven’t been solved after a few weeks or months are necessarily interconnected with other forces and/or people. People that are certainly of good faith, trying to do their best. You cannot do more than suggesting solutions, and if possible, solutions that are based on hints the management might have given you, more or less explicitely (you are necessarily ‘utilized’ by someone to modify an existing state of things – this is normal).

If you invoke your « huge » experience to try to impose solutions, you appear to justify yourself, and weaken your position already. (Virility demonstrations in tech environments will require its own post.) And you must remain open to solutions suggested by others, and solutions that don’t make you necessarily happy, while at the same time you are still adjusting yourself to a new context, a new place, new people, new tech stack… It’s hard.

In the opposite case of a mostly positive environment, this time is good to draw long-term guidelines of your action too. In both cases, you can earn a large amount of credit if you manage to rapidly acquire trust from the team, and both provide rapid help for existing issues.

How to achieve this sense of balance? There’s no magic. Personally, I can see only two things: listen and sleep, from day one. Listening everything is key. Listen to everybody, pay attention a bit on the body langage, but mostly to confirm impressions, listen in every occasion, meetings, lunchs, listen all the time. This is exhausting. Thus make sure to sleep enough. You’ll probably have time to rest a bit more after a few weeks.

I hope you found this post interesting. It outlines a bit the subjects to come in this serie of posts: how to acquire trust from a team, how to deal with autoritative figures, the balance between being strong, and being a part of something you can’t control… Stay tuned!

The v0.8 software malediction (and resolutions for 2019)…

Life in Software-land follows the rhythm of version updates. And big jumps in numbers is usually reflecting what happens under the hood (except for the Linux kernel sometimes): big changes, big rewrites, big decisions, all of them at the same time. Long ago in my own Astro-Software-land, I was developing my famous macOS app: iObserve, which remained in the swamp of the beta phase for a long serie of months. (The beta phase is this period of time before the confidence on the capability of the mentionned software being actually useful reaches an « acceptable » level for the developer.)

iObserve never reached the v0.9. I had to stop development, rewrite a big part of the app, and jump right into 1.0 (I then submitted it to the Mac App Store).

v0.7.16. That’s the current version of (see the changelog). was meant to become my new flagship software for the years to come. Still, I hit the v0.8 malediction. I hit it hard. I feel that a lot has to be rewritten. The good news is that the backend is solid, I’m very happy with it.

But I need to not only rewrite lots of the front-end, but actually rethink the whole shape of the webapp I intend to build. Too many things in the pipeline, but at the same time, nothing really finished. Damn.

I don’t know why it always happens around the v0.8. A kind of teenager crisis for a software. The time where you have exhausted your young energy, and start to think this isn’t the right direction, and something must change.

It’s hard to convince a developer he didn’t develop the right thing. But when this developer is yourself, and you invested a big chunk of a whole year into it, it is rough. At least, I must say I am not denying it anymore. It took quite a few months to really ask for feedback, but I did it, and the results of the votes are clear: I must continue to build new versions of iObserve…

Everything’s inside the meaning of « new versions »… This is where it is interesting to think as a product maker. What is iObserve ? An app that embedd into the same « workspace » a bunch of finely-crafted algorithms and visualisations combined with professional archival data, to let people think and prepare better their astronomical observations.

(Okay, okay! I heard it. It must work offline too.)

Fine. Let’s do that. But the success of iObserve is also the result of a few unplanned features nobody asked for. Say, I have a few in my pocket.

Resolutions for 2019. Actually, only one, which encompasses all others: focus. Really focus on the right thing, and nothing more.

Clear skies to everyone! 0.6: Team Size Doubling + iObserve on the web !

This is a milestone for Arcsecond ! I am happy to announce that Eric Depagne, currently astronomer at SAAO/SALT has agreed to join his forces to His expertise with Python will help a lot on the backend, but I don’t expect him to remain within the boundaries of it!

Moreover, we releases iObserve on the web ! Not as feature-rich as the macOS app yet. But already new features that will belong only to Arcsecond: Night Logs (in prep) and Data !

Freely regsiter in and tell us what you think !

iObserve on the web is coming

Well, winter is already there, anyway. So now, iObserve is coming … on the web. #GameOfCurves

For those who don’t know yet, iObserve on the web is called You can already checkit out here.

I am very proud of the progresses. But there is a lot to iron out (I had to work on various API endpoints to make it work: /observingsites, /observingruns, /nightlogs, /observations, /users, /telescopes).

But I can’t wait to share with you a (debug) screenshot of the current state of it on my machine. Feel free to spread the word!

My blog is my code (quick updates)

I should take the time to annouce a bit more often the releases of my various softwares. But software is a mean of expression by itself, in my humble opinion, when practiced everyday. Don’t you read software? … My blog is my code, and this blog is my secondary blog, talking about the first one.

Anyway, please be aware that is progressing well. It isn’t still ready for a full-blast communication pushed into professional tubes though. But time will come.

In particular, note the fusion of the Objects and Exoplanets page (which are kinda of object, aren’t they?…). It makes the navigation a lot easier. Moreover, Exoplanet Transits have been also added. Pretty nice. Screenshot below, but judge by yourself directly in this example.

 Yes, I usually look for icecream colors for the beta banner... Don't you like this Strawberry-Pistache ? Yes, I usually look for icecream colors for the beta banner… Don’t you like this Strawberry-Pistache ?

Moreover APIs are slowly maturing, and some API endpoints are now in pretty good shape. Obviously that includes /observingsites, /objects and /exoplanets. I am working full-speed on /observingruns and /nightlogs right now. But /datasets is also pretty nice already (although not yet complete).

To follow all the progresses see my third blog… the changelog!

In the meantime, I also released a small update of SwiftAA (v2.0.1) to fix some warnings, making sure it is fully compatible with latest Xcode, and applied a small bugfix about the visibility of a special method (that should be kept internal for that matter). Check it out on GitHub!

I am also busy with new adventures for real professional activities this time. But I tend to usually mutualise the benefits, to increase the pace of releases.

Oh by the way, I am preparing a link between and iObserve ! It’s time for iObserve’s users to submit new observatories and observing sites not in the app but rather in They will further be importable inside the app. It will be great. The benefit is that: it is not manual anymore (which is good for me), but is directly accessible and shared with everybody !

iObserve v1.6.1

iObserve v1.6.1 just submitted to the Store. I couldn’t really find a fix for the rdar problem mentioned earlier. I did modify a little thing in the code that could possibly help. But Apple didn’t respond to my inquiry on the subject. I have a user report saying that the problem went away apparently on macOS High Sierra (10.13).

SwiftAA 2.0

SwiftAA, the most comprehensive collection of accurate astronomical algorithms just reached v2.0! This is the first version of complete Solar System APIs with units safety and a whopping 90%+ of unit tests coverage.

I am very proud of the result. Lots of things remain in the pipe for an even more amazing v3, but here you have: a complete set of easy-to-read and documented APIs to compute everything you need about the solar system. 

New Builtin Observatories: Hundreds and Counting…

It’s been a while now that I chose to make my app iObserve free for all (both on macOS and iPad) and to support it at the basic level (I know iObserve on iPad hasn’t received yet the update it deserves). If you don’t know why, you should read this.

But of course, it keeps thriving! And a lot of people use it! And one of the best channel I have to get a sense of how often it’s being used is the mails I receive to include new builtin observatories. Check this out only for this summer:

It is really warm feeling to see this. 

But if you follow this blog, you also know that I am developing arcsecond,io and that it has a dedicated observatories page, right?

Of course, the obvious thing to do is to plug into iObserve to make it easier for everyone to contribute! And this is what I planned in the past to do, but in the v2.0 of iObserve… which is stalled, because I develop Arg! 

Enough cheating. This blog post is to announce I will develop an update of iObserve 1.6 to use the observatories in That is, I will not wait for v2 of iObserve. The tricky part is that the ObservatoryManager is something essential of the app, and I can’t develop this overnight. But enough said, and back to work!