What is a JSON feed? Learn more

JSON Feed Viewer

Browse through the showcased feeds, or enter a feed URL below.

Now supporting RSS and Atom feeds thanks to Andrew Chilton's feed2json.org service


Allen Pike

A feed by Allen Pike


372 Easy Steps to Expanding Your Mind

Permalink - Posted on 2018-07-01 06:10

It’s a trap, one I fall into often. I’ll be reading Twitter or Hacker News, and come across an article. It’s promising and potentially enlightening, but long, so I send it to Instapaper for reading later.

Each time I do this, I get a sense of accomplishment. “Yeah! Good for me! I decided to read a substantial essay, something that will expand my mind!”

Yet I have accomplished nothing. Nothing has expanded – other than my Instapaper backlog.

Sure, on occasion I’ll have the good sense to read some saved articles instead of the latest bleeps and bloops, and when I do it’s always rewarding. But I like the latest bleeps and bloops. And reading feels like work! I can start tomorrow.

As a result, I do a lot of saving articles, but not a lot of mind-expanding.

So, this spring, I decided the time had come: I would read through my Instapaper backlog by the end of June. I would finally benefit from those thoughtful and insightful articles no matter how much reading it took.

Spoiler: it took a lot.

After turning on the unread badge in Instapaper – and using an advanced setting to let it download my full backlog – I came face to face with my goal: 372 articles. 372 pieces of writing that past-me had delegated to future-me. Well future-me, time to make some coffee.

With my coffee steaming and my toddler napping, I got comfortable and scrolled down, way way down, to the oldest article.

It was from 2009.

Apparently, I once used an early version of Instapaper to save an article from A List Apart on a topic as old as time: JavaScript frameworks. This wouldn’t have been the first article I’d ever saved, but I guess it was the first one I procrastinated reading.

I skimmed the article for old times’ sake, then hit Archive. Progress 1, mind expansion 0.

Over the coming weeks, I diligently worked my way forward in time. The JavaScript article wasn’t the only piece to age poorly. “The bold new world of 3D TV”, ha right. “Why Twitter must reverse its 2012 policy changes,” sigh. “Why Trump could never be elected,” projectile barf.

Before long, I’d learned to cock my Archive finger when I came across a piece about politics or technology news. These links, the bulk of my Twitter and RSS feeds, seemed important when they were new, but a few years later they’re kinda just not. The more urgent a take felt, the less likely it turned out to be an important one. Which is kind of a known thing.

Luckily for me, some of those older articles did stand the test of time. There was a 2010 posting based on a 1988 paper on defensive communication, and how spontaneity, provisionalism, and problem orientation can lead to better outcomes when giving feedback and communicating generally. So that was cool.

Incidentally, this was one of the pieces that aged poorly for another reason: archaic pronoun usage. Prose that I wouldn’t have blinked at 5 years ago sticks out now for strangely gendered pronoun usage, either due to authors flipping between “he” and “she,” or using the awkward “he or she” construct every time they need a pronoun. The singular “they” happened slowly, then all at once.

For every article that aged poorly though, there was a timeless classic. Stories of ages gone by, for example. I loved Nintendo of America’s weird origin story, the story of how NHL ’94 became a masterpiece, and how Starcraft barely worked and originally looked like some kind of acid trip.

I was also pleased to find great stories of great failures – whether it was massive oil rigs losing their way, massively acclaimed studios losing their best staff, or massively funded startups losing their grip. I tell myself I like to read about failures so I can learn from their mistakes, but there’s something more to it. I’m fascinated by the key element of failing at scale: hubris.

Nicholas Carlson spun a brutal tale of hubris in an excerpt from his book about Marissa Mayer and the Fight to Save Yahoo, which was fascinating albeit clearly one-sided. The piece wants you to think of Mayer as hopelessly arrogant, but she sounded to me more like a smart person trying really hard to move a beached whale on an impossible schedule. Fascinating nonetheless.

Hubris is maybe even more interesting when it doesn’t (quite) lead to doom and gloom. I enjoyed learning about Angus Reid and the power struggle at Vision Critical, and the wild way Elon Musk built SpaceX with sheer force of will. Either story might feel like a stretch as a work of fiction.

