Інтерв'ю Скотта Мейерса про сьогодення і майбутнє C++

Скотт Мейерс — один з найбільш відомих і визнаних експертів з C++, автор серії книг «Ефективне використання C++», які читав майже кожен професійний розробник на C++ і які зробили помітний вплив на всю екосистему і якість використання мови.

Особисто я став майже його фанатом ще студентом, коли на початку 2000-х читав статті Скотта, що лежать в основі його книг (самі книги на той момент в Росії ще не були переведені, а англійські з Амазона у мене, як бідного студента, грошей не було).

Тому, коли він деякий час тому приїхав в Яндекс, щоб провести тренінг для наших розробників, я не міг не скористатися цим шансом, щоб поговорити з ним. Розмова була про те, яким він бачить майбутнє C++ і програмування взагалі, як відрізняються розробники в різних країнах і в різних індустріях, і про нього самого.





Оригінал для тих, хто віддає перевагу читати по-англійськиIf you had to name one or two changes in the C++11/14 Standard that are the most important, which ones would you choose?

I think that for most programmers, on a daily basis, it's going to be for auto declaring variables and also, probably, lambda expressions. Those are the things that are most visible to people.

I think that, actually, more fundamental improvement is the support for concurrency, which didn't exist at all in C++98. And that particular new feature is not terribly visible to programmers in a lot of ways, because it mostly affected compiler writers, but, in terms of the most widespread impact on people, it's probably going to be the one that makes the most difference. Move semantics is obviously very important as well but I think the concurrency is a little more fundamental from that perspective.

Even though concurrency was implemented in libraries before?

Concurrency was implemented in libraries before the problem was that the libraries didn't have a foundation in the compiler that they could build on so there was never any guarantee that things were actually going to work. For example, there were optimisations компілятори could perform that could have broken concurrent programs. And so now compiler writers know what they can do and what they cannot do and what they have to do. That makes it possible to build libraries that will reliably work.

The same question, but about the most controversial changes. Is there something that can have a negative effect?

A couple of things come to mind. Both of them based on ideas that I think are reasonable ideas. Then the question becomes — were they executed properly? One of them is what's usually referred to as uniform initialisation. And the idea was that we would have a single syntax for initialising everything. And that particular promise has not been achieved because є re some ambiguities in certain cases and there are situations where you can't use brace initialisation when you have to use a different form. So I think there has been some controversy there about whether that should have been implemented in some particular way than it was.

And the other thing that comes to mind is sync and futures, which is a great idea. It simply says, 'I wan to run this thing asynchronously', and you don't have to think about it at all. But then they did some interesting things regarding specification of the behaviour of futures that come from async and there's been a lot of controversy in the committee about whether they should change that whether or they should replace it. And it's my impression that there is a pretty reasonable chance that starting in C++17 there will be some new features which will probably replace that.

So you've mentioned C++ Standards Committee. What do you think about it? Does it do a good job? Or is it too slow or conservative in some respect?

The first thing I am going to say about Standardisation Committee — and i'm not on the Standardisation Committee, I should clarify this — is that they have a very difficult job. The material is extremely technically demanding. So I have a tremendous amount of respect for the people on the Committee and for the work that they do, because it is not easy work. And even the simplest things require an enormous amount of effort.

Having said that, I think that it shows sometimes that this is definitely a committee that is designing a language. As opposed to a single person or a small group of people with a clear vision for where the language wants to go. And that shows up — for example, we have three different ways for specifying alignment, but we have a relatively impoverished Standard Library.

So I think that committee overall does a reasonable job. I wish that they did things in some ways a little bit differently, and I think that probably they wish in some ways that I was maybe a member of the committee trying to get those things done. So that's my feeling about the Committee.

Do you think that if there were one person — I don't know — Bjarne — or someone esle who would be making all of the decisions — like W3C — it would be better, or is the Committee a good compromise?

