Интервью с яковом файном.

— живет и работает в США уже более 20 лет, поэтому вопросы изучения английского языка ему близки.

В сети Якова многие знают под ником Будам и по его интересным подкастам про США (очень советую послушать, найдёте много интересного). Также хотела отметить, что он автор нескольких книг по программированию, регулярно проводит тренинги и мастер-классы. И все это на английском языке.

Обсуждали много разных тем, среди них:

Желаю Вам приятного прослушивания!

Свои вопросы Вы можете задать в комментариях.

Текстовая версия интервью:

Мой гость — Яков Файн — живет и работает в США уже более 20 лет, поэтому вопросы изучения английского языка ему близки.

В сети Якова многие знают под ником Будам и по его интересным подкастам про США (очень советую послушать, найдёте много интересного). Также хотела отметить, что он автор нескольких книг по программированию, регулярно проводит тренинги и мастер-классы. И все это на английском языке.

Надежда Аверьянова: Привет Яков, очень рада тебя слышать! Расскажи пожалуйста, почему Будам?

Яков Файн: Очень просто. Это аббревиатура от двух слов “Будни Америки”, к тому же этот ник легко выговаривать.

Надежда Аверьянова: То есть у тебя серия интересных подкастов из жизни Америки?

Яков Файн: Ну, в общем да. Я живу в Америке 20 лет, работаю здесь и конечно знаю, что происходит вокруг. Мне нравится эта страна.

Надежда Аверьянова: Когда только ты приехал в Америку, у тебя были проблемы с английским?

Яков Файн: Скажу честно, английский я любил всегда и особых проблем не было. Я учился в школе, в Киеве и у меня был хороший преподаватель английского языка. Затем обучался в институте и там мне тоже повезло с преподавателем. Поэтому когда я приехал у меня было меньше проблем, чем у большинства приезжих людей.
Я не говорил свободно по-английски, но я говорил. Я занимался английским и после института.

Надежда Аверьянова: Как проходили Ваши занятия? На что преподаватель в институте делал акцент?

Яков Файн: Обучение было ориентировано на то, чтобы подготовить студента к защите диплома на английском языке. В то время обучение было на более примитивном уровне, чем сейчас. В наше время существует задача, дать разговорный английский людям, кто изучает язык. Я считаю, это самое главное. В то время когда учился, была задача научиться читать.

Надежда Аверьянова: Упор делался только на чтение?

Яков Файн: Да, только на чтение. В основном, на чтение технической литературы.
Уже после института я доучивался читать уже художественную литературу, на английском языке. Я нашел свой метод изучения языка — читать книги на английском без словаря.

Надежда Аверьянова: Яков, ты считаешь этот способ самым эффективным?

Яков Файн: Я не могу говорить про всех. Вообще можно разделить общение на английском языке на две части. Первая — это умение читать и писать. Вторая — это умение разговаривать. Я видел среди эмигрантов людей, которые бегло говорят и совсем не умеют читать и писать. Они просто научились разговаривать это один вариант изучения языка. Меня интересовало более профессиональное общение. Чтение книг без словаря — метод, который срабатывал для меня потому, что слова встречались в разных контекстах.

Надежда Аверьянова: Я правильно понимаю, что в США есть русскоговорящие люди, которые живут там уже на протяжении долгих лет, но плохо говорят по-английски?

Яков Файн: Я бы сказал они говорят с акцентом. Если этот человек приехал в возрасте до 12-13 лет, то акцента не будет. Когда мой сын приехал в Америку ему было 8 лет. У него совершенно нет акцента. Если люди приезжают в подростковом возрасте, то в большей или меньшей степени акцент остается. Люди, которые приезжают в более зрелом возрасте тоже научились общаться, но акцент у них остался более сильный. Но в Америке это не очень важно, там много эмигрантов, поэтому к акценту все относятся терпимо.
Если ты хочешь улучшить произношение, то можно посетить курсы по уменьшению акцента. Эти курсы изначально были созданы для людей перенесших болезни, такие как инсульт. Когда приходится вновь учиться говорить. А сейчас они очень популярны среди актеров Голливуда, дикторов, эмигрантов.

Надежда Аверьянова: Да, действительно. Многие люди боятся говорить по-английски, утверждая, что у них плохой акцент.

Яков Файн: Я считаю это большой ошибкой. Это самый большой вред, который наносит себе человек, пытающийся изучить язык. В таких случаях дополнительно, можно использовать “язык тела” и главное, как можно больше говорить. С кем угодно.

Надежда Аверьянова: Сейчас очень много возможностей общаться через скайп. Так же в Москве проводятся встречи, на которых общение происходит исключительно на английском языке.

Яков Файн: Скажи, Надежда а зачем люди учат язык? Кто эти люди, которые хотят учить разговорный английский?

Надежда Аверьянова: Прежде всего это люди, которые хотят свободно общаться за границей. Знание английского языка нужно им для работы, учебы за границей и просто для путешествии.
Первый страх человека, публичное выступление. На втором месте смерть. А на третьем месте смерть от публичных выступлений. А уж если речь идет о иностранном языке, то получается двойной шок.
Скажи Яков, а какая мотивация для изучения английского была у тебя?

Яков Файн: Когда я учился в институте у меня была мечта жить в англоязычной стране. Вариантов переехать в Америку у меня не было, но тем не менее у меня был интерес к английскому. Это был язык рок музыки, а я любил рок. Изначально мотивация была не очень сильной, но был интерес.

Надежда Аверьянова: Яков, ты разработчик, программист и мне приходилось слышать от тебя фразу, что английский язык — главный язык для программистов. Что это значит?

Яков Файн: Существует много языков программирования. Как правило программисты знают несколько. Так вот английский самый главный из них. Мне английский язык помогал быть одним из лидеров в своей специальности даже когда я работал в Киеве. Англоязычная литература более современная и количество информации для программиста на английском языке в тысячи раз больше, чем на любом другом языке. Английский это международный язык общения и все самое свежее выходит на английском языке. И если ты не умеешь читать по-английски, те же книги по программированию, ты вынужден ждать пока кто-нибудь переведет. Переводы обычно опаздывают на несколько лет, а это значит ты будешь отставать в своей профессии. Если программист живущий в России не знает английского языка, то у него вряд ли получится хорошая карьера.

Надежда Аверьянова: Среди разработчиков действительно есть такая проблема, как незнание английского языка?

