Weeknote of 2018-08-05, Second-order Effects
On repeat on these hot nights: ultralight beam
I’m currently spending time each week interviewing people for our open software engineer position at OfficeLuv. Most days I’m just searching for candidates, and whenever I do find someone I want to interview (I had 5 interviews on Tuesday), I need to make the questions count.
One focus I’ve found to be quick and a reliable way to judge capability is to ask candidates about the second-order effects of their work. Most of the young developers I meet consider only the immediate effects of their solution or immediate problems they debug. The best ones first extrapolate their solution before implementing it. I’m not condoning analysis-paralysis or premature optimization, just the ability to consider a level above or below the current situation.
- How does changing this interface affect user behavior? How will that cascade into stressing pathways within the application queues?
- How does optimizing this function for speed over consistency guide user behavior?
Often, I’ll ask a technical question later in the interview process. It’s not entirely important that they can readily rattle off the underlying algorithm; I’ll happily go over the technical implementation with them. The important part is the second part of the question, where we talk about which and why certain pitfalls, benefits, and behaviors happen because of that implementation.
Because of this, I’ve had second-order thinking on my mind all week. Here are just good pieces and thoughts I’ve found just this week that fit that theme.
This Mind-Controlled Robotic Limb Lets You Multitask With Three Arms It turns out that even when subjects lost the third arm, their rapid task-switching skills remained improved. How much more of our brain is constrained because of physical limitations through the rest of our body?
Disturbances #16: The Price of Perfection This person writes a newsletter every week about dust and I’ve subscribed for a while. It’s usually pretty fantastic. This week, they wrote about the accumulation of dust as a result of modern technological manufacturing. As it turns out, accumulations of dust can be explosive.
Should computer science researches disclose negative side-effects? There was a publication this week of an idea: software engineers should disclose the possible bad-actor uses and second-order effects of the software they research and/or develop. I completely agree with an initiative like this. I was surprised to see so many engineers trying to argue their inability to even attempt such thinking.
Cryptocurrency mining operators are clustering around low-priced renewable energy sources Energy-guzzling software is clumping together in geographic space where energy costs less.
I change the placement and structure of my desk at work pretty often. Here is my current work desk. Not pictured: this is at a standing bar table.
