Lots and lots of programming advice. I can’t attest to the veracity and efficacy of all of it, but this really rang true:
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
Blogging about your stupid solution is still better than being quiet.
You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.
Create a blog. Post about your stupid solutions.
If we continue as we are, who will maintain the maintainers?
In the world of open source, we tend to give plaudits and respect to makers …but maintainers really need our support and understanding.
Users and new contributors often don’t see, much less think about, the nontechnical issues—like mental health, or work-life balance, or project governance—that maintainers face. And without adequate support, our digital infrastructure, as well as the people who make it run, suffer.
This is quite nifty: a fully-featured photo editing tool right in the browser, with no log-in or registration required.
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.
Taking the idea of the Clock of the Long Now and applying it to a twitterbot:
Software may not be as well suited as a finely engineered clock to operate on these sorts of geological scales, but that doesn’t mean we can’t try to put some of the 10,000 year clock’s design principles to work.
The bot will almost certainly fall foul of Twitter’s API changes long before the next tweet-chime is due, but it’s still fascinating to see the clock’s principles applied to software: longevity, maintainability, transparency, evolvability, and scalability.
Software tends to stay in operation longer than we think it will when we first wrote it, and the wearing effects of entropy within it and its ecosystem often take their toll more quickly and more destructively than we could imagine. You don’t need to be thinking on a scale of 10,000 years to make applying these principles a good idea.
Paul Ford explains version control in a way that is clear and straightforward, while also being wistful and poetic.
I had idle fantasies about what the world of technology would look like if, instead of files, we were all sharing repositories and managing our lives in git: book projects, code projects, side projects, article drafts, everything. It’s just so damned … safe. I come home, work on something, push the changes back to the master repository, and download it when I get to work. If I needed to collaborate with other people, nothing would need to change. I’d just give them access to my repositories (repos, for short). I imagined myself handing git repos to my kids. “These are yours now. Iteratively add features to them, as I taught you.”
This looks like a terrific use of a Raspberry Pi—blocking adtech surveillance at the network level.
Wouldn’t it be great if the clichéd going-home-for-Christmas/Thanksgiving to fix the printer/wifi included setting up one of these?
There’s an article about Pi-hole in Business Week where the creators offer some advice for those who equate any kind of online advertising with ubiquitous surveillance:
For publishers struggling to survive even with maximum ad surveillance, the Pi-hole team recommends a renewed focus on subscriptions, affiliate links, and curated endorsements for products and services that might truly interest users, similar to the way podcast hosts may talk about how much they personally enjoy a sponsor’s products. There’s nothing wrong with pitching people stuff they might enjoy, the team says. It’s just the constant, ever-intensifying surveillance that needs to stop.
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.
The transcript of a terrific talk by Paul, calling for a more thoughtful, questioning approach to digital design. It covers the issues I’ve raised about Booking.com’s dark patterns and a post I linked to a while back about the shifting priorities of designers working at scale.
Drawing inspiration from architectural practice, its successes and failures, I question the role of design in a world being eaten by software. When the prevailing technocratic culture permits the creation of products that undermine and exploit users, who will protect citizens within the digital spaces they now inhabit?
Peter looks into his crystal ball for 2018 and sees computers with eyes, computers with ears, and computers with brains.
I like Richard’s five reminders:
- Just because the technology feels magic, it doesn’t mean making it understandable requires magic.
- Designers are going to need to get familiar with new materials to make things make sense to people.
- We need to make sure people have an option to object when something isn’t right.
- We should not fall into the trap of assuming the way to make machine learning understandable should be purely individualistic.
- We also need to think about how we design regulators too.
James talks about automation and understanding.
Just because a technology – whether it’s autonomous vehicles, satellite communications, or the internet – has been captured by capital and turned against the populace, doesn’t mean it does not retain a seed of utopian possibility.
Alan Kay’s initial description of a “Dynabook” written at Xerox PARC in 1972.
Are you the creator, programmer, or quality-tester of a podcasting application? This page provides a range of podcasts that exemplify a range of atypical use case from merely uncommon to exceedingly fringe. If your app can handle all these, you’re doing well.
The title is pure clickbait, and the moral panic early in this article repeats the Toyota myth, but then it settles down into a fascinating examination of abstractions in programming. On the one hand, there’s the problem of the not enough abstraction: having to write in code is such a computer-centric way of building things. On the other hand, our world is filled with dangerously abstracted systems:
When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.
So that’s a big problem.
Bret Victor, John Resig and Margaret Hamilton are featured. Doug Engelbart and J.C.R. Licklider aren’t mentioned but their spirits loom large.