“What we are discussing in Russia is relevant in the West as well”: interview with Denis Neklyudov

    Denis Neklyudov is interesting for Android developers for a number of reasons. He is engaged in the Android Dev Podcast, speaks at conferences, attends GDE summits - in general, is involved in the life of the community in a variety of ways. And since he now lives in the USA and works at Lyft, he can compare the western situation with the Russian one.

    And on the eve of Mobius 2019 Piter, where he talks about “architecture with a focus on scaling,” we asked him a little about all of this. How can a Russian podcast be of interest to Western listeners? How does it feel to work where hundreds of mobile developers count? What is wrong with Google’s solutions for Android developers? And what's wrong with using smartphones in general?


    - You participate in Android Dev Podcast , and recently Flutter Dev Podcast also appeared - how did this “budding” happen?

    - Initially, I was the most important Flutter troll. Those who were at the GDE summit will not let you lie. I told the main Google managers directly: what kind of craft is this, how can you put it next to our serious adult Android?

    But a couple of months after I said all this, they were released, I myself tried everything with my own hands, looked at what you can do about it, and realized that this was not a toy at all.

    At first, we perceived that there was some kind of virtual machine, JavaScript. And then it turned out that everything is compiled into native code, and really works fast on both platforms. At the same time, tuning is old enough for such an experimental, it would seem, platform. And it turned out that the Dart language is not so bad. Yes, this is not Kotlin familiar to us, but a very adult and good language with all the charms of modern programming languages.

    I changed my mind and it became clear that Flutter had prospects. Even React Native, Xamarin and other third-party frameworks have spread, and here Google support, and even rumors about the new Fuchsia operating system, where Dart and Flutter will be used in the first place.

    But we will not cover all Flutter news in Android Dev Podcast. And then I had the idea that it would be nice to make a separate podcast. I turned to my old friend from the university years, Zhenya Saturov, saying: “Do you want to take the initiative? I won’t pull the second podcast, but you’re younger, maybe you’ll take it. ” And so Flutter Dev Podcast was born.

    - When the same Google company develops both native Android development and Flutter, it may not be clear to novice developers "well, where should I go." Does this seem like a problem to you?

    - If beginners can not decide, let them immediately go to the development of games on Unity! But seriously, there is a described effect, but Google has been sitting on two chairs for so long: web and native. There are things like Progressive Web Apps that are also being developed at Google. It seems that there are native platforms, why are you bustling your PWA? And there are also initiatives like WebAssembly related to the execution of everything that is possible in the browser (Google was originally from the world of the web).

    Therefore, Google is not the first time to create different jobs for different categories of solving the same problem. This is such a huge colossus where inside there are different small companies struggling with each other. Therefore, it is not surprising that there is competition within one corporation.

    - Continuing the topic of podcasts: the company Lyft, where you work, this year has its own podcast on mobile development. Do you have anything to do with this?

    - They started it before I came: when the company is going to do a podcast, it’s not “recorded, laid out”, but a long process of agreeing on what you can talk about, which you can’t talk about. But they promised to invite me to one of those topics (they did not call the host).

    There are many podcasts about mobile development - recently another Russian-language has appeared . I think that the more there are, the better: the quality of those who want to be on top is higher. But the thing is clear that listeners have to consume more and more materials. It is the same with mitaps, conferences, platforms for reports.

    - Still got a podcastThe Context with Artyom Zinnatullin , and since you are now working with him in the same company, the question arises whether you want to somehow join forces.

    - As far as I know, Artyom already missed some editions of The Context due to the high employment at work. But he also comes to us in Android Dev Podcast with joy, it all depends on the topics. Artyom does not edit editions, but comes with expert opinion. And I often like to do editing, and here we do completely different things.

    - When you are engaged in Russian-language podcasts while living abroad, does it feel like two parallel lives, where your podcast is not listened to at work, and in the podcast they know something from your work only from your words?

    - In Singapore, this was not felt, but in the USA it is really felt that these are two different worlds. In Russia they know me, my name already has some weight. Nobody knows me in the USA, and in response to the words “I have a podcast” they ask why they did not hear it. Because he is in Russian. Here, of course, I lose.

    Therefore, my personal initiative is to do English-language releases of the podcast, speak more in English to expand the audience. What we are discussing in Russia is just as relevant in the West, there are many unfilled niches. It seems to me that the topics that we raise in the podcast would be nice to cover more often here.

    - English-speaking listeners already have podcasts like Fragmented - what do you think Android Dev Podcast can give, which they don’t have?

    - I always wanted to believe that we are closer to the listener. We do not try to be objective, and often our personal opinion remains the personal opinion expressed in public. But at the same time, this opinion has some great experience behind us, and we are not embarrassed in our statements.

    Perhaps in the West it just won’t go, so Fragmented is a more refined podcast, where there is little in-depth knowledge, details and difficulties (which many simply don’t understand). In pursuit of a high number of auditions for a wide audience, some podcasts remove complex topics for discussion.

    - Speaking not about podcasts, but about Android development, do you feel a noticeable difference between the US and Russia in it?

    - I think so. I am not yet ready to judge strictly, but the primary feeling (not as hard as in Singapore) is that everyone is very weakly interested in their profession and their skills. Here, when the company has many developers on the same platform, people just sit and do their tasks, for them Android is not their life, not their passion, not their hobby, but simply a list of tasks that they must implement.

    Large scale in mobile development

    - You work in a company where there are more than a hundred mobile developers. Do they constantly ask the question “You have an application from about one screen, what should such a crowd do there?”

    - I myself initially asked about this. The answer comes when you get inside all of this.

    Firstly, we cannot say that we have a single-screen application. To begin with, there are two applications (driver and passenger), and then, if we talk about passenger experience, then we have an application with cars, scooters, bicycles, autonomous cars and with different chips for different regions (both payment and user) .

    And secondly, a lot of difficulties come with scale. There is a lot of work related to thinking through metrics, creating experiments, tracking how your previous work is going. The scale in the form of millions of users affects the development time, now I understand this better.

    We are divided into small cross-functional subcommands, where everyone is responsible for a section. Someone is responsible for the trip, someone for bicycles and scooters, and this is how two dozen different teams are formed, in which there are two or three developers. I am responsible for the part related to user identification. And I would like to see another colleague appear for this part, increasing our total counter.

    If we talk about the developers of small applications, which are full among our readers, it just turns out that we simply consist of a dozen small applications inside one large one.

    The situation is similar in many large applications. And the division into feature-teams, and metric driven development, where metrics drive everything, and the start-up approach, when we first make MVP, and then bring it to a good state: for some it is in the form of the whole product, and for someone in the form of an internal feature. Even Google puts its small teams in such a way that they are like a startup, and tries to minimize bureaucracy and long development cycles.

    - And what does the work of a particular employee look like in such a situation? Can you talk about some of your voluminous task?

    - It took me two months to create a user profile, although it is not difficult in itself. The screen itself is new, previously the user did not have a profile, there were only settings. Besides the fact that it was necessary to make up the finished, it turned out that from the architectural point of view, some components were not enough, it took me to go into the architecture, to help the guys.

    I also decided to experiment with Dagger, it also took time. It was also necessary to think over metrics, build a dashboard, collecting analytics of the success of the experiment, it took time. Then I began to add existing screens from the settings to the internal screens of the profile and update.

    Updating according to the “scout rule" required refactoring what was touched. Refactoring for the latest architecture also took some time. Plus we have a design system, and some components are not implemented from the latest approved elements. What to wait for the team that writes these elements, I took and helped them to copy their work to them, so as not to be blocked.

    Out of all this, two months of work formed, which at first glance seemed a couple of weeks.

    - When you want to "experiment with Dagger" during the task, are such experiments encouraged?

    - Depends on the level of the engineer. I think if he is an entry-level engineer, then he and the manager have a clear understanding that he is not distracted by any architectural experiments, because he himself is still green for this.

    And from experienced engineers, it’s directly in their responsibilities to contribute to something broad: organization-wide, or at least application-wide. Therefore, there is nowhere to go: even if it is not very interesting to engage in architecture, but want to develop, you have to connect your life with something more than just features.

    - And if you experimented, and the result was successful, then it becomes a general policy, or can it remain within the team?

    - Very rarely, it remains inside one team. Usually, if someone starts an experiment, this is immediately consistent with the core architecture team and is subsequently considered as general good practice. For example, now two teams are experimenting with Redux in parallel to understand which of us will win, whose solution will be more universal, and we will begin to use it throughout the company.

    - The increase in the number of people in a team is also the growth of “paper work” when you do not code, but do something related. It’s clear that this is necessary, but how much does this slow down the developer compared to how in a small project he would “just feature”?

    - Again depends on the level of engineer. If the engineer is middle or a beginner senior, then there is no requirement for him to write a lot of documents, he sits and figures out features under the supervision of his senior engineer. But the senior engineer is already gaining managerial responsibilities, as in any other company. He can’t get away with talking with his boss if this is a startup, or writing documents for his manager, if this is a large company.

    - When you make an Android application for a taxi, are the problems and current issues about the same as other large applications, or do you have your own specifics?

    - The problems that we face are very similar. For example, the problem of multi-module assembly adds infrastructure engineers the same worries for every day, so it is not surprising that Uber, Facebook, Airbnb and Lyft use the same Buck build system.

    Others also look at it, reaching our scale, and this confirms that the problems are the same. In parallel, the same processes occur - for example, all slowly become reactive. Well, someone is more conservative, someone still has callbacks, no reactivity, and even no Kotlin, because the scale and qualifications of the developers do not allow this.

    The difference from the situation in the CIS is that we often go to each other and say: "Guys from Gradle, help with something." That is, while the CIS uses tools written in the Valley, here we also constantly communicate with each other.

    Is Google right

    - Recently, Jake Wharton had a number of criticisms of Google's solutions for Android development, and you agreed with some of this. What exactly do you think Google is doing wrong?

    - There was a discussion that it was not necessary to call the ViewModel and put the context into it. With this, I think, many will also agree. I am very upset that many perceive libraries from Google as a source of undeniable and the most correct.

    Candidates come to our interviews, and 9 out of 10 use Android Architecture Components to solve the tasks that we set for them to describe the design of the application that they would write. Here I can not disagree with Jake that the ViewModel has controversial issues, although everyone really likes the lifecycle.

    As for the Data Binding library, Android Summit was indicative this fall, where on a fireside chat five out of ten questions were about something not working in Data Binding. The tool was too powerful, and in my personal opinion, it was never brought to mind for multi-module and quick assembly. But at the same time, everyone took him as truth.

    In fact, it is quite convenient, but Google, in my opinion, did not allocate enough resources to continue to support it. And then the community snapped: they trusted Google, but we don’t get enough support.

    “Some people are unhappy that many of Google’s solutions have appeared only in recent years:“ A good spoon for dinner, you’ve been slouched for years and the community has figured it out, but now you’ve woken up. ” What do you think about this? Why is the company behaving this way and is it bad?

    - I see all this from the point of view of budget allocation and from the point of view of the strategy of some separate higher managers who previously had one point of view or were just other people, but now they have changed with a different approach.

    That is, this is not Google, but just a couple of people who make decisions in the Android resource allocation team. So they got resources, devrel, and library developers who wanted to do just that - there were solutions from Google. And it’s definitely good that they appeared! I am more upset for a community that unconditionally believes what they were told and does not give any critical assessment.

    - Google, in a recent Android development video tutorial on Udacity, provides a mix of basic things everyone needs and solutions like Data Binding. Do you see the problem in that beginners unfamiliar with the context will perceive them as an indisputable truth, and not as an optional option?

    - Video courses on Udacity is a separate story. I have been familiar with Android courses there since 2016, when we did the first Study Jam course on them. There, in general, everything went perfectly, the basic things were perfectly explained. But of the eight lessons in the course, two are in the middle — indigestible, impassable, very complex ContentProvider topics. Why would a beginner know how ContentProvider is structured, already in 2016 it was not clear.

    I still had questions about how they compose topics and place accents. Therefore, the words that everything is mixed up there now, do not surprise me at all. But video courses, worth paying tribute to, are generally always a complicated topic. They become obsolete as soon as you put them out.

    It is very difficult to prepare good quality material. There are many places in the community where you can get fresh sources of updates and an understanding of what is happening and how. But if beginners read us - go to work in any company that is engaged in mobile development, there you will immediately be taught how to do everything right. Something more or less relevant, let’s know, by word of mouth.

    - Here, the beginners will have a question "how to get there without experience, if you have not yet spent a year over the courses."

    - This is a very good question. I believe that many adequate companies will take computer science for basic knowledge without knowing any framework. Because you can always find out the framework, and get basic knowledge on solving algorithms, knowledge of object-oriented programming and just adequate judgment is difficult to get somewhere. This is the basis. With the foundation you will be taken. And if you also have English, then the doors are generally open for you.

    - Previously, you were interested in the Android Things platform, and recently everything has become rather sad for her. What conclusion should we draw from history? That you can never fully trust large companies and you need to use any platform with the expectation that tomorrow it may not become?

    - Conclusion - that we need to monitor trends. This is not the first year that there has been a trend that any electronic device, whether it is a vacuum cleaner or a microwave, starts to be controlled from the cloud, as if we, paranoid people, were not sad from this.

    Android Things as a platform is too overloaded for simple Android tasks, while it does not help much in terms of the cloud or some kind of machine learning (due, again, to performance problems). This suggests that Android Things is not so cool. But I myself was the one who until the last believed that this platform is at least some solution to the problems that the pieces of iron with Kickstarter stop updating. That Google will at least update the operating system and release security patches.

    Therefore, I’m also a little upset, but stay tuned: for example, from the schedule of the recent Google Cloud Next it is clearly visible that IoT on Google is still very much in favor, and there is a big emphasis on placing calculations on two sides - on the cloud and on small devices.

    The harm and benefits of applications and social networks

    - You wrote that humanity needs to use smartphones less, and this is not often heard from a mobile developer. Can you tell us more about your position?

    - Recently I read a post in the Telegram channel of a Russian-speaking resident of China about how frustrated he is with young people who watch videos on TikTok all the way on the subway - unlike his native Petersburgers with books.

    But the main problem is that when we store some that information in our body - only we possess this information. When we store in our notebook - only we own the information. And when we store information in our smartphone - not only do we own this information, which saddens me very much.

    It seems that a smartphone is an extension of our palm and an addition to our eyes and brain, but we do not own it one hundred percent. The fact that a person begins to trust the additional device too much cannot but make one think.

    - And it’s important for you, are you working on a conditional TikTok or on an application that is close to you personally?

    “Life in San Francisco is not honey, and you need to have some excuse to be here with your family.” Just my work and the sphere in which I work is one of such points. Not just for the sake of salary or to realize myself as a developer, but also in terms of the coincidence of my values ​​with the values ​​of the business.

    - Previously, you worked in a startup 90 Seconds, which deals with video - did this also coincide? Isn't humanity shooting too many videos right now?

    - Good question. This is a professional tool, it was not entertainment. It’s just that instead of people using Telegram, WhatsApp or Google Docs in their correspondence when working on the video, we made a platform for them. This is a B2B platform where small businesses connect with large customers, so this is a different story. But I would be sad, probably, to work on an application whose monetization is taking money from schoolchildren.

    - You are a person who is involved in the life of the community, but does not use social networks. Much happens on Twitter, the same Jake Wharton is actively tweeting - are you not isolated from half the life of the community that interests you so much?

    - It seems to me that in the Russian-speaking segment without social networks, it turned out perfectly thanks to the podcast, conferences and great chats on Telegram. In the Western world, there are also private chats of top developers, there are also conferences and podcasts. I think that here I can do without Twitter.

    - The last question: what can we expect from your report on Mobius?

    - In the report I will try to reflect what developers at the start of the application do not think about. Show them how they should build on a scale without over engineering, and in addition reflect how this scale will affect their lives in terms of mobile application architecture.

    We will talk about many things in the development of the application that we learned, reaching the scale of hundreds of screens, several dozen parallel features being developed by 60 developers (and this is only on Android). The purpose of my presentation is to share most of the practices of good application design and talk about the mistakes we studied and grew on. I want to save the listeners their beautiful foreheads from a rake that hits when the application leaves the “2-5 developers and release once every 2 months” stage on a large scale world with a bunch of new tasks and engineering challenges arising from this.

    Also popular now: