Stories we tell ourselves

Last week I had the privilege to speak at infiniTIFF Summit, a part of the Transylvanian Film Festival dealing with technology, storytelling and experimental narratives.

I wrote Stories We Tell Ourselves for the summit. Below is a slightly longer version of the talk I gave.

Slides at speakerdeck.

It's about the curry

I got invited to speak at Monkigras 2018, a superb conference on software, technology and craft. This year’s theme was “Sustaining Craft”. I wrote and delivered It’s about the curry - you’ll find a (close enough) transcript below.

Slides at Speakerdeck.

Fast is not enough

I’ve been advising a startup on the data transformation space. As part of this, we re-wrote the core engine in Clojure. The new version is, at the worst case, 16 times as fast in the same hardware, and in some cases over 200 times faster. And it does it with a fraction of the lines of code.

We did this in under 3 months of part-time work. We couldn’t focus our entire attention on it, as we had other concerns as well - I was involved with general team and management tasks, and the second developer was helping on other internal projects as well. To further raise the bar: we had to keep it functionality-compatible with the current version, so I had to get acquainted with the existing feature set, and it was the other developer’s first Clojure project.

Clojure made our lives so much easier. But this is not a post about why Clojure is cool.

Preemptive commoditization

Note: I wrote this in 2018, while I was helping a young startup and convincing them to open source their core application. If I were to write it nowadays, in 2024, I’d elaborate a bit more, including James Governor’s evergreen remark about how “You can make money with open source, but it’s extremely hard to make money from open source.” (source). Leaving it as-is, however.*

I’ve been advising a startup on the data transformation space. As part of this, we re-wrote the core engine in Clojure. The new version is, at the worst case, 16 times as fast in the same hardware, and in some cases over 200 times faster. And it does it in a fraction of the lines of code.

We did this in under 3 months of part-time work. We couldn’t focus our entire attention on it, as we had other concerns as well - I was involved with general team and management tasks, and the second developer was helping on other internal projects as well. To further raise the bar: we had to keep it functionality-compatible with the current version, so I had to get acquainted with the existing feature set, and it was the other developer’s first Clojure project.

Clojure made our lives so much easier. But this is not a post about why Clojure is cool.

I’ve been arguing about why they should open source anything that is not enterprise-specific, including this layer. There’s many advantages, which I won’t go over right now, but there’s also a looming threat.

Layers are getting commoditized faster and faster. More and more, there is demand for people who are good at wiring things together (beyond the gem install hairball approach), or tools that help with that wiring.

I suspect that’s a big part of what’s driving how many companies like Seldon are going open source-first, or how Unreal opened their code as a way to compete with Unity.

“what’s driving how many… are going” is a doozy

Remember: This rewrite took about 3 man-months, with our attention pulled in multiple directions, while we strove to remain feature-compatible with the old engine. You have to assume anyone else who has the technical chops but doesn’t have that baggage can do it as well. Do you want to be disrupted by some motivated, random person who thought what you were doing was cool, but neither needed your entire feature set nor wanted to be shackled to your cloud version?

Better to commoditize yourself before someone else does it to you. You get to have a say in how it happens, use it as fuel to propel you somewhere new. And you get to tell your customers “if you think this thing we give away is cool, you should see the part we charge for”.

Learning Through Mentoring

On Wednesday, April 26, I gave a talk at Webit 2017 in Sofia about mentoring and movies. The audio unfortunately came out like it was recorded through two tin cans connected by rusty barbed wire. I write these things as effectively a long speech, so my original notes should work as a transcript.

Update: Here’s the video from CodeMotion Berlin 2017.

Interruptions: A User's Manual

Interruptions are one of the best ways to squander time and money, but the value chain is not always obvious. This handy guide will help you make the case for why you should be interrupting your developers (nay, any employee!) regularly.

Be Transparent

This is something of an open letter to team leads and managers out there: you need to be as transparent with your team as you are legally and contractually allowed to.

Reading Clojure, part 2

Welcome back

Have you gone over the fundamentals on Reading Clojure? Did you shake off that preconception that there’s some magic syntax to declaring and evaluating things beyond the list?

Great! Let’s now go over other things you might encounter when looking at a random source file. I’m first going to give you an overview of types and related things. After it, we’ll then we get into the good stuff like going over a project, and the weird stuff like ->, ->>, #, the quote and other squiggles.

Reading Clojure

Preamble

Back in early December I held a Clojure workshop for the Bucharest Functional Programming meet up. Having to explain the language to developers who were completely new at it was an interesting experience. I decided to start from the ground up: how to even read the blasted thing.

Branching workflow: git-flow and github-flow

Choosing a branching model for macchiato

Lately, I’ve been working on Macchiato to bring web application development libraries for ClojureScript on Node.js. Get a few people of different backgrounds involved on a project, and pretty soon a discussion about methodology will emerge.

Since both Dmitri Sotnikov and myself are working on some libraries at the same time, we had to decide which approach to use.

There are two major alternatives: Git-flow and Github-flow (with Gitlab-flow being a slightly more elaborate version).

Let’s review them.