Remarkably, out of 372 articles I found but a single piece of fiction: the brilliantly written and provocative short story Cat Person. The fact this was one of the best articles in the bunch seems to indicate I should be reading more short fiction.

Beyond the hubris and the stories, I did find a few essays that should help me actually do my job. For example, two articles helped me refine my thinking on our labs projects at Steamclock: Aaron Harris’ Why Toys?, and an article about Teehan + Lax’s Labs program. I also got a good reminder from Rands that leaders need to Say the Hard Thing, and a peek at the culture that being too hard purportedly created at Amazon.

I also learned more about the confidence gap that is an obstacle for many women and marginalized people when building their careers, and the pernicious nature of “Assuming Good Intent” in codes of conduct.

As helpful as those few essays were though, I expected to have saved more solid articles on these topics. Building stronger products and teams is my job – I should be reading about it. Sounds like I need to improve my list of inputs.

Today, I read the the final article. I’d already finished the original 372, but I’d also kept adding new articles, so after roughly 400 articles, I finally finished The Trouble With Johnny Depp. I’m now at Instapaper 0.

So, did all that expand my mind? Maybe. A bit, yeah.

But in a bigger way I feel dumber. It feels as though the world of knowledge and ideas and stories that I don’t know has grown a lot, and the world I do know has only grown a little. Which makes sense – there are a lot more than 400 long form stories and essays worth reading, and it’s going to take a lot more than three months to read them. But I’m willing to try.

Armed with my Save for Later bookmarklet and my Kindle, I’m going to keep on reading. I’m going to expand my mind. I’m going to read those great articles, those great essays, and the great novels too. Yeah! Good for me!

I can start tomorrow.

The Great Bug Hunt

Permalink - Posted on 2018-05-30 00:10

A fun thing about programming is that most days, you make progress. Maybe you fix some issues, maybe you add a feature, maybe you build towards something bigger. Your code moves ever forward.

Until it doesn’t.

On occasion, you will hit a Bug. Not a mundane bug, some trifle you can fix in an hour, or even a day. This is a true Bug. One that defies reason. One that evokes a “that’s not possible,” a “how could this even happen?”, or most dreadfully, a “could there be a bug in the compiler?” Hold on kids, we’re going hunting.

Recently, I reported a regression in an app we’re working on: it had become dreadfully slow on launch. QA had noticed the issue too, which is good, but nobody on the development team had seen it happen – which is bad. Scrolling performance was awful on our CI release builds, but fine when the project was built via Xcode. The build settings seemed to be the same. Standard performance profiling turned up nothing obvious. We had ourselves a Bug.

Diagnosing and fixing a Bug requires patience, thoughtfulness, and above all a systematic, scientific mindset. We must eliminate variables one by one. Persistently forming hypotheses and testing each one is the name of the game. While the poor engineer assigned to hunt the Bug already knows this, it is our tradition to ease the pain by sharing the story of a legendary Bug Hunt.

Gather ’round, friends, for the Story of the Crashing Xbox.

You see, before Steamclock, my co-founder Nigel worked in the games industry. The games industry is very fun, when it’s fun. It’s also very not-fun when it’s not-fun. Games are particularly not-fun when you’re finishing them, so by law that’s when you will discover a Bug.

At that time, the team was working on what was to be one of the first games ever for a brand new game console, called the “Xbox”. As final testing ramped up, QA set up three pre-release Xboxen to run automated tests overnight. If the previous day’s build of the game was still running the next morning, it was a sign of a stable build.

Unfortunately, by morning one of the consoles had crashed. Crashes are never good, but this was a particularly bad crash: something running on the graphics card had brought the whole system down. Diagnosing a GPU crash meant hard mode: no debuggers, no stack traces, no “printf” debugging. All you could do is read the code and try things, like an animal.

And so began the Bug Hunt. Each day the lead engineer would comb through the evidence they had, develop a hypothesis, and work to eliminate possibilities. Each night, QA would get a “random” crash, without a clear cause. “That’s not possible.” “How could this even happen?” “Could there be a bug in the compiler?” All the greatest hits.

Naturally, the game ran perfectly well on the engineer’s machine – for multiple days, even. This was little consolation, as the deadline to print and ship the game loomed large.

