MICHA.ELMUELLER

Books I read in the last years: 2017, 2016, 2015, 2014.

This year: 13 books — 11 in english, 2 in german.

Albert Warnecke — Was Sie über Vermögensaufbau wirklich wissen müssen
There were two outstanding books I read this year, the first on the list and the last.

This (first) book is basically a guide on the entire topic of personal finances. It covers everything: where to put your savings, what insurances you need, etc.. Especially the chapters on stocks/ETFs/inflation rate were very beneficial for me. The book also covers some part of the Financial Idependence/Retire Early idea.

I found out about the book after listening to this (excellent) podcast with the author.

Daniel Korth — Jetzt rocke ich meine Finanzen selbst!
Also a book regarding personal finances. The author describes his personal experiences after inheriting money. He let one of the large German banks handle the investment and describes all the bad ways how they managed his heritage and what a better approach would have looked like.

Jeffrey Kluger — Apollo 8: The Thrilling Story of the First Mission to the Moon
Can recommend it if you’re into NASA and/or space :).

Leslie Berlin — Troublemakers: Silicon Valley’s Coming of Age
Interesting book on the story of a couple not-so-famous Silicon Valley personas who were elementary to the tech boom in Silicon Valley. Was an interesting read.

David Kushner — Masters of Doom
This biography tells the story behind “id software”, and its founders John Romero and John Carmack. Both of them are legends in the computer gaming/computer graphics world. They are e.g. responsible for Quake, Doom, Wolfenstein 3D, Commander Keen, the invention of Multiplayer and Deathmatch, etc.. There are may many other small innovations which they made detailed in the book. Mostly stuff which nowadays is elementary in a lot of modern games. John Carmack is todays CTO of Occulus.

The book was an interesting read and I can definitely recommend it if you are remotely interested in tech history and like the effect of “Wow, they also invented that?!”.

Andrew Hunt, David Thomas — Pragmatic Programmer
At mbr we had a book club and this was the first book we read. The book is about 20 years old and a lot of things are obvious now, since they have become wide-spread industry standards. It’s easy to forget that for many things this was the book which first popularized these ideas or even invented things (like “rubber duck debugging”).

There are a couple ideas in the book which stuck, one of them was that they emphasized how important it is to constantly learn new stuff as a software developer. Otherwise you just halt. The recommendation they give is to learn a new programming language each year, as to not lose track of recent language developments.

97 Things every programmer should know
Not much stuck from the book.

Jeff VanderMeer — Annihilation
I read the book after watching the brilliant movie. The book is good, though I liked the movie better.

Cathy O’Neil — Weapons of Math Destruction
The book examines the harmful influence of machine learning and big data on decision making. Each chapter is dedicated to one harmful application of data science models. Some examples: predicting where crimes might occur next (this is called “predictive policing” and already reality), models to automatically filter the best employee/student application, or models to find out which teacher performs the worst. The critique is legitimate and she makes a lot of valid points.

One of her points is that the feedback loop for these models is often missing. In the example of filtering student applications there is e.g. no feedback loop. Nobody ever looks what happened to the students which were filtered out — maybe they went on to become a professor because they were exceptionally talented? In the book she provides a lot of real-world examples for people who were falsely filtered out by these models.

She also highlights that a lot of these models are marketed under the premise “algorithm, neutral, highly mathematical, highly sophisticated, highly complicated”, yet there are very often statistical flaws found after these algorithms are used in production.

My critique on the book is that she often refers to issues which are very relevant to the U.S. (racial stuff, with cities being divided by races, etc.), but by far not that relevant for Europe. Also a number of these applications would be illegal in the first place in Europe, so some examples seem exaggerated to a European mind.

There is one real-world example which stuck: a major city in the USA decides to develop a model to rate teachers, in order to find out who teaches best. Soon after that teachers start gaming the algorithm, e.g. by grading tests very very optimistic and good-willed, so that it seems to the algorithm as if the pupils suddenly turned very good under this teacher. The effect was that the teacher which had the class next year oftentimes received a very bad rating by the algorithm — especially if it was an honest teacher. This was because it then seemed as if the pupils suddenly got bad grades under the new teacher, whereas the dishonest teacher just had skewed all grades in a positive manner.