Яков Файн: Да, конечно! Поэтому Россия уступает в этом вопросе Индии. Все высшее образование в Индии на английском языке. Программистам со знанием английского легче получить работу.
Я работаю в компании, где есть программисты из Беларуси и Украины. Они общаются с клиентами, американцами через скайп на английском языке. Если человек хороший программист, но не может говорить по-английски, а проект требует общение с клиентом, то мне не нужен такой программист. Люди заполняя резюме пишут в графе знание английского языка — средне. Я не понимаю, что их останавливает выучить язык! Желание плестись в хвосте? Знание английского это самый короткий путь к победе!

Надежда Аверьянова: Так как у меня муж программист? и я немного знаю ситуацию и знакома с этой проблемой. Многим программистам не хватает навыка общения на английском языке.

Яков Файн: На мой взгляд это лень. Как можно не вкладывать в себя любимого силы? Я не понимаю, почему это происходит, но меня это сильно расстраивает. Если человек так относится к себе, то ожидать от него большой отдачи на проектах тоже не приходится. Но хочется сказать и о хороших ребятах. Бывают и такие, которые понимают, как себя вести с людьми, отличные программисты, умеют общаться на английском языке. Это редкость, но такое бывает и для нашей компании это большая находка.

Надежда Аверьянова: Скажи Яков, можно ли накупив книжки, накачав программы, обложившись словарями, выучить английский самостоятельно?

Яков Файн: Все можно. Вопрос в том, насколько это будет эффективно, сколько времени это займет. Если есть материальная возможность нанять преподавателя, то это будет самым лучшим вариантом. Это касается любого дела. Почему люди идут на курсы? Да потому, что преподаватель не даст утонуть в разнообразии информации, объяснит все особенности. Преподаватель знает, как правильно построить фразы, как сказать, чтобы тебя поняли. Конечно можно все эти вещи осваивать самостоятельно, но на это уйдет значительно больше времени.
Бывает, что человек все освоил и выучил, но приезжая за границу все же сталкивается с проблемой общения. Я считаю, что курсы по изучению и преподаватель помогут освоить английский более эффективно.

Надежда Аверьянова: Как бы ты описал идеального преподавателя? Какие навыки и качества он должен развить у своего ученика?

Яков Файн: Первое, преподаватель должен уметь преподавать. Я хочу сказать, что знание предмета вовсе не делает преподавателя хорошим преподавателем. Это относится и к английскому и к программированию. Умение преподавать это искусство.
Он должен быть спокойным, терпеливым, уметь зажечь искорку в стеклянных глазах ученика. Если человек это умеет, значит это хороший преподаватель. Поэтому выбирать преподавателя лучше по рекомендации.

Надежда Аверьянова: Какие требования ты, как преподаватель предъявляешь к ученикам?

Яков Файн: Ученик должен быть мотивированным. Больше ничего. Если человек не хочет выучить язык никогда ты его не заставишь. Он найдет любые причины, по которым у него этого не получится.

Надежда Аверьянова: Я, за всю свою преподавательскую деятельность вывела для себя формулу. Чтобы преуспеть в английском языке нужно иметь цель (знать для чего ты учишь язык), постоянно себя мотивировать и заниматься в системе (регулярно). На мой взгляд эти три составляющие обязательно приведут к успеху в изучении.

Яков файн: Надежда, у тебя есть определенная методика преподавания языка?

Надежда Аверьянова: Вообще я интересуюсь различными методиками. Здесь все зависит от ученика. Я комбинирую, когда вижу, что конкретно этому ученику подойдет именно эта методика и учитываю, чего следует избегать при работе с ним. Так же имеются свои наработки.

Яков Файн: Ты видишь по своим ученикам, что эти наработки и методики дают хорошие результаты?

Надежда Аверьянова: Да, конечно я вижу результаты! Просто хочется отметить, что все мы разные. У кого-то хорошая зрительная память, кто-то больше запоминает образами, некоторые лучше воспринимают информацию на слух. Здесь важен правильный подход.

Надежда Аверьянова: Вы переехали в Америку, когда старший сын был ещё маленьким. Как он начинал говорить по-английски?

Яков Файн: Вообще, разговаривать по-английски с ним я начал с его рождения. Моя жена разговаривала с ним по-русски, я по-английски. Причем говорить по-английски мой сын начал раньше, чем по-русски. Оказалось, что английский более простой язык. Фактически он учил одновременно два языка и было все проще. Дети до трех лет очень хорошо запоминают информацию. Я думаю, это помогло в дальнейшем изучении. Хотя я вижу, что многие дети приезжают в Америку и достаточно легко переходят на английский язык. На много проще, чем взрослые- это точно.

Надежда Аверьянова: А сейчас у твоего старшего сына есть акцент?

Яков Файн: Нет, у него нет акцента.

Надежда Аверьянова: Я помню, как обучали нас в школе. Постоянно делался упор на грамматику. Учителя утверждали, что зная грамматику, мы сможем выучить и сам язык. Позже, когда мы уже поступили на языковой факультет мы не могли и слова сказать. Было сложно изучать язык с точки зрения живого общения, разговорного языка. Зачастую, та грамматика, которую мы получаем в школах и университетах, она не пригождается в разговорном английском. Мы не используем все времена. Как в Американских школах объясняют грамматику английского языка?

Яков Файн: Для меня это загадка. Как мне кажется, они вообще ничего не объясняют. Когда я спрашиваю младшего сына, почему та или иная фраза именно так говорится, с точки зрения грамматики, он отвечает, что не знает почему. Он говорит, что в школе объясняли грамматику в первых классах, а больше никогда. Я не знаю, как они умудряются общаться, но вот так они живут в среде и знают, что именно так правильно.

Страница 1 из 1 1

Яков Файн - организатор Princeton Java Users Group, является автором и соавтором большого числа технических книг по программированию, например Enterprise Web Development, (O’Reilly, 2014), Java 24-Hour Trainer (Wrox, 2011).

Специалист Luxoft Training в области Web-, XML- и Java-технологий (В. Л.) взял интервью у одного из основателей двух стартапов - IT-консалтинговой компании Farata Systems и компании по разработке ПО SuranceBay, Java Champion Якова Файна (Я. Ф.).

В. Л.: Здравствуйте!

Я. Ф.: Добрый день.

В. Л.: Начать хотелось бы вот с чего: в последнее время появляется все больше инструментов в области клиентского программирования. Вы знаете, что чуть ли не каждый день выходит новая библиотека, фреймворк, стандарт…

Я.Ф.: Но я бы обобщил, что есть несколько основных направлений:

Подход «Native JavaScript» - попытки максимизировать использование потенциала, заложенного стандартами от ECMA и W3C-консорциума. Вы знаете, что время от времени выходят новые версии этих стандартов, появляются новые features, и есть проекты типа JavaScript 6 Shim и Traceur , которые вкупе с современными средствами разработки, такими как WebStorm, еще до официального выхода стандартов и их реализации в браузерах позволяют пользоваться этим инструментарием. Соответственно, подход состоит в том, чтобы решать задачи в основном с опорой на эти инструменты.