I think that Committee is a reasonable way to get a lot of parties together. To be honest, I don't think that Bjarne has any kind of desire to be the person who makes all of the decisions. The advantage of a person who makes all of the decisions is that they can have a clear vision and then can really implement that clear vision. And there's no one who plays that role in C++ and I don't know of anybody who could play that role in C++.

It's a little bit different from lots of other languages because it's very crossplatform — you're so dealing with lots and lots of different operating systems. Lots of compiler vendors. There is not a lot of other languages for which there would be, say, four major компілятори that run on different platforms. And also, just a range of applications. Especially when you start thinking about the impact of C++ on embedded systems where it is quite an important programming language — they really have different views of the world in some cases.

So it would be nice if there were, like I said, a sort of a clear vision via a single person, but I don't think that's going to be happening in C++.

What would you most likely to advise be changed in the language if you had a chance to go back to 95? Were there any wrong decisions in the C++ history? What would you change in the language if you could?

I don't have specific things I would change. One of the things I find about the problematic language is that it's not terribly consistent and it has lots of special cases. This is something that is particularly important to me, because my job is to explain the language to other people. And it makes my job more complicated.

But I also think that if the language were more consistent and did not have quite as many special cases, then it would be easier for programmers to get their work done, because they would not be stumbling into problems from time to time.

Having said that, the language does a really good job of acting as a tool for professional developers to solve really difficult problems. So we have to view it as a very significant success. Clearly, the Committee has done a pretty good job of getting things right for a lot of programmers.

Is there any chance that some day a version of C++ with little or no backward compatibility will be released? Something similar to Python 3 or Perl 6, for example.

I think that the chance of any decision that would break backward compatibility is virtually zero. Because I think that one of the great strengths of C++ is that it does have tremendous backward compatibility. So there are billions of lines of code, some of it was written 20 or 25 years ago. And it would be a really significant departure for the community to decide that they don't want to preserve peoples' investment. So I don't ever expect that to happen.

C++ is sometimes criticised for being a very and discrete abstract, almost Spartan, Standard Library. It doesn't have a variety that other modern languages have. Do you think this is the right approach?

I think everybody agrees that the Standard Library is too small and it needs to be a lot larger. I think that historically we got to where we are because people focused on the language and they said 'once you have a suitable language then you can build great libraries'. And we've been waiting 20 years for people to build great libraries and the thing is they have build great libraries — there are some really nice libraries out there.

There aren't as many as we would like. One of the reasons for that is, unlike, for example, Java або C#, basically, there's no corporate sponsor behind this language and it's a crossplatform language. So you basically are looking for volunteers to put together libraries and then make them available for everybody else. And a fair number of people have done that but they're just sort of spread around.

The Standardisation Committee now has started to taking a much more serious look at this, and so I think that there is a consorted effort to try to 1) get more libraries developed and 2) take the existing libraries in existing places like Boost, and at Microsoft, and at Facebook, and at Adobe and lots of other places and bring them together under a license that everybody can live with and put them in place where everybody can find them. There is a definite effort being expended to make that happen. But there's no question that the Standard Libraries are much smaller and have fewer features than we would prefer.

Actually, two years ago I talked to Stepanov, the creator of the original standard library. He thinks that it should be small and atomic, and everything else should be in a different library, not in the language itself. Do you think that this should be the case?

I believe that the standard library should be larger. I think it should offer some really basic functionality. For example, it's 2014. There is no concept in a standard library of putting anything on a screen anywhere. There is no concept of graphics. That's silly. There is no concept of the Internet. There is no concept of the URL. There is no concept of the URI. For that matter, there is no concept really of a file system. This role in my mind, obvious places a standard library would really be helpful. And, incidentally, there are also places where standardization can be actively working to address those particular issues. But i'm inclined to say that if there is a common need that many developers are going to have, there is just a lot of mileage to be gained by putting it in a standard form, so everybody knows how it works.

Many people are asking for some standard repository like in some other languages. What do you think about this? Is there a need for it and how soon the C++ community can make it possible?

