Enjoy the little things

View from the High Line.

Packed, crowded, full of people. The (negative) picture I had in mind when I arrived here. What caught my eye is something different. Yes, it is indeed a packed city, but equipped with so much more, with little things, that it felt positive to me.

A city full of life, full of humans (and many dogs) going their way, cars honking their way through the street and a blue-lighted emergency car here and there to cause a bit of extra action. There is not much space for nature, for trees, bushes and other animals (than dogs). But, the places that are crafted for this, for the nature to unfold, they are there. They exist. They are the trees along the sides of the roads, the trees that form small avenues when you walk along one of the smaller side streets. And parks. Not just this one central big park thingy, but all these small oases all over the city. Here people come to meet. To hang out, to chat, to live. To enjoy.

It feels like as if, because this space is so limited, people make much more use of it. A few chairs on the street is the starting point for a small chilly gathering of friends and neighbors. Space that is abandoned and wouldn’t be used otherwise is made useful. Like the high lines. Where nature, art, shops, photo shootings, stunning views on the valleys between the tower buildings, and people making use of the space.

Welcome to New York.

Tell me how much help you need and I tell you how healthy your environment is

“Oh no, it is raining” was what I was saying when looking outside of my window after getting out of bed. As I am getting from A to B in Zurich using my bike having bad weather turns out to be even worse as bad weather is already by itself.

Especially on this day, it was raining really a lot so I was wondering what I could do. Zurich (as Switzerland in general) has very good public transport, so maybe instead of using my bike, why not use public transport on this rainy day? Unfortunately it turned out, using public transport was not an option for this day: There was a meeting at my university in the morning, then I planed to have lunch at Google Zurich and right afterwards another two meetings at the university. None of the meeting I could move or cancel. The commute time from university to Google office is significantly longer when using public transport then when using my bike, which for this packed day would mean I couldn’t make it between all the meeting to get to Google, have lunch there, and then make it back to university for the next meetings in time.

Your speed in an environment

So, in a sense, I had to make a trade off: Either I use a “nicer” solution in terms of “fighting the rain” and use public transport, loose the ability to move quickly (in other words, loose speed) OR to just face the heavy rain, be able to move faster with my bike and thereby make it to lunch at Google. I was looking forward to meet my Google lunch partner for nearly two week and so I decided to face the heavy rain.

What are your options when you want to cycle in heavy rain? Right, you need to take on a lot of rain gear, that avoids you from getting wet when cycling through the rain. And that’s what I did in the end: Open up my shelf, take out my full bike rain equipment, put it on (then walking like an astronaut), managed to not get wet this way while riding my bike through the rain and managed to be on time for all meetings and enjoyed amazing lunch communication at Google.

What I found most interesting about this is the following discovery: Your speed (that is, how fast you can move within a given environment) is not only dependent on the environment itself, BUT also on the help, support, tools, gears, … you apply to the environment. This allows you to keep up your “normal speed” - though the environment becomes suboptimal - by investing more into your help materials. Written down in a small formula you get this:

Your Speed = Your Environment & Your Help

By itself I find this formalisation already very interesting. (Holding a Bachelor degree in physics, I just love formulas.) And it gets even much more interesting!

What does the amount of help tell you?

Take for example developing large scale apps (say, you want to build the next Facebook): A common opinion is that for scaling an app and still be able to develop new features at the same speed, you need to have very good tooling that helps developers. That is why big companies like Google, Facebook etc. invest pretty heavily in their infrastructure - the daily developer “help” so to speak - to still make good progress and develop new features quickly (have a high speed) when the developers move in this “big app” environment.

From this it seems, the only way to keep up your speed is to invest more and more into your help / support area. But maybe that doesn’t have to be true always. You can ask the following (maybe provocative) question:

Is there a way you can change your environment instead?

Just accept the amount of help you need?

In a sense, if you loose speed as your application grows, maybe you should not take that as a “yeah, that’s what happens if your app gets bigger” attitude but say instead: As your app grows you must make sure you have the right environment setup to solve the problem. There is a blurry line here between where does changing the environment end and where does the help you provide start. However, what I realised over the last few weeks is, that often when you start using a lot of “help” to solve a problem, it is actually a strong indication that something might be wrong with the environment you try to solve a problem in and instead of throwing more and more support, tools, … at the problem, it might make sense to look at the environment and “fix” the problem there instead.

Noticing that there is an issue with the environment at first place is often hard and not obvious. But looking at the more concrete fact of how much help you need to get a job done is what I find much easier. From this concrete knowledge it seems possible to derive than something about the more implicit healthiness of the environment you work with in.

Now, for sure, you can not always change your environment - in the case of the bad weather, there is little you can do ^^ But over the last few weeks I appliedBut if I see how much tooling there is required to build performant web apps, I started to wonder if there is a way to fix the environment instead.

