.png){kind=small}
It turns out there is more than one Siemensstraße in Berlin, as Nuno Campos and I found out the hard way on Saturday morning, from the other side of town.. So, it was after a hurried Uber ride across Berlin that we got to our seats, and nibbled on tiny pastries, barely for 30 seconds, just before the keynote that would start Zeit Day Berlin.
Soon afterwards, Guillermo Rauch, founder of Zeit, got on stage to explain the vision of Zeit and announce their most recent steps towards it. In a way, Zeit seems to be betting on the idea of abstraction as the key mechanism for lowering the friction to starting web projects, ultimately making possible projects that wouldn’t get started at all would one need to deal with all the underlying primitives directly. Their main product, now, takes the primitives created by cloud providers and bundles/abstracts them away into project deployment that can be relied upon and, fundamentally, forgotten about.
Next up was Alvaro Videla, speaking about the metaphors that we, consciously or otherwise, lean on when thinking about programming problems, or just thinking in general. It’s interesting to realise how many terms are coined based on the metaphors we use to better grasp the underlying concepts, when working with tech (not only, but also). This was an interesting talk, as it started with a few “not convinced/still not convinced?” slides, and, probably, finished with a lot of convinced people. A big plus was to see how well researched this talk was.
Right after, Maaret Pyhäjärvi delivered one of the most refreshing takes on testing we’ve heard in a long time — testing as uncovering the implicit premises our code stands on, and as a fundamentally creative process: an exercise in reverse-engineering the thought process of the author of the application, first teasing out all the metaphors that work is standing on, second evaluating which ones are appropriate and which ones aren’t. As she said very well: testers break developers illusions, namely, about their code, what it’s supposed to do, what it needs to do, and that it actually only does what it’s supposed to do. She also talked about how this illusions are present on the business logic rules too, and finished with some very appropriate tools all testers should have: looking at things from a different angle, perseverance and serendipity.
The earlier theme of empowerment through abstraction did show up, intentionally or not, in other talks during the day. For instance, Pia Mancini spoke of her work in making Open Collective a solution for funding loosely coupled, fluid, decentralised communities — the sort of community created around, for instance, independent open-source projects. These communities are currently hobbled by the amount of effort and knowledge required to set up the structure necessary to become sustainable while remaining independent, and the corporate and banking system isn’t built or ready for this kind of organisms. Open Collective abstracts the legal and financial details that go into organising funding for a community — setting up pages where a community asks for contributions, and allocates them to cover expenses.
Dan Abramov, reflecting on the JavaScript ecosystem, voiced many pertinent questions. On an ecosystem which he described as fundamentally human — beautiful, painful, messy — how do you balance flexibility against usability? How do you enable a measure of completeness, of having found the right tools for the job, of being able to stop looking? How do you help people not give up before getting started? He brought to the table the discussion about how removing most configuration from tools could lead to easier project setups and less decisions when starting a new project. Not always a simple solution, or an easy answer, but definitively something to consider when contributing to the tools/libraries/frameworks ecosystem.
Ives van Horne, speaking last, suggested an answer to some of Dan’s questions. He spoke about CodeSandbox, an online IDE for web app development. In his words, by “starting top to bottom”, creating a development environment that starts directly with the goals and slowly introduces the underlying tools and primitives as they become useful, the barrier to entry for web app development can be dramatically lowered. CodeSandbox has been evolving very fast, with many new features along the way, and now, being able to work offline and deploy using now. He closed, telling people they shouldn't feel that they need to know everything to start new projects. He, himself, didn't know many of the things required to make his project real, and learned them along the way. Let that be a lesson for us :)
This last talk brought us back to the theme of empowerment through abstraction — with now you can simply deploy anything and later learn about custom DNS, multi-region replication, infrastructure configuration; with Open Collective you can just gather money for your community and only later think about becoming a full-fledged company/foundation; with CodeSandbox you can start to code right away in your browser and learn about transpilers, bundlers, and other tools later as the need arises.
