Curated Content June 2024
A few pieces of content I thought were worthwhile in June 2024.
Articles
How We Hacked Multi-Billion Dollar Companies in 30 Minutes Using a Fake VSCode Extension
Amit Assaraf
Kicking off June's curated content with this one, it was eye opening to see just how trivial of an attack vector VSCode is, and how potentially rewarding a target it could be for malicious users.
Junior Pairing Scripts
JEG2 is someone whose insights I've benefitted from for most of my career, as I started in Ruby, and learned from much of their content there, so it was cool to see the interest and contribution in Elixir, and specifically this resource in pairing scripts to help junior engineers feel like they're able to better contribute to the pair faster.
These are all Elixir specific scripts, but I feel like it's an easily extensible idea, and that you could create some great language agnostic pairing scripts for folks.
Management at Pivotal
I continue to enjoy Nat's writing (and ought to just tell them on Mastodon/email more too), but I'm sharing this one as well, because I find Pivotal's style of management really interesting. Managers are more focused on mentoring individuals across teams, and are primarily individual contributors still, rather than the traditional manager seen at most organizations.
While this will cause some friction and not be for everyone, the tradeoffs mentioned seem extremely worthwhile to me, as then frontline managers are focused on the highest value add tasks they can be, contributing directly, and increasing the capabilities of their reports.
Quality-Speed Tradeoff -- You're kidding yourself
I have often said to my teams, and thought privately, that the "iron triangle" and the need to make tradeoffs to maximize it in software engineering, is crap. But I hadn't seen an article that summarized this well for me, so I figured I'd have to write it at some point.
Fortunately Ron had already written this one for me, so I no longer have to. Worth a read for anyone in software who is kidding themselves and thinks that there is a trade between, quality, speed and budget in software engineering.
How do we build the future with AI?
View all posts by Chelsea
This article is a bit of a bait and switch, because it's not really about AI. It's about where you can go to find real potential innovation, and why generally speaking Silicon Valley Tech seems to have been getting progressively less innovative as time goes on.
The core thesis is that innovation comes from serving users at the margins of society, rather than the broad/wider statistical base (she's written about this before in another piece as well I believe). I think Chelsea does a great job presenting this in an interesting and compelling way. They then tie it back how AI is currently falling short of serving folks in the margins in these ways, but suggesting a few avenues that may be worth exploring.
The complexity is the attraction - reflections on trying to use crypto
edent
This one by Terence Eden highlights something I had observed, not just in the crypto community, but also with engineers that are really into crypto generally. (Barring a few exceptions from folks that have national currency situations similar to Argentina, but those folks seemed to be into crypto not because it helped their money be less likely to lose 50% of it's value overnight.)
For many engineers into crypto complexity is the point. Making something so opaque and difficult to use, rather than mindlessly simple, seemed to be the end goal, and something that they are drawn to, like moths to a flame.
This came out not just in the fascination with crypto, but often in their approach to solving problems as software engineers as well.
Books
No new books to recommend this month.
Conf Talks
No conf talks this month.
Podcasts
No podcasts this month.
Microposts
This is a great tip for senior folks at organizations that can't pair for some reason, or choose not to, but want to be able to show more junior folks how they walked through solving a problem.
Interestingly this can also be used by solo developers to later go back and critique their own software development process. They can see things that they are doing as an outside observer might in order to help them improve. I've had engineers do that on my teams, and done that personally, and while not a tool I've reached for every day, it can be invaluable to do periodically.
And to wrap up June's curated content we've got a nice light one, that I also find to be mostly true.
If any you found any of these particularly insightful, or have some content you think I'd like, I'd love to hear about it.
Send me an email, or find me on Mastodon - @brittonjb@hachyderm.io.