Okay so, definitely not applying to work for Slack anytime soon. This is not the kind of attitude I would want to support.
665 karma · joined October 8, 2012
Okay so, definitely not applying to work for Slack anytime soon. This is not the kind of attitude I would want to support.
Really? For mobile applications, users are very wary of them. Granted, they can't do anything until they either accept or deny location (or whatever other thing the app is asking for) data.
It'd take getting used to but, I think it'd be something users would appreciate long term.
How is that losing their way? They're targeting a way more profitable and way larger market.
- Remote work is hard. It's tough to get right. However, remote work is worth it. It's worth putting in the extra effort to try and get it right for your work place and your job. You get to spend more time with your kids, your SO, and you can travel.
- Face time is still important. Remote work makes face time a pleasant treat that you look forward to.
- Remote work makes financial sense.
- Good remote workers have to be excellent communicators.
It's not for everyone, but it's important that most organizations at least try and make it a reality for those that want it. Everyone will be the better for it.
Instagram is incredibly polished. Notice how fast it is? As you're selecting an image, they're already uploading it to their servers. That is critical to maintaining and growing their user base. I go to Instagram knowing I can upload a nice looking photo quickly. The images load incredibly fast as well. Its simplicity is deceptively robust.
This is not recreated by a developer billing at $50.00 an hour.
So, if you're looking to have an app built, and you're reading this post, just know it's pretty inaccurate. You get what you pay for.
Lead iOS engineer with 4 years experience on multiple large brands, 20+ apps in the app store, experience leading large teams and working remotely. Availability is limited but I could contribute 10-15 hours per week.
Contact: alex/at/a-dlabs.com
All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK.
That's my only fear though really. Rarely do I personally do a lot of subclassing unless I absolutely have to or it really does make sense to.