For iOS developers at any level, learning something new can be a time-consuming and challenging process. When discussing career goals of students in the computer science lab, most individuals possess a good understanding of Swift/iOS coding syntax and commonly used design patterns. However, roadblocks are met when understanding ideas behind basic computer science and algorithms. If this describes you, here are four things to consider when learning this new area of development.
Your Approach
As an iOS developer, it's almost certain you have experience writing Swift/Objective-C code and can code design patterns that use object-orientation, model-view-controller (e.g., MVC), asynchronous functionality or delegation. As we see in software development, there's usually a single best way to present and organize code. Much of this comes to applying specific syntax or using components from the iOS SDK correctly. It's these "best practices" we look up in documentation or search for through (incredibly useful) websites like StackOverflow. However, when it comes to learning computer science, you should consider putting aside the "single-best-way" technique and instead focus on proving your approach.
The idea behind proving your approach is empowering but can also be confusing. Instead of thinking of a single way to solve a problem, assume there are many ways to reach a desired outcome. In the book, I cover concepts such as divide & conquer, the greedy approach, dynamic programming, and the brute-force method. In consideration of the brute-force technique, this implies we're coding a solution with no concern to algorithmic efficiency. Even though a brute-force technique could be used to build an entire app, ask if that approach would be the most optimal. How would you redesign your function, app, framework if it had to process 1M rows of data? If we consider world class websites like Google, "optimal" often translates to speed and efficiency. As a result, many algorithms are merely recipes to increase performance, solve seemingly unsolvable questions or to improve data storage.
What to Exclude
When it comes to learning algorithms such as Tries, Binary Search, Graphs and Hash Tables, a common trait they share is their approach to the exclusion of data. For example, instead of asking "how can I search through the data to find the answer," the question gets reversed to "what data can I exclude to assume the logical result." For those new to algorithms, this insight proves to be a valuable tool when the answer isn't apparent.
Thought Experiments
I first heard the term thought experiment while watching a documentary on the work of Albert Einstein. While you certainly don't need to possess a genius-level understanding of STEM subjects to write code, the idea of reworking problems based on limited information is something that as developers, we will undoubtedly recognize. Again, the concept of thought experiments reinforces solving hard questions by applying an unorthodox approach. As you brainstorm, change things up and work on planning solutions on paper before committing them to code (note: this is where having a solid grasp of Big O Notation helps). What's nice about stepping away from the computer is that your primary effort is put toward problem-solving without added consideration of perfecting code. While you work, assume the code to prove your point is possible, even if you're unable to recall the exact syntax immediately.
Bells and Whistles
The advice of bells and whistles goes hand-in-hand with conducting good thought experiments. Even though I work with many students learning Swift, iOS and interview preparation, tools like Xcode, CocoaPods and Git should be seen as secondary tools to maintain and document ideas, not as the primary way to generate new concepts. By seeing your software development tools in this context, you'll be well-positioned if, for some reason, you're asked to express the same ideas in a different programming language, tool or upgraded environment.