We interviewed our iOS Team Lead Serge L. to talk about typical and unusual problems that we have effectively solved. We also asked about tips and tricks on how people can increase their ability to work under heavy workloads.
The following are representative cases where we were able to provide the most efficient solutions.
We continuously work with customers on the logic of mobile applications. It is the most important topic to discuss because some decisions cannot be supported by the server and some of them are not clear for end users.
When an application we were working on began to be supported in different countries and different languages, we offered the customer a quick and convenient way to update the languages. We wrote a small database on the server so that the languages and keys could be stored there. This made it possible to quickly update any row of code. After all, an application in another country is not only a translation into a certain language, but also its currency, the features of its display, and the price format—the $ at the beginning and $ at the end play a role. Only the phone knows this; not even the server knows what to send us. Therefore, our solution in the form of a separate database fit perfectly for all application instances in different countries.
We were fortunate enough to attend a conference with our American colleagues. They showed us how a web form worked and what third-party windows it opened. However, we weren’t aware of what could and couldn’t be done with this. As a result, we solved a problem with it in a couple of days, although as we later discovered, another group had struggled to find a solution for several months. Furthermore, with the aid of a web viewer, we created a diagram of how it works in our application. The solution was found and implemented in the application and, until today, it works. As a result, it ended up being a running joke with us where we analogized our breakthrough with a hypothetical student who missed a university lecture on an ‘unprovable’ theorem—though ‘unprovable,’ he proved it.
We have a rule on our teams that each participant must prepare two presentations on new technology during the year and put it into practice. We used to gather at the office, now mostly online, to demonstrate new features to colleagues and the first developments put into practice. For example, the presenter can discuss our Siri application or how to apply other Apple technologies. Even if the technology is not needed on our current project, we still study it, and can offer it to a customer in the future. This is how we hone our craft—communicate as a team and find new solutions together.
In any project, whether it is a startup or long-term, it is important to look for ready-made solutions and adapt them to your needs. What we were looking for at the beginning of our company and have been experimenting with over the past few years, still comes in outside-the-box forms. But in the end, the result is identical. The independent path is arduous because initially, it seems the existing system is sufficient and that we are trying to reinvent the wheel. However, in the long run, we achieve something more precise for our customers, albeit through an extended path.
We have discovered over time that we should examine the new, actively take an interest in it, and implement what we have learned from it, even in small blocks and steps. If a developer sees that the screens work incomprehensibly and users might feel uncomfortable, they tell the manager and designer about it. Developers ought to give their arguments if the location of UI objects are annoying. Seriously, if it annoys the developer, it will likely annoy users as well.
We believe that developers should not be afraid to experiment. They should rewrite architecture if they don’t like it. But when rewriting, they must consider each element: What it is used for and what else can be connected to it. They also need to ensure that the old works and the new is applied correctly.