Это было бы очень даже удивительно. Я в 2005 году попал в такую финансовую компанию и был очень удивлен, что один человек сидел за большим белым компьютером Apple, когда все остальные работали на стандартных Windows-машинах. Тогда это было очень странно. А сегодня есть целая политика, есть целая стратегия, какие устройства можно разрешать брать внутренним юзерам, а какие - нет.

Иными словами, я уже говорил, если мы находимся внутри стен одной организации, знаем environment (окружение), то мы можем выбрать один подход. Но даже это, так сказать, не «written stone» (высечено в камне), так как эта политика BYOD тоже может разрешить им приносить свои iPad’ы или Android’ы.

Вторая категория - есть Consumer Facing Applications, то есть приложения, где пользователями являются люди, не находящиеся внутри организации. У них могут быть совершенно любые устройства. И вот тут перед разработчиками уже встает другая проблема - как сделать так, чтобы то, что я напишу, выглядело нормально на всех устройствах, о части которых я сегодня еще даже не знаю. Завтра выйдет iPhone 6 или какое-то небольшое китайское приложение. Подходы совершенно разные.

Ну а теперь, возвращаясь, дам короткий ответ. Вот эти подходы, которые вы обозначили, брать ли обыкновенный JavaScript? Новый стандарт JavaScript 6 - на него можно пока не смотреть, потому что в ближайшие пару лет он не выйдет, а когда он выйдет, браузерам понадобится какое-то время, чтобы его имплементировать. Но уже сегодня ECMAScript 5 поддерживается практически всеми современными браузерами. Под современными я подразумеваю браузеры, которые не старше двух лет. На самом деле в разработке сегодня мы стараемся не принимать во внимание старые браузеры. Например, все, что ниже IE 9, мы даже не рассматриваем, то есть если не будет работать - ну извините, пора бы уже и подтянуться! С другой стороны, что касается фреймворков, о которых вы сказали (jQuery, AngularJS, Ext JS, Backbon.JS), их тоже можно разделить на разные группы. А именно:

Тяжеловесы, такие как Ext JS или Yahoo YUI , который уже прекратили поддерживать, сказали: «все - мы поняли, что это тупик». Тяжеловесные фреймворки годятся для Enterprise-приложений, приложений корпоративных. Ext JS - есть хорошие контроллеры, очень сильные Data Grid, можно формы делать, там есть Charting хороший, то есть можно делать так, чтобы одни и те же данные показывались как pie diagram либо bar diagram. Тут же click on the button, и это уже таблица с циферками. Вот эти все вещи для приложений для корпораций хороши. Минусом же является то, что фреймворк тяжелый. То есть само приложение будет весить много: ваш код + мегабайт. Это много, если это Consumer facing application. Если человек стоит на какой-то медленной сети с мобильником в руках и ему приходит больше 1,5 Мб только, чтобы загрузиться, то это минус. Хотя это rich library - богатая библиотека, в которой есть куча консолей. И если вам это действительно важно - нужно сделать солидное красивое приложение для внутреннего использования в компании. Или так называемое back office operations, то есть для своих юзеров. Да, можно рассматривать эту библиотеку.

В большей части признают легкие. Для легкости используют все-таки другие фреймворки. Для чего пользоваться такими фреймворками, как Angular или jQuery? Во-первых, чтобы упростить себе создание каких-то мелких компонентов, чтобы использовать заготовки, которые уже есть в мире. А во-вторых, чтобы спрятать зависимость от браузеров. Скажем, разные браузеры, может быть, еще не все имплементировали последние feature’и ECMAScript 5, то есть браузер c неполной поддержкой этого стандарта. Эти библиотеки говорят: «Мы от вас спрячем это. Будете работать с нашей библиотекой и не волнуйтесь - поддерживает браузер или нет, - мы будем пользоваться этими feature’ами, ставить специальной загрузкой или еще как-то…»
Вот такой ответ. Я могу еще говорить на эту тему. Но давайте уже перейдем к другим вопросам.

В. Л.: По компилируемым в JavaScript языкам скажите еще пару слов - TypeScript, Dart, другие?

Я. Ф.: Ах да, по языкам. Главный язык - JavaScript. Есть один человек, которого зовут Джефф Этвуд (Jeff Atwood), вместе с Джоэлом Спольски (Joel Spolsky) он создал Stack Overflow. Это популярное место, где программисты собираются и задают друг другу вопросы. И он сказал фразу, которая звучит примерно так: «Все, что может быть написано на JavaScript, - будет написано на JavaScript!»

В принципе, это, конечно, шутка. Но в этой шутке есть доля шутки. Да, действительно, о JavaScript можно говорить все что угодно. Он очень странный, показывает всякие глупости, непредсказуемость неких конструкций. Но «As is what it is» - у нас это есть сегодня, это то, что мы имеем, и это наименьший общий знаменатель для всех приложений. Минусом является что? Резкое снижение продуктивности программистов.

В нашей компании Farata Systems мы делаем разработку на разных языках, на сервере - Java (базовый, никогда ничего не меняем), на фронтенде мы использовали разные языки, в частности, много лет использовали чудную библиотеку от Adobe - Flex . Компилирующий язык, public client и так далее. Удобно. Хорошо. Наши разработчики были продуктивны. Потом по разным причинам Adobe отказалась от Flex, Apple не хочет поддерживать плагины и браузер-компилятор. Эта технология уходит. И мы стали пересаживать программистов на JavaScript. И сразу увидели резкое падение продуктивности. А у нас работают только Senior-программисты, нет Junior или только начинающих. Мы сразу увидели, что нашим ребятам нужно намного больше времени, чтобы сделать то же самое. Это - большой минус JS.

Конечно, нужно пользоваться фреймворками, чтобы превратить в плюс. Но последний год мы работаем на языке Google Dart. Опять же Dart - очень красивый язык, удобный. Это как бы более умная Java, если можно так выразиться. То есть они смотрели на Java, применили ее, исправили очень много ошибок, сделали все удобно, симпатично. Начали работать на реальном проекте - у нас есть продукт, который мы делаем для страховой компании.

Но когда мы говорим слово Dart, мы должны разделять разработку и production (deployment). Сегодня и еще многие годы это не изменится: на Dart вы разрабатываете, а из Dart генерируется все равно JavaScript, и он запускается в production. Почему? Потому что никакие основные браузеры не собираются поддерживать пока DartVM. У Google есть специальный браузер Chrome , вероятно, скоро и сам Chrome будет идти с DartVM. Другие браузеры не собираются пока его поддерживать и не соберутся. Google это понимает, поэтому генерирует очень хороший JavaScript. Dart - это, по моему мнению и по мнению нашей компании, хорошее направление, куда идти, чтобы сделать разработку на JavaScript более продуктивной.