It would certainly be convenient. Whether it's going to ultimately take place and, if so, what form it's going to take, I don't know. But that would be consistent with this idea of going out to people that already have got the existing libraries. And then say, ok, great, now we know where all the libraries are, if we can unify them under some kind of a common acceptable license, now we can start putting them in one location, where everybody can look them up and search for them and things like that. So I think that the foundation is being laid for to make that possible, whether it would take place remains to be seen.

How far do you think this future is from now? A few years?

I'd say probably… I think, it's going to be in a better situation probably next 2-3 years. But we, sort of, have to see. The thing is, there are a large number of libraries that address lots of different areas. This is really part of Standardization Committee. So it's a matter now of finding a way to unify them, so people could go to a single location and look for them. If you look at two or three years ago, there was no single website where people could go for information about standard C++, and now there is, largely thanks to the work of the Committee. This is the place to go, so this project is he's been working on. So i'm optimistic.

How do you think the decision should be made about what language to use? IDK, many people, Yandex may think that C++ is terrible, actually, but they're still using it, and it's the main language used in our development. And i've heard many people from Google saying the same thing. And still they are using C++. So how can we choose between, IDK, C++ and Java. Do you think that C++ still has a great future or will everybody be using managed languages in ten years?

Well, let me answer the last question first actually. It's interesting, because ten years ago everybody was saying, in ten years everyone will be using managed languages. And managed languages are very important, but certainly it's not the case that everybody is using them. So I don't think that in ten years everyone will be using managed languages. I think that C++ is going to remain an extremely important language for production use. Simply because if your goal is to get the maximum of performance out of the machine. If that is what is most important to you. I think that even these days the primary competitors are C and C++. Those are pretty much your choices. And C++ is just a much more expressive language. I have to say that i'm not a C programmer. I've never really been a C programmer. But I think that just a simple notion of destructors is so unbelievably powerful, that as a C programmer I would consider moving to C++ just so I could compile and get destructors. And, obviously, there is a lot more? to it than that. In terms of your original question about choosing between various languages, you know, fundamentally, to me that's a management or a higher level engineering decision. You have to take into account, what do we want to accomplish, what's the goal of the software, who are the people that we have available, what existing infrastructure do we have. And you're trying to optimize for a lot of things simultaneously. I don't offer advice on that question, my job is to understand C++ and help engineers use it better. My job is not to try to tell people whether they should use it or should not use it.

Do you think that it's bad for C++ that it's rarely used on mobile devices? All these new things use managed languages. Java for Android, Objective C Swift and for iOS. What do you think about that and couldn't C++ be used more efficiently for these applications.

I don't follow mobile market that closely. It's my understanding that the mobile platforms originally are set OK, everything will be programmed only in Java. And they said, well, now we're going to have a back door to let you program in C++. And then they said only Objective C. And then, OK, there is a virus, you can use C++. So I think there is a demand, on the part of the people programming those platforms, to have native languages. And, so from that perspective, I think actually the percentage of programs running C++ on mobile platforms has actually increased. Because developers are insisting on that. The other thing, though, is, I think, an awful lot of mobile stuff, essentially axis of front-end, took computation place in the cloud. And I think, if you're thinking mobile, you must take into account what's running on the servers which are servicing these mobile devices. And C++ is certainly very strong in server farms where you are trying to get the maximum possible dollars out of the servers that you have available. So, I think, it's probably going to remain stronger in servers than in the mobile devices. But there certainly no reason it can't be running on mobile devices.


Назвіть два або три найважливіших зміни в C++11/14

Якщо говорити про те, з чим більшість програмістів стикаються щодня, то це автоматичне оголошення змінних, а також, ймовірно, лямбда-вирази. Це два найпомітніших зміни.

