GitHub’s ReadME project did a nice job re-telling the story of why the lucky stiff and his enduring impact on open source developers around the world.
On April 30th, 2021, I rickrolled my high school district. Not just my school but the entirety of Township High School District 214. It’s the second-largest high school district in Illinois, consisting of 6 different schools with over 11,000 enrolled students.
Who doesn’t like a good rickroll story? This one’s replete with screencaps and video footage
Bryan Braughn has been making good use of his Checkboxland library (which makes it easy to display text and animations on a grid of checkboxes). He’s made games, image transfers, and even videos like the one below. But then, some introspection:
This whole process has been fun but I really ought to stop.
I got nerd sniped, hard. Sure it’s harmless fun, but I’m starting to feel guilty spending months tinkering on these things when I’ve got the tools and skills to put actually useful stuff into the world. I feel like Superman, using his powers to fry an egg.
I understand where he’s coming from, but I also believe experiments like Bryan’s are what make the web great and when they inspire someone else to build something, they are absolutely “actually useful stuff”. Don’t you?
This post is a confession of an “egocentric maniac” (his words) and how damaging code review can be:
This review I kicked off the article with? I didn’t send it. Instead I gave the guy a couple of comments and politely asked to fix a couple of things. No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.
My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that. It’s quite easy, actually.
The author of this site handed a neural network brief text descriptions of a bunch of movies and let it generate image that represent each. Read how he did it or just have fun trying to guess the movie titles from the images. Harder than I thought it’d be!
A (short) must-read piece from rachelbythebay:
“Everyone knows” that code is something you type into a computer, that gets interpreted by a computer, and is run by a computer. But that’s not really the end of it. Before that, it’s being “run” on whoever’s working on it. After that, it’s “running” on whoever’s digging into it to fix a bug or add some feature.
You can throw all kinds of wicked, nasty, complicated, Klein-bottle-wannabe tricks into code and the computer will shrug and slog on through it.
Try feeding that same mess to a human and you will have a variety of problems. We see them every day, and, unfortunately, we /create/ them every day.
I’ve often wondered this as well. My conclusion, after not thinking too deeply about the issue, was that it’s a combination of the difficulty in match making and poor tooling. (There are many startups trying to solve those problems, but it doesn’t seem like anybody has cracked the nut yet).
There’s lots of wisdom in this post by Curt Corginia:
A wise, mature person would treat the software engineer interview process as a pure learning experience. He, or she, would enjoy learning about companies out there for the sake of research, interacting with key players, and mastering the art of whiteboarding. It would just be like a fun game.
I don’t think of it like that, but a mature person would. Do what I say, not what I do.
Yes, to all of this! Dave Bailey, author of The Founder Coach, shared ten useful patterns to help nurture more generous interpretations of others’ behaviors.
Reading this makes me really miss producing Brain Science.
When we encounter emotions and behaviours that don’t make sense to us, it’s often because we don’t have all the information. And in the absence of information, we tend to assume the worst.
‘Emotional generosity’ is the ability to see past behaviours that we don’t understand and proactively look for compassionate ways to explain them. It’s easy to do this for young children. If they start crying or throwing a tantrum, we wonder whether they are hungry, or tired, or hurt. Sadly, it’s harder to do this for adults — and especially our co-workers. And yet a more generous interpretation of their difficult behaviour often ends up being right.
Apple said Thursday it will relax some App Store rules in order to settle a class-action lawsuit brought by U.S.-based developers over its store terms.
…Apple will let developers communicate with users about alternative payment methods outside of the App Store. It will also set up a $100 million fund for small developers and make some other changes to its practices, but it’s keeping its overall commission structure.
This settlement is not yet approved by Judge Yvonne Gonzalez Rogers.
From Den Delimarsky:
We are truly living in an era of user-hostile software, and when I say “user-hostile” I mean it as “software that doesn’t really care about the needs of the user but rather about the needs of the developer.” And this is not a problem that is bound to a specific operating system (or version thereof) or class or computers. It’s literally cross-platform, and it follows customers from home, to office, to their commute.
Let me give you some examples from my own experience…
A common offender for me are apps that require permissions to “access machines on your local network.”
Thank you for sharing this Maya. These pull-quotes resonated with me.
I don’t think I noticed I was burnt out until early February 2021, almost six months later. Honestly, realizing it was kind of a relief. I hadn’t noticed how bad it had gotten. A few weeks later, I quit my job. And then a new, different kind of struggle started. Not knowing what to do with myself, or how to recover.
So why did I burn out? I don’t know. It’s not a single thing - like a specific work stressor - that caused my burnout. It was the never-ending treadmill of yet another day’s worth of useless meetings, with a TODO list that only grows, while you get less and less done on it every day. There isn’t a single moment that causes burnout, but there is a single moment when you realize it - that what you’re doing is impossible, insurmountable, unachievable - and that you don’t care. You can’t do it. And you don’t want to anyways.
I desperately needed to enjoy things again - so I could remember what that was like - so I could get back to enjoying ‘productive’ things too. Remember that producing recovery, relaxation, or joy for yourself is still being productive.
Brewster Kahle, founder of the Internet Archive:
As a young man, I wanted to help make a new medium that would be a step forward from Gutenberg’s invention hundreds of years before.
By building a Library of Everything in the digital age, I thought the opportunity was not just to make it available to everybody in the world, but to make it better–smarter than paper. By using computers, we could make the Library not just searchable, but organizable; make it so that you could navigate your way through millions, and maybe eventually billions of web pages.
See also the website they made to virtually celebrate their 25th anniversary. I love the tagline: From Wayback to way forward
I don’t think I’ve ever had more distrust and as a consequence distate for software than in recent years. I don’t think its just me as a tech-nerd with artisanal tech-carpentry aspirations. I want people to build well, treat their users right and generally exercise some actual restraint. I see it very clearly and I react more viscerally than anyone non-technical in my surroundings. However, I see the frustrations and the consequences everywhere…
Doing ops properly is hard. Most of us are failing & learning every day. Some of us manage to have fun too.
This talk by Brittany Storoz from JSConf EU 2018 is sooo good! If you’ve ever wondered why we call bugs bugs, why we throw and catch exceptions, or why we use foo and bar as placeholder variables, give it a 👀
Brendan Gregg tells a tale from 2005:
This is the story of the most unbelievable demo I’ve been given in world of open source. You can’t make this stuff up.
I don’t want to ruin it, so I’ll just say that it’s not unbelievable in the way you might think it’s unbelievable.
Sometimes to solve a problem we tend to choose a set of tools we got used to. How often we pick a tool just because we know it, and not necessarily because it’s the right one for a task at hand? These are my rules to overcome that.
Tom MacWright on the pendulum swinging back and forth between simple and “fancy”
Technology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear.
This article won’t help you write better code, but it might help you better manage your relationship with Twitter. (Which could help you write better code.) It’s also really well written.
Social media are the Trojans at the gates of your mind. Their wooden horse is magnificent. It glistens with all of the fittest memes. I let those Trojans into the fortress of my mind, and it was a mistake.
If you’re intrigued by faustian bargains, incremental games, and petrichor… give it a read.
Hidde de Vries takes a strong, reasoned stance to online criticism of others’ work:
This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.
This is a tough subject because we identify so closely with the things we create (our code), but Hidde is right: if we want to progress as an industry (and individually) we need to be able to criticize (constructively) and receive criticism. It’s part of the process.
We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.
There are obvious upsides to pair programming. This post from Nat Bennett shares both the ups and the downs of pairing all day for years…
So I paired all day, most days, for about five years. This had a lot of upsides, far more than I can list here. There’s a standard list of benefits and drawbacks to pairing that you might be familiar with, but the impact of pairing, especially pairing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.
Nat goes on to share when pairing took more than it gave for them.
Pairing requires being vulnerable, to another human being, for hours at a time. Intimacy, both physical and mental. I had to share space, decisions, thought processes, and often feelings with this person. … This never stopped being draining.
Over time, over years, pairing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.
After working as a software engineer for 20 years, it’s still exciting to see how the results of your work become alive and you still feel yourself as a kid at that moment :)
In the wake of recent events at Basecamp (and DHH’s continued involvement with Ruby on Rails), many have questioned the governance process for Rails. This post from “The Rails Team” is meant to “clarify how the team is structured,” and how they operate.
…no one on the Core team, or their employers, have sole control over the framework or community. There is no individual or subset of individuals who have power to enact policies unilaterally in the Rails community spaces that we operate (for example on issues, pull requests, or the forum).
Casey Newton interviewed a half-dozen Basecamp employees, as well as David Heinemeier Hansson (Basecamp co-founder) to write this account of recent events.
How a list of “funny” customer names triggered an internal reckoning. The controversy that embroiled enterprise software maker Basecamp this week began more than a decade ago, with a simple list of customers. Around 2009, Basecamp customer service representatives began keeping a list of names that they found funny. More than a decade later, current employees were so mortified by the practice that none of them would give me a single example of a name on the list.
Discussion about the list and how the company ought to hold itself accountable for creating it led directly to CEO Jason Fried announcing Tuesday that Basecamp would ban employees from holding “societal and political discussions” on the company’s internal chat forums. The move, which has sparked widespread discussion in Silicon Valley, follows a similar move from cryptocurrency company Coinbase last year.
Employees say the founders’ memos unfairly depicted their workplace as being riven by partisan politics, when in fact the main source of the discussion had always been Basecamp itself.
Seriously loving the writing coming from Casey on Platformer since his departure from The Verge.
What does “developer productivity” mean to you?
At face value, when we think of developer productivity we might think of effectiveness in time management, communication, and task completion. Although we are drawn to personal workflow or time management tools, and learning secrets to improving our productivity, ironically this quest for the holy grail can sometimes take us off course and be a detriment to our productivity. … As a developer of scientific software, and one who has transitioned to working remotely before any stay at home orders, I have slowly learned to optimize my own productivity by focusing exclusively on well-being.
Thanks to Vanessa for summarizing what she’s learned. Here’s a sample…
Establish routine and environment. Small details about your working environment, or lack of a routine, can hugely throw off your workday, and thus your productivity. You should generally pay attention to the lighting, noise level, and comfort of a work space. If you find yourself distracted by anything, you might consider changing your environment.
This will likely pair well with JS Party #169: Work environments & happiness