Always Think Before You Print
Non-technical mistakes I made building my first app
I launched my first app in April, which is three months ago. It’s still my only app. Well, I made other apps, but that was the only one I launched.
Right after the launch, there were problems. Bugs. I fixed them in a following release, 1.0.1. That release got “metadata rejected,” which for me meant my promo video violated the guidelines. I re-rendered my video and released another version quickly, 1.0.2. That was approved.
And now, after almost three months of inactivity, version 1.1.0 is here. I translated my app into Chinese. I made new screenshots and refreshed the video.
But what took so long? 1.1.0 doesn’t have a lot of new features besides Chinese support, and creating the metadata took less than a week. Shelter-in-place was also in effect, which meant I had loads of spare time.
Looking back, there were times when I lost interest, and others when I was simply too lazy. I would abandon my app for YouTube and other entertainment. I would put off new features for later. And then there were the mistakes I made — which largely contributed to my lack of interest and motivation.
Mistakes come in many forms — bugs, organization, and those that are so non-technical, so harmless… those that aren’t obvious.
Bugs in the code are unavoidable, and a great learning experience. They’re easily solved with time and resources, and once you’ve fixed one, you won’t make the same mistake again. And even if you did, you’ll know how to fix it.
Organizational errors are easy to make if you’re coding without a clear structure. Unless you completely messed up, you can usually fix them with some time — move files into folders, split huge classes into multiple extensions, press Ctrl + I to re-format and re-indent code. But these errors aren’t too bad, and I encountered them less and less as I learned more about coding.
And then there are the non-technical errors. They don’t seem like errors… until they slow you down. Until you spend hours cleaning them up. That’s what happened to me.
Non-technical error #1: When Commenting Is Easier Than Deleting
When coding, I’m always afraid to delete my work. What if I need it again? What if it becomes a solution to a future problem? I wasn’t good at git, so I once copied snippets (and sometimes entire files) into Notes before deleting.
Then one day I discovered the Command + / shortcut. It’s simple — highlight some code, press Command + /, and it’ll transform into comments!
That was when I pretty much stopped deleting code.
It never occurred to me that I would one day accumulate so many comments. And these aren’t helpful comments — I didn’t write any explanation of what they were supposed to do — they’re useless. I don’t know how old or how new they are. And worst of all, they’re misleading — I don’t know if they worked, if I had been going on the right path… I don’t know anything.
It took me a long time to clear this up, and there’s still a lot left over. I’m hoping I don’t do this again.
Non-technical error #2: When You Give Yourself Too Much Space
I learned the basics of Swift in an Udemy course. The instructor suggested maximizing Xcode’s “real estate” (something like that), which meant rearranging windows so that you got the most out of your computer’s screen space.
The instructor also recommended pressing enter a couple times after writing each line of code, like this:
var someCode = "Some Code"
func changeCode() {
someCode = "Different Code"
}
print("someCode is now \(someCode)")
I think this is pretty good advice. The code is clean and really easy to read. It’s also easy to add more code in the blank spaces later.
But I pressed enter too much, and it became a habit. I did it without thinking, and my code lengthened.
And sometimes I didn’t press enter. Chunks of code started grouping together with no logic or pattern. Eventually, I probably spent more time scrolling than coding.
I learned that taking advice without thinking doesn’t always end well.
But it wasn’t too bad. I can live with blank spaces — it slows you down, sure, but it’s still better than tightly spaced code.
Non-technical error #3: When You Print Without Thinking
Sometimes my brain shuts down — descending into a blundering autopilot that doesn’t know what it’s doing. This happens frequently, especially when I expect something to happen and it doesn’t.
This autopilot only knows how to do one thing: print().
But in this suspended state, I’m just as lazy as ever. And no, I’m not talking about DRY lazy. I mean lazy lazy. Check this out:
Maybe at first glance, none of these print statements look like they have anything wrong with them — but it becomes apparent in the console.
All these print statements are lost in the flood .
- I don’t know what
[]is. - I don’t know what
7is. - I don’t know what
(0, 0)is. - I don’t know what
[""]is.
Something I wrote in autopilot mode, like this…
print(contents)>> Console: [""]
… would have been decipherable if I used String Interpolation, like this:
print("Contents of list: \(contents)")>> Console: Contents of list: [""]
My autopilot couldn’t even take the time to write a few extra characters!
I realized this problem early on, which is why I could only find ~15 no-context print statements in my code.
But even when I forced myself to use String Interpolation, I somehow still found a way to make my print statements utterly useless.
Let’s take a minute to laugh at this.
print("SEARCH sdsfARR: \(arrayOfSearch)")What’s “sdsfARR?” Beats me. But this is even worse:
print("mani asynccache: \(number)")“mani asynccache?” I think I probably meant DispatchQueue.main.async. At least I could decipher it! That doesn’t apply here, though:
print("LKJFSLDFJLSDJFLSDJFSDF \(differentPaths.count)")By this point I was just pressing random keys in order to fulfill my “String Interpolation” requirement.
However, no-context and no-context/string interpolation print statements are nothing compared to this:
Introducing… absurdity.
I developed a habit of repeatedly (and randomly) pressing keys.
This was because I wanted every print statement to be unique, so that I could find them easily afterwards by pressing Command + F.
Sure enough, my print statements became unique. So unique, in fact, I forgot why I even wrote them… in a matter of minutes. And a day later? They became virtual paperweights, serving one purpose only: Taking up space.
And scrolling turned out to be a problem again. With all the useless print statements, I sacrificed screen real estate for… nothing in return. I was too lazy to clean them up.
It was an even bigger problem in the console. Because I never deleted the unused print statements, they continued printing. And continued. And kept on continuing. When I added fresh print statements, ones that I actually tried to use… they became lost in the wave of absurdity. My original idea, using Command + F for ease of navigation, would be used in the console more often than in the editor. And soon, even Command + F couldn’t keep up with the flood after flood of print statements.
I could have set time aside to clean them up, but I didn’t. In a stroke of (un)genius, I thought of an idea — probably the dumbest idea I’ve ever had while coding — to add long, highly visible chains of characters after important print statements.
Huh?
This is what I was thinking:
If I can’t find my print statements… I need to make them STAND OUT.
And this was the result:
print("Done checking for errors------------------------------------------------------------------")
print("Empty: \(emptyStringErrors)")
print("Single Space: \(singleSpaceWarning)")
print("Start Space: \(startSpaceWarning)")
print("End Space: \(endSpaceWarning)")
print("Duplicates: \(stringToIndexesError)")
At the time, it felt like a victory. A few seconds of extra typing ( — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — ) was enough for me discover my new print statements!
It was doomed to fail. I repeated this tactic over and over again, adding more and more characters. My console evolved from floods of absurdity… to floods of long absurdity.
Almost.
I stopped myself before it got out of hand.
But the legacy of these meaty print statements lived on in my code. I never deleted them. I used Command + / and commented them out.
Always Think Before… Anything
It’s impossible to code without thinking, even if you’re just copying and pasting — but it is possible to make mistakes without thinking.
I used to think of mistakes as the errors you make in the code, like bugs. And if you asked me about my greatest mistake ever in coding, I probably would have said something along the lines of “Oh, I once manually spliced file URLs together and no photos showed up” or “Good question, a few days ago I tried using notification center with tableview cells!”
But these were just technical mistakes — ones that I’d fix with a bit of time. They’re certainly not my greatest mistakes — that title goes to the mistakes that don’t look like mistakes.
And it’s almost ironic how these non-technical mistakes — my greatest mistakes ever — came as a result of not thinking. You would probably assume that the most complex, unsolvable errors are the outcomes of excessive thought… and this is true… but complexity isn’t a bad thing. Instead, you could argue that simplicity (or more accurate to say, laziness) is the biggest oversight that you can make.
That reminds me of a Mordo quote:
If there’s one thing you can do to work more efficiently, it’s to spend a little more time thinking while coding, or doing anything in general. It might seem like extra work at first, but it’s going to help you out in the long run. Believe me, scrolling isn’t fun.
That’s it for this one. Thanks for reading!
