I answered the siren call of contract work and regretted almost every minute of it
It’s hard to care when it’s only about the money
I need to preface this with: I did not regret working with the people I worked with on this project. The people were fantastic. The project, however, was not. In a similar vein to my last title, “This looks like nonsense, but it’s my nonsense,” this is a privileged take, but it’s my take.
For the better part of the summer, I have been solely focused on developing projects (and writing content) for this Substack. It has been creatively and artistically fulfilling, but monetarily, not so much. So when a friend messaged me asking if I wanted to make some quick cash to be a “code mercenary” on a project that was desperate for some help, I jumped at the opportunity.
We got on a call and she began laying out the project details. I admittedly stopped listening past “iOS” because once I heard the hourly rate, I immediately began spending the money in my head. She probably mentioned more critical details like scope, subject matter, and even industry category but my brain went straight to:
“iOS? Hired gun? That’s me!”
I got access to the code the next day, started digging in, and then gradually remembered two keywords she had mentioned to me over the phone: “migration work.” Oh. Oh no no. I have not had to go near any migration work since 2017 (my first year at GOAT), when we re-architected & re-wrote the entire app in six months. It was commonly referred to by our iOS team as “The Dark Times”, as we were often told, “Don’t think. If you think, you’ll start asking questions that only have wrong answers and you will rage quit.”
What is migration work?
Software migration (due to deprecation) is like being forced to move out of your apartment because the building has been sold out from under you to be paved over into parking lots for the LA Olympics. You can stay for those last couple of years before it is torn down, but “deprecation” is a public notice that it will no longer be supported or updated. The shower head is leaking? Sorry, can’t help, please move. Did the hot water stop running? Can’t help, please move. No more electricity? For the love of all that is holy, MOVE ALREADY.
So to avoid these problems, you need to migrate your code to the supported option before the old version completely shuts down. And yes, of course, this work never happens in advance and usually only occurs two weeks before complete shutdown because we are humans and we are busy and migration work is, like Mr. T so eloquently put, PAIN. There’s no glory in it either because there’s no new thing and no celebration at the end to point at and go “I built that.” There’s only blame and new bugs that were old bugs — “Hey this used to work, why did you break it?”
Short side note on the glory part: A friend of mine once asked me if they should switch become a security engineer and my notes to her were “well, you will always be employed but the only time anyone is going to notice you is when you fuck up.”
Case in point: the 2024 Crowdstrike incident (aka the day 8.5 million Windows computers crashed and caused an estimated $10B in financial damage).
Do what you have to do
But ok, enough whining. It’s time to accept my fate and get to work.
So the two options (that I know of) in a migration case like this are to rewrite all of it or to build a bridge of some kind. A full rewrite is a more future-proof way of doing things, but it will take substantially more time because you’re going to have to touch the way data is ingested from the backend, displayed on the frontend, and interacted with by the user side. It also re-introduces bugs that the current setup already handles because you don’t know where any of the skeletons are buried. (This is not a dig at anyone. Bugs are an inevitable byproduct of shipping code, especially at startups where speed often outweighs the risk. And yes, unit tests can solve for this, but again — not all startups have those in place and we are on a finite timeline here.)
A bridge, on the other hand, will get the job done in an expedited amount of time while doing the least amount of “harm” to the current system. It is exactly what it sounds like, a solution that doesn’t really solve the issue at hand but bridges the old code to work with the new code. Similar to that scene from Apollo 13’s “square peg round hole” problem (but with much lower stakes in this scenario). A bridge is not pretty and it does not do the next developer down the line any favors. Because you didn’t fix the actual problem, the next engineer now has to follow the original code, your “fix” code, and then the final implementation. It’s like trying to have a conversation with someone who doesn’t speak your language but instead of taking the time to learn the language (because why would you, you’re only here for two weeks), you get a translator. But then that translator only speaks your language, so they need their own translator! Like this scene from The West Wing:
I owe someone a beer
Apologies to the next developer but yes, I decided to go with the bridge. I am 100% sure I made it worse than before, but hey, I at least got the damn thing to work! And that’s honestly the name of the game with migration work on a deadline — you do what you gotta do to make it functional. But if you, the current reader, are currently working on this project and you see my name in the git blame — I apologize. Please DM me because I owe you a beer (or a bottle of Dom).
Beyond the code itself, the most frustrating part was that it felt like I was actively doing my best to lose IQ points. I was spending every waking minute stuffing my brain with information I would never ever use again because this entire framework was DEPRECATED. I was sprinting into the knowledge wastelands instead of laying down groundwork on frameworks that would pay dividends in the future.
I do wish I walked away with a different experience (and I probably would have if I was being asked to do feature work that explored the depths of iOS’s capabilities) but you live and you learn, so this one is on me. I need to exercise some patience when saying yes to projects and make sure I am not blinded by the money and unnecessarily take on any migration work 😅.
What’s Next
Since this gig took up August’s spot, there will not be an app launched this month. However, next month’s project is already in the works and will be published in two weeks! That app’s working title is called Daylight ☀️.