Особисто я вважаю найбільш фундаментальним поліпшенням підтримку паралелізму, якій в З++ не було зовсім. Ця фіча не так кидається в очі програмістам, хіба що творцям компіляторів. Але якщо говорити про вплив на людей в загальному, то, дуже ймовірно, що саме ця фіча надасть максимальне вплив. Очевидно, що семантика переносу також вкрай важлива, але з цієї точки зору паралелізм здається трішки більш істотним.

А які дві зміни були самими спірними або шкідливими?

Пара речей приходить в голову. Обидві засновані на ідеях, які я вважаю цілком розумними. Але потім виникає питання, а чи правильно вони застосовувалися? Перше — це те, що зазвичай називають універсальною ініціалізацією. Її ідея полягала в тому, що у нас буде єдиний синтаксис для ініціалізації всього підряд. Досягти цього не вдалося, так як в деяких випадках була невизначеність, були ситуації, в яких не можна використовувати списковую ініціалізацію, потрібно використовувати іншу форму. Тобто, схоже, були деякі розбіжності щодо того, чи варто було цю фічу імплементувати саме так.

На розум приходять ще async і futures. Насправді, це прекрасна ідея. Просто кажеш, що хочеш запустити що-небудь асинхронно, і думати про це вже не потрібно. Але в тому, що стосується специфікацій поведінки ф'ючерсів, виходять з async, було зроблено багато цікавого. Всередині комітету було багато суперечок, чи потрібно це виправляти або чимось замінити. Як мені здається, є всі шанси, що починаючи з С++17 будуть впроваджуватися нові функції, покликані замінити.

Комітет з стандартизації досить ефективно виконує свою роботу?

Перше, що я хотів би сказати про Комітет з стандартизації (а я в ньому перебуваю, це потрібно позначити відразу), — перед ними стоїть дуже непросте завдання. Матеріал вимагає надзвичайно глибоких технічних знань. Я відчуваю величезну повагу до тих, хто в цьому комітеті складається. Робота, яку вони роблять, дуже непроста, навіть дрібниці вимагають величезних зусиль.

З іншого боку, іноді стає очевидно, що розробкою мови займається комітет, а не одна особа або невелика група з чітким уявленням про те, в яку сторону має розвиватися мова. І це дійсно помітно. Наприклад, є три способи визначення вирівнювання, при цьому стандартна бібліотека дуже мізерна.
В цілому, комітет, по-моєму, цілком справляється зі своєю роботою. Мені б, звичайно, хотілося, щоб вони робили деякі речі інакше. А вони, можливо, хотіли б, щоб я якимось чином увійшов до складу комітету, взяв участь у роботі. Ось таке у мене ставлення до комітету.

Можливо, було б краще, якщо б був один чоловік, який відповідає за ключові рішення?

На мій погляд, комітет — це цілком розумний спосіб зібрати разом відразу кілька сторін. Відверто кажучи, я не впевнений, що Бйорн взагалі хотів би стати тим, хто приймає рішення. Перевага такої людини в тому, що у нього є чітке бачення, яке можна імплементувати. В C++ ніхто не взяв на себе цю роль, і я не знаю людини, який міг би це зробити.

Тут є невелика різниця в порівнянні з безліччю інших мов: так як C++, що працює на величезній кількості платформ, доводиться мати справу з величезною кількістю операційних систем, з безліччю виробників компіляторів. Не так вже багато мов, під які є чотири основних компілятора, що працюють на різних платформах. Не варто забувати і про широкий спектр застосувань. Особливо коли починаєш замислюватися про те, який вплив C++ справив на вбудовувані системи. Там це дійсно важливий мову, а погляди на світ у хлопців з цієї індустрії в багатьох випадках досить сильно відрізняються від звичних.
В цілому, було б непогано, щоб, як я вже говорив, у одного чоловіка було чітке бачення, яке він міг би транслювати. Але навряд чи таке можливо для C++.

чи Є шанс, що в якійсь версії З++ не буде зворотної сумісності, як було з деякими іншими мовами?