$ #date(07 June 2015)
[Iteration\ Fixed a lot of small typos - thanks a lot to a lovely, wonderful person in Berlin]

Mihai Șucan, my former colleagues, the Stephen Hawking of Mozilla, roughly my age, died.

Kevin: “Ahh, and there is one more thing.”

It was towards the later afternoon and I was calling into our daily Bespin team update call, that we used to do every evening.

Kevin: “There is a potential intern for our project. The Mozilla Labs people want interns on their sides and he cannot go to California because he has something with his skin and cannot stand the sun there. So, they reached out to us to see if he could intern on the Bespin project instead. What do you think about it?”
Joe: “Well, is there any downside in not taking him?”
Kevin: “That’s a good point, I guess no.”

And that is (at least how I can recall the conversation from the back of my head) how the Bespin team grow from four to five developers. I guess no one could only vague guess what this simple “let’s take him” decision would lead to back then. It was not only an intern that would join our team, but pretty soon he would become a full time Mozilla employ and famous within Mozilla. This person turned out to be Mihai Șucan.

But actually, Mihai never turned out to work on Bespin code - back then in 2010, Firefox 4 was developed and because the Firefox team was seeking urgently for man power, the Bespin team was more or less moved over to work on a new Firefox feature. Firefox 4 came with many new features include for the first time build in developer tools (until then Firebug was the only way to debug Firefox). Rob and David had started working on a few prototypes and to help them move faster and make sure the developer tools would ship, Kevin, Joe (later also Patrick), me and Mihai were assigned on the new Firefox Devtools Team.

The start of the project was, well, rough for us. But we were like a small SWAT team of developers that tried to get Firefox Devtools shipped - no matter what. We were all outstanding - but - Mihai just - well - powned us all. He learned quickly, he finished work so fast, his voice was a little bit strange, he made jokes (though they were not always funny, but still, looking back, they were humours in their own sense), he took critic not personal but was thankful for it and got back to work again and overall he was also pragmatic. I remember asking me “is that really only one person that is working there somewhere in eastern Europe or is he sharing secretly work with other people” - he was just working way too fast and at a quality that was outstanding and not imagineable to be done by a single person.

So far I had the pleasure to work with a few giants, people that move at light speed, that cut through problems like butter and still help you and are the most lovely people you can imagine at the same time. Mihai was one of them.

I don’t know Mihai’s birthday, but I guess we were born maybe two, maximum three years apart. I am 25 years now and standing in the middle of my life. Not so Mihai.

On 23 April 2015, Mihai Șucan died of cancer.

When I was working with him back then in 2010, there were no pictures of Mihai on the internet. His voice was strange and I knew something was about his skin (that was why he got assigned to our team at all, recal!). Later I saw him for the first time on a picture taken at the Firefox Devtool Workweek in London. He was sitting in a wheel chair, which was later also visible on his avatar image.

Mihai was suffering from cancer. His ability to use the keyboard was limited. How he managed to do so much work at such at an outstanding quality and pace - I just cannot figure out. Given his work output, I would never had guessed he had such physical problems or limitations. But it seems that what looks like limitations to me where not so for Mihai. He just kept going, he fixed 1919 bugs (if you wonder if this is a lot - yes, it is HUGE), mostly in the Developer Console shipping with Firefox. When I think about him now, he feels like the Stephen Hakings of Mozilla to me - also bound to a wheel chair, but not giving up, in contrast proving life over and over again that he would outlive every estimated remaining time he had left on earth. People gave him a few months, he stayed around for years. Then it were weeks and he still turned them into months. He knew his end was coming and blogged about his disease in his last blog post.

The disease Mihai was suffering from is called Epidermolysis Bullosa - it is seldom and therefore not a main focus for pharmacy companies, leading to suffering of many people that live with this kind of cancer every day. Quoting from Joe’s blog post about Mihai’s death:

E.B. is a brutal skin condition which causes chronic blistering, and makes everyday objects dangerous. Those with it are sometimes called butterfly children because of their brittle skin. In Mihai’s case it has left him in a wheelchair, and having to very gently punch the keyboard to get anything done.

E.B. makes you very vulnerable to skin cancer from the continued scarring from the blisters. So everyday objects that wouldn’t pose a risk to those with normal skin become sharp and dangerous to people with E.B. Needless to say - anyone with E.B. has a huge mountain to climb every single day.

Mihai and I never met in person. But still after we stopped being colleagues we stayed in touch, had a few small chats on IRC or on Twitter and though it feels strange to say, he felt like a good friend to me, that I never got to meet - and never will.

The world lost a great person, a great developer, a great Mozillian and a great fighter.

And I have to say goodbye to a friend :’(

RIP Mihai.

RIP Mihai Cheers

PS: To honor Mihai’s outstanding work on the Firefox Developer Console an easter egg was added - instead of using the normal console.log() commands go and try console.mihai().