The Software Ark: Issue 1
Attribution
Since this is the very first issue, I want to make something clear. I'm not indiscriminately reading every article on the internet. I'm subscribed to a boatload of e-mail lists and read >100 articles a week. These are the ones that stood out.
Some of the subscriptions include: SWLW, The Morning Brew, InfoQ, Pointer, Hacker Noon, Hacker Newsletter, TLDR, LeadDev, Last Week in AWS, PyCoder's Weekly, etc.
Articles
How An Unethical Tech Industry Is Undoing Ethical AI
An interesting article that holds tech to account - arguing that the basics of good AI are little more than a PR stunt, given the inability to hold other software to the same base standard. I’ve flip-flopped on this a bunch. Software is tough to build, and our intentions often miss the mark. There are also unintended consequences that oft get in the way, not to mention business expedience. Either way, criticism that holds us to account is always good.
Resistance to passwordless security
I like the idea of going password-less, but I’d only trust a few companies to implement it properly: fingerprints / facial profiles stored on-device, nothing in the cloud. Privacy is king here. That said, there’s a lot of good that could happen with fingerprints in the cloud. Police might be able to capture criminals more easily - something that's happened with DNA profiles in the past. But it’s precisely for that reason that it could be used maliciously as well.
Consent vs Consensus - Sociocracy 3.0
We used to call this two-way-doors / disagree & commit in Amazon - depending on the depth of disagreement/impact. This is a different paradigm that's fairer. Sociocracy is an interesting idea, but not one that I’ve seen work. Without some autocracy in case of conflict, you’re stuck; and that’s something that happens a lot in tech-teams. It’s also why Python’s BDFL approach worked so well. As with all things, even well intended autocracy can't scale.
Distributed Architecture & Design
A good conversation about Scaling Architecture, Conversationally, and what that looks like. It all comes back to context-transfer for me. Usually, disagreements imply a difference in context and aligning that can lead to consent/consensus. Diversity of perspective is so important precisely because it introduces new context, clarifying the decision-making process. But what about after you’ve come to a decision, how do you cascade that - to the teams involved & to future teammates that are yet to even join the company? That said - I’m not a fan of the "architect" title - you usually don’t write code, and you're so far removed from the details that your advice stops being pragmatic. There’s no worse insult for an engineer. Also related is this article on software architecture that I read a while back.
iPhone SE - the peak of iPhone
I have a friend who’s always liked smaller iPhones, and that’s not been a position I understood. Until now.
Python Packaging v137 in 2022
Yet another blog post on how to create python packages. I will admit that poetry is better than everything else (it's what I'm using for this blog actually - makes this static-site a breeze to build), but I still love pom.xml from my java days. Python needs to get its shit together.
Engineering Career Ladders
It’s important that you grow in your career, but it’s also important that you grow in a way that isn’t tied to your current company. Getting better at internal tools is great - but probably won’t help a lot when you switch companies. In that sense I’ve always found soft skills to be quite resilient to change. This article details a career framework that adds perspective on how to think about roles/career options on a tech team. A good supplementary resource is the Dropbox career framework where they lay out their expectations at each role. If you're reading this, and you're able to influence tech-culture in your space, also check out How to drive away your best engineers. While there are parts of the article I disagree with, it's pretty good overall.
Is FB becoming more like TikTok
The question around polarization on the Meta family of apps is deeply contentious and that's all I'm going to say. Personally - I’d rather watch a well-edited video with salt-bae, than a poorly edited video of a friend's proposal. But that’s also why I spend a lot more time on YouTube than I do on IG / Facebook - so maybe it’s not that much of a change to the status-quo.
You can fingerprint with a font?
Wtf. But, why?
Sandwiches and B+ trees
One of the most cogent explanations of a B+ tree and how it’s used in DBs that I’ve seen in a while. On par with one I read a while back on log-structured merge-trees, also called SSTables.
Generics over Rust keywords
Honestly - it’s an interesting idea, but I’m withholding judgement till it's launched. Allowing the call site to decide if a function-call is async/not will foster re-use, but likely at the cost of understandability. For example - what happens with concurrent calls - do we initialize a coroutine scope with resource sharing? or is it just sequential?
This is where Python stands apart for me. Most things have exactly one way to do things. This makes it super easy to onboard and understand what's going on. Generics can complicate things and should be used carefully for platform-y features, with restrictions on type variances. I worry this might wreck that. Nonetheless, my takeaway from this article is that I need to get aboard the Rust train.
Pebbles, Rocks, and Sand - prioritization
I loved how the author thought through prioritization and optimizing for impact. It's a well suited analogy, and on a topic that I've struggled with. A previous team I was on struggled with "Always the rock, not the pebble" and we just lived with it. Over time we stopped funneling sand, and that's when things got hairy. Either way, this framework for thinking about prioritization really speaks to me and is one I'm looking forward to putting in practice. Then again, there's something to be said about simplicity.
