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 week we’re talking about open source on Mars. Martin Woodward (Senior Director of Developer Relations at GitHub) joins us to talk about the new Mars badge GitHub introduced. This collaboration between GitHub and NASA confirmed nearly 12,000 people contributed code, documentation, graphic design, and more to the open source software that made Ingenuity’s launch possible. Today’s show is a celebration of this human achievement and the impact of open source on space exploration as we know it.

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

High-profile entrepreneurs like Elon Musk, venture capitalists like Peter Thiel and Keith Rabois, and big companies like Oracle and HP Enterprise are all leaving California. During COVID-19, Zoom-enabled tech workers have discovered the benefits of remote work from cheaper, less congested communities elsewhere. Is this the end of Silicon Valley as we know it? Perhaps. But other challenges to Silicon Valley’s preeminence are more fundamental than the tech diaspora.

Understanding four trends that may shape the future of Silicon Valley is also a road map to some of the biggest technology-enabled opportunities of the next decades…

There are most posts like this from Tim.

Brett Cannon, who is a Python core developer (and a tall, snarky Canadian):

I felt it was time to do another blog post to directly address the issue of entitlement by some open source users which is hurting open source, both for themselves and for others. I want to get the point across that open source maintainers owe you quite literally nothing when it comes to their open source code, and treating them poorly is unethical. And to me, this is the underlying social contract of open source. (emphasis added)

You should read the entire post, especially if you want to learn which programming language (having nothing to do with snakes) that has Brett’s attention. But I’d be remiss not to pull quote this gift of a pull quote from the end:

Every commit of open source code should be viewed as an independent gift from the maintainer that they happened to leave on their front yard for others to enjoy if they so desire; treating them as a means to and for their open source code is unethical.

A fun little microsite where you’re given a name (example: Azurill) and you have to guess whether it’s a Big Data project or a Pokémon. Surprisingly difficult! 😆

KBall, Amal, and Nick dive into key dimensions of what makes a developer work environment good – or bad. They discuss systemic factors, individual factors, what you can do about it, and a proposed scoring system for good work environments.

Chris has the privilege of talking with Stanford Professor Margot Gerritsen, who co-leads the Women in Data Science (WiDS) Worldwide Initiative. This is a conversation that everyone should listen to. Professor Gerritsen’s profound insights into how we can all help the women in our lives succeed - in data science and in life - is a ‘must listen’ episode for everyone, regardless of gender.

Ned Batchelder asks the question:

“How do you make a space that is good for beginners when there are too many experts who also want to help?”

He has a few ideas, but mostly Ned is looking for advice/ideas from others. This is a challenging problem for many reasons. How would you approach it?

It’s time for Americans to abandon mm/dd/yyyy and for Europeans to abandon dd.mm.yyyy and for everyone to adopt the truly better format: yyyy-mm-dd

Yup, that’s about it. You write the year, the month, the day, and then the time exactly like it’s done in other date formats. There’s nothing extraordinary, so you can learn it in 2 minutes.

If you don’t think this format is better, open your mind and read the author’s case.

Empirical analysis from Roy Schwartz (Hebrew University of Jerusalem) and Jesse Dodge (AI2) suggests the AI research community has paid relatively little attention to computational efficiency. A focus on accuracy rather than efficiency increases the carbon footprint of AI research and increases research inequality. In this episode, Jesse and Roy advocate for increased research activity in Green AI (AI research that is more environmentally friendly and inclusive). They highlight success stories and help us understand the practicalities of making our workflows more efficient.

Daniel Stenberg and tfw your open source code (curl) is used by a malicious hacker (seemingly, it’s hard to tell for sure) to attack someone and effectively destroy their business (and life, by extension) and then said victim turns around and threatens your life in a completely unprovoked email. Tragic in every sense. Sorry you had endure this, Daniel.

Tudor Girba unpacks the statement “developers spend most of their time figuring the system out.”

…reading is just the means through which information is gathered from data. It also happens to be the most manual possible way to do that, so this lends itself to an important opportunity for optimization.

Before you can do something significant about anything, you have to name it. Otherwise it’s like with Voldemort. Many winters ago, I called the effort of “figuring the system out to know what to do next” assessment. And I claimed we should optimize development around it. For a whole decade my colleagues and I explored this idea. And it led us to what we now call moldable development.

What would happen if browsers came pre-installed with Node.js, an IDE, and a simple runtime environment?

…there’s been a kind of revolution around coding. “Javascript everywhere” (i.e. node.js) has really become the default web-development paradigm. Javascript is alluring - partly because every computer has a javascript GUI and runtime - the browser! You can code in javascript on your computer using a text editor and a browser - without ever touching the command line!

But, what if a full-fledged dev environment for JavaScript was just as ubiquitous as the runtime in the browser?