Некоторые пробовали TypeScript. Но TypeScript - это такое промежуточное решение, которое чуть-чуть лучше, чем JavaScript. А Dart - серьезно лучше! Минус использования Dart - пока еще недостаточная база компонентов UI, которая может быть использована в вашем Dart-приложении. Положительной стороной является то, что в Dart есть библиотека AngularJS, которая на JS написана. Легкая библиотека, MVC и т. д.

А есть уже и AngularDart , во-первых, пишем на Dart, используем AngularDart, и там было мало компонентов. Есть еще такая библиотека Polymer , где все основано на том, что можно создавать компоненты на HTML, то есть из тега можно сделать компоненты, которые потом можно взять, drop’нуть на другой экран и пользоваться там. Это правильное направление, по нашему мнению, и мы идем в эту сторону. Если писать для HTML5 для браузеров, для разных устройств, я бы посоветовал сегодня выбрать Dart с генерацией JavaScript и деплоить в JavaScript.

В. Л.: Спасибо. Тогда следующий вопрос - как раз касательно этой разницы. Как вы оцениваете такой вопрос, который раньше не стоял и появился в связи с ростом популярности JavaScript: строгая типизация - это плюс или минус? И как он влияет на производительность труда программиста? Будущие языки - как они будут разрабатываться - со строгой типизацией или это будут переменные, которым можно будет присваивать любой объект?

Я. Ф.: Ну, этот вопрос можно перефразировать так: «как вы относитесь к острым ножам?» Хорошо иметь на кухне острый нож? Наверно, хорошо. Но вы понимаете, что человек, который только начинает «куховарить», может порезать себе палец? Кого будем винить? Будем винить нож! Правда? Или не нож винить? В этом плане нестрогая типизация - это нож, которым можно порезаться.

Главный минус - программа становится менее читаемой. Конечно, вы можете сказать: «Ну а мне какая разница? Я-то понимаю, я сам написал». Да, но многие могут сказать, что больше времени требуется, чтобы читать чьи-то программы, чей-то код, чем писать свой. Поэтому если Вася Форточкин придет читать программу, которую я писал (а я уже уволился из компании, и это было написано на нетипизированном языке), то Вася очень зависит от меня - от моей доброй воли, от того, насколько я хороший программист, насколько я правильно называл переменные, потому что типов нет. Более того, динамические языки программирования, такие как JS, позволяют на ходу менять структуру объектов. Вот у вас есть какой-то объект, допустим Customer. У него несколько полей: имя, фамилия, адрес и т. д. И никогда там не было поля «Номер телефона». На ходу в программе взяли и прикрепили динамически новое поле и пользуемся. А Вася Форточкин откуда это знает? Он, конечно, разберется, но на это уйдет время. Если вас интересует продуктивность, то строгая типизация намного удобнее.

Так как сегодня большинство программистов - это массовые отряды, батальоны, дивизионы, которые слегка где-то подучились и программируют массовые приложения, т. е. ты не можешь ожидать от них суперэкспертности и большой порядочности в написании кода, для них нестрогая типизация - это вредно. А строгая типизация - это плюс, так как компилятор помогает тебе. Он не дает упасть. Ты написал что-то не то, а он подсказывает, не дает это сделать. Скажем, в нестрогой типизации ты сделал опечатку в названии Property (например, был объект клиент Customer, ты написал Customer.adress с одной буквой d равняется чему-то). Если в строгих языках типа Java тебе бы сказали: «нет такого address с одной d», то в нестрогих - промолчит, создаст новое Property «adress», программа будет как-то работать, а результат не тот, что ты ожидал. Поэтому нестрогая типизация, я считаю, не зло. Но требования к уровню программистов выше, чем к тем, кто пользуется языками со строгой типизацией.

Об этом я всегда говорю (мы читаем разные тренинги). В частности, когда мы обучаем Java-программистов, которые считают себя крутыми («мы знаем Java, multithreading, оптимизированные серверы, параллельные обработки и т. д. JavaScript - это бирюльки…»), на наших тренингах у них, наверно, сначала волосы дыбом встают, насколько сложно писать правильный код на JavaScript. Поэтому на месте программистов со строго типизированным языком я бы не смотрел свысока на программистов с нестрого типизированным языком: им тяжелее, чем вам. Это мое обращение к Java’истам.

В. Л.: Большое спасибо. Вам как эксперту не только по JavaScript, но и по Java должна быть знакома ситуация, когда появился Spring, - он изменил все. Это была революция в Java. Последние лет пять я даже не видел проектов на Java, которые бы не использовали Spring (реализация IoC, AOP). Недавно, когда я познакомился с AngularJS , там я увидел похожие подходы, тоже реализован IoC, некоторые конструкции с аспектно-ориентированным программированием. Я подумал, может, это тоже революция и через пару лет мы не будем видеть ни одного клиентского приложения без использования AngularJS? Как вы считаете?

Я. Ф.: Ну, во-первых, почему выделена именно AngularJS? AngularJS - да, хорошая библиотека. Да, она легкая. Да, она имплементирует паттерн MVC (model - view - control). Да, она позволяет разделить код более удобно на слои - там, где отдельно модели, - там, где данные, отдельно вьюшки, отдельно контроллеры. Да, это хорошая вещь. Да, там имплементировано Dependence Injection и IoC (Inversion of Control), то, что вы говорите, т. е. туда применен голливудский принцип «ты мне не звони, я тебе позвоню». Знаете, когда начинающие артисты в Голливуде ищут работу и обивают пороги агентств, после очередного прослушивания им говорят: «Когда тебе позвонить?» Они отвечают: «Ты мне не звони, я тебе позвоню». Это Inversional Control, т. е. не ты создаешь объект, а тебе он будет дан.

В Spring было сделано то же самое. Сегодня Spring популярен. И популярность его в мире Java часто определяется тем, что в то время (в начале 2000-х годов), к сожалению, Java EE архитектура была сложной. И Род Джонсон (Rod Johnson) создал Spring и имплементацию Dependence Injection. Я бы не сказал, что сегодня нет проектов, которые бы не делались на Java EE. Java EE намного проще. Но, к сожалению, они в свое время испортили о себе впечатление из-за сложности.

Сейчас и Enterprise Java Beans, и Managed Objects Injections, и CDI Dependence Injection - все это очень красиво, удобно. Но люди, которые уже сели на Spring, не видят причин пересаживаться на контейнеры JavaApplication-серверов. Параллель между Spring и AngularJS, наверно, только в том, что и там, и там имплементирован механизм Injections. В Java’вских проектах используется Spring, может не весь, а отдельный модуль, например Spring Security - он добавляется в любой проект, даже если это Java EE проект.

AngularJS тоже хороший фреймворк, но это MVC. Для того чтобы иметь full feature с полным набором фреймворков, нужно не только иметь возможность правильно структурировать приложение с распределением на слои. Там нужны некие компоненты, нужны удобства. Поэтому просто использовать AngularJS не очень хорошо, не мешало бы использовать какую-нибудь библиотеку кнопочек с круглыми краями. Какой-нибудь Goodstrap или еще что-нибудь. Я не хочу сказать, что фреймворк типа AngularJS просто возьмет и будет впереди планеты всей. Я так не считаю. Может быть, он будет один из лидеров, он и сегодня - один из лидеров, но не думаю, что это наше будущее. На сегодня он популярен, сегодня очень много проектов на нем делается. Когда будет полностью чисто сделан проект AngularDart, будет еще лучше. Но это - один из самых популярных фреймворков, и он будет жить и процветать какое-то время. И его изучать полезно сегодня, на ближайшие несколько лет это полезное знание. Но это - не революция.

В. Л.: Да, спасибо. Я хотел поговорить о том, что несколько лет назад появился сервер Node.js. Как вы оцениваете его потенциал с точки зрения рынка интернет-проектов и рынка корпоративных приложений: может ли он в перспективе привести к замене Java-, .NET-языков языком JavaScript на сервере? И как вы прогнозируете его дальнейшую судьбу?

Я. Ф.: Понимаете, один из главных принципов, по которому его продают и делают популярным, - это возможность исполнять JavaScript на сервере, на любой машине, скажем так, на своем движке. Программисту говорят: «Теперь тебе достаточно знать только JavaScript. Ты можешь и фронтенд писать на JavaScript, и бэкенд писать на JavaScript».

Я не считаю, что это правильный подход. Почему? Потому что главная задача при выборе языков программирования - чтобы конечный результат и конечный продукт был оптимальным и лучшим и пользователи его любили. Пользователям все равно, на чем написан продукт. Есть там Java, или JavaScript, или.NET - им абсолютно неважно. Им важно - удобно им или неудобно. Разве, когда вы берете в руки свой Android-телефон или iPhone, у вас есть мысль, на чем было написано это приложение? Нет! Вам оно или нравится, или не нравится. Это самое важное для вас. Это должно быть определяющим критерием. А сказать, что надо пользоваться Node.js только потому, что вы сможете пользоваться JS и здесь, и там, - это все равно, что сказать слесарю: мы придумали вариант, чтоб ты пользовался только отверткой. Другие инструменты тебе не нужны. Ты сможешь отверткой делать все: ты можешь выпиливать, не нужен лобзик тебе, отверткой можно выковырять все, в принципе, тоже. Поэтому я считаю, что программист должен быть сегодня полиглотом и знать несколько языков. И если перед вами стоит задача - ваша задача сделать пользователя HAPPY - СЧАСТЛИВЫМ! А не сделать свою среду удобной: я не хочу ничего изучать, кроме JS, поэтому мне удобно.

Что касается перспектив. Во-первых, Node.js еще не был даже выпущен в продакшен. Весь этот шум, который последний год происходит, - это о каких-то версиях, которые еще не являются «продакшен грейн». Во-вторых, что касается «Node.js заменит Java». В каких-то маленьких проектиках - почему нет? Я видел разные Benchmark. Не разные, врать не буду. Но лучший Benchmark, который я видел, - это тот, где Node.js на сервере в определенных приложениях, которые пытались нагрузить, работал в шесть раз медленнее, чем версия Java этого же приложения. По производительности ему до Java как до неба, пока. Хотя в шесть раз - это уже не так плохо для продукта, который даже еще не вышел. Движок, который, в частности, делает Google , а кроме Google, еще Oracle выпустила JavaScript-движок в составе Java 8 (называется Nashorn) - это тоже движок для JavaScript. Они довольно быстрые и, несомненно, будут ускоряться. Поэтому определенно будущее у Node.js есть, но это - не наше все. И я к этому отношусь совершенно спокойно - есть еще один язык для программирования на сервере.

Прекрасно!

В. Л.: Спасибо. Сейчас я бы хотел отойти от конкретики и задать более абстрактный вопрос по парадигме функционального программирования. Раньше были такие языки - главным образом Lisp , но потом интерес к ним угас. А сейчас мы видим, как они опять выходят на арену. Мы видим на платформе.NET язык F# , на платформе JVM - язык Clojure , да и в самом Java 8 много заимствований из функциональных языков. Как вы считаете - это просто мода или за этими решениями будущее?

Я. Ф.: Я бы не сказал, что это сиюминутная мода, потому что языки, такие как Lisp, уже очень старые. Не то чтобы он очень популярен, но прелесть функционального программирования заключена в том, что оно проще выглядит. Нет, неправильно. Можно короче написать то, на что нужно много кода в объектно-ориентированных языках программирования. Поэтому программисты опытные, грамотные, которые шикарно разбираются в программировании, считают программирование своей профессией, десятилетиями занимаются этим, любят ее, изучают эти языки, пробуют разные, как вы сказали, Clojure, Scala и другие.

Станет ли это массовым? Нет, не станет. Потому что эти языки сложны для изучения, а тем легионам программистов, которых сейчас производят, это сложно. Если в команде будет несколько человек, которые хотят программировать на Scala, это прекрасно. Они сделают отличный продукт, он будет элегантный и все такое.

Но давайте представим следующую ситуацию. Допустим, я менеджер команды на каком-то предприятии и мне нужно начинать разработку нового проекта. И скажем, есть такой крутой парень Джон Смит - эксперт в Scala. Он приходит ко мне в кабинет, здесь же присутствует вся команда. Он говорит: «Яков, давай делать на Scala, посмотри, ты технический человек, вот так я могу быстро, коротко и элегантно написать код». Я понимаю технические плюсы этого. Но с другой стороны, кроме Джона, у меня сидит Мэри, Маша, Ашот, еще и Шреневаз, еще и Петро. И я все думаю - что? Да, Джон крут. Да, Scala выглядит красиво. Но допустим, завтра Джон Смит уходит на другую работу. И я остаюсь с Петром, Машей, Шреневазом, Ашотом и Мэри. И я скажу: «Извини, Джон, может, классный язык Scala, но пока нет. Может, только отдельный модуль можно написать на Scala. Почему? Потому что мы JavaScript-цех. И твои модули могут исполняться на JavaScript-машине».

