twocentstudios

Print Design Mindset to App Design Mindset

Thu, 29 Jan 2026 14:26:08 -0600

The print design era

There was a time when iOS app design wasn’t all that far off from print design.

For the first couple years of the iPhone SDK (2008-2011):

All iPhones had 320 width by 480 height screens.
All iPhone screens were @1x non-retina.
The platform design language was highly skeuomorphic and rewarded delicately crafted Photoshop assets.
iOS did support localization but not for RTL languages and the launch country list was relatively English-speaking (and it was never required for App Store listing).
Accessibility features that dynamically altered app content visually did not exist.

iPhone, iPhone 3G, iPhone 4, and iPhone 5 — all 320 points wide

Sure, there were dynamic elements like buttons with highlighted, disabled, and selected states. Sure, there were scrolling screens. But the overall workflow of app design to app development was taking a Photoshop mockup and recreating it piece by piece in the SDK.

Until Sketch gained some prominence in the 2013-2015 era, Photoshop was still the most popular tool for less technical designers to work in before artifact hand off.

Sketch app showing iOS device artboard presets including iPhone 6, iPhone 5, and iPad sizes

The first cracks in the print design workflow surprisingly started with the sudden differentiation between points and pixels with the iPhone 4 in 2010. Even then, that didn’t necessitate a mindset change away from print design, just a few configuration changes in Photoshop and some extra work come asset export time.

It wasn’t until the iPhone 6 in 2014 that designers (and developers) could no longer assume devices had the same 320 point width. As an iOS developer, you could get away with hard-coding dimensions for your UIViews for a very long time! (Assuming you supported only landscape OR portrait orientation).

iPhone 6 (375pt), iPhone X (375pt), iPhone 13 (390pt), and iPad Air (768pt)

And if varying screen widths weren’t enough, the iPhone X in 2017 broke the assumption that the screen was even a simple rectangle. The notch, rounded corners, and the home indicator meant designers could no longer treat the canvas as a predictable bordered frame.

The complexity catches up

I’ll skip to present day to say that we’re long past the point that most app designers can, with a good conscience, keep a print design mindset when doing visual design for mobile.

The complexity grew, and luckily for iOS developers, the tooling provided by Apple to rein in that complexity has slowly caught up:

For view layout, we have stacks, content margins, size classes, line limits, leading/trailing instead of left/right.
For Dynamic Type (user adjustable font sizes), we have semantic fonts like .body, .headline, .largeTitle. We have the @Scaled property wrapper in SwiftUI. We have UIFontMetrics for scaling non-system fonts.
For Dark Mode, we have semantic colors like .label, .background, .secondary, .blue, .tint, and asset catalogs.
For localization, we have auto-updating xcstrings files, Double-Length pseudolanguage, RTL pseudolanguage, asset catalog localization, plural strings, and localization aware formatters.

HIG semantic label colors adapt automatically across appearances

HIG system colors vary across light mode, dark mode, and increased contrast

HIG Dynamic Type defines seven non-accessibility size categories with semantic text styles

However, there’s a similar time lag (measured in years) between SDK support and true developer tooling support that exists between developer tooling support and designer tooling support for all these features. There probably always will be. Users will adopt them and demand them faster than our tools will support them.

The mindset shift

But going back to print design.

I love (well, maybe love/hate) designing apps, but what I love more is working with talented designers. There’s something about the design field that draws individuals with a tenacious eye for detail and an equally fierce demand for seeing their work reflected with pixel perfection. And most of the time, I would interpret this desire as driven by empathy for the user and not selfishness. They know users recognize and deserve beauty. In other words, their intentions are good.

The trap I’ve seen some of these designers fall into is assuming it’s enough to have empathy for a user and not all users of their designs. In the early iPhone era, 100% of users would see the same screen pixel-for-pixel that the designer created in their Photoshop document. In 2026, the percent of users that see a screen exactly as it was designed is ballpark closer to single digit percentages, if that.

There are simply too many variables that affect the final visual design a user sees when they open your app. Too many to optimize for pixel accuracy with a print design mindset. Dozens of screen sizes. Dozens of languages. Dark Mode. Near a dozen Dynamic Type settings. Bold text. Button shapes. Virtual home buttons. A virtual cornucopia of more esoteric accessibility options. And on iPad, not even fixed screen sizes thanks to Slide Over, Split View, and Stage Manager.

And that’s not even digging into the impedance mismatches baked into the design tools themselves: system fonts displaying a little bit smaller on device than in Figma; color spaces not matching; static assets losing fidelity during export.

I’ve worked alongside many incredibly talented designers over the years. Almost all of them sooner or later made the jump from print design mindset to app design mindset. It took a lot of frustrating (on both sides!) conversations.

At the end of the day, as a developer, I knew the device was the final arbiter of truth. The painstakingly crafted mockups only reflected reality for the brief period of time before the app went live on App Store, and after that they were vestigial colored rectangles, decaying with a half life in the order of days not weeks. The same way that multi-page product spec lovingly crafted by the product manager is lost to the abyss of Google Docs at the end of the sprint.

I knew the signs of the mindset shift, and they all came like manna from heaven. I’d start to receive mockups with loading states leading to the happy path. I’d get error messages with HIG-respectful copywriting. I’d get sidecar notes in the margins pointing out fixed and flexible dimensions. I’d get line limits for text. I’d see table cells with long and short user names. With empty and populated avatar images. The apps were starting to show signs of being apps before I’d actually turned them into living & breathing apps.

More importantly, I would stop receiving design review feedback about marketing copy not line breaking at the exact same words as the mockup. About using a custom alert view instead of the system one.

The designers were now channeling their intrinsic motivation and eye for detail that previously went into pixel perfection into ensuring the maximum number of users with any combination of device settings would still be able to use the damn app to get their task accomplished. And hopefully be able to appreciate the fact the app looked and felt nice while they were getting things done.

The inter-department friction would melt away. We’d ship faster even though we were supporting more design variables than ever before. After all, designers were taking on more of the work I’d previously been doing turning screen after lifeless screen into constraints and states and conditionals. I had more brain bandwidth to double check their assumptions, cover more edge cases, explore architectures that would keep the code from rotting, experiment with animations, and still have time to pair with them on polish. And even more-so, develop abstractions to make this work faster and easier in the future.

When you make the foundational work easy, you have more time left for whimsy. Which is more fun for both the app makers and the app users.

Making the shift

So how can a designer with a print mindset adopt an app design mindset?

Half the battle is simply recognizing the differences between the two. Giving each a name. Recognizing the signs and fighting your instincts for pixel perfection.

From there, I can offer a few suggestions:

Pairing with developers who care about accessibility, design systems, the human interface guidelines, and most of all, users.
Immersing in Apple-sanctioned resources like the HIG, WWDC videos, and learning how to search, read, and understand the developer documentation.
Immediately learning the avant-garde features of design tools that lag behind the native developer tools.
Following the unicorn designer/developer hybrid folks that work in and share wisdom from both sides of the aisle.
Gaining enough proficiency with developer (and AI?) tools to become dangerous (or just be able to update a color value or knock out a quick interactive prototype).
Visualizing apps not just as a collection of snapshots of happy path screens, but a rich journey of pushes, pops, loads, errors, mistaps, drags, interruptions, and everything in between.
Do the painful work of watching over a user’s shoulder as they tap through your app on their 8 year old iPhone with their settings and their cracked screen.

Cheers to many more happy and healthy designer 🤝 developer partnerships in the years to come.

You Are a Frameworks Engineer at Big Tech Corp

Fri, 19 Dec 2025 15:33:38 -0600

You are a Frameworks engineer at Big Tech Corp (BTCorp).

You got the job out of university a few years ago and have mostly enjoyed it.

You’ve gotten used to the pace. Yearly release cycles.

You just finished your last release cycle working on Framework X, a new key feature in BTCorp’s lineup that was internally forecasted to sell lots of hardware.

You’re proud of what was shipped, but know there’s still a lot of work to be done.

You’ve just been reassigned to a new team though. In fact, all of your colleagues working on Framework X have been reassigned. Word is that Framework X is essentially soft deprecated and will never receive any new features or bug fixes. Word is that it was poorly received by tech bloggers and marketing is already starting to scrub it from any materials they can.

You’ve been reassigned to Framework UI. Framework UI is a new UI framework for BTCorp’s hardware. It’s been a skunkworks project for a few years, but finally has the blessing of a VP. After all, Framework CoreUI, the UI framework that’s been around for decades, has an awful reputation outside the company for being too hard to use. BTCorp has been losing developer mindshare and it’s finally affecting the bottom line.

