An amazing tour de force compiling one of python’s core tools black to C using mypyc. There seems to be a lot of activity right now around compiling python code into different targets and also in distributing compiled binaries through python packages.
It has been a while coming that for most workloads sqlite is more than good enough and at the same time also has a lot of operational benefits to offer. I never could believe all the hoops you have to jump through to get a postgres/mysql to run.
“Declaring a feature that’s in customers’ hands “done,”without monitoring, or with flaky tests, or tons of highly redundant code, or other obvious pending work, doesn’t magically get that work done. That work will always be there. It’ll just show up as surprises in your Maintenance Roadmap at an unknown date, when your team has mentally moved on and stopped thinking about the feature.”
For example, there cannot be two parallel flows with mutable access to a value. Nor can there be a flow that borrows a value while there is no flow that owns the value.
So I had some code very similar to the following that wouldn’t compile and me with my old Python head was a bit surprised why this was the case. It was a bit more complicated to figure it out in my example but this simplified version makes it pretty clear.
I agree with this take by Jacob Kaplan-Moss that you should be able to estimate very accurately and then just not do it most of the time. Learning how to estimate is a non-negotiable part of building an intuition for software engineering. It’s not the estimation that we need, it’s the intuition.
Improving the way we do posts is something I’ll be spending a bunch of attention on in the next months and here is an excellent guide of how to improve that part of the incident process.
That’s a very astute observation of the state and culture of the Go programming language. I got out of Go way before I hit anything like this (though the Channel Axioms are something everybody is going to deal with). For me Go is a not very interesting intermediary language between Python and Rust.
“I see operationally-minded engineers working cross-functionally with software development teams to help them grow in a few key areas: making outsourcing successful, speeding up time to value, and up-leveling their production chops.”
A lot of the stuff here is our common sense when running projects and also our unique problem as a platform team trying to get stuff done with/for other teams. One thing that engineers tend to forget is how much agency they have: “Although you can’t control what other teams can do, you can influence them.”
A couple of years ago I learned Haskell and to do that I read a book that is universally recommended for beginners and used to be available free online called “Learn you a Haskell for Great Good”.
An amazing article about COBOL and how deep our investment is in legacy technologies that work really well but are also a dead-end. It also seems that if you know any one of those technologies you can find work up until the moment that you die.
A list of learnings from writing a production database by Mahesh Balakrishnan that can easily be applied to any other part of software engineering as well but of course not one-to-one, like: “Socialize estimates of task difficulty repeatedly”
A field report from doing incident management by John Allspaw that I can very much relate to with lots of learnings that need to be disseminated: “Focus less on incident metrics and more on signals that people are learning”
One of the biggest limiting factors for people working in technology is that they like to forget that everything around them is a socio-technical system. The world just isn’t that simple.
I was amazed at how closely this article about product development at Facebook tracks with how I approach it: “PMs are 100% accountable for the results of your team.”
Any chance I get I also dispense with Pull Requests because I like my projects and teams to be happy and productive and blazingly fast. From my experience both approaches are about equally safe and with proper guidance you don’t even need a team of only seniors to make it work.
The Pulp game editor is hugely impressive and at the same time making something like this is well within the potential of any small talented group of people who have a bit of time and vision.
A quick overview of the importance of communication in software engineering, some guidelines and the many work situations where you will be able to apply this particular skill.
We’re picking up some of these large scale iOS development practices ourselves. Getting rid of those pesky conflicts in pbxproj files alone would be more than worth it.
I’m not a huge fan of the financial metaphor for tech debt but this pries apart the core of the problem well from an optionality lens (or as you could also say “rich moves”).
Traditional operations teams and their counterparts in product development thus often end up in conflict, most visibly over how quickly software can be released to production. At their core, the development teams want to launch new features and see them adopted by users. At their core, the ops teams want to make sure the service doesn’t break while they are holding the pager. Because most outages are caused by some kind of change—a new configuration, a new feature launch, or a new type of user traffic—the two teams’ goals are fundamentally in tension.
Enter prebuilds: pools of codespaces, fully cloned and bootstrapped, waiting to be connected with a developer who wants to get to work. The engineering investment we’ve made in prebuilds has returned its value many times over: we can now create reliable, preconfigured codespaces, primed and ready for GitHub.com development in 10 seconds.
I need to keep track of how our bet on AWS AppSync is doing which is so small that it doesn’t show up in Stack Overflow’s official tags chart but here’s an off-label website that will give it to us.
It’s a bit counterintuitive but I think it’s a good point that all the efforts to more and better coordination are harmful. We should have less coordination which will inevitably lead to more work between teams, but that is work you should be doing anyway. I think teams are in general very heavily underfacilitated.
I’ve been thinking along these lines and a DNA type meeting as an informal place of leadership and sparring sound great. In our case, I think I’ll call it “Debt and Architecture”.
Slack has an interesting S-Curve based approach to adopting new technologies where they mention that getting through the trough of adoption is more like product-work than anything else.
A write-up how Dropbox rearchitected and broke up their monolith into pragmatic components. Nice to read that their base was a large Python code base, a bit similar to Instagram which is still running a branch of Django underneath.
There’s going to be a need for operations in companies however much of their infrastructure they outsource and it’s going to be increasingly interesting and valuable work.
I immediately understand it but I’ve never seen it articulated as explicitly as here by the Singapore Civil Service College: “The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.”
When it comes to software development most of these are good opinions and you can take them as yours without spending the six years Chris Kiehl needed (or the many more I did).
Talking about tech debt is so unspecific and confusing that maybe it’s better not to use the term at all and instead talk about it in these terms (specific goals, business outcomes, incremental delivery).
“This is all to say that Paul Graham is an effective marketer and practitioner, but a profoundly unserious public intellectual. His attempts to grapple with the major issues of the present, especially as they intersect with his personal legacy, are so mired in intuition and incuriosity that they’re at best a distraction, and worst a real obstacle to understanding our paths forward.”
Something I have to keep reminding people of: “Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem.”
The nice part of working on open source is I can finally share some of the amazing work my team has been doing. Here’s some forthcoming Suricata contributions by Sascha and Frank with more on the way.