Culture Icon

Culture

Beliefs, behavioral patterns, thoughts, and institutions of the developer community.
432 Stories
All Topics

Culture mccormick.cx

One million people saw my dumbest tweet

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 hiddedevries.nl

Criticism pushes the web forward

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.

Nat Bennett simplermachines.com

What happens when you pair all day, most days, for years?

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.

Rails weblog.rubyonrails.org

Clarity on Rails' governance

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 platformer.news

What really happened at Basecamp

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.

 Vanessa Sochat cacm.acm.org

10 best practices for remote software engineering

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

Tim O'Reilly oreilly.com

The end of Silicon Valley as we know it?

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 snarky.ca

The social contract of open source

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.

Culture kirby.kevinson.org

ISO 8601: the better date format

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.

Tudor Girba blog.feenk.com

Developers spend most of their time figuring the system out

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.

Tom Critchlow tomcritchlow.com

Why can't I write code inside my browser?

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?

Sahil Lavingia sahillavingia.com

No meetings, no deadlines, no full-time employees

Once again, Sahil Lavingia shared proof that we can think differently about the future of work. Sure, not every company should operate the way Gumroad is operating, but there are plenty of insights to be drawn from their experience.

Recently, I pitched the whole company about going full-time, because it felt wrong to grow any larger without full-time staff.

Nobody accepted.

I realized then that I was trying to copy the status quo–to try and fix something that wasn’t broken–so that I could feel better about doing things the “normal” way. But the deal we already had in place was better for what our people prioritize: freedom over growth, sustainability over speed, life over work.

I recently spoke with Sahil on Founders Talk #66 about failing to build a billion-dollar company. I highly recommend that episode.

Kubernetes github.com

Making k8s do what it was always meant to do... order pizza! 🍕

It may be Monday, but that doesn’t mean we can’t have a bit of fun, does it? If fun to you is ordering pizza by writing some YAML… step right up and place your order:

$ kubectl get pizzastore store-123 -o yaml
kind: PizzaStore
metadata:
  name: store-123
spec:
  address: |
    51 Niagara St
    Toronto, ON M5V1C3
  id: "10391"
  phone: 416-364-3939
  products:
    - description: Unique Lymon (lemon-lime) flavor, clear, clean and crisp with no caffeine.
      id: 2LSPRITE
      name: Sprite
      size: 2 Litre

Ben McCormick benmccormick.org

Are you headed towards burnout?

How do you know if you’re on your way to burning out? Ben McCormick has one question he uses when he’s concerned that himself or one of his teammates is headed down a path to burnout:

If you take the pace & quality of the last 2 months of your life and repeated it again and again, how long would you be able to sustain it?

As we begin the process of closing out the year, and what a year it has been, and start planning for what might be in 2021 — consider how this question impacts you now and how you can shape your future with this question in mind.

Ina Fried axios.com

Making sense of the $28 billion Salesforce-Slack deal

If you missed the news…Salesforce is buying Slack for $28 billion. To be clear, the deal is $27.7 billion in cold hard cash plus Salesforce stock. But who cares about money, amirite? Why does this deal even make sense?

Ina Fried for Axios:

[Salesforce] CEO Marc Benioff characterized the move as a bet that the pandemic-driven shift to remote work isn’t a temporary blip but rather a permanent transformation.

Slack has the lead in its still-nascent space, but was facing a challenge of its own — namely that Microsoft’s rival Teams was bundled into Office subscriptions. As a standalone company, Slack couldn’t easily manage such a move, nor could it afford to get into a price war.

I liked what Aaron Levie (Co-founder and CEO of Box) said about this deal and the future of work:

What’s amazing is that even though the current wave of enterprise software to power the future of work has been going strong for 10+ years, we’re still in the very earliest of stages in this market. The last decade has been about building the tools that power new ways to work from anywhere, collaborate with anyone, and automate workflows and business processes in the cloud. The next decade will be the era when organizations adopt these technologies en masse and transform their enterprises. While many of us in Silicon Valley and similar ecosystems have been using tools like Slack for years now (and even Microsoft Teams, more recently), 90%+ of the world’s digital workers are still not leveraging these modern platforms for the majority of their work. While it’s hard to imagine, we’re still in the early innings of this market.

Linux lists.busybox.net

Understanding bin, sbin, usr/bin, usr/sbin

This post to the BusyBox mailing list from back in 2010 was a fun read to get the backstory on bin, sbin, usr/bin, and usr/sbin.

You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one
, which is where all the
user home directories lived (which is why the mount was called /usr). They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp…) and
wrote files to those new directories because their original disk was out of
space. When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

Jaana Dogan Medium

What did I forget by working for the same company?

Jaana Dogan, now working at AWS, reflects on her (long) time at Google:

My time was up for one exact reason. I no longer had no clue what the life outside Google felt like. My actual superpower was gone. I remember sitting in meetings only bringing insights from what I hear from customers without truly understanding how things worked outside of our bubble end-to-end.

Thoughtful reflection is a powerful tool in your life. Sharing that reflection with others, like Jaana does here, can be a powerful tool in other people’s lives. 💪

Matt Klein changelog.com/posts

My secret to building Envoy's community

Envoy’s open source community is amazing. I looked the other day, and at least on GitHub, just from a code contribution perspective, we’re almost at 600 contributors. Which for a fairly low-level C++ project… that is freakin’ incredible. It just blows my mind. And then you look at all of the vertical products and all these other things that are built on top…

There are many factors that contributed to this success, but one thing I did early on stands out as the most important thing I could’ve done. In this post I share my secret with you.

The New Stack Icon The New Stack

An open source leader is gone, a remembrance of Dan Kohn

Thanks to Alex Williams over at The New Stack for doing a great write up remembering Dan Kohn and the tremendous mark he has left on open source and Cloud Native. Of course Dan had help along the way, but by-and-large the CNCF and “cloud native” as we know it are the direct result of Dan’s vision and leadership.

Thank you Dan. You will be missed.

We knew little in 2016 about what Dan was up to but we soon got a hint. The CNCF was already established but what it represented was still a bit unclear. If anything, Dan was a businessman and a computer scientist. He knew the economic importance of at-scale computing and the technical complexity that made it so fascinating.

The technical community was ready for someone like Dan — they needed help. Open source cloud native projects were growing but the resources were essential to keep progress moving. He was there to make sure the work got done that technologists should not have to do: Building awareness, supporting the publicity of new projects and perhaps most of all, smoothly running the conferences.

We’ve had Dan on The Changelog a few times. Go back and listen to episode #276 and episode #314 to hear from Dan himself about the journey of the CNCF and Cloud Native.

An open source leader is gone, a remembrance of Dan Kohn
0:00 / 0:00