You and all your colleagues are used to Framework CoreUI though. There’s plenty of knowledgeable individuals inside the company that have built or used Framework CoreUI; anyone inside the company can read Framework CoreUI’s source code; and there’s plenty of internal documentation at the source level.

You’re happy to be on the Framework UI project. It seems like an interesting technical challenge. Supposedly there’s a lot of executive team members that are monitoring it closely.

You could spin this into a coveted L5 promotion.

You learn that no one on the skunkworks team (or BTCorp at large) has built software with Framework UI that has shipped to users outside the company yet, but that doesn’t bother you. BTCorp is well known for being secretive about new projects.

You meet with your new team and get assigned your function. You’ll be responsible for everything to do with this function and have a year to get it implemented, documented, tested, and successfully presented at the next World Wide Developers Meetup (WWDM).

Your function is called PaintColor. It takes a Path and Color instance. There’s another team working on Color.

Your PaintColor function is responsible for drawing color on a path. Any color on any path.

You work with your tech lead to understand the requirements. They tell you you should be calling through to Framework CoreUI under the hood. Most of Framework UI is actually just a wrapper over Framework CoreUI.

You’re told the underlying goal is to abstract away a lot of the complexity of Framework CoreUI so third-party developers are less intimidated by BTCorp’s tech stack.

You get to work and quickly realize that this isn’t going to be as easy as you thought!

You’re not just calling through to the existing Framework CoreUI PaintColor function. Framework UI is in BTCorp’s oldest programming language. And you learn there’s a new system in place in Framework UI that defers draw calls. There’s a new concurrency system being tested but it’s not ready yet.

You dig some more and find that going down to the byte level there’s some very complicated mapping you need to do to convert colors. It’s no problem because you’re well versed in algorithms and data structures (you passed the coding test during your interview process at BTCorp after all).

You spend the next couple months getting the implementation perfect. There’s tons of transforms and bit shifting. It’s annoying you’ve had to rewrite it from scratch a few times already (the concurrency system keeps changing), but it’s okay because this is your function and you’re committed to getting it right.

You’re satisfied with the implementation. In your automated testing, it displays all your test colors fine.

You’ve got plenty of time before the World Wide Developers Meetup.

You start documenting your function.

/// Paints a color on a path.
///
/// - Parameters:
///   - Path: a path.
///   - Color: a color.
function PaintColor(Path, Color)

You check the existing documentation for other functions in Framework UI and yours is far and beyond the most detailed. You were originally thinking about going into more detail about the edge cases, but you figure there’s still so much about Framework UI that’s in flux that it’s best not to overcommit.

You hand off your documentation to the documentation team to copyedit and give final approval. They’re already very busy and understaffed, so they tell you to check back in about a month.

You start working on your 30 minute presentation for WWDM. You’re told to emphasize how easy it is to paint colors on paths using Framework UI.

You put together the simplest example you can in your first code sample on slide 24: PaintColor(Path.square, Color.default).

You see nothing on the screen. Hmm… what’s going on? you think.

You start debugging. Color.default is an alias for Color.blue, the default system color. Color.blue doesn’t show up either.

You try the other semantic colors: Color.yellow, Color.red, Color.green. All of them display fine. It’s just Color.blue that’s not painting.

Your function’s only purpose is to paint colors and there’s a color it won’t paint.

Your earlier testing was only on Colors initialized from random hexadecimal strings. Semantic colors were only introduced recently by the team in charge of colors.

You dig deeper and find the exact low-level byte-code representation of Color.blue that was chosen by the team. You put that directly into your function and it’s broken.

You dig even deeper and realize this goes far beyond your understanding of the system. As far as you can tell though, it’s only this one color value that maps incorrectly into the Framework CoreUI painting function.

You start freaking out a little bit. You realize that you’re going to need some help from the experts in the language team, the concurrency team, and Framework CoreUI team to get this solved.

You go talk to your manager. You explain what you’ve uncovered. Those teams are busy, your manager says. The WWDM presentation is the most important thing right now, your manager says, let’s focus on that.

You go to lunch and meet with some friends on other teams. You explain the situation as a hypothetical and ask what they would do. No one inside BTCorp is going to use Framework UI, so who cares, they say.

You decide to stop by to see the Color team on the way back from lunch. You ask them if they have authority to tweak the semantic color values and they say no, you’ll have to talk to the design team.

You head over to the design team’s office, interrupting a designer at your level and they seem annoyed. You explain in too much detail the function you’re working on and the situation with that exact shade of blue. They don’t understand any of the terms you’re using and besides, all this seems like your fault.

You ask the designer if they would please just shift the semantic blue color one bit in either direction. It would be imperceptible to users, you say with an unearned certainty that can’t hide your desperation. The design team will not relent. It has to be that blue. This was decided months ago and is already used in all the promotional materials.

You go back to the team in charge of the Color implementation. You ask, could we add a new semantic color to the API called Color.paintColorBlue that’s one bit off from blue? It will make it easier for all third-party developers to work around the bug during the beta period. The Color team’s manager does not think this will be aesthetically pleasing in the API and may cause confusion. All affected third-party developers can just redefine the color themselves with the hexadecimal initializer, they say.

You give up with workarounds for now, confident you’ll find time and resources to fix the bug before the final release that’s still a couple months away.

You finish writing your WWDM presentation, using Color.red to show off your PaintColor function. At the end of the presentation, you add a quick aside that Color.blue and Color.default are currently broken.

You get a note back from the WWDM presentation review team that says they’ve cut the section about PaintColor being broken. The policy is not to mention any known bugs or malfunctions, as it makes BTCorp look bad and undermines confidence in the new Framework UI framework.

You ask the documentation team if you can still add a “known issue” to the Framework UI beta release notes. They respond that it’s too close to WWDM and they don’t have time. They haven’t reviewed your main documentation yet either, but making any change will move it to the back of the queue. And you’re planning on fixing the bug before the main release, so adding any note about it for just the beta period doesn’t make sense.

You record your WWDM presentation.

Your presentation is lauded as one of the best at WWDM. All third-party developers are really excited about Framework UI. From what everyone can see, it’s so much easier to paint colors on paths now. All the examples from the presentations, including yours, look like such an advancement over Framework CoreUI.

You attend a meet-the-framework-engineers session at WWDM, where third-party developers line up for hours to ask you and your colleagues questions. You’re terrified someone’s going to call out your bug. Luckily, Framework UI has only been available for a few hours, so only one developer asks you about the bug. You tell them to try restarting their computer and to get back in line. By the time they get to the front, you’ve gone home.

Your next few months in the beta period after WWDM are hectic. You’ve been pulled away to fix more important bugs in Framework UI. Management is panicking because it’s become increasing clear that Framework UI is not yet capable of being used for real software.

You watch as Framework UI is released on time anyway. Long time third-party developers are angry they’ve invested time in learning it and trying to build apps with it before the beta period ends. But management still considers it a success, because the narrative among the tech press is positive and new third-party developers are onboarding at record pace. Veteran third-party developers are simply using Framework CoreUI as they always have, just like the developers inside BTCorp.

Your performance review season begins, and at the meeting your manager doesn’t mention anything about the Color.blue bug you spent months agonizing over being unable to fix. Your manager does, however, mention a peer review from the design team that states you were “hard to work with”. Regardless, you weren’t going to get a promotion anyway, but your manager now has something documented to justify it.

Your colleagues called it: it’s been a few months since launch and no developer inside BTCorp has attempted to use Framework UI for production work. Most haven’t even read the Getting Started page that the documentation team worked so hard on.

You decide to jump ship and quit BTCorp, using the outwardly successful launch of Framework UI to secure your next gig at Competing Tech Corp.

You check the third-party developer message board on your last day at BTCorp. You’re curious to see if there’s any feedback about Framework UI as you haven’t really kept up with the launch.

You scan the first page and see a message on the board with a title that mentions Color.default not working. The original poster tracked down the issue to Color.blue and even mentioned the same workaround.

You respond anonymously:

`Color.blue` is not supported in `PaintColor` at this time. 

If you're interested in this functionality, please submit a report to the external bug tracker.

You hit “Send” and not a moment later, the original poster has already responded, exasperated that they’ve already spent hours chasing down the bug, asking why supporting Color.blue would need to be considered as a separate feature, and why you couldn’t have added this to the documentation.