Большим плюсом, даже огромным плюсом я считаю тот факт, что в Java были введены эти конструкции для функционального программирования. В Java 8 так называемые Lambda Expressions используются в разных местах, они делают код действительно более элегантным. В чем прелесть функционального программирования? В том, что я тебе - объекту даю поведение, записанное как функция. Я тебе говорю: «Вот ты возьми этот код и его выполни». Это плюс.

Я написал несколько блогов, я работаю над вторым изданием своей книги по Java, которая скоро выйдет. Я написал несколько примеров, которые помогают упростить код. Допустим, в обыкновенном Java иерархия наследования - несколько слоев. А с помощью вот этих лямбд я могу убрать эти слои, я могу брать разные кусочки функционала и передавать их одному и тому же объекту. И он послушно это выполнит. В этом плане функциональное программирование - это шикарно. Я считаю, что это полезно знать, но не думаю, что если ты Java-программист, тебе нужно взять и переучиться на другой язык. Хорошо разберись с Java 8, и будет очень красиво! Ну а если ты чувствуешь в себе больший потенциал - изучай больше. То есть функциональные языки - это плюс, но опять же я не думаю, что это наше все. JavaScript, кстати, тоже функциональный язык.

В. Л.: Да, спасибо. Сейчас в мире приложений для мобильных устройств мы наблюдаем картину, к которой не привыкли в области ПК, когда есть две флагманские платформы Apple и Android и под них нет решений, чтобы писать код универсально. Понятно, что есть PhoneGap , есть jQuery Mobile . Но по факту мы видим большинство приложений, которые написаны на Dalvik или Objective-C. Как вы считаете, почему до сих пор не создано настолько же зрелой универсальной платформы разработки, каковой является Java для персональных компьютеров и серверов, чтобы четко соблюдался принцип WORA и при этом не страдала производительность? Насколько это следствие технической несовместимости этих платформ и насколько - следствие политики конкуренции Google и Apple?

Я. Ф.: Я бы не назвал это политикой. Ну как можно обвинить Google или Apple в том, что они хотят, чтобы был определенный строгий процесс деплоймента на их платформе, чтобы их приложение продавалось в их магазине? В свое время Apple сказали: «…не пустим Flash». ОК, нехорошо ругались, плакали, нашли решение. Даже на Action-скрипте, который используют флешевики, можно писать приложение, которое потом перекомпилируется специальным компилятором, и его можно продавать в том же самом Apple Store. Разве это плохо? Почему Apple? Не знаю, как у вас, но в Штатах я хожу по улицам и вижу, мне кажется, больше людей с Apple-устройствами, чем с Android. Хотя мировая статистика показывает уже, наверно, другое. Почему? Потому что Apple очень жестко следит за процессом того, что попадает в продакшен, как выглядит приложение. Google, кстати, меньше следит, поэтому там, конечно, полная анархия. Я не считаю это политикой, но, скажем так, куда бедному крестьянину податься? Нативные приложения, которые написаны отдельно на Dalvik, отдельно на чем-нибудь для Apple, - это правильный подход, если вы себе его можете позволить. Например, если вы одиночка, который пишет какую-нибудь игру, вы считаете: это мой продукт, я сам решаю все, сам имплементирую, сам знаю и тот язык, и другой. Шикарно! Пишите нативно! Нативные приложения, как правило, будут всегда выигрывать по сравнению с приложениями общего плана, написанными на одном и том же языке и портированными как-то. Даже если это HTML и JavaScript. То есть вы сможете делать абсолютно точные компоненты, которые будут выглядеть нативно. Которые будут выглядеть так же, как все остальное на этом устройстве. Если вы себе это можете позволить.

Вернемся в корпоративный мир. Я - менеджер проекта. Мне сказали: начинаем внедряться на мобильники. Обычно выбирается какая-то пилотная платформа. Как правило, начинается или с iOS, или с Android. Мы выбрали какую-то, но я всегда думаю о следующем. Хорошо. Вот у меня есть эти же люди (если вы помните их имена: Ашот, Шреневаз, Петро). Я могу их послать на курсы, они выучат Objective-C или что-то такое. Хорошо. Вот мы задеплоимся, пойдем в продакшен. А мне через шесть месяцев нужно делать то же самое приложение на Android. Что, опять их брать тренировать? А они junior. Скажем так, сколько у меня денег в кармане? Сколько я могу нанять программистов, которые будут работать? Есть ли у меня бюджет на то, чтобы сделать две параллельные команды, которые будут делать параллельно и то и другое: одни - нативно для iOS, другие - нативно для Android? Если да - шикарно! Но тоже не очень шикарно. Это значит, у меня будет две базы кода, это значит, что багов у меня будет два набора, а не один. Релизы нужно будет делать, учитывая, что и там и здесь что-то поломалось.

Но крупные компании, которые могут себе это позволить, будут это делать! Наверно, это правильно. Что касается PhoneGap - это так называемые гибридные приложения. Они говорят: «пиши на HTML и JavaScript, есть у вас везде». На самом деле PhoneGap - это такое commercial, т. е. то, на чем Adobe хочет делать деньги. А на самом деле это все базировано на библиотеке, которая называется Cardolla. В свое время Adobe купила разработчиков Cardolla. То есть можно open source написать с использованием Cardolla-библиотеки, а можно использовать PhoneGap и их сервер для того, чтобы написать на JavaScript и HTML5, а потом отгрузить этот код к ним на сервер, и их сервер запакует ваше приложение, написанное на HTML и JS, под несколько платформ (не только iOS и Android) автоматически.

Но недостатками такого подхода является то, что люди говорят, что оно чуть-чуть медленнее, скроллинг будет работать не так, как нативно. То есть все-таки есть разница. Хотя это некое решение. Тот, кто не может себе позволить две отдельные команды, должен писать на одном языке, например на JS или HTML5 с какими-то библиотеками - с любыми. А потом отгрузить все на этот PhoneGap-сервер, сделать Build и отправить. Такое тоже возможно. А некоторые просто сидят, делают одно приложение и запускают у себя на устройстве с использованием… Но опять же здесь развилка. Либо я буду пользоваться отдельными фреймворками для мобильных, как вы сказали, jQuery mobile или Sencha touch например. Но тогда опять будет две версии приложений - одно для десктопов, второе - для мобильников. И надо определять, что человек зашел с мобильника. И есть там такое понятие User screen в HTML header и т. д., а их очень много. Или лучше выбрать другой подход - не пользоваться мобильными фреймворками, а писать все - писать одну базу кода HTML5 и JavaScript. Но есть такая техника - Responsible Design. То есть можно сделать так, что одно приложение будет написано и оно будет грузиться на разные экраны, будет хорошо работать, хорошо выглядеть. Там тоже есть какие-то нюансы. В общем, есть много подходов. Я не думаю, что какой-то выиграет. Если можете писать нативные приложения, пишите для каждой платформы. Не можете - извините!

