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.

Software Dev

Duct Taped Software

I love this article on the ugliness of complicated (or not so complicated) software in the real world. A games goes open source, and developers are horrified by the code they see. 😱😆

Beautiful. Disgusting.

I’m not surprised at all. Almost every successfully shipped system I’ve seen is full of really ugly code. At some point, you just have to ship that mother. 🤷🏻‍♂️

👉 The truth is that many games are held together by duct tape

Via iOS Dev Weekly.

Software Dev

How to Design Offline-first Approach in a Mobile App – net guru

Nowadays, almost everyone has access to either wireless network or the mobile network. Does it mean that we shouldn’t be concerned with the availability of network when making mobile apps?
— Read on www.netguru.com/blog/how-to-design-offline-first-approach-in-mobile-app

Great overview of building an app that works offline first as a means to a great user experience.

The offline-first approach is not the universal solution to every problem you will experience with unreliable network connectivity – it heavily depends on your app’s requirements. It’s more like a design approach that lets you focus on what really matters to your end user: a robust app with a great user experience. 

The World

The Trouble with Manager Objects – Ben Sandofsky

Benjamin Sandofsky, a Software Engineer in San Francisco, California.
— Read on sandofsky.com/blog/manager-classes.html

A technical pet peeve of mine, this post does a nice job articulating why “manager” classes in software design can be a problem. To me, a “manager” class is like saying, “this class does some stuff” and the stuff has no boundary. But what does this class do? What is it’s purpose? It might be a sign of an unfocused and unsustainable design.

Or as the post says:

Managers can be a symptom of poorly-defined responsibilities. When you think about it, the word “Manager” means nothing. In object oriented programming, every class is a manager. Cocoa Touch could have UIApplicationManager, UIViewManager, and even a humble NSStringManager.