Only a tiny fraction of the code your application runs was written by you or your team. How do you know you can trust the code that was written by other people? Where would you even start? This piece is part of a larger series on Engineering for Site Reliability, specifically balancing stability against the edge of technology. What do I mean by “trust”? Movies and TV shows have given us a version of trust which essentially boils down to “Do you trust me?

Over my career, my job title has typically fallen into the baskets of: Front-End Web Developer, Software Engineer, or DevOps/SRE. I’ve done a lot of interviewing to try and find the right people to join the teams I’ve worked on, and I thought it might be helpful to share part of my process. NOTE: I want to start by stating that what is written here are my own thoughts, and not representative of any past or current employer. Remastered? This is an updated and revised edition of my original piece from 2011, “The Hiring Process, Part I: What I Look For in a CV/Résumé”.

While YouTube is free (as in money) to use, the cost is paid in terms of privacy and advertising analytics. So I've decided to investigate self-hosting my video content. The Cost of YouTube With YouTube, you sacrifice privacy in favor of cost. YouTube is the very best at what they do (serve video to all resolutions and bandwidths), and they are backed by Google who is the very best at what they do (collect data in order to facilitate selling a primed audience to advertisers).

When recruiters have absolutely no understanding about the things that they're recruiting for! In this episode of Clueless Recruiters! (Cue theme music!) Explanation There are few things that technical people are more annoyed by than technical recruiters. A very large segment of the technical recruiting industry has made a bad name for the rest of their industry by relentlessly spamming technical professionals after having not done their homework. These people hock job openings the same way that sleazy salesmen hock used cars.

When it comes to Docker containers, the smaller, the better. Smaller containers are easier to work with, deploy faster, and tend to have fewer security vulnerabilities. This piece is part of a larger series on Engineering for Site Reliability, specifically Docker. Big is Bad I worked at WePay during the transition from a monolithic application in the datacenter to a series of microservices running in the cloud. I spent a lot of time working on the Vagrant-based CentOS development environment for the monolith, and also started maintaining a custom CentOS base image in Google Cloud.

After reading Dear Nintendo…, a friend today asked me “How do you feel about the Switch?” Well, let's go down the list. Nintendo Account I can log into my account online, yes. Apparently, Nintendo Network ID is simply an OAuth provider for the rest of the Nintendo website. But you can also have a standalone Nintendo.com login. I deal with this stuff every day, and I still get confused on Nintendo’s website. I have a Switch, a Wii U, the original 3DS, the original 3DS XL, and now the new clamshell 2DS XL.

TL;DR: How I improved the performance of case-insensitive XPath queries by 30–35%, reducing an 8× performance hit to only 4.5–5×. This was originally posted to the SimplePie NG blog. Parse-at-all-costs Most feeds are a mess. The old SimplePie “OG” took a parse-at-all-costs philosophy, and could handle many of the most broken feeds you could find — at a cost. While the early versions of SimplePie supported the letter of the RSS 2.0 specification, there were a surprising number of feeds which didn’t.