Mark Seemann explains why we need young people in the software industry:

We need young people in the software development industry. Because of their vigour and inexperience, they’ll push the envelope. Most will fail to do the impossible, but a few succeed.

And why we also need old people in the software industry:

We need old people because they’re in a position to speak truth to the world… Old people have less on the line, so they can speak more freely. If someone you used to admire retires and all of a sudden starts saying or writing unpleasant and surprising things, there might be a good explanation, and it might be a good idea to pay attention.

Alexander Wales:

This image was created by an AI, MidJourney. All I had to do was type in a prompt (“wildfire”) and aspect ratio. This AI is pretty good, but nowhere near the state of the art, and AI like it are, over the next few years, going to make art like this available within seconds at a cost of pennies. This applies not just to “art” like the above, which is going to accompany my prose and worldbuilding projects, but to almost every area of life where you see pictures of any kind. I think it’s hard to understate how big of a deal this will end up being, and this blog post is largely my attempt to collate a lot of the arguments under one roof, in part because some of the arguments aren’t actually arguments at all.

Every year Mozilla releases an Internet Health Report that combines research and stories exploring what it means for the internet to be healthy. This year’s report is focused on AI. In this episode, Solana and Bridget from Mozilla join us to discuss the power dynamics of AI and the current state of AI worldwide. They highlight concerning trends in the application of this transformational technology along with positive signs of change.

John Goerzen built a computer for his 3yo, installed Debian on it, and set up a GUI for it.

The looks of shock I get from people when I explain, as if it’s perfectly natural, that my child has been able to log in by himself to a Linux shell since age 3, are amusing and astounding. Especially considering that it is really not that hard.

It’s not that hard, but it is so foreign to people that they’re quickly impressed by such things. Still, John decided to introduce his kids to a GUI eventually:

Jacob mastered the basics of xmonad really quickly. Alt-Shift-C to close a window. Alt-Shift-Q to quit back to the “big black screen”. Alt-Shift-Enter to get a terminal window.

We launched thunar (the XFCE file manager) and plugged in his camera. He had a good deal of fun looking at photos and videos from it. But then I dropped the true highlight of the day for him: I offered to install Tuxpaint for him. That’s probably his favorite program of all time.

Tux Paint!

Gather round while Jim Grey tells a (long) tale.

My 33rd anniversary in the software industry was the Sunday that just passed, July 3. I remember the date because my second day on the job was a paid holiday!

I want to show you just how far our industry has come and how much we’ve learned.

The more things change:

Lots of things we all take for granted didn’t exist. The Internet existed but not the Web. Software was delivered to customers on tapes or floppy disks. The CD burner was still a few years in the future. Java didn’t exist, JavaScript didn’t exist, .NET didn’t exist.

The more they stay the same:

There was a holy war over text editors. IDEs weren’t a thing yet, so we all coded in a text editor. I was firmly in the Emacs camp, but most of my co-workers loved vi.

Wise words from Andy Brice:

When I was a child I assumed that all the adults running the world knew what they were doing. Now that I am an adult, I am under no such illusions…

I’m going to let you in on a little secret. Most of us who are running businesses had no real idea what they were doing when they started, and still struggle with decisions now.

I tell people this all the time when they ask me for advice. I’ll still give them my advice. But it comes with the disclaimer that I really have no idea what I’m doing. 😆

Lars Wikman on the history of ID3 tags:

If you were a Winamp user back in the day, or curate an MP3 collection currently, you might recognize the humble ID3 tag. It is what the metadata in the MP3 file is made up of. First it was pretty limited in the version later dubbed ID3v1. Like any good 2.0 they added a ton more fields, features, removed character limits and it was suddenly ID3v2. The latest spec is ID3v2.4 while the most commonly adopted one seems to be ID3v2.3. I recently found myself having a reason to dig into this specification.

I wonder what reason he might have to dig into this spec? Could it be for a soon-to-be-announced collab with his friends at Changelog? 😏

This post is not about the technical intricacies of the format… This is about a simpler time, where people saw the wild possibilities of music on computers and when people cared about files, damnit. This is about some of the most interesting and entertaining things I’ve run across while reading the spec.

YouTubeDrive is a Wolfram Language (aka Mathematica) package that encodes/decodes arbitrary data to/from simple RGB videos which are automatically uploaded to/downloaded from YouTube. Since YouTube imposes no limits on the total number or length of videos users can upload, this provides an effectively infinite but extremely slow form of file storage.

Filed under: ways-no-youtube-engineer-ever-imagined-people-would-use-their-software

Good news, everyone! Jan Schaumann merged Futurama with your (least) favorite programming languages. Amy Wong is… Ruby?!

Object-oriented, cute, really popular, and a bit naive. Had a bit of Fry grafted onto herself for a while. Also had a thing with Bender. And Zapp. Easy going, but doesn’t do well in difficult situations, falls over easily.

Bender is Shell. Fry is Perl. If you care at all for his reasoning, you’ve already clicked through!

Gui Heurich on one of the legends of the Ruby community, _why the lucky stiff.

Through the things that he built, the way he performed, and the books that he wrote, _why makes us think about code and also about ourselves. It makes us think about ourselves as programmers. In a sense, _why was the meta-programmer, the one that generates other programmers by promoting reflexivity.

