This has been my second week at Typeform, and I have done a couple bootcamps in other teams I will be in constant contact with. It has involved working a lot with Kubernetes (locally and in our development cluster, also got to trawl through Istio stuff) and Go, which I hadn’t written in a long while. I have also worked a bit in a few data tickets when I had some spare time. Having fun so far!
Although I focus on the setup for Go in this post, the important part is having an example of a preLaunchTask and a postDebugTask: with these you can start helper docker containers and stop them once done.
While reading this post I was wondering: given data D, a query Q a query planner R is R(D, Q) = QP (a query plan). A heuristic query planner has the form R(_, Q) = QP (ignores data), and a streaming query planner would adapt to data changing over time $$D_t$$. Seen like this, we could have systems creating new query plans “in batch”, depending on what the data looks like. Somehow reminds me of Futamura projections.
This… this looks good. I kind of like TLA+, but writing specs in it is cumbersome and a bit horrible. And Pluscal(s) are not that great either even if easier to write. Alloy is easier to write, but writing temporal logic in Alloy (even with Electrum) is kind of painful (or more like I still can’t get it to work as I want). Spectacle has a lot of potential, and not only because it is Haskell-based.
Is this software core to your business and its unique value? Will you need to change the product regularly to meet new business needs? Does it need to adapt to those changes quickly, on the order of days or (few) weeks, in order to keep up with the demands? These are indications that this is core to the business, even if the software isn’t the direct business logic.
This is by Atul Gawande, and has the alternate title Personal Best. Gawande is a surgeon, and he uses surgical examples so if you are easily spooked by that, skip it. If you are not, consider reading his book The Checklist Manifesto too. I’m wondering now what coaching for software engineers could look like.