Developer slash artist Alex Miller joins Jerod & Amelia to discuss the challenge he faced after deciding to eschew fancy frameworks and libraries in favor of vanilla JS to build an interactive essay called Grid World for the html review.

What can art historians and computer scientists learn from one another? Actually, a lot! Amanda Wasielewski joins us to talk about how she discovered that computer scientists working on computer vision were actually acting like rogue art historians and how art historians have found machine learning to be a valuable tool for research, fraud detection, and cataloguing. We also discuss the rise of generative AI and how we this technology might cause us to ask new questions like: “What makes a photograph a photograph?”

After two years of work, Kirby Ferguson has combined his four part series into a single, hour-long video. I haven’t even watched it yet (it’s queued up), but I know this is absolutely deserving of an hour of your time this weekend.

Alexander Lotvall:

It’s a typing app specifically for software developers. You type code snippets from real open source projects. It supports inviting your friends to a room and competing in real time against your friends, and you can get your result on the global leaderboard.

I like how it uses code snippets from popular projects. I don’t like how slow I am at writing Rust code! 🤣

In this episode Adam and Mireille discuss what it takes to develop a high performance mindset. Your mindset is the mental framework that influences your actions, your decisions, and your overall approach to life. Discover how to nurture a growth-oriented and positive mindset, fostering resilience, adaptability, and a commitment to self-improvement. This episode is a must-listen for anyone looking to optimize their mental framework and cultivate a growth-oriented mindset to achieve success in their personal and professional lives.

Quirks: every language has ’em, and the more you learn a language the more of ‘em you run across. Here’s a collection of quirks across a bunch of languages. I’m positive there’s many more that could be added…

Evan Hahn, describing what he calls the “lone developer problem”:

A lot of software is built by one person. It might be an entire product built by a lone developer or a significant piece of a system.

When this happens, I’ve observed that code written by a single developer is usually hard for others to work with. This code must’ve made sense to the author, who I think is very smart, but it doesn’t make any sense to me!

All this time, I just thought it was my code that was hard for others to work with! Turns out I’m not alone…

In a post about overestimating our short-term ability and underestimate our long-term ability, Paavan drops this nugget:

It’s important to recognise the value of quantity over quality. This is best illustrated by an anecdote that I first heard from Kevin Cannon at PUSH Conference: a potter who spends time making 100 vases will end up with one that’s better quality than if they spent the same amount of time trying to just make 1 perfect vase. So, while quality is obviously important, focussing on quantity at the start of a creative journey is the way to get there.

I’ve never heard that anecdote before, but I absolutely love the truth it so clearly represents.

This short piece by Jim Nielsen resonated with me (much like Manu’s post resonated with Jim). He says:

I like this idea of beginning to notice and bring attention to people or creative works that intentionally bring closure, even when you’re left wanting a little more.

When it comes to open source software, people often see a lack of activity and proclaim that a project is unmaintained. Sometimes that’s true, but sometimes the project is merely finished, and that’s okay. In fact, it’s better than okay. It’s downright successful.

There’s a big difference between quitting and finishing. Quitting is in the realm of failure, but finishing is in the realm of success. The key is to define what finished means before you get there, lest you feel like you’re merely quitting.

The art of knowing when to quit? Sure. But how about the art of knowing how to finish?

Tyler Cipriani read “‘Did you miss my comments or what?’ Understanding Toxicity in Open Source Discussions,” and learned about entitlement:

The term is new (to me), but the paper renders a familiar scene, “The author is usually visibly upset about not being able to use the tool, often complaining about wasted time.”

The situation is all-too-common and exhausting. And when it happens over-and-over, maintainers give up.

It made me wonder: why have I never seen “entitlement” in a code of conduct?

Good question…

We’re back! This is from our “lost episodes” — This is your brain…and this is your brain on burnout, any questions? OK, but seriously, burnout effects everyone, even if they/you don’t admit it. Burnout is a state of physical, emotional, and mental exhaustion caused by prolonged stress. It can affect ANYONE, but it is especially common among high-performers who push themselves to the limit. In this episode, we dive into the latest research on burnout and its effects on the brain, as well as offer practical advice for preventing and managing burnout. If you’re heading into 2023 feeling overwhelmed and drained, this episode is for you.

On Wednesday, Stability AI announced it would allow artists to remove their work from the training dataset for an upcoming Stable Diffusion 3.0 release. The move comes as an artist advocacy group called Spawning tweeted that Stability AI would honor opt-out requests collected on its Have I Been Trained website. The details of how the plan will be implemented remain incomplete and unclear, however.

This seems like a step in the right direction, but it appears that artists will have to proactively register and manually flag matched images in the database. Ain’t nobody got time for that!

This week we’re joined by Christina Warren, Senior Developer Advocate at GitHub, and a true tech and pop culture connoisseur. From her days at Mashable covering the intersections of entertainment and technology, to Gizmodo, to Microsoft, and now her current role at GitHub we talk with Christina about her journey from journalist to developer, and the latest happenings coming out of GitHub Universe.

