An example of how even everything is hard at very large scale, in one of my favourite domains: how to distribute requests across replicas. Checking to see if the services you need to talk are "healthy" is a trivial problem if you have ~hundreds of services. This article talks about the problems and some of the solutions when you have thousands or more. If you like this, you should read The Tail at Scale, The power of two random choices in load balancing, and Load balancing in the datacenter from the Google SRE Book. (However, it does drive me crazy to see "health check" spelled as one word.)
While I don't completely follow the details of the bug and the UI is a bit rough, this is exciting: this debugger answers questions like "where in the entire execution history was this variable set to null" or "show me the state of the program at all calls to this function." I like to argue that log debugging is better than traditional debuggers because logs show you some state over time, which is more useful than the entire state at one time. This does both, since it records all state for all time. The about page has more information. I find the debugging continuous integration example very interesting.
An anecdote about school projects, applied to software teams. I think there are at least two interesting points I agree with here. First, for general-purpose software using modern tools, any team should be able get something to work, regardless of experience level. Second, that ideally teams should be balanced in terms of experience level. Another theme in the article that I've been thinking about a lot lately is how a huge part of an experienced engineer's job is to help others do stuff, rather than directly doing stuff.