GitLab’s Sid Sijbrandij shares 12 strategies managers can use to support their team and prevent burnout. One of his standout strategies that I doubt rarely gets put into use is reduce the number of hours worked by agreeing to reduce effort

I used scare quotes around “whole life” because those are his words and surely there’s a lot more to life than things you can quantify, but still: this is interesting

Back in 2019, I started collecting all kinds of metrics about my life. Every single day for the last 2.5 years I tracked over 100 different data types - ranging from fitness & nutrition to social life, computer usage and weather.

This data produces 44 graphs that are all shared publicly on the website.

Dominick Schroer:

When was the last time you completed a project? When was the last time you started a project? Have you every felt that you were trapped working on something that you don’t enjoy anymore? Size is something that I’m sure most developers with the drive to do side projects have felt. Recently I have been completing more projects with more success than ever before. This is my new process.

His 4-step process is so simple it might be brilliant.

KBall and Jerod digest and disect recent JS community news (React 18, Redwood 1.0, MDN Plus) then sit down for yet another game of HeadLIES! Can KBall fare better than Nick Nisi did last April Fools?!

So what?

Well, that is the single largest expense we have. If we want to optimize anything in our discipline we should look at this part first. We talk often about how we build systems, but how often do you talk about how you spend the “figuring out” time? If we do not talk about it, it’s not explicit. If it’s not explicit, it does not get optimized.

In addition to the author’s suggested solution to this problem allow me to add: developer retention! Nobody has more to figure out in a system than the people who just joined the team. Cut down on that (via better compensation, workplace satisfaction, etc.) and you cut way down on that oh so expensive “figuring out” time.

The incomparable Jessica Kerr is back with another grab-bag of amazing topics. We talk about her journey to Honeycomb, devs getting satisfaction from the code they write, why step one for her is “get that new project into production” and step two is observe it, her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design can translate to how we skill up and level up our teams, and so much more.

Daniel and Chris talk with Lukas Egger, Head of Innovation Office and Strategic Projects at SAP Business Process Intelligence. Lukas describes what it takes to bring a culture of innovation into an organization, and how to infuse product development with that innovation culture. He also offers suggestions for how to mitigate challenges and blockers.

Last year, TikTokker Avery Steeves posted a video asking why no one talks about how there’s an entire generation of teenage girls who taught themselves to code HTML on Tumblr. “People are like, ‘Oh, there’s no girls in STEM,’” she says, imitating the faceless internet mob. “No, there were! They were just making pale blogs.”

OK so we don’t usually link to Mashable (first time ever?), but this was cool news to me, so I thought it was worth passing along. Long live HTML!

Rands asking himself some tough questions about our “new normal” remote work environments:

Relative to the Pandemic, the single biggest work question I’ve been asking myself for two years is: what did we lose? What is the measurable and objective loss for teams not working in close proximity? I’ve been looking for cracks. I’ve been looking for leading indicators of future doom. The Great Resignation seems like a proper crack, right? But are people quitting their jobs because they can’t work together or because their current job sucks and all this terror in the air has given them a new appreciation of what really matters?

A sobering perspective.

Old as in old school cool not old as in passe:

Despite the new gatekeepers’ best efforts, the old Internet never completely disappeared. Personal websites created by individuals that have always been the meat of the old Internet are still around. They are still about exploration, innovation, fun, and all the rest. Try as the new gatekeepers have, they simply have not had the power to eradicate the old Internet completely. All they can do is pretend it does not exist. And, that is exactly what they do.

But…

… the old Internet seems to be slowly and quietly coming back, and it is coming back even better than before. Now it has better technology and an additional well-defined purpose that it never had before.

Some people have begun to refer to personal websites as the “indie web”, the “small Internet”, or the “smol Internet”. Some seem to reserve the last two terms exclusively for the Gemini Network, which nearly quadrupled in size last year. But, I think all three terms should also apply to some of the other networks that use alternative networking protocols–the Gopher Network, the Tor network, and the ZeroNet network, to name a few.

Here’s a little bonus episode before we get back to your regularly scheduled Go Time. We’re calling it the funny bits. It’s a compilation of times we cracked up making the show for y’all. If you dig it, holler at Jerod. If you don’t, email Mat Ryer.

We laugh so that we do not have time to cry. (via Zachary Taylor in our community Slack)

Today we’re bringing our appearance on DevDiscuss right here to The Changelog. Jerod and I guested their launch episode for Season 7 to talk about deeply human stories we’ve covered over the years on this podcast. For long-time listners this will be a trip down memory lane and for recent subscibers this will be a guided tour on some of our most impactful episodes. Special thanks to Ben Halpern and Christina Gorton for hosting us. Check out their show at dev.to/devdiscuss

Milosz Danczak shares a principle that was surely born from years of painful experiences:

When committing to a piece of software, favor those created by people who value backward compatibility.

But how can you tell if a piece of software is likely to remain stable? Milosz also provides some heuristics you can apply when evaluating a project.

This week we are joined by Sophie Alpert, Head of Engineering at Humu, and former lead of the React Core team, to discuss her experience on being a very early adopter, contributor, and eventually maintainer of React. In her 4+ years on the Core team, she went from supporting a new niche OSS UI library to supporting a project used by millions of developers around the world. Join us to hear about this epic journey, as well as Sophie’s thought’s on some common critiques and misconceptions of React.