The work and times of the app development team at Steamclock.

Archive (48) RSS Feed

Erica Leong • Nov 25th, 2021

What the Duck?

Stuck on a problem? Feeling frustrated? Not sure what the duck is wrong with your code?

Well in this case, it’s traditional to consult a rubber duck. Rubber duck debugging is an age-old practice, but conventional rubber toys tend be a bit… lifeless. That’s why we’ve created What the Duck!

Bruce (that’s the duck’s name) is eager to listen to you talk through your code, line by line. It’s almost like therapy! (Not really.)

While not a licensed therapist, Bruce is here to help. Rubberduck.zone is a safe space. Unless you turn on Rude Mode, that is.

11.25.21.103

Accent Accent

Brendan Lensink • Oct 6th, 2021

Levelling up our Networking at Steamclock

On most mobile app projects, networking is a pain. Over the years our team members at Steamclock have tried a half-dozen different networking libraries, and each one tended towards some combination of common problems. Too often projects end up with one giant networking file, requests that require wrappers to handle simple JSON, and painful error handling when juggling global and local errors.

Three years ago, with Codable on the horizon, we concluded it may be time for something better. We started by brainstorming some core principles around a networking library:

  • Handle the simplest REST API calls with minimal code, while still having the extensibility to decode the gnarliest responses
  • Leverage Swift’s Codable protocols for automatic decoding and encoding
  • Avoid monolithic networking files and avoid wrappers
  • Straightforward global and local error handling
  • Add a little bit of magic, but only where it goes a long way

From there, we prototyped a humble little networking library. One by one, we started implementing it in our projects, refining and improving the library based on what we learned.

Now, after two years of refinement, we’re happily using Netable as our networking library of choice in most of our projects, including our popular game Two Spies.

Today, we’re thrilled to announce Netable 1.0. As with our other libraries, Netable is open source under the MIT license, and we are accepting pull requests over on GitHub.

10.6.21.237

Accent Accent

Brady Valentino • Aug 24th, 2021

Case Study: Two Spies

Is it a game? Is it an app? Yes!

Our latest case study goes behind the scenes on the development of Two Spies, our Swift experiment turned side project that netted 700k downloads and rave reviews.

Read the case study

8.24.21.47

Accent Accent

Brendan Lensink • Jun 22nd, 2021

Quests: Now Free as in Speech

Two years ago, one of our Build It Day experiements produced a little Mac menu bar app called Quests. It let you quickly access the Github issues assigned to you. In the spirit of shipping stuff, we packaged it up and put it up for download on the App Store as a free app, business model TBD. A lot of folks found it useful, which was great!

Since then, we’ve continued our work building products for clients, as well as exploring and prototyping product ideas of our own. While we love Quests and we’re glad to have it, we’ve struggled to find a plausible business model that would support Quests as a sustainable product. For now, it seems destined to stay as “just” an interesting tool, and not a Serious Product™.

Which is perfectly fine!

But that’s meant that when Github, Gitlab, or Apple changes something that impacts Quests, it’s been hard for us to prioritize fixing it as promptly as we think our users deserve. We want products to delight, and an app that takes forever to support new macOS releases is not delightful. So we’ve been hosting a useful app that’s basically languished, meanwhile bunch of programmers around the world have been writing in about their ideas for for small fixes and additions to it.

So, we’ve open sourced Quests. As of today, the app is available under the MIT License, and pull requests are now officially welcome. The Mac developer community has been wonderful supporters of Quests so far, and we’re looking forward to being able to reply to feature requests with “patches welcome!” instead of just “that would be nice!”

Quests is still available on the Mac App Store for the time being, and has recently been updated with fixes for Big Sur – including that one CPU usage issue. We plan on continuing to upload releases as appropriate, though we may end up moving to a flow where the app is direct-download if it gets enough community contributions that our App Store distribution impedes release management somehow.

You can find the new, open source, Quests repository on GitHub. We’re excited to see what’s next for it.

6.22.21.365

Accent Accent

Erica Leong • Jun 8th, 2021

The Path to Sharing Work, Early & Often

Chances are you’ve heard of the common adage, “share work, early and often.” The benefits are clear: sharing in-progress work early on allows teams to get on the same page and avoid surprises or wasted work. Easy win, right? A lot of teams find it easier said than done.

The Bumpy Beginnings

You might’ve heard that Steamclock has a culture of focusing on quality and polish. This has led, on occasion, to us taking things too far – or, relatedly, jumping to polish too early. In the early days for instance, we sometimes ran into situations where a designer would take a concept, dive straight into a rabbit hole, get sidetracked by the allure of polish, and eventually emerge with a proposal weeks later that was totally out of scope. Suffice it to say, we’ve learned some hard lessons.

Various lo-fi sketches of a pencil concept

So, why is it hard to present work while it’s still rough? On a personal level, it can feel uncomfortable — vulnerable even — to present work that hasn’t achieved our personal threshold of polish. Or, if you’re anything like the designer writing this blog post, you might be so enthusiastic about exploring a particular idea and getting straight to iterating, that you forget to check whether you’re even on the right track, or whether there are other, potentially better ideas that are worth considering. Oops. 😬

But there are ways a team can make things harder too. In our early days, our team hadn’t yet created a consistent workflow for presenting in-progress work, nor a regular schedule for checking in. Sure, we had Slack channels for each project, not to mention Github issues for each task, but requests for feedback on either avenue could get lost in the sea of messages we’d go through daily. We had syncs for each project, but thoughtful design reviews tended to get pushed out of these cross-team meetings.

When we did get around to discussing design feedback, we would often find ourselves getting pulled into a long, prescriptive, or occasionally ambiguous feedback loop. “Make this bigger” / “this isn’t working” / “I don’t want to say make it pop, but…” What we really needed was feedback that was more driven by goals and principles, setting people up to do great work more independently.

The Turning Point

Like any good team, when we see a problem we aim to fix it. So we changed how we worked.

First, we created a #design-wip channel on Slack for posting explicitly in-progress work — such as early sketches for a logo or low fidelity wireframes. We do this with the shared understanding that the work is rough and might even be — gasp — ugly. This helped with visibility, but intentionally sharing early was key: it meant that we were able to consider more approaches and then commit more wholeheartedly to the right one, or shelve an idea entirely if it turned out to be a less promising direction than originally thought.

Shelving a half hour sketch feels a lot easier to do — and much less painful — than shelving weeks of work. Well-timed context via a Slack message or Loom video can work wonders.

For things that required more synchronous feedback, we created weekly design syncs for presenting work internally. This has become a safe space for presenting rough in-progress work to the team, discussing projects’ priorities and goals, asking questions, and clarifying assumptions — essentially, anything that warranted deep discussion. This not only helped us get into a better habit of checking in on each others’ progress, but also pushed us to provide and receive better, empathetic and constructive feedback that could get lost in a Slack message.

Where We Landed

Two years later, our design syncs are our team’s favourite meeting. We’ve found a lot of value in setting up these spaces for ourselves, and getting feedback to come in early has really strengthened collaboration amongst our team. Accepting crudeness in our process granted us freedom to be more divergent in our early ideas, and gave us more confidence in converging on the best one.

In a way, focusing on quantity early on has driven better quality work.

So allow us to impart some of the wisdom we’ve learned on our journey. Create safe spaces to allow people to share rough work. Establish high level goals early to drive more focused, high fidelity polish later on. And never, ever, say the phrase “make it pop.”

Illustration of pencil in final 3D form

6.8.21.765

Accent Accent

The work and times of the app development team at Steamclock.

Archive (48) RSS Feed

Interested in future posts or announcements? Subscribe to our feed.