We're embedded directly in project teams at agencies. I spent five years working remotely and running a major open source project before joining the U.S. Digital Service in January. I love remote work and enjoy extolling its virtues, but very simply, we could not do this job remotely, at least not for the time being.
Our friends at 18F (https://18f.gsa.gov) have a lot of people working remotely, as well as offices in SF, Chicago, and New York. The nature of their work is simply different (and just as awesome).
I'd be interested in learning about the restrictions at USDS that prevent it from going remote. Perhaps taking the conversation off thread is best. I imagine it's a combination of being embedded at agencies and perhaps a clearance issue?
Conceptually, I think everyone at the U.S. Digital Service would be comfortable with working on a remote team. Many of us have done it, and since we're scattered across agencies, the group itself operates in a fairly distributed fashion on a day-to-day basis.
Remote work does work at 18F, where they are often shipping projects that are self-contained and executed in-house. It's also a lot easier to build a remote-friendly culture if you start on day one, which 18F did. It's really just about the nature of the work we do, embedded on these agency projects, that necessitates being in D.C. The role of USDS HQ is simply different -- we're often grafted onto existing 'culture' elsewhere (I work on a floor with more than a hundred of product and engineering folks who were here years before we arrived), and are then tasked with helping to advise/fix/transform those projects as quickly and effectively as possible. (I'd also read https://blog.newrelic.com/2014/03/26/depth-look-team-saved-h..., which was a precursor effort.)
If you're interested in serving in the U.S. Digital Service but are in a position to be only able to work remotely, 18F is a pretty great option.
WordPress works great sharded and/or replicated across databases, servers, even datacenters. This is what WordPress.com, WordPress.org, and pretty much any major WordPress site uses: https://wordpress.org/plugins/hyperdb/.
Yes, it is confusing to talk about how blogs get paginated, in general. But if you're curious about WordPress internals: "page" is for archives, like the second page of blog posts categorized as news. "paged" is used when a single post (and page, or any other single item of content) is paginated. You know, like reading multiple pages of a news article.
Yup, I realized the typo this morning. Hanging my head in shame. In fairness, this message was written at 4am after working for 18 hours straight (and 63 of the previous 84 hours, according to rescuetime).
In terms of git features, I think I value correcting embarrassing typos in my commit messages higher than fixing typos in my code! They're a lot more frequent due to the fast and loose typing, and lack of a compiler on my back.
Our commitment to backwards compatibility simply forces us to make smarter, more deliberate decisions.
Because we talk so much about our back compat efforts, it is certainly understandable that people might think that is where almost all of our development effort goes. But that isn't actually the case.
We heavily emphasize our philosophies because it makes adopting and updating WordPress easier, and we want users to know that. But in practice, the way we build software doesn't hamstring us. We've introduced new features and rewritten entire APIs without needlessly breaking plugins or sites. And we do sometimes drop stuff -- we are just careful about it. We do whatever is necessary to make WordPress evolve. In the end, we've simply become really good at following through.