“they fail often”
¶ by !undefinedNotes 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.
Shell scripts, JavaScript pedantry, CSS fixations, Java debugging, and the rest of the polyglotism.
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
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?
Angular is Easy. React is Hard.:
Eric Clemmons’ perspective on the perception (myth?) that React is easier to reason about and therefore easier overall than AngularJS. Among his main criticisms of React: that it’s only solving the view problem, that you need to “bring your own architecture”, that there subtle bugs may be introduced by JSX, and that confusion around props vs. state can lead to tightly-coupled components.
Ultimately Clemmons’ opinion is that AngularJS is better for prototyping while React is a better fit for “universal” applications. He admits though that all his points may be irrelevant in the near future as newer versions of these frameworks come online. His conclusions seem even-handed and worthy of consideration (though I think he under-states how useful AngularJS can be when properly applied).
The Debate Around “Do We Even Need CSS Anymore?”:
As with just about all approaches in software, there’s no one-size-fits-all solution, and for any given development team, they’ll need to come to their own conclusions about the trade-offs. Personally, I think the “do it all in JavaScript” approach seems like a short-sighted optimization. From the component-based perspectives like we’re seeing with React, I can see why you’d want to bundle style changes to the components — but my gut says this is a slippery slope that prioritizes developer ergonomics over all other concerns.
Consider battery performance on mobile, for example — I’d put even money that mobile browsers have been tuned for CSS performance with respect to power consumption, but there’s probably a lot more overhead in managing JavaScript changes and then having to repaint with all those low-level styles applied at the element level. (To be fair: this is a hunch, and I have no data to back this up, nor have I been able to find any in my admittedly brief and shallow search.)
Keith J. Grant’s “stop pretending” point is a legitimate claim, and regardless of which of the big front-end frameworks you’re a fan of, you’ll find that they’ve all embraced some flavor of this by now. However, I remain skeptical of the wisdom to put all the eggs in that particular basket. I still see a lot of value in keeping these concerns separated… to the extent that you can separate them at all.
What Is Code? If You Don’t Know, You Need to Read This:
They will do their standups. And after the standups, they will go off and work in the integrated development environments and write their server-side JavaScript and their client-side JavaScript. Then they will run some tests and check their code into the source code repository, and the continuous integration server will perform tests and checks, and if all goes well, it will deploy the code—perhaps even in August, in some cloud or another. They insist that they’ll do this every day, continuous releases.
Read every word. Every one of those 38,000 goddamn words. Even if it takes you 6000 hours.