В. Л.: Спасибо. Следующий вопрос в сторону бэкенда - базы данных NoSQL . Это новая тенденция, которая появилась. Сейчас все больше и больше о них слышно. Может, вы их тоже используете в своей компании? Как вы оцениваете их потенциал и если есть какие-то гибридные решения, то как их использовать?

Я. Ф.: Здесь я могу только одно. NoSQL базы данных занимают очень маленький сегмент у нас в Штатах. Может быть - 5%. Если взять все базы данных, которые используют, все-таки большая часть, подавляющая - это реляционные базы данных. И недостаток для предприятий, для приложений, типичных для Enterprise, - это то, что в них не поддерживается транзакционность, что часто нужно. С другой стороны, я лично ими не пользуюсь. Я смотрел несколько презентаций, читал о них, но не являюсь экспертом в этом деле совершенно. Поэтому мое мнение здесь не очень важное и весомое. У нас в компании есть парень (работает консультантом в крупнейшей финансовой компании), и он работает именно на MongoDB. Его взяли на проект, он ее изучил и пишет для них на MongoDB. Там приложение, где в основном отчеты - Reports. Они делают очень много отчетов. И вот там MongoDB показывает себя очень хорошо, хорошее быстродействие.

Здесь какая-то транзакционность особо не требуется. Опять же почему используется NoSQL? Можно хранить объекты в БД. Не требуется описание структур, как, например, в SQL требуется описание таблиц, колонок и т. д. И изменение структуры меняет все. Здесь этого не требуется. Поэтому я не могу сказать, что у меня есть хороший опыт с mixed solutions, когда используется и то и другое. Недавно был на презентации, где люди делают какие-то open source продукты, где они вообще пишут слой - ты пишешь SQL, язык запросов, но как движок они подставляют NoSQL. Ну OK, есть какие-то гибриды. Опять же я не могу много говорить об этом, так как я не специалист.

В. Л.: Хорошо, давайте в продолжение разговора о структурах данных поговорим о форматах их представления. Традиционный формат - это XML, но в последнее время XML стал постепенно вытесняться JSON . Как вы оцениваете перспективы этого противостояния?

Я. Ф.: Форматы данных. XML уходит, он тяжелый, нужно много писать тегов. И мы стремимся, чтобы количество байтов, которые бегут по проводам, было как можно меньше. Поэтому XML считаю уходящим, и писать приложение, где между клиентом и сервером будет бегать XML, непрактично. То есть его заменил JSON. JSON-формат заменил его почему? Потому что он не такой тяжелый, там нужно писать меньше тегов, а главное - он очень похож на формат написания JavaScript-объекта. Там почти все одинаково. То есть написать JS-объект и написать JSON. Поэтому сегодня на все браузеры (опять же говорю все, если этот браузер не старше двух лет) имеем парсинг JSON, ничего не нужно устанавливать. Поддерживается шикарно! Платформа, которая на backend, поддерживает генерацию и парсинг JSON! И.NET, и Java, и, скажем так, native Java - у них есть специальная поддержка JSON, там она уже внедрена. Не хочешь на этом - пожалуйста, Google сделала библиотеку JSON. JSON - самое популярное, и мы этого метода придерживаемся. Что касается того, чем люди пользуются.

Конечно, Google Protobuff - это специальный формат, который компилируется, т. е. можно написать объекты на сервере и на клиенте, компилировать их в специальный формат и передавать данные с помощью этого protobuff. Но минусом является то, что нужно кое-что устанавливать для того, чтобы этот protobuff поддерживался на клиенте. Но мы остановились на JSON.

В. Л.: Насколько перспективным вы видите потенциал данного подхода?

Я. Ф.: Это было и в прошлом, и в настоящем - это так называемый Fatclient . Мы это используем постоянно внутри приложения, которое используется внутри Flash player. Написано на ActionSсript. То есть очень много бизнес-логики находится на клиенте. Что касается HTML- и JS- приложений - тут важную роль сыграл тот факт, что можно не перегружать всю страницу, - что называется AJAX. Позволяет больше иметь JavaScript-кода на клиенте, иметь логику там, не надо перегружать страницу, не надо перегружать state-состояние. При выполнении неких скриптов можно положить в какой-то объект промежуточные результаты, затем подтянуть новые данные; страница не перегружается, поэтому следующие скрипты могут использовать это state-состояние, что самое важное для таких rich frontend приложений. Это есть и будет. Вся бизнес-логика не уйдет на клиента. Это однозначно. Особенно на языках типа JS, где можно посмотреть исходники. А часть - да. Что касается еще одной предосторожности - валидация чего-то. Как правило, валидация в Java-приложениях, где есть HTML-код и JavaScript и что-то на backend, делается и там и здесь. Допустим, вы провалидировали данные на клиенте логикой на клиенте (форму заполнили, проверили), нажали кнопку Submit, и данные по проводам побежали на сервер. А может, их перехватили по дороге плохие дяди, плохие мальчики и девочки? Да, и на клиент уже пришло что-то другое. Все равно приходится писать валидацию на сервере тоже, чтобы обезопасить себя. То есть это будет существовать, я не хочу сказать, что это будет только так. Как раньше в 90-х годах самой популярной архитектурой была client-server. На клиенте все считалось, на сервере была база данных и все обрабатывалось. Не думаю, что это вернется в жесткой форме. Будет достаточное количество бизнес-логики на клиенте, но не вся.
Я желаю всего хорошего программистам из России, Украины, Белоруссии. Мы с ними хорошо работаем и дальше будем работать.

В. Л.: Спасибо вам за интервью.

8 декабря 2014 года Luxoft Training приглашает специалистов, пишущих на любых языках программирования, на онлайн-тренинг Якова Файна «Практическая разработка веб-приложений на JavaScript и AngularJS». Вы получите навыки разработки клиентских частей веб-приложений вне зависимости от используемой технологии серверной части. Обучение пройдет в среде, максимально приближенной к реальной.

Яков Файн, бывший киевлянин, 19 лет назад уехал покорять Америку. Сейчас у него консалтинговая компания, которая помогает клиентам делать RIA . Он автор нескольких технических книг, под ником Budam ведет популярный подкаст на русском языке За cool жизнь . Несколько дней назад Яков был в Киеве , где я и взял у него это небольшое интервью.

