Subscribe to Weekend Reading, a weekly email about code, design, technology, and people

Weekend Reading — Little Professor

Published on 9 months ago

Pulp Librarian This is the story of the 1970s great calculator race... (thread)

Design Objective

Are we designers shamelessly good at self promotion? What do tech designers write about? What do they read and share most? Posts about templates, news, case studies, etc get far more attention than essays about ethics and responsibility. Much content is self promotion, no surprise. And unfortunately, the people with the most experience to share don't have time to do so; the people with the most time to post, don't necessarily have insight from experience. So remember, just because it was posted on the internet and shared wide and far, doesn't mean it's good advice.

Something I have always wondered: why do airlines tell you departure AND boarding time? Like, we really only need to know boarding time, and if you’d stop telling us when we were supposed to take off, we’d stop getting mad that you never seem to do it

Compiler writers let C programmers pretend that they are writing code that is "close to the metal" but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language.

Moon Mom 🌙 "Reminder that we should be using the 🥖 Baguette emoji as the directory separator"

Lingua Scripta

JavaScript for impatient programmers I often link to Rauschmayer's blog posts because I like how well he introduces new JavaScript concepts: accessible to novice and experienced developers, covers common and advanced use cases, distills the Good Parts. Anyway, the book's out, go buy it.

Lines of Code

don’t be clever
code is a liability
ask, learn, and teach
design and architecture matter
first make it correct then make it fast
only make it fast if you know it matters
it’s not done until customers are getting value
it’s not done until there’s nothing left to take away
don’t automate something you haven’t done manually
quick incremental progress is better than the alternative
code is shared by the team. there is no such thing as my code
it’s easier to change a dry-erase board than a production system
code is written to be understood by humans first, computers second

Architectural

Programming is great because you can just take that huge messy chuck from the middle of your function and hide it away under a new name in a new function and feel good about how you "cleaned up" the original function by abstracting the internals.

This is exactly how I used to clean my room as a kid - I'd refactor all the junk on the floor to be under my bed. Boom - problem solved.

TUESDAY. The day you realize that nothing can stop you, because you are a MAGIC SKELETON packed with MEAT and animated with ELECTRICITY and IMAGINATION. You have a cave in your face full of sharp bones and five tentacles at the end of each arm. YOU CAN DO ANYTHING, MAGIC SKELETON

Locked Doors

For people to have trust in their vote being counted, the voting machine needs to be understandable by everyone, not just software engineers specializing in cryptography.

A counting room full of people counting paper ballots is a machine, and it's a transparent machine where everyone inside it and outside of it can understand how it works, and trust that it's working properly.

But the biggest argument against electronic voting is that you're not solving any problems, you're just adding problems and decreasing the trust in the elections massively. And for what? To get election results a few hours faster? That's ridiculous.