Думаю, вірогідність того, що буде прийнято рішення, ламає зворотну сумісність, практично дорівнює нулю. Мені здається, одна з найсильніших сторін C++ як раз у відмінній зворотної сумісності. Написані мільярди рядків коду, що з цього з'явилося 20-25 років тому. Рішення не зберігати привнесене іншими було б занадто складним кроком для спільноти. Так що я не вірю, що це коли-небудь відбудеться.

C++ часто критикують за надто коротку і абстрактну, майже спартанську стандартну бібліотеку. Немає такого розмаїття, як у деяких сучасних мовах. Ви вважаєте такий підхід правильним?

Я впевнений, всі погодяться, що стандартна бібліотека занадто мала і вимагає розширення. Мабуть, так склалося історично, з-за того, що люди занадто сильно концентрувалися мовою. Вони вважали, що, як тільки вдасться створити відповідну мову, можна буде створювати чудові бібліотеки. І ми чекаємо цих бібліотек вже 20 років. Насправді такі бібліотеки є, в тому числі дуже непогані. Просто їх не так багато, як хотілося б. Одна з причин такого сильного відмінності C++ від, наприклад, Java або C#, полягає у відсутності корпоративного спонсора, що стоїть за мовою. Справа в кроссплатформенности. Все, що у нас є, — це добровольці, які створюють бібліотеки і викладають їх в загальний доступ. Цим займалося і займається досить багато людей, просто все це трохи розсіюється.
Комітет з стандартизації зараз став набагато пильніше до цього придивлятися. Зараз, як мені видається, різні люди докладають узгоджені зусилля, намагаючись 1) розробляти більше бібліотек; 2) зібрати існуючі в розрізненому вигляді бібліотеки (такі як Boost, бібліотеки Microsoft, Facebook, Adobe) під єдиною влаштовує всіх ліцензією в якомусь одному місці, де всі могли б їх знайти. На реалізацію цих проектів витрачається все більше зусиль. Але немає ніяких сумнівів, що стандартна бібліотека занадто мала і пропонує набагато менше функцій, ніж хотілося б.

Автори STL вважали, що стандартна бібліотека повинна бути маленькою і атомарної. Це одна з причин того, що в ній немає деяких базових для нашого часу речей. Що ви думаєте про це?

Я впевнений, що стандартна бібліотека повинна бути більше, що вона повинна надавати базову функціональність. На дворі 2014 рік, а в стандартній бібліотеці немає концепції виведення чого-небудь на екран. Там немає поняття графіки — це просто смішно. Немає поняття інтернету, немає поняття URL, URI. З цієї причини там за великим рахунком немає поняття файлової системи. Як мені здається, в цій ролі стандартна бібліотека була б досить корисною. До речі, є ще кілька місць, де стандартизація могла б активно працювати на усунення саме цих проблем. Я маю на увазі, що є загальна потреба, з якою зіткнеться безліч розробників. Просто пройде ще чимало часу, поки все це прийде до стандартної формі і всім буде зрозуміло, як воно працює.

Потрібний чи С++ єдиний репозиторій, і чи з'явиться він коли-небудь?

Це безумовно буде зручно. Я не знаю, чи станеться це коли-небудь, в якій формі буде реалізовано. Але це цілком відповідає ідеї зближення з людьми, у яких вже є готові бібліотеки. Потім можна буде сказати: окей, чудово, тепер ми знаємо, де лежать усі бібліотеки. І якщо ми зможемо об'єднати їх під яку-небудь підтримуваної усіма ліцензією, то зможемо складати в одному місці, де всі їх побачать, зможуть шукати за ним і т. п. Так що, на мій погляд, фундамент для цього вже закладається, але станеться це? Поживемо — побачимо.

Є багато людей, яким доводиться використовувати C++ не дивлячись на те, що вони його не люблять. Як ви вважаєте, за якими принципами має вибиратися мова для великих проектів?

Мабуть, я спочатку відповім на останнє запитання. Це забавно, адже десять років тому всі так і казали: " от пройде десяток років і всі перейдуть на керовані мови. І вони дійсно дуже важливі, але користуються ними далеко не всі. Мені здається, C++ залишиться вкрай важливим мовою в продакшені. Просто тому, що основна мета тут — домогтися від машини максимальної продуктивності. Якщо для вас це важливо, то головними конкурентами всі так само залишаються C і C++. А C++ просто трохи більш виразний мову. Слід застерегти, що я не C-розробник і ніколи їм насправді не був. Але якби я ним був, то одного згадування деструкторів вистачило б для того, щоб я задумався про перехід на C++. Просто заради можливості компілювати і отримувати деструктори. Звичайно, це лише мала дещиця.

Повертаючись до вашого питання про вибір між мовами: по мені, це рішення має прийматися менеджерами або старшими інженерами. Потрібно брати до уваги, які цілі ви ставите, яка мета, які співробітники є у вашому розпорядженні, яка інфраструктура вже збудована. І всі ці речі потрібно намагатися оптимізувати одночасно. Я не даю ніяких порад на цей рахунок, моя робота — розуміти C++ і допомагати розробникам ефективніше його використовувати. Розказувати людям про те, чи варто їм застосовувати C++, в мої завдання не входить.

чи Погано, що C++ рідко використовується на мобільних пристроях? Всі вони як і раніше працюють на керованих мовами: Java — Android, Objective-C і Swift — на iOS. Не пора більш активно застосовувати C++ в цій галузі?

Я не дуже пильно стежу за мобільним ринком. Наскільки я розумію, коли з'явився Android, всім оголосили: окей, тепер усім слід писати на Java. А потім сказали: ну, тепер є бекдор, завдяки якому можна писати на C++. І те ж саме з Objective-C. А потім — знову бекдор, через який можна користуватися C++. Так що, мені здається, можливість використовувати рідні мови — це потреба розробників, які пишуть під мобільні платформи. І якщо подивитися з цієї точки зору, кількість програм на C++ під мобільні платформи не так вже мало.

Розробники наполягають на цьому. Крім того, мені здається, величезна частина мобільного коду, зокрема кістяк фронтенда, тепер працює в хмарах. Якщо говорити про мобільних сервісах, потрібно брати до уваги і те, що крутиться у них на серверах, обслуговує ці мобільні пристрої. А позиції C++, безумовно, дуже сильні на серверних фермах — там, де намагаються домогтися максимального прибутку від наявних серверів. Так що C++, швидше за все, як і раніше буде використовуватися в серверах, а не в мобільних пристроях. Але серйозної причини, по якій його можна було б використовувати і там, немає.

Сьогодні ви один з найвідоміших експертів по C++. Як ви почали програмувати на цій мові?

В деякому сенсі вибір був зроблений без мене. Я почав програмувати дуже давно, в 1972 році. Моєю першою мовою був Basic, в 1972 році він був досить поширений. Але в 1985 році я поступив в аспірантуру, щоб отримати PhD з інформатики. В обов'язки аспіранта входила участь у деяких курсах в якості асистента викладача. Природно, я був асистентом на курсі розробки ПО. Професор, який вів цей курс, сказав, що хоче використовувати якийсь нормальний мову програмування. І він вибрав C++, а мені через пару років довелося його вивчити. Так що я не вибирав C++, я просто працював на курсі, де C++ був основною мовою. Ось так я і став на ньому програмувати.

Але все ж ви вирішили пов'язати своє життя саме з цією мовою.

