Little Weeds of Dread
A sobering comparison occurred to me last night: the same way that I can never again fully enjoy the software on the little devices in our pockets and on our wrists, knowing as I do how an app is made and being able to spot when one is not made well, perpetually bracing myself for whatever horrors await at the end of each flickering transition and every unrelenting activity indicator – it is like the anxiety of becoming parent, a parent who was once a child also but whose simple childhood joy has since been choked by the little weeds of dread that take root in the soul of every adult, as one cannot reach adulthood without acquiring unspeakable knowledge, accompanied by horrifying detail, of how a life is made and how easily a life can be unmade.
TIL: Boy, Have I Been Misusing SCNetworkReachability
After reading this discussion — courtesy of Jeremy Sherman — I learned that I’ve been misusing SCNetworkReachability for years. I’ve been allowing certain user-facing states and features to be influenced by the current reachability state, even to the point of blocking some user-initiated network requests. In ’sodes, for example, I’m currently preventing a playback attempt whenever the network is unreachable.
Turns.
Out.
SCNetworkReachability, like all networking, is not reliable enough to support that kind of behavior. If there’s a false negative (which is much more common than one might think), it means the app becomes needlessly unusable.
SCNetworkReachability should only be used to influence what you do about a network request that has already failed, not an initial request that has yet to be attempted. Use a negative status to determine whether or not you attempt an automatic retry, or to tweak the user-facing language of an alert. Use a positive status to consider retrying an earlier failed request. Never prevent a user-initiated request from being attempted just because SCNetworkReachability thinks there’s not a reachable network.
You can see the code I’m using to monitor reachability status right here on GitHub. To drive the point home to myself, I’m probably going to change the public API of my network reachability wrapper from this:
var isReachable: Bool {...}
to something that more accurately models the truth:
enum ReachabilityStatus {
case probablyNotButWhoKnows
case itWorkedThatOneTimeRecently
}
var status: ReachabilityStatus {...}
SCNetworkReachability, or rather the realities of real-world networking at whose mercy SCNetworkReachability remains, is just not reliable enough to deserve a Bool.
Migrating to Unified Logging, Swift Edition
I have a new blog post up on our company blog. If you have a Swift project that is not yet using Unified Logging (os_log and friends), I think you’ll find this helpful. There are some surprising differences, for better and for worse, compared to NSLog and print statements.
If you’re brave, I also have an open-source Swift wrapper around the Unified Logging APIs which takes some of the edge off of the migration away from legacy logging techniques.
Twitter Made Flesh
OH:
I unfollowed my wife. She came home one day, keys jangling against the dusk. Check this out, I said, making a witty joke about a reference, a joke I had made earlier that was laughed at by the right people. She dumped her bags on the chair by the door. I repeated the joke. She went on through the house, past me, past the joke she didn’t get, racing for her cozy clothes by the bed. It was a funny joke. It had a reference in it. She walked past the joke, past me. The right people had laughed at it. She put on her cozy clothes. I unfollowed her. She asked me later to explain the joke, but I had unfollowed her, so there was nothing else I could do.
I unfollowed my dad. He said something about “the Lord”. I don’t like what he believes. He doesn’t know about what I believe. It was family dinner out, at the restaurant where they had a shooting a week later when two men with guns shot and killed a third man who shot at the guests with a gun, and my Dad said something about “the Lord”, and that was one too many things about “the Lord” for me to hear that day. So I unfollowed my Dad. Now I don’t hear about “the Lord” anymore.
I unfollowed the other parents at my kid’s school. It didn’t take long.
I didn’t stop there.
I unfollowed the one who wears those Oakley sunglasses. I unfollowed the one with flaky ears. I unfollowed everyone with a Samsung phone. I unfollowed the one parked outside the Dave & Busters probably waiting to go inside. I was driving fast, I couldn’t be sure. Better to be cautious. I unfollowed the one who chose a heartbreaking brand of beer.
I unfollowed everyone who doesn’t appreciate how much effort I have put into my guilt.
Bad Idea Rejection Tokens™
Something I really appreciate1 when I see it manifested in an engineering lead is the habit of letting subordinates’ arguments frequently win the day during run-of-the-mill code reviews, even when the lead remains skeptical or — especially — is in sharp disagreement with the proposed changes. Disagreeing but permitting isn’t a sign of weakness. In the context of a healthy team dynamic, it’s a sign of good leadership.
There are a finite number of Bad Idea Rejection Tokens™ that a lead can cash in before their teammates conclude that the team lead has a closed mind and a bad attitude. “I wouldn’t have done it that way” is not something an engineering lead should find themselves saying often during code review. Making a habit of rejecting your teammates’ work is toxic for morale and productivity. If instead the lead only occasionally exercises their veto powers, then the teammates can trust that when the lead rejects their work it isn’t motivated by stubbornness but by a good-faith effort to practice good judgment. Finding the right balance between permissiveness and restraint is key.
-
Yep, it’s a good habit I’m seeing demonstrated at work these days, and I’m stoked about it. ↩︎