Расскажите о своей карьере в США. Насколько легко или тяжело было вам как эмигранту «пробиваться» вперед? Искать работу, строить бизнес, завязывать отношения? Насколько быстро можно двигаться по должностям, сколько лет уходит на «вживание» в страну.

У меня не было с этим особых проблем, опять же, потому что у меня был английский, я знал мат. часть, но при этом не строил из себя примадонну. Приехал в 1992 году в США, нашел работу и спонсорство, чтобы получить рабочую визу. В 1995 получил грин карту и начал работать фрилансером на разных должностях. Последние три года являюсь партнером в компании Farata Systems, которая занимается консалтингом, тренингом и разрабатывает open source software . Написал несколько книг связанных с программированием.

Америка довольно демократическая страна и тебе не будут ставить палки в колеса только потому, что ты иммигрант. Можно послушать вот этот подкаст о работе в Америке: budam.rpod.ru/83693.html .

Вживание в страну у меня прошло безболезненно, потому, что я любил США. А если вы едете туда как на каторгу, то не вживетесь никогда, а так и будете оставаться пятой колонной.

В чем отличия работы и жизни в Америке глазами программиста?

Не знаю как сегодня работается программистам в Украине, поэтому трудно говорить об отличиях. Об Америке могу сказать, что количество работодателей, где работают программисты огромно, но работа не гарантирована. Надо постоянно поддерживать свой профессиональный уровень чтобы спать относительно спокойно. На работе люди общаются вежливо, и стартаются критиковать друг друга выбирая слова и уважая мнение оппонента.

Какая ситуация на рынке работ для разработчиков сейчас по сравнению с год-два назад? Как живется русским?

Ситуация на рынке работ сегодня крайне тяжелая. На традиционных языках (Java,. Net) работ очень мало. С Adobe Flex получше, однако нужно хорошо знать мат. часть. Русские программисты не являются здесь отдельной категорией, и если плохо/хорошо всем, то так же и русским, китайским, индийским, и т. д.

Насколько сложен социальный фактор для «наших» программистов в Америке? правда ли, что большинство ограниченно общением в кругу русских эммигрантов? насколько комфортно общаться с нейтивами? Возможны ли дружеские отношения и насколько это похоже/отличается от дружбы здесь?

Социальный фактор дело индивидуальное. Я себя чувствую комфортабельно. Общение после работы в основном среды бывших иммигрантов, хотя это не потому, что нас как-то ограничивают. Просто когда люди выросли в разных культурных средах, интересы бывают разные. Например, меня не интересует бейсбол или американский футбол... А в общем люди относятся друг к другу довольно дружески, хотя без панибратства, сохраняя дистанцию.

Много ли хороших (интересные люди, проекты) работ для программиста в Штатах? а таких, куда можно попасть иммигрантам?

Количество проектов, где работают программисты огромно - думаю больше, чем в любой другой стране мира. Иммигранты должны сначала должны получить право на работу (например виза H1B), а дальше обычная конкуренция.

У нас любят говорить про «тупой аутсорс», имея ввиду то, что на аутсорсинг часто отдают неинтересные с технической точки зрения проекты, связанные с поддержкой какого-то старого кода. Действительно ли заказчики дают в аутсорс только «тупые» проекты, оставляя сложные проекты «своим» программистам? Может заказчики с интересными проектами не занимаются аутсорсингом?

Аутсорсингом занимаются не для того, чтобы сплавить кому-то неинтересную работу, а чтобы выполнить проект с наименьшими затратами и желательно без потери качества. А главное, программистов в Америке просто не хватает. Работа бывает интересной и не очень, но если вы программист-профессионал, а не любитель, то привыкайте к тому, что работу нужно делать всякую. Конечно, если вам дают только проекты требующие только поддержки (maintenance) чужого кода, попробуйте найти другого работодателя. Хотя на определенных стадиях карьеры и maintenance projects могут быть вам полезны. Попробуйте составить себе карьерный план и придерживайтесь его. Например, сначала найти какую-нибудь работу, потом более интересную с точки зрения кодирования, потом ту, которая требует общения с заказчиком, и т. д.

Ваша компания работает с программистами из стран бывшего СССР. Чем отличаются «наши» программисты от других? Есть ли какие-то «типичные» слабые стороны? Сильные стороны?

В одном из интервью у нас на сайте утверждается такое: «зарплату [в США] повышают раз в 5 лет и только 10% тех, кто круче всех остальных Никто вас не пустит в менеджеры раньше, чем через 10-15 лет непрерывного опыта на инженерных позициях».

Я сменил много работодателей, но пока мне не приходилось работать в компаниях, где повышают раз в 5 лет. Обычно, служащих повышают ежегодно, если в компании нет серьезных проблем. Прошу не путать служащих с контракторами, работающими на почасовой ставке. Тут законы совсем другие. У меня был проект, где я работал фрилансером у одного и того же заказчика и они мне дважды понижали часовую ставку. А менеджером в компании можно стать и раньше и позже - это все очень индивидуально.

Говорят, что Америка - страна трудоголиков, а вот наши программисты работают не очень производительно: отвлекаются на перекуры, интернет, опаздывают и т.п. Что вы можете сказать по этому поводу?

Да, в Америке работают много. Если программисты из бывшего СНГ живут и работают в Америке, то они работают по графику своих работодателей. Я не заметил, что они опаздывают или отвлекаются больше других. Что касается расписания людей работающих для нашей компании из-за океана, меня не особо волнует, работают ли они 8 часов подряд с утра или с перерывами. Главное, чтобы работа была сделана и чтобы я мог с ними связаться в случае необходимости. Конечно, если есть назначенные совещания на определенное время, они должны быть на связи.

В своих подкастах вы часто говорите о карьере. Какие приемы, навыки повышают шансы построить успешную карьеру программисту? Помимо собственно умения писать хороший код.

В карьере программиста, кодирование только одна из обязанностей. Communication skills (умение общаться с людьми) считаю очень важным достоинством профессионального программиста. Самые ценные специалисты это go getters или люди, которым можно дать задание и они сами найдут ответы на все вопросы, связанные с программируемым приложением. Возможно для этого им придется встречаться с business users, клещами вытаскивать из них нужные ответы, но если в результате они приносят вам сделанную работу, а не список проблем, которые помешали им ее сделать, это и есть профессионализм и высший пилотаж. А мальчики с моторчиками, которые просто любят играться с кодом и просто заниматься тем, что им нравится, мне как работодателю не интересны.

Вы не жалеете, что уехали? Почему?

Не жалею. США - это страна, где уважают закон и практически нет коррупции. Здесь есть обычный человек может жить безбедно, если он хочет работать. Здесь нет притеснений по национальному вопросу - если ты чего-то стоишь, то можешь добиться многого.