Turns out I hadn’t noticed my hosting provider Vimexx has their MySQL databases on latin1 coding and this blog was running on that happily corrupting data.
Thoroughness unpacked in three dimensions like this by James Stanier is so good and gives a much better way to think and talk about issues of velocity:
As somebody working in platform for the past years, I’ve become very familiar with the different dimensions of this debate around productivity and John here unpacks the topic in a way that’s really useful. I used the nails analogy just yesterday.
After watching the misery around python packaging for years, it’s good to see a bunch of movement in this space and with uv potentially something like a clear winner. That winner should take all and this problem can be solved for the foreseeable future.
I don’t agree that naming is that hard but I do agree with Steve Klabnik here that we should avoid redundant naming if at all possible. Say on Github I have to describe my commit, name my branch and then also title my Pull Request. It’s a bit much.
You start out writing a small flask app that gets a bunch of traffic, then rewrite it in an afternoon and then look at this: “The site was rock-solid after the go rewrite.”
The thing that Bert is not getting here is that Gaia-X is meant to be a distraction and not much else (that “else” would be politically far too risky to act upon). That’s the way these kind of things work. Meanwhile Europe will remain without its own cloud.
A piece about real-world Rust development that struck a cord with many people. Most of the issues listed here are valid and longstanding to the point that you have to wonder if they’ll ever be fixed.
The end of free money has had a huge negative impact on open source. I agree with the author here, it would have been better to license everything under copy-left and see what happens.
Stop writing documentation about your codebase norms that nobody will read anyway and use this approach codifying requirements in tests. It’s so simple and frankly quite ingenious.
A breath of fresh air to read somebody breaking with the TDD dogma. Test are useful but please remember: “Write tests, not too many, mostly integration.” and try to exercise some judgement.
More people have mentioned it and I think it should be part of every Rust tutorial to encourage people to just clone() whenever they get in a jam and get their stuff done: “keep calm, clone and move on”. I think that one thing will make it possible to onboard any team onto Rust quickly and get them shipping.
The Netherlands is facing similar problems where depressed salaries, lack of housing and rampant overt racism are making it difficult to attract digital talent from all over the world.
Amos’s style of software engineering historiography accompanied with snide commentary on the state of the art is both educational and entertaining. The weird factoids about Github Actions are the main act here but don’t miss out on the introduction on software delivery or the lead out on capitalism.
Besides being a clear warning that the open source party is over, this article is a good overview of the different service mesh offerings out there and how they compare to one another. It beats having to wade through the endless amounts of vendor material that’s out there.
This piece about moving away from CDK is a bit overly dramatic and comes down to “CloudFormation sucks” which is something that anybody who’s worked with it can testify to.
Simon Willison is one of the best engineering communicators out there and this podcast with him about LLMs and AI is one of the most insightful episodes I’ve heard on the topic.
It’s much healthier for Germany if digital issues have an answer that goes beyond “Let’s see what the CCC has to say!” The CCC is a shady organization which is good at taking things apart but does not have that much constructive to offer.
Late to the party but I very much love this interview with Karri Saarinen, the co-founder of Linear. Their way of working, “The Linear Method”, will be waved away by companies (“we can’t do that because…”) but with leadership with the right mentality and experience I don’t think it’s that far off at all. Ask your leadership how you can work like this.
A strong analysis of the AI concept by Emily Bender who proposes we just call it “automation”instead. Which is fair because if you use these systems, it becomes incredibly obvious how they work and what their limitations are.
After reading this I get to appreciate a lot more how big of a problem Python packaging is (mostly because Python is so big and diverse) and what kind of a miracle it is that these systems work and keep working at all.
Finding time for side projects and putting out new versions of Cuppings is difficult as always, but I’m glad we have a new version out this week again.
As much as it pains me, I’m teaching myself Helix and trying out the Jetbrains IDEs. Code has been the first editor that really clicked for me but as with all free things, there’s a hidden price to pay for it.
There’s a lot of conversation happening around async Rust which is why I found this article a good primer on the terrain and history of that part of the language.
The post makes it look simple but pulling off a database migration project like this is very difficult to get right and incredibly costly in terms of time and attention that it requires.
A handy overview of how to hire for developer tooling and how to improve the developer experience at companies from a perspective that recognizes these are socio-technical issues but also needs to get stuff done.
I prefer to use contributing factors over the concept of a “root cause” and if people believe an incident has a single cause, usually that also means that they’re not very serious about reliability engineering.
We’re seeing a bunch of these posts come around serverless around the time that we too are reconsidering our investment in this area. Lambda has a lot of operational benefits but at larger scales the developer experience just does not keep up.
A long post that builds up to async Rust from the ground up and explains how the various bits and pieces work. Really quite the tour de force with a simple conclusion: use Tokio.
With our re-evaluation of Lambda as a platform and after talking to some people, I’d say that Rust is the most (maybe the only) viable language on Lambda mostly because it’s negligible cold start times, high performance and the amazing developer experience of aws-lambda-rust-runtime.
The examples are hugely exaggerated for effect but the explanation of why so many people in software engineering keep themselves busy with solving imaginary problems is worth it.
Every time I mention slack time as one of the most important things for healthy engineering teams people look at me as if they’re seeing water burning.
Doing the things listed here as a VP by Emily Nakashima sounds all nice and well (maybe fun even for some people), but the core deliverables of alignment and focus are the real test: both are impossibly hard to achieve and worth their weight in gold.
Nice to see both the scale of the problems that Discord is attacking and the detail of the write-up of how they go about it. I always wondered whether migrating from Cassandra to Scylla would be worth it and it turns out that it is.