From the last chapter:

If a Big Data college application model had established itself in the early 1960s, we still wouldn’t have many women going to college, because it would have been trained largely on successful men. If museums at the same time had cofidifed the prevalent ideas of great art, we would still be looking almost entirely at work by white men, the people paid by rich patrons to create art. The University of Alabama’s football team, needless to say, would still be lily white.
Big Data processes codify the past. They do not invent the future. Doing that requires moral imagination, and that’s something only humans can provide.

Cal Newport — So Good They Can’t Ignore You
I liked the Deep Work book by Cal and so I was motivated to also read this. Basically his hypothesis is that the phrase “All you need to be successful is to find your passion and follow it” is extremely harmful.

He examines this advice of “just follow your passion”, as very often propagated by people like Steve Jobs, and shows that it is extremely seldom that this works. Often the people giving this advice do this after they are already successful whilst they didn’t even follow their own advice.

He gives the example of Jobs, who — if he would have followed his passion — would rather be a meditation trainer in Palo Alto today instead of having started an electronic software company. The book is good and I liked a lot that he questions such an established belief system.

Pedro Domingos — The Master Algorithm
This book examines the idea of a master algorithm, a general purpose learning algorithm, which can derive anything from data. So if you would give this algorithm a huge pile of books it would learn to read, interpret language, extract the semantic knowledge in the text, etc. all by itself.

This is opposed to the current state in machine learning where individual algorithms have dedicated appliances. Domingos makes the case that such a general learning algorithm exists and sketches how it could look and why it has not yet been discovered.

The first chapters are written really well, but I got lost when he examines the five learners which are currently established in machine learning. I decided so skip these chapters since I wasn’t interested that much in the mathematical details, but rather the grand idea. The book itself was an interesting read and definitely falls into the tech-utopian, enthusiastic category.

Aubrey de Grey — Ending Aging
I’ve dug into this idea of ending aging. The book makes an elaborate argument for why it makes a lot of sense to put research effort into this idea. He argues that extending the human lifespan by a significant amount is totally doable and would prevent a lot of suffering which comes from age-related diseases.

Steve Klabnik, Carol Nichols — The Rust Programming Language
I’ve written a more detailed article here. But yeah, basically this was my main resource for learning Rust. I read the book mostly on the subway. 20 minutes in the morning, 20 minutes in the evening. Great book with a lot of examples and small projects.

Rust is quite an elaborate expert language though, hence Chapter 19 [sic!] starts like this: “By now, you’ve learned the most commonly used parts of the Rust programming language. […] We’ll [now] look at a few aspects of the language you might run into every once in a while.” Chapter 19 and still not every aspect has been touched!

During my time at mbr I wrote a couple of Slack Apps which I included into the internal company channels.

I’m quite happy with the way they turned out and how actively they were used. They all contributed to the great company atmosphere — either in functional or entertaining ways.

Weekly interview with a random colleague

I wrote a Slack App which interviewed a different employee of the company each week. The questions were the same for everybody:

Hi there!
This app interviews everybody in the team subsequently. The idea is to get to know your colleagues a bit better and maybe find out some things which you didn’t know before. This time you have randomly been chosen to be interviewed.

If you choose to answer the following questions, the answers will be posted for others to see.
These are the questions:

• Who are you and what is your job here?
• What was your nicest moment at mbr?
• What is your favorite place nearby?
• What was the last thing you discovered which excited you?
• What have you learned recently?
• When are you most productive?
• What was the last book/show/movie that you recommended to someone?
• My happy place is …?

The app offered the choice of answering the interview, skipping it this time, or skipping it forever.

Overall I am very happy with how it turned out. It’s one of the things I wrote of which I’m very proud. I would say the App was a success and it was always very interesting to read the interviews.

The team was only slightly de-centralized and I would imagine this to have even more benefit in a decentralized company where more people work remotely.

Bi-Weekly histogram of most used reactions

Slack offers the possibility of pinning emoji reactions to any message. This is (not only) a fun feature, but also reduces a lot of noise. Instead of “I agree”, “I join”, “Great idea!”, … people just pin a fitting emoji.