Чесно кажучи, це була випадковість. Спочатку я вивчив C++, а потім мені надійшла пропозиція від компанії, якій був потрібен курс по C++ для навчання корпоративних клієнтів. Це було цікаве пропозицію. Я був аспірантом, роботи було багато, а грошей — не дуже. А вони просто сказали: давай ти запишеш все те, що вже знаєш, а ми тобі за це заплатимо купу грошей. Я відповів, що це звучить дуже привабливо. Так я і став займатися C++. Потім я почав вести заняття, написав свою першу книгу Effective C++, виявилася досить популярною. Забавно: коли році в 1991-му дружина запитала, чи довго я буду цим займатися, я відповів, що це ж мова програмування, вони зазвичай живуть не так довго, ну максимум п'ять років. Минуло 25 років, а ми як і раніше цим займаємося. Ось така випадковість.

Як ви перейшли від статей до книг? Чи є різниця між створенням статей та створенням книги?

Відмінностей кілька. По-перше, за своєю природою книга охоплює більш широкий матеріал, по-друге, треба мати більш загальне бачення проблеми, яку ви збираєтеся вирішити. І нарешті, потрібно більше простору, в якому ви будете діяти. З іншого боку, якщо у вас скромний задум, то і книжку писати не потрібно, достатньо статті. Так що все залежить від того, багато чи ви хочете сказати. Крім того, коли ви пишете статтю в журнал, вам потрібно лише ненадовго утримати увагу читача. Для цього є різні техніки: ви можете провокувати читача, викликати в нього бажання сперечатися. Це як якщо б ви розговорилися з людиною, що стоїть поруч з вами в черзі в супермаркеті. Це коротка розмова, і тут вам доступний зовсім невеликий набір прийомів. Книга передбачає більш тривалий контакт з читачем. Я б порівняв це розмові з сусідом в літаку. Чи ви захотіли б сидіти поруч з тим, хто вам суперечить, сперечається з вами і провокує протягом шестигодинного польоту. Мені навіть довелося переписати мою другу книгу — я відчув, що вона дуже схожа на журнальну статтю. Прочитавши п'ятдесят сторінок такого, починаєш божеволіти, ненавидіти того, хто все це написав. Так що мені в голову приходять саме дві речі: більший охоплення і тон розповіді.

чи Є різниця між аудиторіями в різних містах? Які типи аудиторій вам зустрічалися?

Культурні відмінності між різними країнами помітні. Де-то зовсім не бояться сперечатися з доповідачем, задавати питання. Я зустрічав таке в США, Англії, Німеччини. Там люди не соромляться сказати: стривайте, тут якась помилка. І доводиться приводити доводи, обґрунтування. В інших країнах люди намагаються не створювати проблем, не хоче вас образити. До речі, з мого досвіду, через це теж можна прорватися, якщо намагатися активно залучати людей. Особливо легко це вдається, якщо ви проводите з ними більше двох-трьох днів — до вас звикають. На мої виступи слухачі найчастіше приходять за власним бажанням. Коли до них вдається достукатися, виявляється, що вони дуже розумні і думки у них цікаві. Так що я не бачу особливих відмінностей між розробниками в тому, як вони думають, сприймають матеріал, задають питання. Я дуже радий, що куди б я не приїхав, мені доводиться спілкуватися з розумними людьми, які працюють з дійсно цікавими завданнями. Намагатися встигати за ними — це для мене одночасно виклик і задоволення.

А ви самі пишете зараз код?

Ні, не дуже багато. Я багато років тому вирішив, що я не розробник. Я колись розробляв, написав багато коду, коли навчався в аспірантурі. Раніше я соромився цього: розповідати всім про програмування, хоча сам уже не практикую. Але це вже не моя робота. Мені здається, що завдання розробників — виробляти продукт. Для цього необхідно опанувати інструментами, API і в результаті зробити щось продуктивне. Вони занадто зайняті, щоб відслідковувати все, що відбувається у світі розробки та C++. А ось моє завдання — стежити за всім, що відбувається, а потім перетворювати це в статті, книги, виступи, щоб розробники могли сприйняти все це у відносно короткий термін. Так що я більше не розробник, я не приділяю програмування багато часу, але я перестав цього соромитися. Я вирішив, що моя робота теж цілком має сенс.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.