BTW, we’re planning to get Christina on Backstage in the new year to talk about Plex, MakeMKV, and all things that go into hosting your own media server. Drop a commment on this episode with a +1 if you want to see that happen.

Mat Ryer has a very particular set of skills… 🤣

Burnout has reportedly reached a critical point in the software developer circle since the onset of the Covid-19 health crisis. A recent study by Haystack Analytics, a company specializing in productivity of engineers, found that 83% of software developers suffer from burnout. The main reasons given by the latter to explain this exhaustion are high workload (47%), process inefficiency (31%) and lack of clarity of objectives and targets (29%).

That few?! 😏

Kate Monica and the team at Tremendous have been doing this high-documentation, low-meeting work culture for awhile now, so she wrote up five discrete benefits that they’ve seen as a result of it.

Rachel Stephens, trying to reconcile the claims that the tech industry is vastly overstaffed with other claims of vast resource scarcity:

Both things can be true: it’s not a clear over- or under-staffing problem. It’s a problem of proportionality. There can definitely be organizational bloat… At the same time, there are also areas in tech that remain chronically understaffed and under-resourced: OSS project maintainers, people working on-call support, and people writing documentation to name a few.

An interesting analysis with a much-needed call for kindness to our fellow nerds as they face these tumultuous times.

And (I can’t believe I’m writing this, but the jokes about Twitter layoffs in particular keep coming at a surprising rate) be kind to people facing layoffs. Losing your job is awful in the best of circumstances; going through it in such a public and charged situation must be emotionally grueling. Be kind.

Apropos of nothing 😉

Mastodon, a decentralized microblogging site named after an extinct type of mammoth, recorded 120,000 new users in the four days following billionaire Elon Musk’s acquisition of Twitter, its German-born founder Eugen Rochko tells TIME. Many of them were Twitter users seeking a new place to call their online home.

Those users, whether they knew it or not, were following in the footsteps of Rochko, 29, who began coding Mastodon in 2016 after becoming disillusioned with Twitter. “I was thinking that being able to express myself online to my friends through short messages was very important to me, important also to the world, and that maybe it should not be in the hands of a single corporation,” Rochko says. “It was generally related to a feeling of distrust of the top down control that Twitter exercised.”

Adam and I first spoke with Eugen in 2018 (before it was cool) and even signed up on his instance, but haven’t started posting there… yet. I’m a bit skeptical of its ability to scale beyond technologist circles. But maybe that’s okay?

André Staltz:

I used to believe there was mass collaboration on the internet. But I’ve realized that collaboration is extremely hard. It does not scale, especially not at internet scale. The examples we look up to are either not collaborative on the microscopic level, or are rare exceptions to the rule.

The examples he’s referring to are “Wikipedia, open source projects such as Linux, hacktivism, and crowdsourced science experiments such as Rosetta@home.”

This post is sobering, but André speaks from a lot of experience.

No, not that Matrix, although I’m sure you could pull this off there as well…

This project is a web implementation of the raining green code seen in the Matrix franchise. It’s built right on top of the upcoming graphics API WebGPU, but falls back to the functional WebGL wrapper, REGL; its previous Three.js version is maintained in a separate branch.

I used to spend countless hours in college scouring the web for the best digital rain screen saver for my laptop. Sounds like the author is with me on that:

The number of implementations out there of this effect is a testament to the size of the film’s impact on popular culture. For decades, I’ve enjoyed searching for and comparing them from time to time. That’s probably how you arrived here— it’s fun to see what kinds of solutions different people come up with to a problem, when the process is purely recreational and its success is subjective.

This one’s really nice and even has a 3D mode. The README says it’s “made with love”, but from what I can tell it’s almost entirely JavaScript. 😜

iliana etaoin:

There is a lot of attention on securing “software supply chains.” The usual approach is that you want to try to avoid security issues in your underlying components from impacting customers of your product; and when they do, you want to be able to respond quickly to fix the issue. The people who care about this class of problem are often software companies. The class of components that are most concerning these companies are ones where unpaid hobbyist maintainers wrote something for themselves with no maintenance plan.

This is where the supply chain metaphor — and it is just that, a metaphor — breaks down…

I think we all know this intrinsically, but it’s easy to forget. iliana goes on to describe feelings I’ve heard expressed by a few maintainers recently:

I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place.

A lot of ink has been spilt over the years trying to elucidate the divide between junior and senior. Miłosz Piechocki makes the distinction this way:

Junior Engineers care about writing Software. They value code quality, employ best practices, try to adopt cutting-edge technologies. They invest a lot of time into learning new technologies. To them, the ultimate goal is to create elegant, performant, maintainable software.

Senior Engineers care about building Systems. To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.

He goes on to describe how hard it is to build Systems and lists activities that are part of that process.

Jacob Kaplan-Moss with a hot take on software quality:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

What does he mean by “a system designed for quality”? Read on to see for yourself..

whytheluckystiff.net is back online and now hosts links and mirrors to everything the man published on the internet during his illustrious career.

It works sort of like a museum that sells maps.

If you’ve never heard of why the lucky stiff, click through to get acquainted. If you were fortunate enough (like myself) to be around when he was actively creating things, click through for some top notch nostalgia.