You close your laptop and leave your badge at the reception desk on your way out.

Cookpad: A Retrospective

Wed, 18 Oct 2023 17:25:00 -0500

It’s been almost 5 years since my last series of posts, and 8 since Timehop: A Retrospective. As my last day as an iOS engineer at Cookpad was June 30th, 2023, it’s time to start another chapter of this blog.

While I only published publicly twice on the Cookpad developer blog (Working with AWS AppSync on iOS and Path Drawing in SwiftUI), on our company internal blog I wrote nearly 90 posts, including tutorial videos and recorded presentations. At the time I knew I’d regret publishing internally only, but the ease of writing for a known audience was too hard to break from.

In my next phase, I’ll be making up for lost time. However, for the moment, I’ll try to recap the last ~6 years at Cookpad.

Overview

I worked in some capacity in 7 departments at Cookpad over my tenure, mostly as an iOS engineer, but also in and around AR, IoT, hardware, and ML. From my perspective, management at Cookpad was always encouraging of inter-company movement of engineers, even at smaller scales like 2-3 months (“study abroad”). I certainly appreciated these opportunities.

For context, I worked for Cookpad remotely from Chicago for Cookpad Japan for 6 months starting in April 2017. I moved to Japan in October 2017 and have lived here since.

Cookpad Global

I started off on the Cookpad Global team.

On Global I learned of the complexities of supporting a fully internationalized app, especially in the era where Apple’s support for things like right-to-left languages was still primitive. I learned how intentional distributed work must be while working with groups in the UK and Japan from both Chicago and Japan. I re-learned that premature scaling (choose your preferred definition of “premature” and “scaling”) is perhaps the most irrecoverable mistake startups can make. I continued to refine and put into practice my ideas about unidirectional architecture, immutable view models, and the tradeoffs of functional reactive systems.

It was a unique team where I worked closely with teammates from dozens of nationalities and cultures.

My three biggest (non-solo) projects were:

Converting our app’s navigation layer to use the nascent coordinator pattern.
Rewriting our recipe editor.
Rewriting our login module to support region switching, new OAuth services, and Apple’s new Safari APIs specifically for login.

Studio Satellite

Next was Cookpad Studio Satellite, a startup project within the Cookpad TV organization with a team of around 5. Our goal was to make an app where any cook could easily shoot and edit their own quick-cut recipe video from their iPhone. In later stages pre-launch, we even bolted on a social network that included all the mainstays: a feed, likes, comments, profiles, etc.

Video editor timeline of a pre-release version of Cookpad Studio Satellite

On this project I learned that I love prototyping, working on zero-to-one ideas, working with small teams, and having input (whether true or imagined) into the full product development process. I learned that there will always be stakeholders and that check will always come due.

I learned that sometimes your first users aren’t who you originally thought they’d be. Specifically: we had a dedicated group of community managers from the Global division beta testing from the early versions of the app and giving us very detailed feedback, and yet we never treated them as our “real” users, instead sticking to our original plan of eventually launching to more traditional Cookpad users. It’s speculation, but with some hindsight, I think those community managers could have a been the perfect group to seed the app to and grow from.

Interlude: WWDC 2019

I attended WWDC for the first time 2019 with a small group of iOS engineers from Cookpad Japan and Cookpad Global. It turned out to be a massive year: iOS 13, SwiftUI, Combine, UICollectionViewDiffableDataSource, dark mode, etc. And it was also the final year of the “classic” in-person WWDC format before COVID19.

OiCy (Smart Kitchen)

During a transitional period, I built a one-off app for the Smart Kitchen team. Our team used the app to present a concept during the Smart Kitchen Summit Japan 2019 conference. From concept to presenting the fully functioning app at the conference, it was less than 2 weeks. The app interfaced with a connected oven, inductive cooktop, condiment dispenser, and variable hardness water dispenser, and was remote controlled via the Multipeer Connectivity framework.

A video still from the OiCy Smart Kitchen Summit Japan 2019 presentation showing a hardware-integrated recipe app prototype.

Through the unique scope of this project – a one-off demo app used for a conference presentation – I learned how to radically tailor my development style to some given constraints. It can be surprisingly difficult to choose between development techniques that I know well and work well for 1M+ user-facing apps, and hacky techniques that get the prototype shipped by the end of the day.

In the end, the presentation was a success, but the smart kitchen division closed down a year or so later in late 2020.

R&D

I joined the R&D division with a remit to prototype and productionize various R&D technologies under active research by our team of 5-10. I shipped an MVP that integrated image recognition into an app flow to estimate calories. This was another project that was developed and released internally within a few weeks.

My next big project was using image recognition to filter food photos in the main Cookpad’s recipe photo picker. The main challenges were converting the machine learning model to Core ML and doing all processing transparently on device as a background task for potentially hundreds of thousands of photos. The feature was released for a brief period in beta, but was later rolled back after changes to privacy settings in iOS 14 rendered it too low impact to justify continued maintenance. However, my teammate and I won patent JP,2022-040842,A (US patent is still pending) for the design of the feature.

Diagram from food photo filter patent

Next, I worked with a small group of R&D members on an RGB and thermographic camera system placed above one’s stovetop. As an R&D project, the scope of this project changed significantly over its lifetime. I wrote algorithms in Python for image registration, investigated HLS video streaming over AWS, and built myriad apps and tools in Swift and SwiftUI to move this data around.

Many of my projects during my time in R&D were short explorations. I researched, mostly from the applied technology side, topics like image segmentation, image classification, image inpainting, ML sound classification, pose detection, automatic video editing, and image generation with Stable Diffusion, ControlNet, and Textual Inversion.

However, my persistent focus in R&D was the field of augmented reality. This started with building a “recipe playground” app built in Unity for the Microsoft HoloLens 2 and used in the kitchen. Later, I began building prototypes with Apple’s ARKit and RealityKit for iOS, with the knowledge that eventually Apple would release a headset (Apple Vision Pro, announced at WWDC 2023).

Although my primary role was R&D during this period, I split my time on a few other teams as well, working an average of 2-3 days a week on each.

Cookpad Japan’s recipe app

I did a brief stint working part-time on Cookpad’s flagship recipe app for the Japanese market as an iOS individual contributor. My biggest contribution was a recipe module presented when opening a recipe from an external source that included paging behavior between recommended recipes. The design spec was surprisingly complex and required significant planning work, experimentation, and eventually a custom UICollectionViewLayout.

Recipe carousel in the Cookpad Japan app

Tabedori

I joined the Tabedori team part-time for around 2 years. Tabedori was service within – but separate from – Cookpad run by a small team of between 4-8 members. I was originally slated to cover iOS duties for the 3 months of a coworker’s childcare leave, but the product and team resonated so well with me that I stayed until the product was discontinued in 2023.

The service always served to teach people how to cook without recipes, but advanced through nearly 7 different versions over its lifetime, with myself contributing mostly as an iOS engineer for 2.5 versions. The first version I worked on was still primarily a UIKit codebase, but I added a chat system in SwiftUI, and then the final 2 versions of the app were all SwiftUI. It was the perfect environment for me to dive deep into the details of SwiftUI to understand its constantly evolving limitations from iOS 13 through 16 in real shipping app with a very opinionated style guide.

One of my favorite eras was participating in 2 intense prototyping and exploration periods between versions 5 and 6, then versions 6 and 7. It was during this time we developed, iterated, pitched, and discarded dozens of prototypes individually and as a team, working towards a release. In a short period I learned so much about animations, gestures, navigation, and rapid UI development in SwiftUI, while also considering the product and design angles.

Tabedori version 7, developed with SwiftUI

Cookpad Global Redux

I was invited to visit the Global headquarters in Bristol, UK for 2 months in late 2022. I had the chance to revisit a codebase I hadn’t touched in 3 years while working alongside new and old coworkers and cooking in the office kitchen.

By this point the Cookpad Global iOS codebase and development process had matured significantly. I dove back into UIKit and specifically UICollectionViewDiffableDataSource and helped build an interface for exploring machine translated recipes from other countries.

Cookpad Mart

After a company-wide restructuring in 2023, I found a new home in Cookpad Mart for my final few months at Cookpad. I had been a long-time user of Cookpad Mart’s unique grocery delivery service since its early days and was looking forward to improving the service through the iOS app, its primary client-side interface.

