|Dilbert comic by Scott Adams
There’s an inherent and subtle level of creativity with coding as well as layers of analytics involved. With the Internet of Things
and the explosion of Big Data and mobile, I wouldn’t be surprised if some level of programming is introduced as part of core classes in high school and colleges soon.
So I don’t get carried away with paragraph after paragraph of… stuff, I’m going to share a quick list of what I’ve learned from getting started on iOS and building out Dee Duper. As always, I’m being specific about my experience, but any of these take-aways can be ported to any other programming – macros in Excel, SQL for databases, Ruby on Rails for web apps, etc.
Hopefully, these will help you stop waiting and empowering yourself to learn and put yourself ahead of the curve.
Keep programming day in, day out to keep your skills sharp.
The hardest part of programming isn’t getting started. In fact, getting started is the second hardest. The award for Hardest goes to… programming consistently
. Like I said before, I had programmed in the past, but programming, like most skills, is perishable knowledge. It’s important to keep the skills fresh with continued practice.
Be prepared to delete and adapt when adopting new technology.
I decided to plunge into Apple’s new language Swift
vs. Objective-C because Swift will be the programming language Apple preaches going forward, and I liked its clean syntax. However, when I started, Swift wasn’t officially released… having spent many months/ years in development, I had to do a lot of code refactoring when Swift was actually
released at Apple’s event in September (2014). I had a bunch of code that needed to be updated because functions and classes were already obsolete/ deprecated.
Note: Refactoring is the process of “cleaning up” code via restructuring code, implementing more efficient syntax, etc. while keeping the behavior the same. The benefits happen behind the scenes beyond efficiency.
Big features may represent 90% of the tech, but the remaining 10% will take up 90% of your effort.
I actually got a TON done of the Dee Duper app in the first week surprisingly. However, it was all the fine-tuning and dealing with Constraints that had me incredibly frustrated and head buried in my hands at the desk.
This wasn’t so much of a big deal before when Apple had really just one size (iPhone 5s and earlier all had the same width), but once screen sizes change, you need to set limits and constraints right so your app doesn’t look ridiculous on the various screen width sizes. Then, you’ve gotta handle the exceptions of “well, what happens if a user selects this first before that?”
Rules are easy to plan for… exceptions are what crashes your app and aren’t explicitly planned for.
Note: Constraints are what dictate the size of images, labels, etc. to fit different sizes of screens.
Dealing with Apple’s Developer processes will infuriate everyone – account for this time if you want to launch by XYZ date.
Apple’s products are [usually] pretty great quality because the ecosystem is so tightly regulated. I never appreciated this so much till I started developing. I had to buy a MacBook to even program iOS in the first place. Then, there’s a ton of headache involved with just being ALLOWED to program. There are things like certification, provisioning profiles, etc. that you have to constantly share keys and authorize devices to even test, authorize people to be able to test your app, etc. It’s mind-numbing.
If someone makes this process easier (a few clicks maybe?!), he/ she can make a ton of money. The frustrations through these processes are MANY for newbies like me and even experienced pros, I’ve found.
If you want to launch on a particular day, you need to be wary of how long it may take for Apple to approve the app (or if it gets restricted).
Don’t forget that if you leverage other tech, you may also need to get approval from them, too, like Facebook.
When you’re down in the dumps of coding disarray, Google is your best friend.
I probably run a hundred searches a day for problems I have or for ways to build Dee Duper out better – probably because I’m that green. Some of the features I was trying to build have been attempted/ successfully implemented by other developers. So, there’s a high likelihood there are other developers who have had similar problems and solutions. Being able to Google these situations is great, but you have to get the search terms right or you get flooded with irrelevant content. Google will likely steer you to personal blogs and Stack Overflow
posts to help. The development community is alive and strong. Though with new tech like Swift, the community is much, much smaller, and can be a bit more difficult to find help with.
Integrations to platforms can be stupidly easy.
Credit goes to the great startups today who have developed such great platforms that can be easily tapped into.
For Dee Duper, I leverage Facebook
’s API (application programming interface) so users can sign up and log in easily. With it, too, I can show mutual connections/ friends. Facebook’s documentation is decent, and can really help get you started.
I also use Parse
(acquired by Facebook in 2013) as my back-end – stores the data model, content, etc. so I don’t have to build one from scratch. It’s so simple to get started and running. Creating tables and running queries is a cinch. I also use Parse to send Push notifications. This is useful when Dee Duper users send messages to one another critical for buyer-seller interactions. Push notifications are great, too, for Saved Searches (like if you’re looking for a particular items with key search terms, you can save the search, and be alerted whenever someone posts a listing that matches your search).
These large platform integrations just makes building apps that much easier and faster.
It’s so easy to keep building, and going overboard, but you need to stay simple.
Plugging in my earbuds and sliding my hoodie over my head, it’s easy to just get cranking and keep going.
“Oh, that can be a cool feature to implement… hmm, I’ll do that!” And the next thing you know it, you’ve blown past your MVP
(minimum viable product).
It’s easy to just keep going, and thus, spinning your wheels and delaying your launch. As much customer discovery as I’ve done, I need to get the product in people’s hands to test hypotheses like features, layouts, etc. If I keep building, I’ll never get this good insight.
I have a couple lists in my notebook and on my whiteboard at home with clear objectives of what the MVP is… everything else can come later after some testing and learning.
Building is easier than selling (in my view).
I like to sell. I like to work with people face-to-face to find how I can help them through my product/ service. However, building things like an app is way easier, I think. You can do it from anywhere pretty much and at any time. Except for some quirks, the computer and code is pretty unbiased towards you with not so many personality “differences”. Thus, it’s easy to get validation when things work or why things don’t work.
In sales or working with people, there’s so much more you’re not necessarily privy to because there’s a person on the other side with a mindset, an attitude, a life, etc. However, I still like the people interaction, so would rather hand over the technical reins when the timing is right.
It’s really easy to take your time or delay.
Dee Duper was approved for the Apple App Store
on Monday, December 1, 2014. (First try – sweet!) However, it took me a while to publish it officially because I was scared about how it’d be perceived by others.
Fast forward to February 2015, and since its launch, I really haven’t marketed it at all. I think I was excited about Dee Duper as an idea and as a project to learn coding with. However, since then, I’ve developed a couple other apps. As a solo-preneur, I dictate what gets my attention and what doesn’t. My schedule is completely of my own choosing, and sadly, that could mean I focus on building so many different things without the focus of only one thing even after launching it recently.
I need to do some marketing, though, so that I can get feedback on the apps that I’ve built. At least this way, I can really work in the Lean Startup
mindset of iterating and collecting feedback.
|Another Dilbert comic by Scott Adams… because they’re great.