“We all strive for complexity and then struggle with it”: interview with Venkat Subramaniam



    “How many viewers will come to your java report? It depends on whether Venkat speaks at the same time in the next room. ”

    This is a joke with a fair amount of truth: in the Java world, Venkat Subramaniam is one of the most famous speakers, really capable of pulling audiences from other halls at conferences. It is constantly moving across the planet and recently set an impressive record, speaking to its 50th anniversary one year ahead of 50 different Java User Groups.

    What is it like when your Java career is not “sitting in the office”, but “constantly moving”? And what does Venkat think about topical Java questions? In October, he will get to St. Petersburg, and on the eve of this we ( phillennium , olegchir) they took a detailed interview with him, where they started with “living on the plane” and tips for novice speakers, and then turned to technologies.


    As Venkat responds in detail, the text is very long. If you wish, you can go directly to the second part:





    For a life


    - Let's start with your tour, during which you visited 50 Java user groups, hardly anyone has ever done this before. What were your impressions?

    - The most interesting thing for me was the realization that in different cultures in different parts of the world, people who speak different languages, despite all these differences, are united by programming as a single connecting thread. When we start talking about programming, it turns out that the problems we face every day are the same. This was a great discovery for me - you can meet a programmer at any airport in the world, and you will certainly find common topics for conversation. I can endlessly list the cases when I was involved in talking about Java on the other side of the Earth.

    Therefore, the experience with these groups was very useful for me. Managing a user group is very difficult ... I don’t want to say “work” because it’s not work, but it takes a lot of effort. I have great respect for all the leaders who, again and again, gather these events every month. Different groups have different dynamics - some at the meetings have 20 or 30 people, others - 200 or 300. Nevertheless, the number, in essence, does not matter, because the main thing is the passion of the developers who come to these meetings, their interest in technology and their desire to learn. So I was very lucky to have the opportunity to meet with these groups, and I am very grateful for her.

    - And with the similarities mentioned by you, do user groups in different parts of the world have any noticeable local differences?

    - These differences are surprisingly small. I noticed that in some regions more preference is given to heavyweight frameworks, and in others to more lightweight solutions. But, as a rule, all these features are superficial, and deep-seated questions and problems, on the contrary, are universal. I sincerely would like to tell you that at some point on the map people do completely different things than we do, and everything is interesting and unexpected, but I can’t say that.

    We all strive for complexity, it delays us, and when it tightens, we begin to fight it. This is a general trend almost everywhere. Another important problem that no one has avoided is the stringent business requirements and lack of time to work on quality. I can talk about some example to people anywhere in the world, and after my story they will ask me: “Did you happen to work in our company?” Our problems are so deep and universal that, judging by everything, they are common to the whole world. Which involuntarily makes us think about our common human essence, about psychology and philosophy, which we ultimately follow. No matter how many times we imagine ourselves geeks turned on technology, we must not forget about the human aspect in the development of software. Apparently, he is a unifying and universal force.

    - I want to ask about the "hiking" lifestyle. When you sit in the office, it may not be obvious if you would like your life. For example, for many, the jetlag is a problem, and because of this constant flights can seem like a nightmare. But perhaps with practice you adapt to this?

    - To answer your question, let's recall the integration. If the team performs the integration once a month, then you suggest that they do it all the time, they will consider you crazy. In this relationship travel resemble continuous integration and continuous delivery: if you deal with them quite a lot, your approach to them changes.

    Understand me correctly, I am not proud of my lifestyle, in my opinion, it’s not worth living this way. I always say that when I travel I least like traveling. Sitting in an airplane is tiring, the body wears out, and with age these problems go nowhere. But when I find myself at the point of destination, when I meet with other developers, I see their passion for technology, their inspiration, I get the opportunity to share this passion, learn something new and help them learn, all the difficulties pay off with interest.

    If we talk specifically about changing time zones, then it does not bother me at all. Because of the constant flights, in a certain sense, I have no permanent, “home” time. I have a rule: I always wake up at the same local time, around 3.30 at night, and the body very quickly enters a certain rhythm. And, of course, coffee is always very useful.

    - Many people would like to see the world, but they usually go on tourist trips rather than business trips. Do you manage to look at the city, or because of lack of time only at conference rooms?

    - Yes, partly there is a problem with time. But besides this, because of the constant flights, I have some principles that I adhere to. If travel is related to work, then I do nothing except work. I try to spend as much time as possible with the developers. When I have a free Saturday or Sunday, for example, in Europe, I usually spend it in a user group. It gives me great pleasure to communicate with developers, so on my business trips I almost never go to the sights.

    But every four or six weeks in the summer, I travel with my family, and we go sightseeing. This is our time for joint rest, and in the other months I am concentrated at work.

    In addition, my approach allows me to pay maximum attention to various community events, which also gives me great pleasure. It absorbs a lot of time and is a kind of compromise, but it suits me. Life is sometimes too stressful, and I am glad to have the opportunity to sometimes distract and listen to developers who may not have the opportunity to attend a conference or training course. In addition, I believe that it is also my professional duty, for the reason that these things inspired me in my youth. I visited the user group, listened to speeches and dreamed of myself speaking at the time. If I, in turn, manage to inspire at least one person in the same way, this time will not be wasted.

    - The last question about travel. In the film “Up in the Air,” George Clooney's character, constantly flying between cities, knows many tricks to increase travel efficiency: how to stand in line, how to pack luggage, and so on. Perhaps you also have some unobvious knowledge that you would like to share?

    - I am ashamed to admit this, but I sometimes send clothes between cities via FedEx, because I simply don’t have time to fly home and take clothes for the next week. Often, when I arrive at the hotel, my clothes are already there, and when I leave, I send them home. Fortunately, this does not happen too often, perhaps three or four times a year, when I am on the road for three weeks in a row. There was one awkward moment when my wife had to go to the airport to hand me bags, because I only had half an hour between flights. But over time, you really learn to do some things more effectively. I am sometimes surprised when people say “I need to pack up” because my things are collected all the time.

    If we talk about efficiency, I have at least one advantage: I am a very single-task person. We live in the world of Facebook, Twitter and various instant messengers, they constantly distract us. I worked very hard to reduce this influence, because the minutes turn into hours, the hours turn into days, the days turn into weeks, and sooner or later you realize that it was not possible to achieve what you wanted. I usually have a journal in which I write down the things that need to be done for each trip. Thus, I have a schedule for each day (for example, November 7 or October 8), and my phone reminds me of each task on the corresponding day. For an eight-hour flight, I can easily write most of one chapter of the book, or prepare an example for the course. Therefore, flights for me is an extremely effective time. I never need additional entertainment during the flight - quite enough entertainment associated with debugging code. So a professional traveler (if such a term is applicable at all) spends time in flight quite differently than a tourist.

    - Probably, because of your fame, you receive a lot more letters than regular developers. How much do you write and how much time does it take to work with mail?

    - It is worth adding that I teach at the university and get a lot of letters from students. Usually I receive 20 or 30 letters a day. About a year ago I wrote in a blog about one of my principles: “answer now or tell me when you answer”.

    I really appreciate my time, which means that I value the time of other people. In my opinion, respect for another person is not in the treatment of "sir", but in appreciating each other's time. Therefore, if I receive a letter, I always reply within 24 hours. But there are periods when giving a full answer does not come out - for example, if the conference organizer asks to send an abstract or if an industry colleague asks a question about solving a particular problem, asks for some code to be refactored or for some method. Sometimes the answer may take ten minutes, and sometimes two hours, but even ten minutes cannot always be spent. This may sound a bit strange, but I still answer in such cases within 24 hours and write: I received your letter, I will work on this problem, say, on September 2 and write to you on the 3rd.

    Thanks to this approach, my inbox is always empty; I clean it every night before going to bed. So I am extremely disciplined to respond to letters. People often wonder that I respond to their letters so quickly, and I, on the contrary, do not understand how it can be otherwise. I do not want to stand in the way of people, prevent them from developing. In addition, I consider it important to be able to say no. I like to repeat that the more often you say “yes”, the worse you will get what you do. At a certain point you need to realize that we can not achieve everything in the world. Therefore, sometimes I answer that, unfortunately, I cannot help. In turn, I prefer to be told “no” at once, rather than dragging rubber and saying “no” afterwards. In my opinion, this also speaks of respect for the person and unwillingness to waste his time. You are not obliged to help, but, at least do not interfere. Therefore, it is important to say no. That's the way life is, you shouldn't try to pretend that you can do everything in the world. For me, the ability to respond quickly and honestly is a sign of professionalism.

    - You are a very experienced speaker. As conference organizers, we meet people who have no public speaking experience or have very little. Perhaps you have recommendations for them? You had an interesting advice on Twitter “to visit the hall in advance where the report will take place” - are there any similar ones?

    - My first reports were in user groups, which is why I continue to do in them 15 reports each year. And I recommend others to start with the same: with the user group in your area, then in the next, and so on.

    On these reports, for many reasons, there are less risks than at a large conference: there is a friendly atmosphere, people come there to share knowledge, after your reports you will easily get a response. You may well begin to speak, saying that you have little experience in this matter and would like to know the opinion of the audience. This year I had a new report, during the preparation of which I was experiencing quite a lot. I wrote about this on Twitter: it seems that everything can be said in two minutes, but in reality the material cannot be laid in an hour and a half. And I am very pleased that the first time with this report I spoke in the user group, because it gave me the opportunity to better prepare it for the conference.

    In user groups or in the company where you work, you have a great opportunity to practice with performances. First, you will receive criticism from colleagues that will allow you to improve the report. Secondly, even if they do not say anything directly to you, you will still understand a lot when you start talking. I believe that the report can really be improved from the third time. For the first time, you're only trying to put all your thoughts together. And what is interesting: practicing alone here will not help, awareness of problems comes only during performances in front of other people. By the third time, the logical chain of your narrative becomes clearer for you, turns out to be complete. This is not always noticeable, but I sometimes pause during a speech for the third time - at this point I realize what I was trying to say in the report, there comes a kind of moment of truth. So, practice is very important, but not alone with yourself, but with people. To a young developer this can give the necessary confidence.

    True, some make their first reports at conferences. Sometimes it is easier for a person to die than to speak in public, and they are easy to understand - it requires a lot of nerves. Two or three years ago I spoke at the same conference. A very interested person came up to me and said that I seemed to be very worried, to which I replied that this was indeed the case. He asked, "Is this your first report?", And I replied: "No, probably ten thousandth, that's why I'm worried." Each performance before an audience requires a great deal of emotional strain, even if you have a lot of experience, simply because you care about how the report goes. You will do yourself a great service if you relieve this tension with a few test reports in user groups or in your company. This applies to all speakers, including experienced.

    - Is there something in public speeches that, on the contrary, should be avoided?

    “I made many mistakes in my life that taught me that people learn best from experience.” When you speak to an audience, you need to remember a few things. Firstly, you need to maintain self-confidence: you have worked a lot on the topic, and you know a lot about it. Secondly, remember: knowing everything is impossible, and not knowing anything is not your fault. It simply means that you have not had the opportunity to pay attention to it, and there is nothing wrong with that. It is extremely important to honestly admit this to yourself. You can quite answer the question at the conference like this: sorry, I can't tell you anything, I have not had the opportunity to study this problem.

    Another important point is that students can be divided into three types. There are people who want to learn something new from you. Others keep themselves somewhat more cautious, they will listen to you, but they will not be ready to accept everything you say. Finally, there is a third group of people, fortunately, rather small in number: those who are hostile are trying to catch you all the time. Sooner or later, there will always be one developer on your report who will interrupt you all the time and disrupt the progress of the report. In such cases, it is very important to remain calm, to allow him to speak out and return the discussion to the direction you need - but, I must admit, I am also a person, and I do not always succeed in doing this. For example, I can say: I understand that this is important for you, let's discuss it after the report, This topic is important to many here. True, very often you have allies in the audience, and when a person really disrupts the progress of the speech, he is asked to calm down. All this I say to the fact that it is important not to be too conflicted in such situations, even though our nature can oppose it. As a young speaker, I quite often entered into this kind of confrontation to the fullest, and this never brought anything good to anyone. It is necessary to show emotional maturity and not try to prove anything to anyone by engaging in such kind of squabbles. Instead, in such cases, you should lead the topic back to what is interesting to the audience. that it is important not to be too conflicted in such situations, even though our nature can oppose it. As a young speaker, I quite often entered into this kind of confrontation to the fullest, and this never brought anything good to anyone. It is necessary to show emotional maturity and not try to prove anything to anyone by engaging in such kind of squabbles. Instead, in such cases, you should lead the topic back to what is interesting to the audience. that it is important not to be too conflicted in such situations, even though our nature can oppose it. As a young speaker, I quite often entered into this kind of confrontation to the fullest, and this never brought anything good to anyone. It is necessary to show emotional maturity and not try to prove anything to anyone by engaging in such kind of squabbles. Instead, in such cases, you should lead the topic back to what is interesting to the audience.

    I would also like to talk about some of the negative habits during the speeches, which, in my opinion, the developers have. For starters, people should look into their eyes. I understand that it is very difficult and requires a lot of emotional effort, but this should be practiced. Speakers often look at their monitor or, even worse, at the screen, standing with their backs to the audience. You should always face the listeners and you should always look at them. In addition, you need to maintain self-confidence. You are speaking to an audience of programmers, and you can bet that none of them have code that works the first time. If your demonstration during the report did not work - there is nothing wrong with that. All those present are likely to think: "Damn, I have everything the same way." Over the years, I have learned in such situations to turn to the audience for help with debugging. Usually, in such a situation, the speakers begin to mumble something under their breath and try to solve all the difficulties on their own. Instead, you should ask the audience - friends, do not tell me where I am stupid? You will immediately receive a lot of suggestions, and very often they will help you find a mistake. It is difficult for one person to speak and write code at the same time, do not be afraid to ask for help. This experience is also valuable for listeners. This is one of the reasons why I visit other people's reports: to see what they are doing and to understand what should not be done. In my opinion, these habits will help you refactor your speaker skills. Instead, you should ask the audience - friends, do not tell me where I am stupid? You will immediately receive a lot of suggestions, and very often they will help you find a mistake. It is difficult for one person to speak and write code at the same time, do not be afraid to ask for help. This experience is also valuable for listeners. This is one of the reasons why I visit other people's reports: to see what they are doing and to understand what should not be done. In my opinion, these habits will help you refactor your speaker skills. Instead, you should ask the audience - friends, do not tell me where I am stupid? You will immediately receive a lot of suggestions, and very often they will help you find a mistake. It is difficult for one person to speak and write code at the same time, do not be afraid to ask for help. This experience is also valuable for listeners. This is one of the reasons why I visit other people's reports: to see what they are doing and to understand what should not be done. In my opinion, these habits will help you refactor your speaker skills. where I visit other people's reports: see what they are doing and understand what should not be done. In my opinion, these habits will help you refactor your speaker skills. where I visit other people's reports: see what they are doing and understand what should not be done. In my opinion, these habits will help you refactor your speaker skills.



    About technology


    “Kai Horstmann, the author of well-known Java books, told us that he proposed to simplify the creation of“ Hello world ”in Java. Because beginners at the sight of “public static void main” are faced with many new concepts at the same time, and this is frightening, it is wiser to have a more gradual entry.

    The interesting thing is: Java developers rarely think about the benefits of this, because they already seem to take these things for granted, and Horstmann understands this, because he teaches at the university and personally sees the fright on the faces of the students. You as a teacher, author of books and a speaker also teach people. Do you also want to change something in Java because of this?


    - Yes, definitely. Moreover, this is one of those things that attracts me to Java - this is not the same language as it was in 2000. Over the past few years, the creators of the language have begun to realize that when a language becomes verbose and pompous, this significantly complicates the work of programmers, and not only beginners.

    Suppose you communicate with your colleague, you are visited by some new thought, but it is not immediately obvious to your interlocutor, and he asks you to demonstrate what you mean. You open the editor, and in the very first seconds realize that in order to implement this idea you need to write 70 try-catch blocks. And, although the idea is good, you decide to leave it for later, because right now there may not be time.

    For me, programming is a series of small experiments. As a consultant, I work with teams of programmers, each of which has its own way of writing code, and I often recommend them ideas that I have seen from other people. When this happens, they want not only to hear a new thought in words, but to see it in code. In such cases, it is important that they can quickly demonstrate it. In this aspect, I like the least fanciful languages ​​that allow you to implement your idea with a few lines of code.

    That is why Java 12, 13 and 14 are evolving in this direction: developers realize that, although Java is an extremely powerful language, it is not very easy to experiment with it, and it is difficult for it to learn. When you know exactly what you want to write, Java works perfectly, but usually programming looks different. You are always learning and experimenting, you always have ideas that would have seemed impossible before. If I work in a company with an established code base and a certain code structure and if I add new features to the application based on existing templates, these changes will not affect me significantly, here Java works fine in an already existing form. But if you are an architect, tmlid or just a programmer who writes code innovatively and experiments, then Java in its current form will limit you in many ways. Therefore,


    Minute advertising. In October, Venkat will open our St. Petersburg Joker conference with the “Don't walk away from complexity, run” performance . And since every Joker speaker goes to the discussion area after the talk, there will be an opportunity to personally discuss with him the topic of the talk, and other issues.



    - In the context of “less pompous Java”, it’s impossible not to ask you about Kotlin, which is often called that.

    - Yes this is true. And it's not just less pretentious. For me, one of the most exciting things in life is meeting new languages ​​and their capabilities. One of the possibilities in Kotlin is to run a lambda in the context of an object, even though it is not part of a class. I became very interested when I found out about it, because the same possibility is present in JavaScript. There you can pass a context object in the call (what is called a receiver in Kotlin), and then execute this arbitrary global function as if it were a function of some object. The fact that this feature is in JavaScript is not surprising, since this language is dynamic. But Kotlin is a static language, and it does the same, while respecting type safety. The lack of pretentiousness is definitely is a big advantage of the language, as is the fact that it generates a significant part of the code automatically, so that we can not write the same templates over and over again. But the advantages do not end there, because this feature allows you to create internal DSL.

    Science and mathematics led me into programming, but 30 years later I remain a programmer due to the fact that it is an art. Our area combines science and art, this is not going anywhere. The ability to simply make the system work is not limited, here you can draw an analogy with the writing of poems: ask two people to write about love, and each will write in his own way. The code for any task can be written in many different ways. This is what attracts me to languages ​​like Kotlin and many others: the ability to express some of these ideas, to give the code flexibility and ease. You can think less about the syntax of the language and more about the thought you want to convey.

    - For you, quality code is important. It’s kind of important to everyone, and everyone seems to want to write better, but it’s known that a significant part of the existing code has problems. Therefore, the question is: for your colleagues not to be hated for your code later, you just need self-discipline, can you give any specific recommendations?

    “I’m convinced that the only way to write readable code is to read it.” When they tell me that the code is readable, I ask - who read it? If the author himself read it directly after writing, this is not considered. Therefore, I am a strong supporter of the code review. I want to clarify: I am against bringing the team into a room with a large screen, showing the code on it and criticizing it. This inevitably leads to resentment, such a public rotting is not good for anyone.

    One has to honestly admit: we all write bad code. I am proud to admit: my code sucks, I can't write good code. If you ask how this fits with my conversations about code quality, I’ll answer: writing code is a process with constant innovation, and when you try to implement some idea, the quality of the code doesn’t worry you too much. It is always necessary to go back and refactor, and even when I do this, it usually doesn't work for me. But over the years, I realized that, even though my own code is low-grade, I am very good at finding flaws in someone else's code. Therefore, instead of pretending that my code is already excellent, I will write it as well as I can and give you a check, and in the meantime I will take the code of a colleague and check it. As a result, both my code and colleague code will be of higher quality.

    It is very important to give up false pride. I always remind the developers that they are part of the team, it makes no sense to compete with each other and find out who is better. I am ready to honestly admit that my knowledge is rather limited - but I know well what I know. And my colleague also has very deep knowledge in some other area. Together we become stronger when we are ready to learn from each other. Therefore, I always suggest checking the code of each other, and extra pride is completely useless here. You need to be honest with each other, this is one of the most important qualities of a good team. Honesty should not be punished if a person admits that he wrote bad code - this is normal. We raise the general bar by offering each other ways to improve the code.

    Another important point: do not tell the person that he made a mistake, I must say that it is possible to improve. Do not say: "God, what a terrible name for a variable," better like this: "You probably wanted to say that this variable shows the frequency of the distribution - you should probably call it appropriately." This will help you better convey your intentions. This also applies to editing books: talk not only about what needs to be improved, but about what has been done well. We often forget it. When I edit someone else's code and see a place that is well executed, I write in a comment that I like it very much, that we need to do this more often, and explain why. This creates constructive feedback, lets the developer know that you are not hostile to him, and ultimately improves the quality of your team’s code.

    - You wrote that using a tool that drives you into depression is like getting stuck in a toxic relationship: in such a situation, you just need to leave, and as soon as possible. It sounds great, but often the tool has no particular alternative, and what to do then?

    - Quite justified question. Indeed, there are situations where there is nowhere to go. But I rather talked about those cases where there is still a choice, and all that is lacking is the desire to make it. In my opinion, this is a significant factor.

    When there is no choice, instead of complaining, pain points should be identified: what exactly makes this tool uncomfortable for you. And then you can do in different ways. You can contact the developers and say - thanks for your work, it seems to us that your tool could be much better if you paid attention to such and such an aspect. Or you can spend a hackathon - get together with several developers on a weekend, organize a user group, tell them that you spend nine hours a day with this tool, that it is terrible, and ask them to try to add some features to it.

    You may not be able to solve all the problems alone, but at least you can gather other people and solve this problem with them, especially if their interests are similar to yours. Finally, if your tool really gives you so many problems, you can try to write a new one yourself - if you have three or four friends in the community with the same attitude as you.

    So, in my opinion, there are still alternatives. You don't have to put up with a toxic relationship. You should always be able to find a way out - either reach an agreement with a partner and reach an understanding, or leave.



    - You wrote a book about lambdas, and you are known for this book. I also read it, and I think that it is beautifully written, gives what the application developer needs, and does not give anything extra. As a true professional, I would like to ask you: what is functional programming for you? Could you describe it in your own words? I ask this question because everyone defines it a little differently, and each time hidden meanings are revealed that differ from the standard definition from Wikipedia.

    - This is a great question. My understanding of this concept has evolved over the years, and now for me the most important thing in functional programming is the removal of extraneous complexity. The point is that in imperative programming you not only indicate what exactly needs to be done, but also spells out in detail how it should be done. For me, functional programming is a superstructure over the declarative programming style, in which we indicate what needs to be done, but we don’t say how.

    Let me give you a primitive analogy: my best friends adore cars, and I am not at all interested in cars. When we get together, we agree not to discuss cars, because we want to remain friends. I will never drive a car with a manual gearbox - the need to constantly change gears spoils my entire ride, and the same goes for the imperative programming style. An automatic gearbox makes driving a bit easier, but for me the best option is for the driver to carry me. In this case, I just say where I need to go, and along the way I write the code on my laptop in the back seat. For me, this is the difference between imperative and functional programming. With imperative programming, you yourself are driving, you need to know where to go, how to go, where to turn, where you can cut.

    How does the removal of this extraneous complexity occur? Through the composition of functions. When composing functions, your code goes through a series of transformations, during which the data is transferred from one form to another. And for us, it is not important how each of these steps is carried out, but what exactly it achieves. For me, the first aspect of functional programming is functional composition. The problem is that many languages ​​in which functional composition is implemented - Ruby, Python, JavaScript, Groovy, and so on - due to this provide elegance and expressiveness, but have very low productivity. The functional composition in them is implemented inefficiently. I think that elegance without efficiency is not viable. Not only is the code beautiful, it also needs to work quickly. And here we come to the second, a vital aspect of functional programming - this is lazy computing. The result of a certain function is calculated only at the moment when it is needed. Due to this, functional programming achieves a combination of elegance and efficiency. So, for me, functional programming is an emphasis on what to do, not how to do it; the use of functional composition as a series of data transformations; and the ability to perform these transformations efficiently thanks to lazy calculations. for me, functional programming is an emphasis on what to do, not how to do it; the use of functional composition as a series of data transformations; and the ability to perform these transformations efficiently thanks to lazy calculations. for me, functional programming is an emphasis on what to do, not how to do it; the use of functional composition as a series of data transformations; and the ability to perform these transformations efficiently thanks to lazy calculations.

    Please note that I did not talk about immunity and high order functions. The fact is that they are only ingredients for getting the result I described. We use functional programming not for immunity and high-order functions, they are only a means to achieve a higher goal: getting rid of extraneous complexity.

    - Fine definition. Today, there is a language that is a benchmark for how functional programming should be: Haskell (and possibly F #).

    - Absolutely.

    - At least, many think so. But Java is obviously not Haskell, it is limited in many ways. Does functional programming make sense as a discipline for Java? Indeed, in our language there is a very limited set of tools for such an approach.

    - For me, the pragmatic aspect is more important than the pursuit of perfection. I am curious about perfection, but for everything to work, I have to be a pragmatist. I am crazy about Haskell and spend a lot of time with him, just to find out how this or that problem is solved in functional programming. But for my clients, I'm not writing Haskell. Here you can draw an analogy with the "Cathedral and Bazaar". The cathedral is beautiful, but most of the time I spend in the bazaar. The question is how to survive in this world. When languages ​​evolve and when we try to connect several different paradigms together, we, as programmers, need to be extremely careful with their implementation.

    I do not think that in Java functional programming is impossible at all. In situations where there is a choice, I will focus on the most appropriate language for me. But I will never tell the client: you should use this language. Most often, I ask what exactly they do, and I try to find a way to do the same in a more optimal way within the framework of the environment that they already have. I believe that in languages ​​like Java, a combination of imperative and functional programming is quite possible and even recommended, but it should be done very carefully. Imagine that you have a kind of circle of pure functions, around which there will be a ring of sewage. Everything that you want to make changeable must be outside the circle. Inside this circle you can realize your chain of functions, but all changes must be outside it.

    This is one of the reasons why I really enjoy learning new languages. Recently, I became acquainted with the Elm language, which is Haskell syntax with F # splashes, which is compiled into JavaScript. I was interested in this approach from the very beginning, because JavaScript is a bazaar. When you travel through JavaScript, you constantly attack in puddles. Elm, thanks to Haskell syntax, is clearly a cathedral. Nevertheless, this cathedral code is possible to run on the market. The Elm architecture is elegant, it has a model (that is, data), there is a view that displays this data, and there is a transformation, update. The first main principle is that the data is stored in the view. When the user performs an action (presses a key, for example), the data from the view is sent to the update function, where the conversion takes place. The data is immutable, and the update function returns new data that the view saves instead of old.

    If you think about it, then Redux functions exactly in the same way. There are data in it and there are reducers converters. When data is sent to reducers, you receive in return a new copy, which you save instead of the old one. But if Elm and Redux operate along the same scheme, then the same scheme can be implemented in Java. We can create clean functions that will take data, convert them, and return a new copy. By learning from Redux and Elm, we can make the Java architecture more functional. I am talking about this because Redux is compiled into JavaScript, which is definitely a bazaar. JavaScript, I think, is the most removed from the ideal of functional cleanliness, here at every step you step into a puddle. Nevertheless, Redux gives you a functional purity in this extremely unclean world.

    - Well thank you. In your opinion, is the set of tools that we have in Java complete and sufficient? Do we need anything else besides lambda expressions, references to methods, collections with streams?

    - In my opinion, we still lack a lot. The Java world is constantly evolving. I recently had a dialogue with a man who said: "I heard that you were in our city several years ago and argued a lot on the topic of generics," to which I replied: "I always argue a lot about generics." I believe that Java generics are very poorly made. Brian Goetz is angry at me all the time: “There will always be someone who complains about generics,” and that someone, of course, is me. In my opinion, much can be improved in this area. Very important, in my opinion, reification. Much can be done in terms of reducing bombast, getting rid of the template code. The code can be made much more fluent. And a certain movement in this direction is already visible today. Now pattern matching is implemented in Java, which makes me very happy - I really like it, as it is implemented in Scala and Kotlin. I think it is very important, and the analogy with the banknote processing machine comes to my mind. If you skip a bundle of bills through it, it will sort them out according to the value of each note. Similarly, pattern matching works in programming. You pass data through parameters that can retrieve data for processing. I think this could help get rid of that huge number of branch operators that we write in Java. The code will become much more expressive. In general, I believe that Java needs a lot of add-ons, but apparently, it is already moving in this direction. it will sort them out according to the value of each note. Similarly, pattern matching works in programming. You pass data through parameters that can retrieve data for processing. I think this could help get rid of that huge number of branch operators that we write in Java. The code will become much more expressive. In general, I believe that Java needs a lot of add-ons, but apparently, it is already moving in this direction. it will sort them out according to the value of each note. Similarly, pattern matching works in programming. You pass data through parameters that can retrieve data for processing. I think this could help get rid of that huge number of branch operators that we write in Java. The code will become much more expressive. In general, I believe that Java needs a lot of add-ons, but apparently, it is already moving in this direction.

    I want to mention one more aspect, which for me is really curious. I grew up in the world of traditional programming. I'm not afraid to publicly admit that my first language was Visual Basic. In a sense, this is a good language for the first experience, because it cannot be worse. Then I wrote in C and C ++ for a long time, and I spent most of all the time in all languages ​​with C ++. After that, I started writing in Java, C #, languages ​​like Ruby. At a certain point, I realized that I always wrote in languages ​​with multithreading. Therefore, acquaintance with Node became a kind of insight - it took me some time before I figured out asynchronous programming. But, in my opinion, asynchrony is one of the most important areas in which the Java language and ecosystem can develop. Asynchrony refers to coroutines and continuations. I think that Java is already moving in this direction, and this, in my opinion, is extremely important. And I assume that it will be as difficult for Java programmers to become familiar with asynchronous programming, as it was for me. My approach to programming is entirely based on parallelism; I wrote a dissertation on parallel computing. Moving from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving toward things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. extremely important. And I assume that it will be as difficult for Java programmers to become familiar with asynchronous programming, as it was for me. My approach to programming is entirely based on parallelism; I wrote a dissertation on parallel computing. Moving from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving toward things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. extremely important. And I assume that it will be as difficult for Java programmers to become familiar with asynchronous programming, as it was for me. My approach to programming is entirely based on parallelism; I wrote a dissertation on parallel computing. Moving from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving toward things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. My approach to programming is entirely based on parallelism; I wrote a dissertation on parallel computing. Moving from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving toward things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. My approach to programming is entirely based on parallelism; I wrote a dissertation on parallel computing. Moving from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving toward things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. that the world is moving towards things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right. that the world is moving towards things like microservices, asynchrony in the long run becomes significantly more important than parallelism. Java is developing in this direction, and I think this is right.

    “But don't you think that asynchrony is extremely difficult and difficult to achieve?” There is no easy way to debug asynchronous code in JVM platform languages, it cannot be profiled in an easy way. You can enumerate difficulties for a long time. What do you think of it?

    - This is a very popular question, but it is not easy to discuss it. I am ashamed to talk about it now, but I spent my youth in a debugger. The reason why I am ashamed now is this: in the morning, when I came to work, I found the cursor in the same position I had left the previous evening, because I was so tired that I could not continue debugging. Over the years, I have mastered the development through testing, and now I do it in a very disciplined way. I will give an example. In the application that we are developing now with the client, we probably have millions of lambda. This is a project about Big Data. We run parallel code that constantly shoots a bunch of lambdas. As you understand, the system does not always work as expected. And yet, when this happens, we usually find out about it because the unit test does not work. Then my client puts a breakpoint in the test where the error occurred, and debugs this test. Due to this, we are debugging not huge arrays of code, but separate modules.

    In other words, often the inability to debug the code is not a consequence of the qualities of a particular technology, but of the insufficient modularity of the code. The more modularity, the more controllable the code becomes. This is true both with respect to parallel computing and lambda and with respect to asynchrony. If we have several threads and it is difficult for us to debug them, this is quite expected, since multithreading is inherently non-deterministic. In essence, you open the cages at the zoo, and then try to figure out where to run. Your task is to tame this zoo, to gain control over it, and for this you need to make the code modular. The same goes for lambda. When people ask me how I debug lambdas, I answer: no way. You do not need a lambda, consisting of 30 lines of code. You need a separate function,

    Asynchrony is beautiful, and this is why. You make a call, and specify what to perform when the call is completed. But this next stage does not necessarily have to be called from within an asynchronous call. The following method can be called separately for debugging and testing. And the asynchronous method itself is not necessary to perform, instead you can have a stub that simply checks whether the call is made or not. I repeat: the inability to debug the code is most often not the result of the properties of a particular technology, but indicates an insufficient modularity of the code. And the further I work with many technologies at the same time, the more I become convinced of this and the more I find ways of active debugging, which allow us not to lose my mind.

    - That is not technology. Perhaps we should change our way of thinking about such a code? Rather, it is not only in thought, but in their combination with technology. For example, the Reactive Streams specification, implementation in the Spring Reactor project, or CQRS and event sourcing. Have you ever met people who actually use CQRS?

    - Yes, of course, it is used by many. But, going back to what you said about changing the way of thinking - I completely agree with that. At one time I was not familiar with Angular 1, and the client, whom I then worked with, asked me to look at this framework. In Angular, you can write the “$” symbol and access the global namespace. When I found out about this, my first reaction was: “What nonsense. So you can not do. I say this not to praise myself, but to the word about the raised theme of the way of thinking. Because then I started to google, and was completely amazed to learn that everyone is doing it. I was convinced that I would never write like that. After a few months or years - I don’t remember exactly - Angular 2 came out, in which the developers admitted that this thing was really stupid and had to be got rid of.

    We, as developers, are happy to learn how to work with new libraries and new technologies. But when we do it, it is not enough to study the new syntax and the new API - it is necessary to assimilate the corresponding way of thinking. What should be a good code? What anti-patterns should be avoided? These technologies are created by talented people, but remember that they are still people. And people make mistakes. That is why in Java - and in any language - there are deprecated-methods. Therefore, the time has passed Angular 1 - we have found more perfect ways to solve problems. In general, when you master a new technology, it should be done pragmatically and with a share of healthy skepticism.

    Returning to your other question - event-driven systems (event-driven systems), in my opinion, are the future of programming. And they combine well with asynchrony, as well as with micro services. Many of these technologies, applications, APIs, and libraries have existed for a considerable number of years, but now there is a real boom around them. Thanks to their interaction, our perception of how applications will be developed in the future is changing. If you look back in time, you will see that approximately every 5-10 years, our idea of ​​what the application architecture should be is changing. From desktop applications, we moved to server and web applications, then to mobile applications, and now we are thinking about microservices and event-oriented systems. I think, that today we are in the next stage of transition. When people ask me if the future belongs to functional programming, I answer - no, it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. whether the future belongs to functional programming, I answer - no, it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. whether the future belongs to functional programming, I answer - no, it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. Reactivity is the composition of functions and lazy calculations applied to the data stream. So, in my opinion, reactive programming did not fall from the sky, but is a logical continuation of the functional. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. asynchronous capability. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use. asynchronous capability. Each of these concepts alone is perhaps curious, but together they lead to fundamental changes in the architecture of applications in the future as they change the tools and techniques that we use.



    - Well, that is, these changes are not important separately, but together.

    You are one of the Java Champions, previously there were Microsoft MVPs, and now you are writing in JavaScript, so you can see three different ecosystems well. My question is: does the Java ecosystem develop in general or not, and how does it look compared to other worlds? Can we compare it with .NET, JavaScript or something else?


    - Much of what Java is only moving for now is present in .NET for some time. C # was at first a slightly improved version of Java, and we said that C # repeats everything after it. But today the situation is reversed. Lambdas appeared in Java a few years later than LINQ was added in C #, which allows you to write lambdas and that have an action and a function (what they call Func). Similarly, asynchrony appeared in C # several years earlier than the promise to add asynchrony in Java. True, I must say that in Java since 2014 there is a CompletableFuture. But asynchrony appeared in C # long before that.

    The same can be said about Java and JavaScript. I know that the phrase “we have a lot to learn from JavaScript” can cause fright, but JavaScript programmers have seen a lot and know how much a pound is hard. They have the concept of “callback hell”, when callbacks do not work well with each other, it becomes extremely difficult to handle exceptions and it turns out to be very difficult to build on callback functions that must be performed by asynchronous calls. In the end, in the JavaScript world, a solution was found in the form of Promises (promises), which are analogous to CompletableFutures in Java. And yet it must be admitted: the beauty of our world is that there is no single correct method for all times. One of the advantages of Promises is that composition of functions is possible there. Another advantage is that they can deal with exceptions and you can skip data through Promises. However, imagine that in your code, among other things, there are several levels of exceptions. It can become quite complex, and at a certain point you will realize that it would have looked much better if it had been written in an imperative style, and not functional. That is why async and await have been added to JavaScript. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. However, imagine that in your code, among other things, there are several levels of exceptions. It can become quite complex, and at a certain point you will realize that it would have looked much better if it had been written in an imperative style, and not functional. That is why async and await have been added to JavaScript. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. However, imagine that in your code, among other things, there are several levels of exceptions. It can become quite complex, and at a certain point you will realize that it would have looked much better if it had been written in an imperative style, and not functional. That is why async and await have been added to JavaScript. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. It can become quite complex, and at a certain point you will realize that it would have looked much better if it had been written in an imperative style, and not functional. That is why async and await have been added to JavaScript. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. It can become quite complex, and at a certain point you will realize that it would have looked much better if it had been written in an imperative style, and not functional. That is why async and await have been added to JavaScript. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin. In essence, they are imperative shells for Promise. You can write imperative code, and when a call to a function is made in it, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that is exactly what coroutines do in Kotlin.

    If we compare all these languages, it will become clear that I am a polyglot for purely selfish reasons. In a sense, programming in different languages ​​is similar to traveling to different countries. I love being in Russia, Estonia, India, different parts of the United States, because during these trips I meet different cultures and see different practices, different ways that people solve the same problems. Therefore, I always tell developers that one of the most important qualities of a good programmer is the understanding of the fact that there is no one correct way to write code. Of course, some methods have advantages in some situations, others - disadvantages, and we need to choose what is best for us. If we compare async in C #, async / await and Promises in JavaScript and coroutines in Kotlin, we will see that in some situations it is better to use the functional style, in others - imperative, but asynchrony can be realized with that and with a different approach. It seems to me extremely curious. Java in the field of these innovations lags behind other languages. But I believe that Java is changing, not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create advanced applications. I think that a language that no longer meets the requirements of a business becomes obsolete and goes out of use. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. but asynchrony can be realized with a different approach. It seems to me extremely curious. Java in the field of these innovations lags behind other languages. But I believe that Java is changing, not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create advanced applications. I think that a language that no longer meets the requirements of a business becomes obsolete and goes out of use. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. but asynchrony can be realized with a different approach. It seems to me extremely curious. Java in the field of these innovations lags behind other languages. But I believe that Java is changing, not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create advanced applications. I think that a language that no longer meets the requirements of a business becomes obsolete and goes out of use. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. that Java is changing, not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create advanced applications. I think that a language that no longer meets the requirements of a business becomes obsolete and goes out of use. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. that Java is changing, not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create advanced applications. I think that a language that no longer meets the requirements of a business becomes obsolete and goes out of use. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time. Java must evolve to survive. And I'm not too concerned that Java lags behind some other languages ​​— it still has time.

    I really appreciate another aspect of Java. Let's take a look at the lambda. I usually say that Java was late for the holiday, but brought a great dessert. Lambda in Java appeared very late, but their implementation with the help of invokedynamic, in my opinion, is amazing. It improves the use of lambda in all languages ​​that run on the JVM. Java is not a language innovator, but it is an innovator in the search for better ways to implement it. And, in my opinion, this is a very significant advantage. I think in the future other languages ​​will continue to outpace Java in terms of the availability of new features, but Java will look for better, more practical and high-performance ways to implement these technologies on the JVM. And after all it also is necessary for us. We do not need new features just for beauty, we need a code that meets our requirements.

    - Good. Now, probably, the last question from me, and it will deal with the topic of multilingualism. We live in a very complex world, you can no longer write anything for 5 lines of assembler. A few lines of assembler is an unattainable ideal. For centuries, languages ​​with a flexible syntax have existed - say, Common Lisp, where you can create your own JavaScript using the Meta Object Protocol, and today there are cool ways to write DSL like Kotlin or JetBrains MPS, using GraalVM you can soon write a Java compiler and so on. If you wish, you can write a project in twenty programming languages ​​at once. How is it possible to control complexity in a multilingual world with dynamic and changing rules every day?

    - This is a very important question. I always say that you should try to avoid the fascination with technology. By fascination, I mean the feeling when you see something new and it seems to you that you should definitely use it in your application right now. Here we, as developers, need to work on ourselves. First, we should not learn a new technology just because it is needed on the current project. Secondly, we should not apply everything that we have learned. I say this because many of the things that I have learned, I do not apply for six or seven years. I studied these technologies not for direct application, but to have an idea about their existence. Certain wisdom is needed to decide that this technology is not yet needed in this project. Difficulty arises when we pile together different components, not fully understanding their virtues. For example, when I come to the client's site, I always ask: why do you use it? Moreover, why are you trying to solve this problem? Why is it just as important as many other problems that you solve? Therefore, I recommend that developers take the time to figure out why their technology was created. I often ask them: can you say when and under what conditions you would use Angular, and when - React? Sometimes people can’t answer, but they use React in their project. My question in this case is, do you really need it here? I don’t say that it is not needed, but we often don’t know why we use it and just do it because someone said that it’s necessary. Difficulty arises when we use technology, not fully understanding their purpose. You can fight it by studying these technologies and comparing them with each other, assessing the advantages and disadvantages. If a developer cannot give me five aspects that appeal to him in a certain tool, and five that repel him, it means that he has not studied this tool enough. When we see each tool from different sides and get an unbiased idea of ​​it, we can successfully use it.

    The last thing I want to say about complexity. When you evaluate technology, get rid of your emotions and desires. In our discussions, someone usually says: I like this or that technology, I want to use it. I recommend that teams draw a table and list in it the capabilities that your application needs: testability, scalability, asynchrony, security, and so on, depending on the application. Then in front of each write a number from 1 to 10, where 10 means “extremely important”, and 1 means “indifferent.” After that, for each opportunity write a list of existing technologies and for each enter a number from 1 to 10, where 1 means "does not support", and 10 means "it performs excellently". Finally, count the points and see which of the existing technologies will earn the most points. Now your emotions are not involved in the assessment, and this allows you to more intelligently choose the necessary technology. You are making this assessment not on a global scale and not even on the scale of a company; you make it based on the needs of the current project. Therefore, I do not like the statements of some companies that they have Angular, React or Java is a common standard. I always ask in such cases: for what exactly? We do not even know what we are going to do. This is the same as saying: our entire company will travel exclusively on bicycles. This is meaningless. It all depends on what we are doing, and this is the question that needs to be answered first. In general, I believe that the complexity can be significantly reduced if we correctly understand what we are doing and why we use this or that technology; if you get rid of emotions and desires and sum up the resources and needs; if we correctly assess the comparability of our solutions.

    Finally, the last thing I would like to mention is minimalism. I always tell teams to add things to the project easily, removing them from the project is extremely difficult. The cost of removal is ten times the cost of adding. Therefore, when adding something you need to be sure that you are really cutting costs not only right now, but also in the long term. And you need, among other things, to think about reversibility. We are talking about the possibility to roll back the decisions made about the architecture of the application. If the solution is reversible, then tomorrow you can refuse it, and in this case you should not think about it for too long. If the solution is poorly reversible, then it is necessary to spend more time on it, to collect more data. If we take into account the degree of reversibility of our decisions, then we thereby significantly contribute to reducing the complexity of applications. In general, I believe that we must in many aspects overcome our passion for technology in order to reduce the degree of complexity.

    - Thanks, this is a great answer. At our Joker conference, you will also be talking about complexity , so it will be possible to continue the discussion there.

    - Yes, I will be waiting for this with enthusiasm.


    Also popular now: