Reviews, speculation, and other idle thoughts on hardware, software, firmware…
Sharing Our Work: Testing and Feedback in Design:
Really thoughtful and fascinating piece about the iterative design process at Etsy. If you’re involved in product or interface design in any way, you should read this. The story about the sidebar was magnificent.
How I Structured Engineering Teams at LinkedIn and AdMob for Success:
Now I tend to despise the word “manifesto” but the bit about having an “engineering cultural manifesto” was particularly interesting. Where I work we had an all-hands Engineering off-site about exactly this topic a couple months back that really got me thinking about how to translate your successful habits into values, and how to translate those values into a foundation for everything else – on-boarding, technology selection, what conferences you go to, etc. It works well at the macro level, with big division-wide missions statements, but it’s probably even more effective at the micro level – i.e., how scrum team charters can help them develop and maintain a laser focus.
Notes on Distributed Systems for Young Bloods:
Required reading. Short version: It will fail. It will be slow. You won’t know why. Plan for that.
Solving the OPTIONS Performance Issue With Single Page Apps: A worthwhile read, this talks a bit about the history of XHR, the origin of the X-Requested-With header, and how/why you should prefer an Accept header for content negotiation. In particular,…
“I’m writing this piece because building software is half strategy and half improvisation, and I really do think there are ways to train in both.”
–
Sara Simon, Learning Fluency
Given that my own background has a lot of overlap with her story, this struck a chord with me. The diverse interests, the broad learning, the liberal arts background. You can focus on computer science (or software engineering, or really anything) early and go as deep as possible, as fast as possible. But you’ll miss things.
But something else struck me here in Sara’s essay – something that should have been obvious to me because I have small children: that our important learning comes not in these big flashes (at least not most of the time), but in the repetition of small things. My kids do this. A tiny thing gets repeated over and over again until its mastered, and then it’s just… there. (And again: this should have been obvious to me from my recent study of Scrum and Agile, and its alignment to shu-ha-ri.)
“Is the web platform too big? For one person, yes. Is it a problem? No. No one can be an expert in the whole web. Surgeons aren’t experts in all types of surgery, scientists aren’t experts in all of science, web developers aren’t experts in all of web development.”
– Jake Archibald, If we stand still, we go backwards
The Boring Front-end Developer: Adam Silver waxing philosophical about being the kind of front-end developer who builds useful things and then taking care of them, rather than the kind that builds shiny things and then leaves them to decay.
Understanding the critical rendering path, rendering pages in 1 second:
Essential reading from Luis Vieira about what’s happening in the browser after those bytes start to stream in. Combine this with Ilya Grigorik’s High Performance Browser Networking and you’re going to be one knowledgeable front-end developer.
“We have a space station in 2014, but it’s too embarrassing to talk about. Sometimes we send Canadians up there.”
–
Maciej Cegłowski, Web Design: The First 100 Years
Talking about where the web came from, where people like to think it’s going, and where it’s most likely actually going.
I realize this all sounds a little grandiose.You came here to hear about media selectors, not aviation and eschatology. But you all need to pick a side.
Why Hiring for “Culture Fit” Hurts Your Culture:
Mathias Meyer’s discussion of “culture fit” works with too broad of a definition (e.g., ping-pong may be an instrument or reflection of your culture, but it isn’t culture itself) but manages to make a couple of important points. First (and most important) is the idea that relying on the “culture fit” question is usually an indication of an exclusive culture – and that you’re using it to keep out people who would disrupt the status quo. Which leads to the second critical point, that an over-reliance on that question suggests a toxic environment that is too busy being insular and self-congratulatory, at the expense of questioning its assumptions.
Meyer uses a lot of examples that involve drinking and bars, but I’d say that you should closer to the office first. How does the team engage with the work itself? With each other? When something fails, does it turn into a witch hunt? Or a learning opportunity? Are you using “culture fit” to find more people that are just like you? Or are you building an inclusive team with diverse opinions and talents?