Software Dev

“What you can see here is that I was learning…”

I love this post from swiftjectivec.com.

๐Ÿ‘‰ Things I Made That Sucked

Not only does he detail the interesting stories of some old apps he made, but also the valuable lessons learned from each app that he shipped.

Highlights

Aim first, then shoot. “Ask yourself why youโ€™re doing what youโ€™re doing and channel your excitement into less action and more thinking before you fire away.”

Pace yourself and don’t complicate. “Take time to learn about design and holy moses donโ€™t toss in an open source project just because itโ€™s shiny.”

There is no overnight success. “Always remember that character is carved out rather than instantly created. Each of these misses can eventually add up to a win.”

My own lessons

Applying the same thought process to my own old sucky apps, here is what I come up with…

Where in the World is Santa Claus?

Ignorance is bliss. I genuinely thought it would be easy to make an augmented reality Santa tracker as my very first iPhone app. Who cared that built-in AR support on the iPhone was years in the future?

I understood that I’d have to learn Objective-C and Xcode as I went. However, I did not appreciate how much there was to learn about location APIs, motion APIs, audio APIs, audio editing, 2D animations, CoreData, the State Pattern, linear algebra ๐Ÿคฏ, the terrors (at the time) of shipping in the App Store, plus legal/privacy matters. Also why not translate the app into six languages, starting with Spanish?

And all just to see Santa blink on your screen when you pointed your iPhone north. ๐Ÿ˜†

My blissful ignorance allowed me to jump in fearlessly and forced me to conquer a mountain of challenges as I went (or quit).

This app only ever sold a few hundred copies but was a goldmine of experience and made me a mobile developer.

Bedtime Balloons

Simpler is better. App #2 was more useful and less technically challenging than the AR Santa app. Bedtime Balloons let me get into some fun art and more interesting animations. Plus this app actually made a difference in at least a few people’s lives.

Third-party frameworks can kill your app. At the time, there was no standard 2D animation engine for iOS. SpriteKit was not a thing yet. ๐Ÿคท๐Ÿปโ€โ™‚๏ธ So just like the Santa app, I built the animations around the very nice Cocos2d engine, which would eventually morph and evolve and… break my app. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ Yeah, I could have rewritten my app, but again only selling a few hundred copies, I chose to avoid all the sweat and tears and just move on.

Continuous Math Cards

Be practical. I never expected to sell many copies of my barebones but highly configurable math flashcards app for kids.

Written quickly in the new (at the time) Swift language, the app was alright. ๐Ÿคท๐Ÿปโ€โ™‚๏ธ But it worked for me professionally. My next step would be a full-time day job as an app developer, which had long been my dream.

Software Dev

Mobile Native Foundation: Developing Large-Scale Apps

Writing apps for a large organization has its own unique challenges.

Large teams require that you collaborate in complex ways while keeping quality and delivery speed high. It’s not straightforward, and it makes the days of knocking out an app on your own look fun and easy, if somewhat solitary.

@MobileNativeFoundation

It’s not just about “data structures and algorithms” or any of that Computer Science 101 stuff at this level.

The Mobile Native Foundation is a new organization that focuses on large-scale app development issues for iOS and Android.

It’s mostly just discussion groups right now, but they have contributions from people at large companies with apps you know and respect such as Lyft and Spotify.

The discussions cover relevant topics ranging from organizational (such as Encouraging and enforcing testing), to design (Building Modern UI), to technical (Splitting an app into modules).

๐Ÿ‘‰ This site also reminds me of a book on large-scale app development that I’m currently working through: Building Mobile Apps at Scale.

Via iOS Dev Weekly.

creativity · Software Dev

“Itโ€™s time for me to build an app”

Here is a funny and relatable perspective on being an app developer wanting to just make your own goddamn app. Via iOS Dev Weekly.

๐Ÿ‘‰ Going indie, step 5: Suffer from crippling imposter syndrome

You want to build something that belongs to you, you want to pour your heart into it, and frankly, youโ€™d like to find some success doing it. โ€œItโ€™s time,โ€ you proclaim boldly, โ€œfor me to build an app.โ€

The post does spend a lot of time talking about social media stress and imposter syndrome, which doesn’t bother me too much. Personally, I have long let go of any dream of having a big, important Twitter or Instagram account. Or even making any money off of an app. I just want to make my own apps.

A big part of you still feels that, as someone who can competently design and build software, you are uniquely positioned to create your own lifeโ€™s work… Wouldnโ€™t it be a shame not to try? Youโ€™re tired of deferring your dreams to your future self; itโ€™s time to act!

My own situation is further complicated by my additional dreams of writing a book and making some songs. I’ve actually made some progress on those dreams already. Can I really fit another dream into the rotation?

Stay tuned and see. Give me like a year. Baby, I want everything!

Reaching to place your app among the very best
The World

Apollo 11 Source Code ๐Ÿš€

In the coolest news ever, the source code for the freakin’ Apollo 11 space modules was recently revealed on GitHub. ๐Ÿคฉ

Specifically, this is the source code for the guidance systems of the Lunar module (the thingy that landed on the surface of the moon) and the Command Module (the can that orbited the moon during the mission).

๐Ÿ‘‰ Apollo-11 on GitHub

A few cool points:

  • The code submission date is March 28, 1969.
  • The programmer is one Margaret H. Hamilton, Colossus Programming Leader Apollo Guidance and Navigation. If anyone is still saying “girls” can’t code, then you can seriously stop now.
  • There are two literal modules in the project: Comanche055 (Colossus 2A, the Command Module), Luminary099 (Luminary 1A, the Lunar Module). So much for thinking of “modules” as just a programming concept. These were two physical components literally flying around the moon.
  • These nerds were funny too. The master ignition routine is called BURN_BABY_BURN. ๐Ÿ˜‚
  • The code seems to be written in some sort of assembler language, as in 1969 basically no modern languages were yet invented.
  • The code comments are currently being translated to other spoken languages as part of this open source project. For all mankind, mothers! ๐ŸŒŽ
Software Dev

Clean Code is Not the Goal ๐Ÿคท๐Ÿปโ€โ™‚๏ธ

I want to thank this article for having the guts to say that basic working code is okay.

๐Ÿ‘‰ Goodbye, Clean Code

As software developers, we all aim to write amazing, beautiful code. It’s part of what motivates us. But remember, the real goal is to ship something that people can use. And writing beautiful code isn’t necessarily what makes that happen (example).

Donโ€™t be a clean code zealot. Clean code is not a goal.

This hit home for me after years working with an incredibly tedious and impractical code review process at a previous company. The reviews went way beyond sussing out bugs and tech debt and into opinions about the “right” approach for days on end. The team was unproductive and unhappy, and we still shipped plenty of bugs.

Sure, aim for great code. But there is a practical point where you need to let go and ship something that works.

Let clean code guide you. Then let it go.

As an engineer, yes, be elegant. But more than that, be practical. Voltaire put it elegantly ๐Ÿ˜† way back in the day.

Perfect is the enemy of good.

Voltaire

Via iOS Dev Weekly.