As an e-commerce startup, Cookpad Mart has the conflicting goals of being stable, robust, and bug-free enough to support reliable exchanges of goods for payment, while also needing to iterate quickly to find product market fit and profitability. I was incredibly humbled jumping in and seeing the evolution of a 5 year old codebase and how the alumni iOS engineers had handled these constraints. Much of the required reliability came from systems built around the codebase, rather than the codebase itself: test plans in every pull request, thorough code reviews, a weekly release cadence automated to the bone, “tap parties” where all iOS team members get together to thoroughly test each new feature, rotating QA participation from the product and design departments, and finally a culture of bug fixes being high priority.

Unfortunately, the Mart service itself underwent a massive pivot almost immediately after I joined the team.

The End of the Story

Cookpad as a company went through some significant turmoil starting in early 2023 with the departure of the Japan CEO, then a call for a round of voluntary retirements (PDF) in February, a CEO change (PDF) in May, and finally a larger round (PDF) of voluntary retirements in June.

I was part of that last round of voluntary retirements.

My honest thoughts? It was good time for me to go. I’ve been immersed in solving problems in the food and cooking domain for these past 6 years. Although I’ve always considered cooking a genuine interest – especially in the context of moving to a different country – there are several other domains that I’d like to explore.

So cheers to a good ride. The part I’ll miss most is working with so many kind and talented coworkers, hopefully at least a few of which I’ll be able to work with again.

On Learning Japanese

Wed, 06 Apr 2016 19:26:31 -0500

This is a heavily autobiographical (and most likely boring) post. If you’ve ever done a deep dive into language learning, you may find it interesting.

This past year, I’ve revitalized my efforts to learn Japanese. In the process, I’ve learned a lot about how I learn. This post is personal summary of the efforts of my distant past, recent past, and present.

Distant Past

I started learning Japanese during my Sophomore year in college. The College of Engineering at the University of Illinois at Urbana-Champaign requires three semesters (or the equivalent three years of high school classes) of foreign language study in order to graduate.

My options at the time were to continue with Spanish (I’d taken two uneventful years in high school and absorbed nothing), or start from the beginning with Japanese. After a lot of thought, I chose the harder, but more rewarding path of studying Japanese.

I’ve always been interested in Japanese culture, all the way back to middle school. As far as the language though, I was starting from scratch.

For 18 months straight, I was in Japanese class for one hour a day, five days a week. My memories of those classes consist of great pain. They were difficult. The homework was brutal. I remember staying up until 4am at least a few times a week copying kanji stroke-by-stroke hundreds of times into scratch notebooks. I remember cutting up notecards and making hundreds of flashcards for words I could barely write or pronounce at the time. I remember cramming for grammar tests five minutes before class started every day.

I struggled. I think I got sympathy B minuses because I put in the effort and worked hard (but probably not smart). I even went so far as to retake (as an auditor) the second level class during the summer between my Sophomore and Junior year.

My struggles came from a few places:

Curriculum: We used the Nakama series books. Which weren’t/aren’t bad. But they often lacked nuance in explaining word choice and grammar. A lot of the exercises leaned heavily on in-class participation which there wasn’t always a lot of time for. And as I’ve found, it’s usually a mistake to learn anything from one source.
Teaching: My teacher for my first two semesters was super super nice. She was a grad student from Japan studying classical piano at UIUC. Unfortunately, her English wasn’t fantastic and her lack of linguistics or teaching experience showed at times. My professor for third semester was a lot more qualified, and I ended up doing a lot better that class.
Technology: Technically the spaced repetition software Anki was around when I was studying, and I think I remember trying it briefly. I had already done a lot of manual work making flashcards though, and the concept of entering all of my vocab words into a computer program seemed like even more work, and less mobile capable. In the several years since that time, technology has matured significantly.
Divided Attention: Taking a full load of Engineering classes is no walk in the park. At the time, I could never have a singular focus in learning Japanese, which is something I’ve found to be important to my success in the years since. There were plenty of occasions that even when my motivation for learning was at its peak, I just didn’t have the time or mental energy to give.
Lack of Extracurricular Practice I’m admittedly not the most outgoing person. I never ended up making any Japanese friends around campus to do language exchange with (until study abroad), so my immersion was localized to my daily hour of Japanese class.
Cram-Exam-Forget Cycle: Because I was taking these classes for a grade (that would be weighted heavily into my GPA), it was easy to fall into the cram-exam-forget cycle where I could cram all the vocab into my brain the night before, do alright on the exam, then immediately forget it all the next day and still do alright grade-wise. But there was no motivation to keep up vocab and grammar from previous chapters (besides the inevitable studying for finals).

That reads like a long list of excuses, but truly, the real thing holding me back was that I never sat back and pictured myself as a fluent speaker of Japanese. It was easier to tell myself and others, “I’m just not good at learning languages.” And honestly, it’s a line of thinking I still struggle with.

After my third semester was finished, I was no longer under any obligation to continue my language studies. It was a difficult decision, but I ended up concluding that it’d be for the best for focus those five credit hours on my Engineering studies rather than continue onto a fourth level of Japanese since I wasn’t pursuing a double-major.

As an aside, it’s really frustrating how the university/grading system can warp your priorities. It’s all too common for short term gains to take precedence over long term learning, and for real internal motivation to be sacrificed for manufactured motivation in the form of a letter on a report card. Formal education can certainly be a double-edged sword at times.

I did, however, make a compromise with myself, and was accepted into a study aboard program for the upcoming Summer. Spending the Summer between my Junior and Senior years in Kanazawa, Japan at Kanazawa Institute of Technology was one of my most memorable experiences of those four years at University.

The experience itself was incredible, but after taking a semester off from language study, my language courses over the six weeks were one-foot-in-one-foot-out. Being there definitely helped, but it was actually demotivating being around other Americans who seemed to be picking up the language at such a rapid pace compared to myself.

I promised my senseis that I would keep studying when I got back to America. I sent a few emails to my new Japanese friends over the next few months, but as time slipped by, it took longer and longer to craft even a few sentences in Japanese. As my Senior year progressed and core classes and final projects loomed, Japanese fell to the wayside.

Towards the end of the year, I applied to Mitsubishi Japan and made it through three interviews before I was rejected. I would have spent three years training in Japan before returning to Chicago. I think it was an Engineering sales job (selling industrial relays or something like that). Not really in my wheelhouse, but the prospect of living in Japan was incentive enough.

My first job out of school was also an Engineering job that wasn’t necessarily in my wheelhouse, so a few months in I applied to the JET program. The JET program is a program run by the Japanese government that places native English speakers in assistant teaching roles in schools all around Japan. Teaching English is also not in my wheelhouse, but again, at that point I was still young and really wanted to live in Japan. I was convinced that it would be impossible to improve my Japanese outside of Japan.

I wasn’t accepted to the JET program either, so I continued on my Engineering career path and eventually migrated into software development.

Over the following years, I stayed in touch with some of the Japanese friends I met during study abroad. I did some quick Japanese cramming before my two week vacations to Japan in 2011 and 2014 just so I didn’t get too lost, but of course nothing ever stuck.

Recent Past

This brings me to present day. I lived in Sapporo and Nagoya, Japan for three months over this Winter. I spent most of my time working on a (to be open-sourced) Swift iOS app, as well as doing some sightseeing, seeing friends, and eating great food.

Before I left, I was still undecided about how much time I wanted to contribute to learning Japanese. It wasn’t until my ride to the airport that I downloaded an app I’d heard about called Memrise and started exploring my options.

Memrise turned out to be a great addition to my routine. On good days, I’d spend about an hour a day reviewing or learning new words before I’d dive into coding.

My first course on Memrise ended up being a JLPT N5 course. JLPT is the national proficiency test. It’s used by the Japanese government and some larger companies to assess non-native speakers. It’s divided up into five stages of increasing difficulty, N5 being the easiest and N1 being the hardest.

One of the pros of the JLPT curriculum is that since it is so popular, there are a wealth of materials available for it and lots of people who are in the same boat or ahead of me. That translates to less time spent crafting my studying materials and more time learning.

One of the cons is that in only includes bits and pieces of what would be considered “everyday Japanese”, and thus works better if your goal is to become fluent rather than simply know how to order dinner and talk about the weather.

So I decided to dip my toe in and do the JLPT N5 course. I’d been previously exposed to around 2/3s of the material through my previous courses which made it much easier to digest. Plus, I was only being tested on the English to Kana and English to Kanji, and therefore only had to “recognize” the Kanji and not necessarily read it.

