{"id":30489,"date":"2020-10-19T16:45:56","date_gmt":"2020-10-19T20:45:56","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30489"},"modified":"2020-10-19T16:45:56","modified_gmt":"2020-10-19T20:45:56","slug":"pure-programming","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/10\/19\/pure-programming\/","title":{"rendered":"Pure Programming"},"content":{"rendered":"

gazzini<\/a> (via ChrisLTD<\/a>):<\/p>\n

\n

I used to joke, back then, that I was a professional App Store rules explainer, because in every role, I was constantly explaining to peers, managers, and clients why we couldn’t build X because it violated Apple’s terms & conditions. I just wanted to build what our users wanted, but instead we debated endlessly about what Apple might allow. Even then, we’d still occasionally be punished by a frivolous rejection, moving us to the back of the app-review line.<\/p>\n

But Apple isn’t the villain here – this is a large industry trend. The entire internet is increasingly burdened by various governments, corporations, and everything in-between.<\/p>\n

[…]<\/p>\n

In-app purchases. Email verification w\/ various “unsubscribe” options. Sign-in with X. DUNS numbers. Applying for AWS Service Limit increases to send any emails. These “table-stakes” features are a real drag on productivity because… well, because they’re no fun to develop! It’s energizing to solve real problems, and draining to solve fake problems.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n