Extremely cool conceptual work around the CLI and how it could be possible to pry things apart, create proper primitives and communications channels, and make this an infinitely more powerful interface.
Grateful that Hillel Wayne wrote down here that the 4doc model is not the alpha and omega of documentation and that—like with everything—you should keep thinking while you use it.
I started my show and tell at work yesterday with: “Every company has a crazy person talking about #Nix. I never imagine that one day I would be that person but here we are.”
I had a really bad time getting into #Nix but I used my onboarding experience to fork and update a well-known community resource so it can be used again.
I got nerd sniped pretty hard by somebody sharing a Django code challenge: “only touch views.py and optimize a page load to a time and memory budget in 60 minutes”.
One of the most interesting applications of Rust is to take over after algorithms have been prototyped in Python and create dramatic performance improvements.
Because it’s twenty years old a crusty technology like Django is the fastest way to bootstrap something into production. Get yourself some engineers who are more interested in creating business impact than they are in sprucing up their resume.
Turborepo also has a well considered rationale about why they want to move to Rust. Go still has a relatively strong position on the server, but it’s weird design choices are ill-suited for client side tooling and file system work.
Ink & Switch is doing amazing work leveraging technology like CRDTs to create novel highly-interactive multiplayer interfaces. Here’s their work on Upswelling which is a git-like take on writing and editing.
After having programmed Go for a bit professionally, my experiences in switching to Rust for the backend have been very similar to what’s described here by @adam_chal@hachyderm.io.
What’s interesting about this write-up by Ferrous Systems of creating a real life visual demo with embedded #Rust is that the technology looks increasingly accessible.
A nice deep dive on algorithm design to speed up bracket pair colorization—one of the nicer innovations in code editing recently—in Visual Studio Code.
A nice deep dive into the lowest levels of #Rust programming just to be able to target the web browser (!). I’d like to use #wasm as soon as I have a good reason and project to do so.
A useful distinction between “code proofreading” and “code editing” by Hillel Wayne both of which are part of a standard PR process but neither is really a good fit there.
I’m not sure what lesson to take from the Frankenstein end state of the Facebook iOS app. Is it that mobile does not really scale? Or is it that you shouldn’t scale mobile in this way?
One of my favorite new podcasts is Oxide and Friends which is a weekly live show that’s technically very deep, focused on #Rust, morally opinionated and funny.
The Fly.io write-up of how they built their own orchestrator is a wild ride and also contains a crash-course introduction into how to schedule workloads at (non)scale.
A good overview of the protections that Rust offers compared to out in the wild C code based on the audit of the git source code. In short: if you write idiomatic Rust, you get a lot of protection.
A reasonable enough rationale to choose Java in this article. Am I missing out if I never built a serious backend on the current Spring/Boot JVM (and never seen a team outside of the consulting space use it)?
I read this thorough survey of monospace fonts by Tim Bray and found out in the end that I’ve already been using the fonts that he recommends (Jetbrains Mono and Inconsolata) for a while now.
A thorough explanation why building UI frameworks in Rust is uniquely difficult (and why we haven’t seen clear victories for Rust in that domain… yet).
The next bit of insanity has to do with the German Datenschutz nutters. This is a small but virulent group of people who have blown up privacy issues to the point where most of Germany is still afraid to use the internet.
Ilya Grigorik notes down a perspective on what people at the higher senior+ levels should be doing. At that level things can get fuzzy and people tend to struggle.
“This may surprise you, but continuous deployment is far and away the easiest way to write, ship, and run code in production. This is the counterintuitive truth about software: making lots of little changes swiftly is infinitely easier than making a few bulky changes slowly.”
A really enjoyable three part essay series by Hillel Wayne comparing software engineering with traditional engineering disciplines to see whether we are really engineers, whether we are special and what we can learn from each other.
Machine learning looks like a very challenging field to keep up with let alone to study it. This guide by Vicki Boykis gives a bunch of pointers around reading, mapping and learning that can be applied to any large field you want to get into.
Looks like we can bootstrap a web app using pretty much only Postgres for the data layer and kick out the redis cluster, the celery process and the ElasticSearch server.
Running multiple strategic tracks will set you up to dominate at a large scale, but many organizations can’t run one let alone run multiple at the same time. The visualization and plays as described here by Itamar Gilad look a lot like Wardley mapping.
A short guide of how a team can turn around the work they need to do on a legacy system and come out the better for it. I’ve seen lots of teams struggle with this but as described here a lot of it is in the approach and the praxis of doing it and working together.
A lot of very uncomfortable questions in this list of staff engineering program dysfunctions. It seems this is quite widespread and we’re collectively figuring out how to shape this path.
Good programmers will naturally start to abstract and develop a model that can do more work. But when this happens only in a technical setting, without collaboration with domain experts, the concepts are naive. That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.
I get a bit of a chuckle thinking about the amount of C++ programmer hours that are being wasted here on this next generation car software. I’d love to learn about details when it comes to this.