Even with my fair pace of study, it took me about 9 weeks (the majority of my time there) to finish the course of all 675 words. Granted, I took a week or two off between my move from Sapporo to Nagoya, and I spent more time with friends in Nagoya. But still, I couldn’t tell if I was proud of myself or I should have pushed myself twice as hard.

One of the most disappointing parts of the experience was that even after finishing the course, I still was only understanding a word here and there while listening to the conversations of my roommates. I would still clam up and say “I don’t understand” when interacting with shop owners. I realized that drilling vocab was in some ways an avoidance of the speaking, listening, and grammar pillars.

Not all was lost though. I was getting much quicker at hammering out messages in Japanese through LINE. And with the combination of the awesome Midori Japanese dictionary for iOS and sparing use of Google Translate, the feedback loop was getting tighter, I was learning quicker, and my confidence was growing.

Upon returning to Chicago after my three months in Japan, I was at another crossroads. Do I push for fluency, maintain my current abilities by reviewing vocab at intervals, or just let it taper off?

It took a week or two, but I sort of fell into the decision going all out into the JLPT N4 course one lazy Sunday afternoon. This time, however, I elected to learn the Kanji readings as well for the 700 words. I set a goal to finish the remainder of the course (about two-thirds of it) in seven days.

For that week, I was on the Memrise website for about eight hours a day with frequent breaks for decompression. My pace was about 50 words and Kanji readings per day, although some days I did 25 and others I did 100.

The experience tested the limits of my memory and the limits of my frustration. Although I was only learning 50 new words a day, in reality, I was just adding to the pile of linguistic debt, because I would have to review those 50 words the next day, and the 50 words from the day before, etc. A few days in and I would wake up to 400 words to review. Reviewing those words would take the entire afternoon and evening, and it would be 11pm before I’d start learning my new set of words.

I finished the remainder of the course in a little under two weeks instead of one. It was a really fascinating experience pushing myself to the limits of my abilities in a significantly different way than programming does. I learned (and am still learning) a lot of meta things about how I learn best, especially when it comes to rote memorization.

A few lessons I’ve learned. First, starting with mems:

At this point, I still have mixed feelings about mems. Memrise has heavy emphasis on mems in their interface. Mems, or mnumonics, are a memorization technique used as sort of mental scaffolding to connect a new word to something you previously know. The mem assists in the process of learning and forgetting the word until finally, the mem is no longer needed and fades away.

In college, I knew about mems but never used them. I did a lot of writing over and over in a notebook (which doesn’t help at all).

I was still anti-mems until about half way through my Week of Pain. I quickly realized that when I was blazing through learning my new words for the day (exhausted at 11pm), I was putting them in the shortest of short term memory and simply deferring their learning until the next day. The next day’s review was as bad as learning them for the first time.

I found that, during my vocab introduction sessions, when I slowed myself down and spent time crafting a mem for each word, my sessions the next day went about 75% better. It took some extra time recalling my mems before my brain got to the final word, but it made a huge difference having that initial foothold to latch onto. That first review actually felt like a review and not learning for the first time. After this experience, I was (finally) sold on the value of mems.

Present

So I finished my 700 word JLPT N4 course, did some extra review of the words on the automated Memrise schedule, was feeling pretty good about things, then went on vacation for a week and didn’t touch it.

Getting back into it was painful. Sitting down and seeing 900 words to review was bad, but going through that first session and not recognizing more than half the words was heartbreaking and demoralizing.

I found myself at another crossroads. Do I continue on to JLPT N3 (which has about 4x as many words and kanji) or should I get back to full time programming?

I wrestled with it, but ended up taking about four days to power through the vocab review anyway. Once I finished and started looking into JLPT N3 courses, I couldn’t find the exact type and quality I wanted. If was going to dig into another two month process, I definitely wanted to make sure the curriculum is as polished as possible.

Unfortunately, the more I do outside of SRS/Memrise, the more I realize that sort of one-dimensional studying helps very little in the long run. I have a hard time recognizing words in context, and I have a feeling that doing more rapid-fire vocab SRS isn’t the answer.

The other problem is that because I decided to jump straight to vocab and skip learning radicals, kanji meanings, and kanji readings, each vocab word feels very isolated. The effect of learning should be multiplicative instead of additive. I don’t necessarily regret doing all the work I’ve done so far. I’ve learned a lot about learning and about myself through those intensive studying experiences. And having been exposed to these vocab words at least once will undoubtedly help when I see them again.

Over the last few weeks, I’ve tentatively decided to try out a different SRS program to see if I can rectify some of these deficiencies. I had come across Wanikani before, but at the time wasn’t ready to commit to it. After working with Memrise, I have greater appreciation for Wanikani’s benefits. Some of these benefits are: learning radicals first, building to kanji, then building to vocab; starting with easy kanji first and composing them into more complex kanji later (even if the easy kanji represent more complex concepts); learning both the English and Japanese readings; embracing mnemonics (and not having to create my own); getting two full practice sentences with each vocab word; and having a large community going through the exact same curriculum.

That being said, the first couple weeks haven’t been all roses. The pace right now is significantly slower than I got used to with Memrise and there’s no way to go faster by design. This might be a good thing, I’m not sure if my word retention will be better in the long run. I currently have more time to commit to learning Japanese, so I’d like to spend more time if I can (if my brain can handle it).

The other problem is that Wanikani is very strict with input. Just knowing the concept of something isn’t enough. You have to know its exact English phrasing when being tested on kanji -> English. Going from kanji -> English is a new test type for me though, so I may get better at it.

I’m still adjusting to Wanikani’s mnemonics. I usually remember the whole story after 2 hours, bits and pieces of it after 1 day, just enough to get the right answer after 2 days, then by the 3rd day, I’ve forgotten it and can’t remember the readings without them. I have a feeling I’ll get better at internalizing the stories, but it’s going to take more effort on my part.

As a sidebar, that’s the huge paradigm shift with SRS. I’ve always been taught through 16+ years of school that “the more time you put in, the better you’ll do”. SRS actually teaches the opposite, that if you study just a little bit at specific times, you’ll actually remember more than you would if you studied continuously and never allowed yourself to get the edge of forgetting. Sort of the culmination of the “work smart, not hard” mentality. I’m definitely hoping that once I get through a few more levels in Wanikani that I’ll be able to prove to myself that the “burned” kanji/vocab (aka the kanji/vocab that I’ll allegedly remember forever without needing to study it anymore) will actually be burned forever. So in the mean time, I sit here all anxious waiting for my next review time when my natural instinct is to keep hitting the books!

Outside of Wanikani, I’ve been slowly making my way through some classic Japanese childrens’ books. I might punt on those for a while because they’re not as useful as I’d hoped they’d be. They’re mostly written in hirigana and thus are hard to parse. Plus, there are a lot of outdated words and phrases.

I might try to dive into NHK Easy News more, but I’m still missing a lot of the necessary vocab. I’ve read that at around Wanikani level 30 you’re at the point where you know enough that reading basic texts isn’t as painful anymore (or in other words, you know enough vocab that you can get the gist of a sentence and keep your rhythm while reading). Maybe in the mean time it makes more sense to really hunker down on grammar. Maybe not.

I’ve been watching some old Digimon Adventure 02 episodes in Japanese. These are good for listening practice, but still above my current level. I can follow along getting bits and pieces of the dialogue, but eventually my brain gets fatigued and I can no longer keep up with the realtime “have I heard this word before?” game I have to play while checking the subtitles.

My final curriculum addition has been to start reading the non-fiction book Moonwalking With Einstein by Joshua Foer, a book about memorization told through personal anecdotes. I’m hoping to pick up a few tips and tricks, or at least get an interesting read out of it.

Future

I’d like to write more about my successes and failures as my studies progress. Wish me luck.

If you’ve gone through a similar journey or are just starting one, I’d love to chat about it. Feel free to contact me on Twitter @twocentstudios.

Timehop: A Retrospective

Tue, 03 Nov 2015 06:19:53 -0600

I worked at Timehop as an iOS Engineer for almost two and a half years. The experience meant a lot to me both personally and professionally, and I believe it set me on the right course for my future in this industry.

Here are a few thoughts I have about what I learned along the way. Granted, most of them are the kind of lessons you come across every other day in Medium posts from those in the industry, but it feels important to have lived them first hand.

Shipping

There are a million reasons not to ship… but you have to ship anyway.