Each two weeks this integration posted a histogram of the recently most-used reactions. It was interesting and entertaining to watch how the reactions changed over time — e.g. during Christmas time or when there was some incident in the data center. The data center incidents were always clearly visible in the reactions :-).

Slack offers the possibility of creating custom emojis and Thomas had created an emoji for everybody with a photo of the person. So you could observe people showing up in the histogram, when they had e.g. achieved something nice. Or when somebody had a trademark thing that could be clearly attributed to her/him. We had also added a lot of logos as emojis — e.g. for the data center operator company. So whenever they caused chaos their logo was showing up high in the list.

I have put the script on GitHub.

Weekly histogram of on-call alarms issued by our monitoring system

I was working as a DevOp and part of the job was to be on-call during nights, on weekends, etc.. This meant that whenever our monitoring system detected failures or anomalies the system would notify the person on-call; first with a push notification and then escalating further…up to a robot calling the person if he didn’t react at all. It was hard to keep track of the alarms which were raised, since the on-call shift was changing weekly. So I wrote this App which after every shift of a person would post the night and weekend alarms the person had to deal with.

This really helped improve awareness for the stack stability and the number of problems we had to deal with.

I would say that this definitely also had a huge impact on how the DevOps people were seen by non-DevOps colleagues. It raised awareness for stability issues and helped other people understand how much work being on-call was. It also offered a way for other people to show appreciation of how a person managed an incident (e.g. by talking to them, since this histogram was how they even found out that there was some incident in the first place).

After a while we started to explain the cause of the incidents in a thread below the post. This helped a lot communicating what was actually going on in the stack. We also later used these notes when discussing possible improvements and reflecting on what could have been prevented.

Oftentimes these histograms were the start of a longer discussion of how something could have been prevented with the whole team being involved. Before my integration this was something which only happened when there were major incidents, but not in this structured and holistic way.

I think this integration — simple as it may seem — was a big contribution to the company. The main take-away was that it made incidents visible, not only to the directly affected engineers.

Status information about active campaigns

Another simple integration I wrote posted a notification whenever manual intervention was necessary into something running on the stack. The nice thing was that — since Slack offers threads — people were able to discuss the issue immediately in Slack and coordinate on who would take over.

I had fun playing with the messages and giving the App a bit of character. So the App would always choose a random message when alerting people about mishappennings or successful fixes.

The idea for this post actually came from Markus. His idea was to post the individual points as an advents calendar, one item each day. I sadly did not manage writing this up in time, but I had written down some notes and so I thought I’d finish this nevertheless.

Since quite a while we are on a Zero Waste trip. This is a huge scene of people who try to minimize their waste. r/zerowaste is a fitting subreddit, but there are also a lot of books, talks, ….

These are 24 things which changed in 2018 in our household as part of our zero waste effort.