Luckily, a pattern was soon detected – albeit a strange one. The game was only crashing overnight on one of the three Xboxes. A search for differences ensued. It wasn’t the power cables. It wasn’t the controllers. It wasn’t the order they were burning the DVDs. Bring the Xbox back to your desk – no crash. Put it back – crash. It was something about the very specific setup QA was using.

Now, the process of elimination requires eliminating all variables. So eventually, in desperation, the engineer tried one more thing: he shuffled which console sat on what table. Boom.

It wasn’t that Xbox that crashed, it was any Xbox sitting on that table that crashed. In the middle of the night.

Now, sometimes you need to do strange things for science, and this was one of those times. Stoically, the engineer set up a chair, gathered the requisite quantity of Red Bull, and the Bug Hunt became a Bug Watch. He vowed to watch the Xbox run automated testing on that cursed table until he saw the problem with his own two eyes.

The night passed by slowly, then quickly, and eventually dawn approached. The game still ran. Infuriatingly, it ran. The sun began to rise.

As he started to consider calling it for the night, something interesting finally happened: The Table was struck by a ray of light from the rising sun. Minute by minute, a sunbeam crept across the table towards the Xbox, its warm glow quietly enveloping that black blob of a console.

Which promptly crashed.

It turns out, early Xbox units had an issue where the graphics card could fault when the console reached a certain temperature. There was nothing you could do about it in software. The hardware issue was escalated, the game was cleared for release, and the Red Bull was swapped out for beer – or let’s be honest, probably whisky. Science one, Bug zero.

Back at Steamclock, our scrolling performance Bug was more straightforward. After some process of elimination and some teamwork, yesterday we tracked it down to our crash reporting SDK. A recent change in how the Buddybuild SDK interacts with iOS means that Buddybuild’s Instant Replay feature now causes severe performance degradation, which is very visible when scrolling. Feature disabled, problem solved.

Next time you hit a Bug that defies all explanation, it’s worth trying to channel the persistent and systematic nature of the Bug Hunters that came before you. Whether the Bug is in your code, a 3rd party library, or the thermal expansion of prototype hardware in the morning sun, the only solution is science. And maybe a little whisky.

Caravan to Xcoders

Permalink - Posted on 2018-05-01 08:00

In 2013, I decided it was time to start an iOS development meet up. I’d run VanJS for many years, which was great. There was one thing about running VanJS that was not great though, and that was using Meetup.com.

You see, Meetup is optimized for getting small groups assembled and running. A huge proportion of Meetup’s focus is around making it easier for groups to organize, socialize, and maintain their momentum. Meetup continually adds new ways for members of a group to post various things to the group. If your goal is to have as many Meetup™s as possible surviving and paying dues, optimizing your KPIs for optimal synergy, then this is great.

This is not as great if your goal is to curate a high-quality speaker series for a group with 3000 members, watched hungrily by dozens of hungry recruiters and other loud individuals.

For example, a few years back Meetup added comments to events. They also opted everybody into notifications, as is the style. This probably worked fine for groups with 10 attendees, but at that time we were organizing a large event with 200 attendees. Naturally, Rando Calrissian hops onto the event’s page to say “ill be 5 min late”, which caused Meetup to email 200 people the very important alert that Mr. Calrissian will be 5 minutes late.

In another fun encounter, I started getting urgent messages asking things like “I can’t get in, where is everybody?” I briefly panicked. Had I organized an event but forgotten to attend? I checked my Meetup page, and although I hadn’t, somebody else had! Meetup had quietly added the ability for all attendees to “propose” events, and assign them dates and times, and send announcement emails, without necessarily ensuring that there was a venue or staff or anything associated with that event. So a bunch of people showed up at our usual auditorium, for a talk that somebody had offhandedly suggested. Unfortunately, the auditorium costs $500 and needs to be booked weeks in advance, so this resulted in some poor customer sat.

An interesting problem

Given all that, I wasn’t keen to start another group on Meetup. And doing some research, chatting with other event organizers, I learned that many organizers weren’t keen on Meetup either. Complaints about the lack of control were plentiful. Multiple Meetup customers told me point blank, “I hate Meetup.”

