Beam Radio: live from New York (almost)

Listen

Takeaways

Sophie DeBenedetto hosting, with Bruce Tate, Lars Wikman and Meryl Dakin. The title is a joke: I was in New Jersey, not New York and from Kisumu rather than Nairobi.

How I got to Elixir

University, electrical and electronics engineering. Then a bank job that lasted two weeks because it was too boring. Then an electrical engineering job that lasted exactly nine months, because of the repetition and the same standards used over and over. I had and probably still have, a bad case of shiny object syndrome. I chase moving targets.

So I quit and went out to sell software to high schools in Kenya. I found an open source project written in Ruby on Rails and studied enough Rails to adapt it per school. There was no technical decision behind landing on Rails. It was not really a decision at all.

Then I joined AgileVentures, an online community that did a lot of teaching and mentoring for people getting started. They were running a book club on Dave Thomas's Elixir book and Sam, the founder, thought it would interest me. It did. It thoroughly messed up how I thought about code, since I had production Ruby in my head by then.

What kept me was having to be explicit. No calling user.save and hoping. I could follow what was happening without going a level deeper into the framework, which is what I loved about Ecto and Phoenix. Look at the data, pipe it through to the end. I have tried going back to object-oriented languages since and I find it hard to see where things change and how.

Teaching and the plug game

Training was easier than expected, partly because for some of the team Elixir was their first language and first framework, so I could explain it the way I understood it.

The part I have thought about since is why it is easier to teach a functional language first. Most of the magic in Phoenix back then lived in macros and the convention is that you do not write macros unless you must. So the black-boxed parts stayed out of the way and the pipeline stayed visible.

Bruce told the story of the class we taught together, where he would be mid-explanation and the students would be lost and I would ask for a word. Then we would put the pens and post-its down and gamify what had just happened.

The plug exercise came out of the introductions. Everyone says who they are and where they are from and we collect the names as we go around. So you start with something empty, each person adds to it and it comes back full. Suddenly everyone is a plug, everyone knows everybody's name and everyone understands plugs.

I had done this before. In 2015 I trained a group in Ruby on Rails and we gamified MVC, giving everyone a role. One person was the controller, one the view, one the model and they passed information between them until the view produced the result. There is a man called Kevin who has been called Controller ever since.

Elixir Kenya and the safari

The order was Monday streams, then monthly webinars with guests, then annual conferences. Alongside those we ran community open source projects, one of which was a wrapper around our mobile money payment system so that anyone starting in Elixir could drop in an API key and send and receive money. Mobile money is very big in Kenya.

On the volunteers, since this is a BEAM podcast: we spawn off the processes. Three to find speakers, three to find sponsors. They report back to the supervisor, who tells them what to do next. While they are busy with this year, the supervisor is thinking about next year.

Which brings me to the pitch. Everyone knows Kenya for wildlife, the great wildebeest migration, all of it. So what if the conference were a safari? You come to Kenya and we build you an itinerary for two days or two months, or for going around several African countries. Breakfast with the giraffes. A game drive on Saturday evening for the elephants and the lions. Say hello to the hyenas. For the butterfly people, we have a large forest with a lot of diverse butterflies and birds. You also get to cross the equator.

The point underneath the giraffes is that this part of the community is geographically far from everywhere else. There is a stack of Elixir conferences in the United States and the Code BEAM and ElixirConf events in Europe and most people in this ecosystem have never met a technologist in Kenya.

Embedding in other people's codebases

I have worked with Frame.io, later bought by Adobe, which is where I met Meryl. Currently Pulpo, a German company working with warehouses.

The reason is experience. From outside, Pulpo looks like a small thing to build. Then you count the integrations and what it has to handle and you have to think hard about when and what gets done, because there are microservices and a lot of GenServers doing different things at different times. Warehouses deliver things, so they do not get to fail.

Big existing systems have completely different challenges and completely different solutions and it is a long way from training exercises where one plus three gives you the result. The design, the architecture and how people think in large teams is diverse enough to change how you approach implementation and problem solving.

My method there is the same as everywhere: spawn a few people to take care of things, steer and be consulted only when necessary.

The Bruce way, for the record

I raised Matt Enloe's refactor at Adobe as the counterexample to doing it your way on day one. It has run on and off for about two years, the business was willing to support it and by his account at the conference it paid off. Greg Mefford's talk covered the tooling, which worked on the AST and automated the changes. Not a linter warning you when something steps out of bounds, but something that fixes it against an opinion.

What I took from GigCity

First, that Americans love air conditioning. It is always on, the windows do not open, you can only move the blinds and I kept my sweatshirt on the whole time.

On the actual talks, the range was good. Brian Hunter's hospital management system spawns a process per patient and keeps that process's state, adding information as it goes, which is a genuinely nice way to think about designing software. Chris Keathley, who I also met at Frame, gave strong opinions on organising code. Somewhere in the middle of all that I talked about observability without showing a single line of code, on how aviation manages 22 million flights and 22 accidents while knowing exactly what happened in each.

Asked what I would carry back to ElixirConf Africa: look after the speakers behind the scenes, since they are new and should be comfortable on every day they are there. Get everything ready weeks ahead, all of it, because then you have time to reprint whatever went wrong. And build a balanced speaker panel, African and non-African, male and female.