My most important lesson was learning to scope down to the bare essentials and compromise on bugs. It’s easier to argue for project scope than it is for whether a bug is a “show-stopper”, but it’s important to always have the idea of shipping resting heavily on your shoulders pushing you to make the hard decisions.

Over time I got a lot better at understanding how design and engineering decisions affect scope and shipping schedules. Most of that is gained with experience. When you’re first starting out, coming up with one solution to an engineering problem is cause for celebration. But when you need to get that feature out the door in two weeks instead of two months, that’s when as an engineer, you need to have three potential solutions in your head and understand the cost/benefit for each. Then, you need to communicate those concerns clearly to the rest of the team so that everyone is on the same page with the tradeoffs that have to be made.

“I can get a prototype out to our beta group in three days, but if it’s successful, I’ll need to more or less start over with an alternate implementation to make it scale to the rest of our user base. Is that acceptable?”

A simple example of this that came up time and again was receiving designs for custom views and components that worked just slightly differently than the standard iOS components. I would have to evaluate each component, create a time estimate, then report back to the product manager and tell them, “hey, this navigation paradigm is slick, but it will stick out like a sore thumb from the rest of our app and I can ship two days faster by using a built-in component. Are you sure you want to do it this way?” Some of the time, the answer would be, “No, it doesn’t affect the core user experience enough to warrant the delay.” The remainder of the time, it would be, “It’s worth it. Our hunch is that the navigation will significantly affect uptake of the feature.”

Of course, that hunch is a gamble. Which leads me to instincts.

Product Instincts

Your product instincts will get better with time. What I mean by instincts is your ability to predict the behavior of a diverse and statistically significant amount of people in response to your product or feature (note: your group of close friends is probably not diverse or statistically significant enough). How will they use it? How long will they use it for? Will they use it like you predict they will? Will they even use it at all?

Your product instincts will get better with time… but only if you set up your experiments correctly and are brutally honest with yourself.

It’s natural to think of product instinct as something “you have or you don’t”. Psychology and sociology are sciences though, and I believe that applying the scientific method to product can lead to better outcomes for users and for those learning from the results.

It is absolutely more difficult to design a product experience in a way that is based in a few key hypotheses, facilitates the collection of analytics data, and uses that data to ultimately prove or disprove the original hypotheses. Without this process product development is simply taking disparate stabs in the dark and crossing your fingers that you’ll hit some abstract goal. Not only is it impossible to iterate effectively, it also denies the chance to learn from the outcome of an experiment and improve the instincts of the entire team.

“I predicted that users would tap the ‘Follow All’ button 60% of the time, but after one week of data collection it’s only at 15%. I can now begin to ask the next questions such as ‘do users understand the value of following others?’ or ‘do users just not see the button?’.”

Forcing yourself and the rest of the product team to make hypotheses isn’t about seeing who was right and wrong at the end of the experiment. It’s not a competition. It’s about forcing yourself to take all of your collective experience into account (and hopefully your direct experience from previous experiments) and draw a line in the sand. It’s all too easy to forget your original hunches when the analytics numbers start rolling in, and by then you’ve missed a great opportunity to adjust your internal biases.

More often than not, goals of your product experiments will fail and that’s okay. You’ve learned something. The worst thing you can do is to sweep your failures under the rug. By ignoring failures, you’ll be skipping the most important part of the iteration process: the part where you don’t repeat your mistakes. When you don’t learn from your experiments, each product cycle will be like starting from scratch, never progressing.

Making Mistakes

Ultimately, someone has decide where to start and what path to take from there. As much as a meme the “idea person” has become, leading a product takes legitimate effort. Sustaining the product development cadence can be brutal and unforgiving (especially if you look at it as taking alternating stabs in the dark, which you shouldn’t). Always having the right idea ready to go at the right time is something I respect greatly.

When I started at Timehop, my primary goal was to improve my craft of iOS development. Having a new feature spec’d out, designed up, and ready to implement is great for that. There were never a shortage of ideas, and thus there was always interesting development work to do. I’ve touched what feels like a dozen disparate iOS frameworks over my tenure, gaining a breadth of knowledge because I was pushed to implement features that on my own I would have judged to be too time consuming or too far out of my comfort zone.

On the flip side though, I only got a few chances to put my own ideas to the test. For those few chances, I am undoubtedly grateful. However, the rush of nurturing an idea from start to finish is an intoxicating feeling, one that I started to miss dearly as the day to day became implementing feature after feature. It was ultimately the desire to make my own mistakes that nudged me out the door.

No one has all the answers. No one really knows what they’re doing.

I participated in dozens and dozens of product experiments. Features that were pitched as sure wins often failed the hardest. Features that were incremental improvements or minor changes in response to something as innocuous as required Apple API deprecations sometimes produced our largest user influxes. At some point you have to come to terms with knowing that no one has all the answers and you have to brace yourself for a bumpy ride.

The People

My favorite part about coming into work every day was working with such an amazing team of people. Team Timehop was both fun and talented, and inspired me to do some of my best work.

It was an honor to be part of something that brings joy to the lives of millions of people.

TDD, RSpec & Conway's Game of Life

Mon, 08 Oct 2012 21:22:00 -0500

On my continuing quest to do more micro-projects, I decided to begin focusing on TDD today. After doing a little RSpec Googling, I came across this live coding video for doing TDD with RSpec on Conway’s Game of Life, something I hadn’t heard of before.

After watching about half the video, I realized I was far enough along that I could try it myself. So I took a stab at it doing TDD the whole way. It was actually pretty fun doing a simple OO Ruby project and getting my feet wet with RSpec. I’ve always had this ugly feeling of repeating myself with tests, which is one reason I never could bring myself to write tests upfront for my little Rails projects.

It turns out (as everyone knows) that testing actually saves the repetition that comes with hand-testing everything in irb. If I had a nickel for every time I sat there banging away at the keyboard constructing objects and relationships in the Rails console just to do a reload and wipe everything out, I’d be rich (and a cliche).

In any case, it was apparent very quickly that I was really saving myself a lot of headaches by writing tests. The feedback loop was much quicker writing tests first. Fixing bugs and not having to re-establish all of your test setup by hand each time makes it much easier to focus on the bug at hand. And this was just for a three-class micro-project. I can only imagine how much headaches testing saves in large scale Rails projects.

RSpec was actually a lot more intuitive than I expected. It helped that I found an old cheat sheet to kind of guide my thinking of how my should statements should be structured. I tried to keep all the best practices in mind while writing my tests, but I’m sure I missed quite a bit on my first run. Looking back, I probably should have had a few more edge case tests especially on the 4 big rules. I’m still getting used to describe, context, let, before, and all the other structural stuff. It doesn’t help that, from what I’ve seen, there seems to be a personal style to writing tests that varies. It varies in both test structure and amount of testing.

I also forced myself to get a primer on Ruby Debug (using the debugger gem). It’s a little different than I’m used to with the full IDE and the goodies that Xcode offers, but I’m sure it’ll be another useful tool in the toolbox.

I wrote a Cell class and a World class in what I think was good OO. Then I wrote a Display class that handles printing the world to the terminal (and even a little animation). I didn’t write tests for that though, it was kind of a just-for-kicks deal.

Sidebar: this actually reminds me a lot of the big project we did in my C++ class Sophomore year of high school. We spent what seemed like several months writing all these classes to simulate fish. I can’t remember exactly what the rules were, but I remember it being a bit tough to wrap my mind around. I don’t think I really understood the difference between UI code and game logic back then. I didn’t get that STDOUT was all we really needed for the concepts we were learning. I kept wanting to understand the GUI classes when all that was in the curriculum were the comp sci basics.

I’m not sure if my code is worth posting to github. I’ll keep it off for now and try to leave room for the more important/interesting projects I’ve got planned.

"I Wonder If I Could Make Something Like That"

Sun, 20 May 2012 16:29:00 -0500

For as long as I can remember, I’ve been a jack-of-all-trades sort of person.

Whenever I see someone create something that I enjoy or respect, my immediate response is “I wonder if I could make something like that too”. It’s led to me acquiring all sorts of weird skills and hobbies. Here are some somewhat self-indulgent auto-biographical examples to get things rolling.

Calculator Programming

Since this is a programming blog, I’ll start with an example about my first experiences with writing code. I’ve been playing around with computers for as long as my family had one (Dell, Intel Pentium, Windows 3.1). But it was freshmen year of high school that the graphing calculator fad took off and I really fell for programming.