A lot of the complaints centered around the UI. Meetup’s interface is full of feature clutter and bloat. They even have a feature where you can print out a checklist of attendees to check them off as they arrive. Who does that? In part due to this chaos, Meetup’s look and was about a decade behind the times – not the best for events focused on cutting edge design and development.

In contrast, I saw that CocoaHeads Montréal had a simple custom site that presented Just the Facts: the events, where they were, and how to RSVP. It was a breath of fresh air, and far closer to what I wanted for our new group than could be configured on Meetup.

So, we spent a couple weeks prototyping a custom web app, which we called Caravan, for our new iOS meet up, which we called VanCocoa. We left out all of Meetup’s social features, spam, and list-printing doodads. Instead, we focused on what we saw as our key differentiator: Caravan pages would be simple, attractive, and easy to use. In particular, went to great lengths to not require attendees to create accounts – years before it was cool.

That August we hosted the first VanCocoa using Caravan. Although people liked the event and the site, I immediately started to receive a lot of support email about it. 90% of the issues stemmed from my brilliant idea of not requiring accounts:

  • “Did I RSVP?”
  • “How do I un-RSVP?”
  • “I accidentally RSVPed twice with two different emails, what do?”
  • “Do I have to re-type my email each time I RSVP?”
  • “I accidentally RSVP’ed to another event using a different email address than I’d used before, and now I’m getting announcements to both emails, can I just merge them somehow, should you maybe just have some kind of account login?”

We were able to fix some of these in a workable way without requiring people to create accounts, but the product design challenges around avoiding logins made it painfully clear why every product in the space requires account creation for attendees. Blech.

Meanwhile, I started demoing our Caravan prototype to the Meetup organizers who told me they hated Meetup so much. Each organizer was excited to see our progress, but had a feature request. Which is great! Every person’s feature request was different than every other person’s. Which is not great.

One organizer wanted to charge fees. One organizer wanted a message board. Another wanted a poll for pizza preferences?

My favourite was the Meetup organizer in New York whose venue had some security rules that required them to do paperwork for every event. Before attendees could enter the venue, a security guard needed to check them off a list – a list they generated with the very Meetup feature I’d been using as an example of needless bloat. Well, f.

As if that wasn’t bad enough, we were soon offered a cool new venue for VanCocoa. It was very nice and well located, but had a catch: they needed us to sign attendees in. From a list. Well, .

Perhaps even worse, we saw first-hand the power of Meetup’s network effects. Where our VanJS group on Meetup naturally grows substantially every month just by being an active tech event in Vancouver, our Caravan-based group grew ever so slowly, despite having talks of the same caliber. The iOS development community here isn’t quite as big as the web development community, but it’s strong and healthy – something that just wasn’t reflected in the attendance for VanCocoa, despite glowing reviews from attendees.

What do

Given what we’d learned from our prototyping and interviews, we went back to the drawing board and did some design explorations for what a “Next Generation” Caravan could look like. The more we explored and the more we talked to organizers of large Meetup groups though, the less it looked like there was a clear niche for a simple, beautiful Meetup competitor focused on large tech groups. Around that time I saw that CocoaHeads Montréal, the group that inspired Caravan in the first place, started using Meetup themselves. 😕

So, we decided to shelve further development on Caravan and focus on other products we wanted to explore. We kept the site running for VanCocoa for some time, but this winter I sent out a survey of the group asking about future directions. Besides positive reviews, a big message that came back was that we should switch to Meetup – even though people liked Caravan better – because more people would find the group that way. Well, who am I to argue?

So today, we finally ported VanCocoa to Meetup. We also took the opportunity to rebrand: next week will be the first ever Vancouver Xcoders. We’ve always had a great relationship with Seattle’s Xcoders group, and it felt right to join forces. If you’re in Vancouver or visiting sometime, and you’re interested in giving a talk about development in the Apple ecosystem, let me know.

Of course, Meetup is still bad. Very bad. But there’s nothing like trying to build your own thing to help you appreciate the bad thing you don’t need to maintain. And I’m pretty sure the network effect and new name will bring together more of the Vancouver iOS community, and – perhaps more importantly – a more diverse audience beyond the bubble of folks that knew about VanCocoa.

Of course, if you do end up beating Meetup at their own game, please drop me a line.