The Importance Of Discipline for iOS Programmers
As companies want to build great iOS products, job descriptions for iOS Developers usually demand top quality software skills. To fulfill this demand, developers need to learn and apply best practices. However, there are no agreed or predefined rules, nor a set of steps for performing such practices in everyday operations. Thus, the importance of discipline comes in hand.
By working with and helping teams meet the firm’s expectations we’ve noticed that the terms “top quality” and “best practices” are ambiguously used. This ambiguity leaves room open for personal interpretation and miscommunication.
It is logical to promise and aim to produce great results. However, to achieve great results, it's not enough to just work hard. We often see teams working hard but, over time, unintentionally breaking their promises because of external pressures. Pressures such as deadlines, frequent changes, and the addition of requirements, for example.
The Importance of Discipline on a Daily Basis
We have been teaching our mentees that top quality shouldn’t be their direct goal, because it can be extremely hard to imagine what “top quality” means in the context of the whole system. Instead, we show developers how to think of quality notions as byproducts or the result of a series of small actions they need to take. For example, to create a “great” codebase, we must build first the codebase. To build the codebase, we must write the code. To write the code, we should split our contribution into several commits. Thus, a sequence of “great” commits results into a “great” codebase or a “great” result.
The end result is merely a mirror of each intermediate choice and action we’ve made to get there. For example, it is impossible to end up with a sustainable codebase if the vast majority of its units weren’t built with sustainability in mind. So instead of focusing only on the big picture, we must get the smallest of contributions right first. How to achieve such a result? One word. Discipline.