One of the best ways to waste time in math class was playing calculator games. I’m still surprised how quickly these games spread from TI-83 to TI-83 (I wonder if kids do it the same way today?). There were the classic snake-type games, and then there were the formula pack apps where you could plug in variables and get your answer without having to punch out the whole equation.

Getting my first taste of these, I immediately thought “I wonder if I could make something like this too?”. I was in my first real programming class that year (Visual Basic 6), so I was getting a taste of common programming syntax and elements, but learning the specific TI-83 APIs was trial and error. Over the next year or two, I made my fair share of little apps and games. Even to the point where I made an entire playable board game app for my Homer’s Odyssey English class project.

Music

This behavior had already started for me back in middle school, where I started getting into popular rock music. Before long, I had started/joined my first band and started writing songs as soon I learned my first two guitar chords.

Then we needed recordings, so I listened to my favorite records and said “how can I make recordings that sound like this?”. I started buying gear and cobbling together our first records. I’ve recorded in the order of 30 to 40 records for my bands and others’ bands since then.

By college, my musical tastes had expanded. I started a second band with one of my friends who sided more towards classic punk/acoustic music. I listed to the records he and I shared a taste for and thought “I bet I could make music like this.” And so we did. Five records with that band in eight years. Everyone has to have a solo project, and so I started one of those too. At one point I was writing and recording one record for each of my three bands per year.

More Programming

I learned VB6 and C++ in high school mostly by curriculum. In college I learned C and a couple different flavors of assembly, mostly by curriculum too. It wasn’t until the summer after my graduation that I looked at smartphone apps and said “I wonder if I could write something like that?”. I dove in and learned Objective-C and Cocoa Touch from scratch. That was the only thing I did for an entire two months until I got my first job. Once I got my job, however, it was back to the part-time shelf with all the music stuff.

Looking at the App Store and coming up with new ideas for apps over the next year, I realized all my best ideas needed a back-end. So I put my iOS coding on hold while I started learning Ruby and Rails. That of course spawned the need for JavaScript, HTML, CSS, and all the other related technologies.

Photos & Video

During college, A friend of mine was delving into photography and always posting his DSLR photos of our group of friends to Facebook and blowing all of us away. I asked myself “could I learn how to take photos like that?”. I borrowed his old camera when I went to Japan for two months, and returned with a new back-burner hobby.

It wasn’t until a few years later that I got my own camera and started shooting regularly again. My camera has video, so it wasn’t long before I had focused most of my energies to shooting video at gatherings and editing together clips with my own music arrangements to show everyone a few days later, an idea I appropriated from the same friend that loaned me his camera.

Master of None

At a certain point, I realized that having this many semi-active interests means that I will never be at the top 1% of any of them. I’m still of the persuasion that no one can escape the 10,000 hours rule.

This wouldn’t be a problem if I was still a high school or college kid, but as an adult I realize that some pursuits have more of a payback than others. In the past, the only priorities I assigned to all these activities was based on my own random day-to-day decisions and the promises I’d made to those I worked on these projects with.

And because most of these pursuits require multi-month projects, I am constantly backlogged with a dozen simultaneous commitments. Every time I finish one, two are already there to replace it.

With my realization that programming is going to be my breadwinning function for the indefinite future, should my programming pursuits be my default number one priority? Should music and photography and the others be placed further back in the list than they already are if I am to keep up with the programming industry and stay employable?

Or is this a trait that a lot of successful people have? I know that my various pursuits always end up giving me some lightbulb-over-head insight into other seemingly unrelated pursuits.

I don’t think I’ll ever be able to completely during off my wandering ambition towards acquiring new skills. I know it’s part of who I am. The question that’s on the table is if I should artificially adjust my priorities. I’m sure if I were 40 instead of 25, I’d be able to answer these questions succinctly and insightfully, and it would help a lot of young people like myself.

Going Forward

From here, I’m guessing I’ll just have to keep a better handle on my current projects and commitments. Opportunities for new projects should be evaluated more carefully for time and enjoyment, because at the end of the day, a lot of these pursuits are things I should be doing because I really really want to do them.

That’s how I’ll have to reason things next time the thought pops into my head: “I wonder if I could make something like that?”.

Hosting

Sat, 30 Jul 2011 00:00:00 -0500

My rent on my shared garbage VPS is up in early August and I’m not sure what to do. I’ve got two problems and a number of routes I could go.

I know very little about server admining and hosting. Next to nothing I’d say. I would like to learn, but like anything, there’s an opportunity cost to it. I’m leaning towards not taking the easy way out this time, simply because I know some more advanced knowledge of Linux will most likely be useful sometime in my not-so-distant future.

My first problem to solve is what platform is best for this blog. I started on Wordpress because it’s ridiculously easy to leave all the technical stuff aside and just get to writing. Unfortunately, I don’t know any PHP and don’t much care to learn it, so hacking on it is out of the question for now. And if I’m not going to try to deal with PHP, I might as well put my eggs in one basket and try to hack on a Rails blog framework. So I guess my real problem is how to migrate the few posts on here over to a Rails platform (after setting it up of course).

Seeing as I’ve decided not to continue on with Wordpress and switch to Rails, the next item on the agenda is where to host it.

Stay on my current garbage VPS for another year. This is what I'd call the easy way out. I could leave the WP version of this blog and the rest of my site up and give myself some time to migrate over. While supposedly my VPS does support Rails, I don't get command line access without paying some ridiculous fee, and I have no idea what its capabilities are.
Set up something on Heroku. I was exploring Heroku a little bit over last weekend, and things there are looking rather nice. However, I think it may end up being too complicated for the low-key hodge-podge of things I'd be running on it. At some point in the future I'd like to deploy some stuff there just to check it out in greater detail.
Set up a VPS on Linode. I feel like I would easily learn the most on this route. I'd get a chance to really dig into a Linux distro and learn how to set everything up manually. I know there are a ton of great tutorials out there for doing pretty much anything on a fresh install. The only downside is that I'm sure it would pretty much every waking moment of my freetime to get everything I need up and running to the capability I'm at right now. I'm just not sure I have that kind of time to devote to this right now.

With all that being said, I looks like maybe my best option is to go with #1 (as much as I feel like I’m wussing out), and shoot for #3 next year. That will give me some more time to get a better hold on Rails.

If anyone else has been in this boat before, I’d love to hear about it in the comments.

State of the Three20 Union

Sun, 10 Jul 2011 00:00:00 -0500

I’ve been sitting on this topic for a little while now, and feel like I should finally weigh in on where the Three20 framework is at this point.

Where I Started

I started working with Three20 a little over a year ago. In that time, a lot of really talented people have improved the library to the point where it is today. They have done great work that all of us have benefitted from greatly. Recently, I got comfortable enough with the library to start filling in holes in the documentation using this blog.

But I think everyone in the community has started to feel the weight of Three20. I think the three main reasons for this are documentation, architecture, and community. All of which seem to be making each other worse as time goes on.

Documentation

Three20 has gotten continuous flak on Twitter, blogs, and anywhere else iOS devs talk for the lack of documentation. There’s really no argument against that. Everyone acknowledges it.

A lot of people have gone out of their way to help with tutorials and blog posts that usually get a sliver of functionality across. But a lot of them are intermediate or advanced and assume you know about dependencies and other Three20 magic. And there’s no nice neat repository for all of them. And a lot of them are out of date.

The startup docs written by Jeff are great for just that: getting started. This gives beginners a taste of what Three20 can do for them and completely leaves them out to dry once they try their first customization. So they look at the documentation and find nothing. Then they look at the source and find nothing. Then they search blogs and find a bunch of old stuff. Then they get pissed off after a number of hours or days and give up and post angry comments to Twitter.

With the mass of source that Three20 has, I can’t blame them. It’s tough to know where to start, especially if you want to use a large portion of the library. And this is definitely not something that can be explained in a short bit of source documentation. It’s much better suited to an Apple “programming guide” type document. This just doesn’t exist because I truly believe there aren’t that many people that know the library inside and out. And those that do exist are busy fixing the plethora of issues and pull requests.

Architecture

The modularity that Jeff introduced sometime last year was heavily called for and a step in the right direction in theory. But I think the problem is that Three20 was originally written as a cohesive app, and you basically had to add all seven or so components anyway in order to get the thing to build (I always included the full library because I usually use all of it, so don’t quote me on that).

There used to be a chart that had “The Three20 Ecosystem” showing how all the table stuff worked together. I still believe the concept behind the Three20 table structures has plenty of merit over Apple’s. But you can definitely tell that the architecture is such that it works for the Facebook app, but not much else without a lot of rewriting, which almost defeats the purpose of having reusable library components.

