Startup development teams need to optimize for speed. Code needs to ship quickly to validate ideas, and it needs to turn on a dime as feedback comes in. Perfect code that solves the wrong problem or ships too late is of no use to the company.
But speed needs to be balanced with quality, and one of the most effective tools for ensuring quality (as well as sharing knowledge and coordinating) is code review.
Web frameworks are sneaky. They lure you in with their promises of just overriding one method, and (voila!) you have a web or API server.
But then time passes.
Suddenly you want to change something that the framework doesn’t make extensible. Or you spend hours debugging something deep in the bowels of the framework you’re using. Suddenly your framework is your enemy.
In fact, I’d argue the eventual frustrations from using a given web framework are directly proportional to the amount of magic it wows you with up front.
Reusing code of any kind involves a tradeoff between having control…
Everybody is trying to get you to download their app.
It’s clear why they want to.
The story is more complicated if you’re a user. Sure, the app itself is a better experience, but
It’s time we had a conversation about Apple’s app review process.
Apple reviews apps to “ensure they are reliable, perform as expected, and are free of offensive material.” But in practice the process is both slow and arbitrary. Reviews regularly take over 7 days and sometimes take weeks. It can take even longer if there’s any back and forth over the rules, a common outcome given the ambiguity and wide scope of the rules. Apps that seem totally reasonable are summarily rejected. The slow speed and poor quality of app review is hurting users.
The speed of review matters for…