Polymath Engineer Weekly #102
Go-to-Market, Modularity, Local-First, Property-Based Testing, Tiger Style, gRPC and Texture
Hello again.
Comic of the week
Links of the week
I’ve spent 20 years investing in and working with deeply technical founders at a very early stage. Looking back, there seems to be one overwhelming determinant of success for those technical teams. In my experience, success is highly correlated with how obsessive a founding team is about developing an extraordinarily efficient go-to-market (GTM) machine.
Testability is the quality which enables the developer to easily test a software component separately from the rest of the architecture.
Thus, a testable architecture is one which is made of components that are easily testable in isolation.
How do the latter sentences relate to modularity?
Home-Cooked Software and Barefoot Developers
For the last ~year I've been keeping a close eye on how language models capabilities meaningfully change the speed, ease, and accessibility of software development. The slightly bold theory I put forward in this talk is that we're on a verge of a golden age of local, home-cooked software and a new kind of developer – what I've called the barefoot developer.
Do you want to be the first to know about new posts? Subscribe now for FREE. Just cool content, no SPAM!
The sad state of property-based testing libraries
The first project at Ericsson that Quviq helped out testing was written in Erlang. Unlike Haskell, Erlang is not a pure functional programming language and on top of that there’s concurrency everywhere. So even the second, monadic, version of QuickCheck didn’t turn out to be ergonomic enough for the job. This is what motivated the closed source Quviq QuickCheck version written in Erlang, first mentioned in the paper Testing telecoms software with Quviq QuickCheck (2006). The main features of the closed source version that, as we shall see, are still not found in many open source versions are:
Sequential stateful property-based testing using a state machine model;
Parallel testing with race condition detection by reusing the sequential state machine model.
Simple event broker tries Tiger Style
It has taken me much longer to learn this than is reasonable, but I now finally know, and act as if I know!, that the very first thing you must do when trying to make your program faster is to measure it and be very systematic about your measurements. Yes, I know it is much more fun to guess at the problem and try out random solutions, crossing your fingers in the hope that one of your guesses magically make things go brrr. But if you plan to make progress instead of trying your luck all day, going straight to some sort of profiling is the winning move. Every. Single. Time. Even if you’re just printf’ing timestamps; you must measure!
In this post, we’ll dive into what HTTP/3 is and explore the compelling reasons why it’s an ideal fit for gRPC applications. We’ll uncover the technical advancements that promise to make HTTP/3 faster, more reliable, and more secure. But we won’t stop at theory; we’ll get our hands dirty with practical examples in Go, demonstrating how to set up and test gRPC servers and clients over HTTP/3.
I have created a survey to get feedback from you. It takes only 2 minutes.
Book of the week
Joshua Weissman: Texture Over Taste
Have a nice week. 😉
Have you read last week's post? Check the archive.