Three20 has a lot of independent goodies and additions that don’t have much to do with the architecture. But most of the components require you to do things The Three20 Way. And if you’re going to use Three20 the way it was intended, you should probably be writing an app that has similar layout.

Three20 is best for making apps for web services that have assets in databases. I’m not sure how else to describe this, but maybe API-centered app is the best description. Think of Facebook then set your bounds somewhere outside of that. Most all your data used in the app should come from the cloud. The webservice should have a well-documented API. It should be heavily URL based.

This is because Three20’s URL system does not do well with passing around data. Sure, it can do it. But it’s not designed for it. You’ll be fighting the whole way, especially with tablecells. Each view controller should have a corresponding URL on your webservice for best compatibility.

This post isn’t about when you should use Three20 so I’ll cut that example short. Needless to say, those new to Three20 don’t know if they should or shouldn’t be using it because there’s no documentation because there are so few people that understand the library and we’re back to the chicken and egg problem.

Community

I have to be frank with this one. There are plenty of great people in the Three20 community so I don’t want to give the wrong impression that I know all the players and I can pass judgement freely. But from what I see, there’s an increasing number of weight that is being added to the community due to many of the problems mentioned above.

Let me start with a fictional iOS developer. He’s been developing using standard libraries for a year or so and has the basics of Objective-C, Foundation, and UIKit down. He hears something about a library from the Facebook developers, checks out the github page, sees some examples, and says, “Wow, this is awesome. This will save me a ton of time writing my own networking classes and photo rendering classes and all that other stuff that I need right now but don’t have time to dig into the Apple frameworks to perfect.” In one word, they get greedy.

This is perfectly normal. Perfectly acceptable too. This is exactly what I thought when I first saw the framework. After all, the whole point of a framework is having a black box to use where you need it without having to have thousands of developers write the same code. Spending more time on your app-specific business logic and app aesthetic is the siren song of most developers.

But whereas some developers give up and curse Three20 after not finding any documentation, there are also two other groups.

Group 1 digs even harder for documentation. They find and read every blog post, step through the source of every provided example, and even read the source until they understand it. Obviously this takes a long time, and thus the group is small.

Group 2 immediately pounds Stack Overflow and the Three20 forum with questions. They don’t hesitate to file issues on github for anything and everything they don’t understand and assume is a bug. A lot of the time, they really didn’t understand the standard UIKit way in the first place, and are more or less spinning their tires and flinging mud in everyone else’s faces.

Group 2 exists in every community, but they usually are indistinguishable because plenty of books and guides exist for all three groups to use. The main contributors are there to answer the really tough questions, but they mainly get to work on fixing mission-critical bugs and writing new features/components. So again, we come back to a lack of documentation making a different problem worse.

Where To Go From Here

Again, I am not trying to demean any of the hard work all the Three20 contributors have done, especially Joe’s original idea and Jeff’s great curation. My main question is this… is the Three20 framework salvageable?

From where I sit right now, I don’t believe it is.

I think those moderately familiar with the library understand that there are a lot of inherent flaws baked into the framework. Hindsight has made those flaws easily visible, but still not extractable from the framework. It’s a cliche to say that programmers love to rewrite their projects, but in this case I’d like to think we’re rewriting this time from higher ground.

I know I’m not the only one that feels this way. Jeff’s new Nimbus project seems to be the answer to many the above complaints. Documentation is the number one priority of the project, and so far Jeff is doing great out of the gate. Many of the best parts of Three20 will be ported over, but foreseeably with all the changes that have come from Jeff’s hindsight of the project.

What do I mean by not salvageable? I think that more time should be spent rewriting Three20 as Nimbus than should be spent fixing the multitude of Three20 bugs that exist. That being said, I should probably put my money where my mouth is and help with some of that workload.

I hate to see Three20 collapse under its own weight seeing as how much great work has been put into it. The rapid iteration of the iOS frameworks requires even more rapid iteration of community-driven frameworks to keep up. I think the best way for Three20 to keep up is to gradually migrate to its new form. This will also give us a chance to reevaluate the need for some of the Three20 functionality that was written to cover up holes in previous iOS versions that have since been filled by Apple. It will also give a chance to incorporate other open source projects that have become well known and stable since Three20 was originally started.

This post was not meant to be an attack on the community, and I’m definitely not trying to be a Negative Nancy. I’d simply like to document my opinion on the source and exacerbation of Three20’s problems so that hopefully the same mistakes can be avoided in the future.

When Learning a New Language, One Book is Never Enough

Wed, 18 May 2011 00:00:00 -0500

How do you go about learning a new programming language or tool?

My steps to learning a new language are traditionally as follows:

Stare blankly at source code of new language until my eyes and brain hurt.
Acquire a book and fight my way through it, reading from cover to cover.
Use said book and Google to code up whatever idea had originally inspired me to learn the language.
Find more well-written (I hope?) source code and this time actually understand about half of it.
Acquire a second book and read through it slightly faster than the first, seeing things I read in the first explained in a slightly different way.
Work on a more complicated idea, using all previous knowledge acquired.
Start using only Google, Github, and targeted blog posts to gain more knowledge.

As a kid (high school, college), I realize I relied way too much on one source of information when learning a new language. Of course, the internet wasn’t the same as it is now, but the bookshelves were definitely filled with plenty of “Beginning Zombiescript++” books. Heck, I remember pulling random books off the shelves and leafing through them just to try to figure out why I would want to use whatever language they were teaching. Most of time I couldn’t figure it out.

I’ve seen it a million times through my schooling years; I just don’t really get things the first time through. A lot of the time that was because I didn’t really understand why I needed to know what I was being taught in the first place (which is an entire topic of its own). But even if I saw the entire birds-eye view of a subject, it would still take seeing it from a different angle to really get me to connect the dots.

(Aside: I know of the popular technique of immediately trying to teach what you’ve just learned. At the initial stages of learning, I find this pointless. Mostly because it only really makes sense for memorization type exercises, and if you’re trying to teach something serious, you’re not really teaching, you’re pandering to be corrected. I only feel comfortable publicly teaching after I know I have enough knowledge to put together that general birds-eye view curriculum and have proven successes.)

One particular event in college when things really lined up for me was learning assembly in two different courses at the same time. I was learning x86 assembly in my systems programming class, while at the same time learning TI DSP assembly in my digital signal processing lab. Before starting these, it wasn’t obvious to me that assembly wasn’t like C++ or other high level languages that you wrote once and someone else wrote the compiler for each system type to make it run. Seeing how the instruction sets were tailored to the main function of each processor (processing digital signals, running complex operating systems, etc.) opened my eyes to the underlying logic of how these systems were designed in a way it wouldn’t have understood if I were just taking one of the classes.

When you’re learning something new, get as many perspectives as you can on whatever you’re learning early on. Not only will it help you better understand the subject itself, but it will also prevent you from getting a “brainwashed” view of your subject. If one author thinks the best way to teach iOS programming is to start with learning everything there is to know about views, you might be a little disappointed when you realize you didn’t have to worry about them at all to write your first UITableView driven app. Likewise, if the author you’re reading thinks it’s fine and dandy to never touch the CoreGraphics framework, having another perspective might change your mind if you’re building a very customized UI.

The other thing to hunt out furiously when you’re first starting out is the big picture. Knowing what you don’t know, knowing what you need to know now, and knowing what you can do with libraries and frameworks is the main focus here. I was painfully unaware of how to find good opensource libraries when I started out iOS programming, and in turn wrote a ton of basic low-level stuff from scratch. A lot of it was wrong, and a lot of it worked anyway even though it was so hacked together it was indecipherable the next day. I did learn a lot from this, but only by seeing it done correctly later (usually much later). And also by getting a few apps under my belt and revisiting it to assess the damage. There are some cases where it’s a good idea to roll your own, but it’s almost always a better idea to use it as a guided exercise so you can immediately learn from your mistakes.

The last tip I have is to push yourself in your research often. This usually means reading blogs and opensource projects containing advanced topics and problems about your chosen subject. You will almost certainly run into terms, algorithms, techniques, and ideas you will need to know in the future. Bookmark anything that jumps out at you, and maybe try to gather enough understanding to write a one paragraph summary of it (for your own personal future reference). It’s good to get that first meeting out of the way so you’re ready to start building recognition the next time you see them.