1. Using napkins out of textile — so much less waste, so much nicer. Can be easily washed and reused.
2. Cotton handkerchiefs instead of Tempos. Same as above.
3. Buying groceries in very large packs (e.g. 10l oil canisters, 2.5 kg nuts, etc.).
4. Shop regularly in one of Berlin’s supermarkets which don’t generate waste (by selling only unpackaged groceries). The Original Unverpackt is Germanys first supermarket like this and in Kreuzberg, it’s the one we frequent most often. The difference is really astonishing, for example we now always have a large bottle of dish soap at home and fill it up there whenever needed. The canister which they have in the supermarket is refilled directly by the manufacturer.
5. Bring own bags along to the bakery, market, supermarket, etc..
6. Use chestnuts for washing. This works surprisingly well. During autumn we collected some kilos of chestnuts which had fallen from trees. There are a number of blog posts and videos online on how to use them. They can be dried and stored for usage in the coming months.
7. Use plastic bags which you received unwillingly (e.g. the ones in which packets sometimes are wrapped) as waste bags.
8. Process vegetable leftovers into a soup (works really well with e.g. brocoli stems).
9. Instead of gift wrapping paper you can easily reuse e.g. paper bags, comics, or city maps.
10. Grow our own herbs. Thyme, rosemary, mint, parsley, chives, basil, arugula, ….
11. Shower soap instead of shower gel.
12. Cling film is this roll of thin plastic which is typically used to wrap food as a mean of keeping it fresh. Bee’s wrap out of wax cloth can be used instead and easily washed/re-used.
13. Use textile leftovers instead of Cewa.
14. Drink tap water instead of water from plastic bottles. We handed a bottle of our tap water in to the Berlin Water office for analysis. The water quality in the city pipes is extremely good, the thing is that the last meters in a house are not controlled. So with Berlin’s old buildings it’s unclear how the quality is (and if there are any lead pipes on the way to your tap). The analysis only costs a few euros and is even free in some cases.
15. Giving away stuff. Some stuff we sold and some stuff we donated. Some other things we put in front of our flat with a “Give Away” sign. I guess it’s typical for Berlin that everything was taken, most of the stuff even in under one hour.
16. Sew clothes that you no longer like into something else — e.g. napkins or a different clothing item.
17. Congratulation cards from old photos. This was something that worked out really well. We had a lot of photos that we had gotten printed out (or developed) at some point. Many of these could easily be transformed into a congratulation/greetings card.
18. Use bamboo toothbrushes which are biodegradable.
19. Use a metal razor with an exchangeable single razor blade instead of the fancy plastic ones which go bad quite fast.
20. Donate books and buy new ones from a book donation center. In Berlin there are a lot of them, “Berliner Büchertisch” in Kreuzberg is our favorite one.
21. In the summer an Iso-bottle can be used for having cool water wherever you go.
22. Instead of buying finished products we started doing some stuff by ourselves: chili garlic oil, granola, compote, burger buns, rice milk, ….
23. If you just squeezed a bio lemon and are about to throw it away: you can rub off the zest and freeze it. This can later be used everywhere where you need lemon zest (baking, etc.). So you don’t need to buy a dedicated package of lemon zest.
24. The thing that I had most fun with was to take out every food item that we have in the flat and place it on the floor. We then went through everything and sorted it back in properly. This really helped in gaining awareness of what is actually there and what needs to be used up soon.

I spent a couple months of 2018 diving into Rust, a modern low-level programming language with high-level language features — functional programming, asynchronous programming, closures, ….

The language is a bit out of the family of languages that I usually work with and so a lot of stuff had to be learnt.
Also, I characterize Rust as an expert language. It is very explicit since one of its design goals was to not have hidden performance costs of functions without the programmer being aware of it.

I learnt the language the same way that I learnt stuff during university and it has proven to work very well for me:

• I read a fundamental book on the topic from cover to cover and made sure that I understood every single line in the book. The book was “The Rust Programming Language”.
• After having read a large part of the book, I summarized each chapter that I had read so far in my own words on paper. To me it’s important to not immediately summarize each chapter after I’ve finished it, but rather gain an elementary idea of the domain first.

  For this summary I re-read each chapter and wrote up the most important things. During this “second reading” I very often suddenly understand things that I haven’t before or suddenly notice some detail that I haven’t before. Also it often suddenly clicks and I see the connection to something that appears only later in the book.

• I immersed myself into the community, subscribing to the r/rust subreddit and reading the weekly “This Week in Rust“.
• I watched a number of YouTube talks by the leading people in the field.
• I coded up an own project: this was a problem that I faced and Rust was a perfect fit. The project was definitely challenging in its goal and I had to use a number of different language features. So it was no easy walk, but the result took use of a broad set of features the language offers. I open-sourced the project and published it as a package to cargo (the Rust package manager).
• I provided Pull Requests for projects which I respect which also use Rust. The feedback was really helpful and I think this is an excellent way to learn a language. One basically gets a mentor and feedback for free. In programming languages there are often idiomatic ways and patterns to do things and this is a handy way to get to know them.

  Also, while fixing bugs for those projects I had to read the source code of bigger Rust projects. This way I saw the idiomatic way to structure/design large projects in this language.

I would say the idea of summarizing the chapters of the book in my own words is the most important idea from the list above. To me, the core idea is that it helps me find my own view on the material. It’s especially important to me that this process is done without any computer, I’m too distracted otherwise.