Ответы на вопросы читателей Хекслета

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

Вопрос по поводу прокачки “понимашки” :)

Проблем с самоорганизацией и мотивацией нет.

Есть проблема с интеллектом и математической подготовкой: многие сложные вещи не получается переварить самостоятельно. Конкретные примеры такие: задачки из СИКПа (над большинством сижу по неделе, таким макаром я его читать буду года 3, что затормозит мой прогресс в других сферах программирования), некоторые задачи на работе (трачу очень много времени - вместо выделенных 3-х часов на таск, в итоге залогировано 9 часов).

Последние исследования говорят о том, что мозг пластичен, меняет свою структуру при развитии, но вопрос во времени и целесообразности действий.

Можно ли, используя правило 80\20, научиться прикладывать усилия в самых “нужных” местах, чтобы получить максимум возможного результата и потратить меньше ресурсов?

Ориентируйтесь не на исследования, а на ощущения: что говорит тело. Нет смысла тратить адское количество времени на СИКП. В итоге, убухав год, вы станете только одним из тех, кто прорешал весь СИКП. Таких как вы тысячи, но им по-прежнему тяжело найти работу в промышленной разработке и сделать карьеру. Насчет последнего вопроса: если я понял правильно, то да. Не обязательно прорешивать каждую проблему до самых мелочей. Для обучения достаточно понять суть и двигаться дальше, а вот уже на настоящем производстве решать задачу не на 100, а 200 процентов.

Углубляясь в профессию посредством курсов,статей или практики, определенные вещи даются хорошо, какие-то только на уровне понимания и использования (углубление откладывается на потом). Но с ходом времени, даже с минимальной практикой, то, что знал хорошо - забывается и с трудно воспроизводится даже с помощью конспектов, а отложенное для углубления - растёт как снежный ком. Причем, дело тут даже не в в самом “откладывании”, а скорее в кол-ве информации, которую нужно изучить. И такая ситуация происходит по сути на каждом уровне знаний, будь то фундаментальные вещи или продвинутые концепции.

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

Вопросы следующие: это перманентное ощущение незавершенности - это нормально? Как лучше учиться - идти дальше и все в конце концов сложится в пазл, либо пытаться “докопать” до конца? И как лучше структурировать материал/вести записи, когда информации действительно много? Может есть какие-то лайфхаки/материалы которые в этом помогут?

Ощущения незавершенности – нормально, особенно в процессе обучения. Все решения тренировочных задач незавершены, потому что это упрощение. Чередуйте движение вглубь с движением вперед. Рассматривайте мозг не как книжную полку, а индекс, который быстро направит к нужной полке. Не так важно, что вы не поняли быструю сортировку, это нужно отложить напотом и двигаться дальше.

1. Здравствуйте, сейчас пытаюсь изучать Machine Learning & Data Science и в процессе изучения возникают некоторые трудности, в частности когда речь заходит о мат. анализе или статистике, приходиться во время прочтения книги или просмотра курса, углубляться в те познания которые отсутствуют или были забыты. На это уходит достаточно много времени ,так как за изучением одной темы, скрывается другая и т.д. Хотелось бы узнать какую стратегию изучения выбрать - гуглить по мере поступления вопросов или сначало набраться нужного бекграунда и после приступать к изучению данной темы. Интересно ваше мнение и как бы вы поступили в данной ситуации.

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

Ответ на оба вопроса одинаковый. Все учебные материалы похожи, т.к. разрабатываются примерно по одной схеме. Правило простое – гуглите книги или курсы, берите тот, где больше звездочек. Этого достаточного для быстрого старта. Потом, чтобы опыт не выветрился, нужно затолкать себя в проект по этому направлению. Дальше вас будут учить опытные коллеги, они же подскажут материалы для продвинутого изучения.

Блокчейн (не касаясь криптовалют)- есть смысл погружаться в него? Технология войдёт в нашу жизнь, как смартфоны, или останется “игрушкой” а-ля эфир-зефир-койн?

Проблема Блокчейна в том, что он оброс толстым слоем всевозможных крипто-аналитиков, мошенников, сомнительных стартаперов. Выражение “крипто-стартап” вызывает тошноту. Скажем так – блокчейн как технология будет иметь место, но не настолько широкое, как заливают упомянутые лица. Просто будет такая технология, будут вакансии, случаи внедрения и отката. Стоит заметить, что за 10 лет Биткоина не появилось ни одного действительно полезного продукта на его базе, а это повод задуматься.

Как правильно заниматься по СИКП? Решать все задачи подряд, какие главы стоит пропускать? Заметил что между Последовательностями и Программированием, управляемым данными в книге есть немалый раздел про графическую и символьную часть.

Главное правило в том, что не нужно себя насиловать и выставлять СИКП как откровение. Это мощная книга, но вопрос в том, будет ли польза от того, что вы потратите год на решение всех задач. Мне кажется, будет лучше внимательно их разобрать. Польза будет такая же, а времени потратите на порядки меньше. Ну и за один только СИКП на работу вас никто не возьмет.

Когда по вашему мнению профессия программист исчезнет(как массовое явление)?(только честно). Ведь автоматизация в этом направлении уже идет…

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

1. Когда спрашивают на собеседовании об ООП, чтобы вы посоветовали отвечать? Классика жанра или по Алану Кею.

1. ML это мыльный пузырь или тренд на десятиление? Математика была готова как лет 40 назад, инструменты с 2000-х точно (matlab, excell, python), а вот реально доступные большие данные появились с 2010-х (вернее генерация данных для бизнеса). Это ж голый матстат и линалгебра. Откуда хайп? Почему все готовы учить ML? Есть ли реальный спрос на ML или все-таки это спрос на фундаментальных математиков?

1. Рекурсия. Почему многие языки так и не поддерживают оптимизацию хвостовой рекурсии?

1) Если вам позарез нужна эта работа, отвечайте по канонам, не нужно что-то доказывать. Вообще, при устройстве на первую работу полноценного мнения у вас и не может быть из-за малого опыта. Отвечайте что написано в книгах, если собеседник не согласен – не спорьте, а спросите прямо: у меня мало опыта, мне интересно ваше мнение. Это даст миллион очков в вашу пользу. Человек, который умеет слушать в сто раз полезней человека, который знает ООП. Собственное адекватное мнение про ООП у вас может быть только после 5-8 лет работы в промышленной разработке, но там и собеседование будет другое. Когда джуниора спрашивают про ООП, это скорее проверка на адекватность и базовую осведомленность.

2) Пожалуйста, не используйте слово “тренд”. Стараниями маркетологов, сеошников и прочих оно обесценилось до уровня слова “хайп”. Не хватает только банера мобильного оператора со слоганом “МТС это тренд”. Если по делу, ML займет определенную нишу. Оно уже показало, что способно решать важные задачи, поэтому будут вакансии, будут курсы. Тренд – это максималистическое, юношеское понятие (если речь не об экономике или промышленности). Кто-нибудь может сказать, что программирование на Руби это тренд? Мир быстро расширяется, и то, что вчера было “трендом”, становится просто устойчивой его частью. Можно неплохо зарабатывать обычным разработчиком сайтов безо всякого ML. Но если есть время и деньги на изучение – почему бы и нет. Помните, что после курсов нужно запихнуть себя в проект с ML, иначе все будет зря.

3) Потому что хвостовая рекурсия неочевидна даже опытному программисту. Каждый раз приходится напрягаться и определять, “оптимален” ли этот случай или нет. В императивных языках с изменяемыми переменными и циклами в ней вообще нет смысла. В Кложе специально ввели конструкцию loop-recur потому что это удобно – во-первых, сразу сигнал о том, что это хвастовая рекурсия (под капотом это цикл), во-вторых, она гарантирует жесткие проверки на “хвостовость”. В Скале требуется специальная аннотация. Словом, в императивных языках хвостовая рекурсия даром не нужна, в функциональных она должна быть явно обозначена.

Сколько оптимально выделять в день времени на труд над решением задач и изучением теории программирования, так чтобы не перегореть и двигаться более-менее эффективно?

Достаточно приходить на работу немного раньше, не читать соцсети, исключить посторонний шум. Тогда будет час времени, что достаточно на неглубокое изучение чего-то нового. Если времени не хватает, а страсть к предмету все выше, нужно переходить в проект, где с этим работают, или в конце концов отпустить это увлечение.

Что нужно делать чтобы развить soft-skills?

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

Я вот на эликсиреСкулл просматриваю текст Основы. Вот что мне делать. Я вот если прочту мне просто это повторять (кодить)? Быстро запоминаются? То есть как программисты работают с документацией?

Вы можете это повторить, но без гарантий, что в голове что-то останется. Повторение без педагога не всегда эффективно. Например, я могу повторить 100 китайских иероглифов без какой-либо пользы для изучения китайского языка. Так что я не уверен, что одно только повторение даст результат.

Эликсир есть смысл учить?(не участвую в конкурсе) Или другие лучше?(Руби, Ява,…) А зачем Язык Racket изучать? С++ толк есть изучать? А язык Go?

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

как стать веб разработчиком сайты…, и нужнали для этого математика какая иммено

Нет, “веб разработчиком сайты” математика не нужна.

Скажите, пожалуйста, сколько времени в день/неделю вы посвящаете на чтение книг, статей, ведете ли вы какие-либо пет-проекты ?

Я раньше читал и пилил пет-проекты много, теперь меньше, потому что дети. Этим летом планирую снова читать больше. На самом деле все зависит от желения, а не от времени.

Используете ли вы язык Go в разработке? Какие плюсы у этого языка, и где он находит применение?

Плюсы в простоте, высокой производительности, быстрому старту, изначальной ориентированности на сетевое программирование и распараллеливание задач. Применяется для командных утилит, микро-сервисов, сетевых программ. Поддерживается Гуглом, очень популярен в Китае. Из минусов – убогая система типизации, нет дженериков (общих типов, например “любое число”), бедный тулинг (система зависимостей).

heroku, firebase, gitlab и прочие сервисы - надо/не надо, как использовать, best practice

Очень поверхностный вопрос. Любой сервис можно использовать эффективно, если знать как. Короткий ответ – читайте документацию, в ней очень много полезного.

Добрый день. У меня к вам несколько вопросов:

1. Какие нерешенные задачи есть сейчас в программировании как в профессии?
2. Какие неочевидные риски ожидают человека при выборе профессии программиста?
3. Какие типовые ошибки совершаются при входе в профессию?
4. Каковы прогнозы по появлению новых направлений в программировании?

1) Для меня наболевшая проблема – неинформативные сообщения об ошибках, когда что-то не запускается. Почти ни одно сообщение невозможно понять, только поиск в Гугле.

2) Непонимание того, что в программировании много переговоров с заказчиком. Что вокруг одной строчки может быть обсуждение в несколько дней и десятки писем. Что в 9 случаев из 10 вы редактируете чужой код, а не пишете свой.

3) Думаю, все то, что следует из предыдущего пункта. А еще излишняя самоуверенность и презрение к чужому коду и языку.

4) Что-то на стыке технологий: программирование квантовых систем или нано-машин как это показано в игровой серии Metal Gear. По сюжету, в тела солдат внедряются микрочастицы, которыми можно управлять совокупно, например, подавлять боль, эмоции, контролировать доступ к оружию или территории.

Сейчас в сети можно найти много литературы по компьютерным и математическим темам , переводов иностранных авторов, которые издавались в СССР в 70-80-90-х годах. Некоторые из этих книг, например Алгоритмы + структуры данных = программы Н.Вирта рекомендуют почитать, даже несмотря на возраст книги, мол они действительно полезны в плане развития профессионального кругозора, особенно для начинающих программистов.

Вопрос такой - стоит ли читать такую литературу, именно для развития профессионального кругозора, чтобы просто самому больше узнать не только больше о программировании но и об истории этих наук, так сказать как это всё развивалось и как мы пришли к тому что имеем сегодня? Может просто показаться что эти книги старые, неактуальные, безвозвратно устарели и нет смысла в их прочтении.

Стоит, если это приносит удовольствие. Насиловать себя смысла нет. Удовольстве будет, если вы уже знаете материал и читаете книгу как подтверждение того, что вы крутой. Тогда читать будет ненапряжно. Гораздо хуже, если вы читаете через силу и вдобавок пишете об этом во все чаты. Вспоминается сарказм: если ты бегаешь по утрам, но никто об этом не знает, это не считается.

Продолжали бы вы заниматься программированием и обучать, если за это не получали денег?

Если абстактно – нет, деньги это неотъемлемая часть качественного труда. Если в реальности, я бы нашел способ получать за это деньги.

говорят что профессия программист для молодых после тридцати ты никому не нужен какой бы гуру ты не был, потому как можно взять молодого и ездить на нем

Абсолютная чушь, в тридцать только начинает появляться опыт. Всем моим коллегам по 30 с чем-то лет, у всех проекты. Другое дело, что возраст должен кореллировать с уровнем. Искать работу джуниором в 30 лет весьма сомнительно.

Расскажите, пожалуйста, каков, в вашем видении, должен быть процесс роста front-end разработчика после Middle-уровня. Я конечно, понимаю, что это все размытые понятие, и в разных компаниях это может обозначать кардинально разный уровень навыков и самостоятельно решаемых задач, но все же - какой путь развития выбрать после 2-3 лет в индустрии (хотя это уже наверное что-то между senior и middle будет)? Дальше развивать свои навыки, расширять стек и улучшать качество кода, становясь полноценным Senior? Подтягивать back-end (ту же ноду, например) и брать курс на full-stack разработчика? Или же плавно перекатываться вообще в менеджмент? Или архитектура?

Я понимаю, что направления разные и нельзя однозначно сказать, что одно лучше другого, но интересно, какие бы вы могли дать рекомендации относительно каждого из них, плюсы-минусы, а если еще и своим опытом поделитесь - вообще будет прекрасно:)

Я не уверен, что после Middle-уровня пора уходить куда-то в сторону. Нужно замечать, что оказывает влияние на конечный продукт – и довольно быстро выяснится, что все. И бекенд, и менеджмент. Невозможно сказать точно, что именно вам понадобится, так как это зависит от конкретного продукта. Просто берите больше ответственности и действуйте по ситуации.

Я достаточно апатичный человек. И это сильно мешает по жизни. С одной стороны, очень хочется выполнять работу в срок, дописать несколько начатых программ, всё успевать. Но с другой стороны, всё время заваливаю сроки, отвлекаюсь на мелочи и просто хандрю :-( Пытался составлять список дел, не хватило собранности ему следовать. Мне 22 года, учусь в университете по технической специальности. Есть опыт работы после колледжа. Как по Вашему опыту, есть выход из ситуации? Что посоветуете? И присоединяюсь к вопросу о soft-skills.

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

Как вы боролись в ActiveRecord в своем проекте, бодрые советы как не создавать божественные модели (PHP Yii, Laravel)

Не знаю, как это делается в указанных технологиях, но попробуйте поработать с сырым SQL с минимальными обвязками. Постепенно придет понимание, как лучше устроить работу с базой.

Как обьективно оценивать время для решения той или иной задачи и не впасть в крайности? И еще один очень важный вопрос - возможно ли эмоциональное выгорание в профессии программиста, из-за чего оно происходит, как решать?

Есть нехитрое правило – взять первую же оценку и умножить на два. Например, если кажется, что сделаешь задачу за день – бери два. Выгорание возможно по многим причинам, в том числе из-за проблем на уровне команды. Поможет отдых, разговор в непринужденной обстановке. Иногда нужно отпутсть цель, которую достичь будет слишком дорого. Иногда проще сменить проект. Все зависит.

Виртуальная реальность сейчас - это как интернет в прошлом? Что вы думаете о перспективах развития этого направления?

Мне кажется, VR будет связан с сексуальной темой – реалистичной порнографией и имитацией секса с воображаемым партнером. А может, и настоящим – при работе устройств в паре или по сети. Добавьте сюда материалы для имитации кожи, запахи, звуки, воздействие датчиков на эрогенные зоны, в общем – картина ясна. Тому способствуют два фактора. Первый – VR это технология исключительно для развлечения, ни к чему другому ее нельзя применить. Второй – никто не видит, что происходит у вас на мониторе. Все сходится.

Брался за программирование несколько раз в своей жизни, но всегда бросал. Проблемы были из-за мнений других людей. Допустим, негативный комментарий к коду на сайте про IT-тематику, который мог бы написать я (статья и код не мой, просто похожий образ мыслей) мог выбить меня из колеи на несколько месяцев. И всё в таком духе. Из-за этого боязнь задавать вопросы и т. д. Может быть, вопрос не по адресу, но что делать в такой ситуации? Спасибо.

Это проблема широкого плана. Главное понять, что комментарии относятся не лично к вам, а коду, который можно исправить. Еще помните, что в интернете нет баланса между положительными и отрицательными отзывами: можно собрать тонны ненависти за кривой виджет и ни слова похвалы за работающий в целом продукт. И вообще, слушать нужно только нескольких авторитетных для вас людей, мнением остальных полезно пренебречь.

Как не просто быстро, а супер быстро прокачивать скилл и ex. в разработке?

Запихать себя в проект с упором на то, что вы намерены прокачать.

Где можно найти достоверные толкования терминов программистких? И онлайн словарь Eng - Rus достоверный?

Достаточно спросить у коллег.

Как Находить проблемы которые нужно решить в программировании? В вебе.Или в фрейворках .Или как то еще. Задачи. На чем практиковаться.

Достаточно собрать отзывы пользователей вашего продукта в свободной форме. Работы хватит на несколько лет.

Что уже не нужно знать?( к примеру фронтендеру верстку?) Или что не так важно знать в программировании вообщем? пример - не нужно выполнять какие-то действия не из-за их простоты, а из-за того что они под капотом, и снаружи облегченное использование (н/р рельсы). Или полностью автоматическое …?

Я не знаю, есть ли что-то, чего не следует знать. Наверное, из чего делают колбасу? Если серьезно, любое упрощение подразумевает, что вы знаете, как устроен процесс. Уверенность в том, что это или то знать не нужно, может вас подвести. Утверждение звучит еще более нелепо, если речь идет о карьерном росте, который наоборот подразумевает рост ответственности и кругозора.

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

Повторюсь, нужно отдыхать, даже когда очень хочется засесть и фигачить код всю ночь. Не нужно ставить невыполнимых задач. Нужно уметь отпустить цель. Всякое знание закреплять на практике в реальных проектах.

С++ нужен для фронтенда? Как считаете он будет для веба популярен? И каковы перспективы ВебАсембли?

Не нужен, не будет. Насчет Веб-ассембли – не хотелось бы впадать в пространную аналитику. Потребность в нем есть, написано очень много JS-кода, который не хочется выбрасывать. Что-то из этого будет.

Добрый день . не подскажите ,я являюсь системным администратором и хотел бы переквалифицироваться. но глядя на все это со стороны “чайника” вижу и понимаю .что это пучина , озеро в которое бухаться очень страшно и непонятно с чего начинать , дак я о чем . подскажите с чего можно начать программирование ( преимущественно думаю выбрать php/javascript\html5) заранее спасибо.

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

Вопрос про участие в опенсорс проектах, стоит ли начинать новичку, какие плоды это принесет, как и с чего начать, и участвуете ли вы, если да то в каких? Спасибо!

Моя практика показала, что нет смысла соваться в опен-сорс без навыков закрытой коммерческой разработки. Опен-сорс сообщество порой ожидает опытных разработчиков. Это среда, в которой никто никому ничего не должен, и для начинающих это скорей вред. Мой совет – поработайте несколько лет в закрытом стиле, когда код только в репозитории заказчика. Только потом появится понимание, зачем вообще нужен опен-сорс.

Плоды это приносит хорошие, например, если вы автор популярной библиотеки, собеседование сводится к формальностям.

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

В моем случае это стала Кложа после 8 лет классических ООП- и императивных языков. Я со студенческих лет увлекался различными лиспами, но Кложа стала поворотным моментом. Замечу, что никакой перемены бы не было, если бы я не поменял работу на ту, где писали на Кложе. Так и осталась бы игрушечными проектами на Гитхабе. Отвечая на вопрос: неплохо развивают функциональные языки без лишних усложнений, это Clojure, Racket, Erlang, Haskell. Не Scala.

Как развивать в себе ментальное программирование? Посмотрел доклады, понял к чему нужно стремится, а как это сделать не понял.

Достаточно мысленно поделить проект на множество систем и группировать код согласно этому правилу. У вас есть подсистема авторизации, только она знает как это работает. Остальным модулям запрещено нырять в ее кишки, а только вызывать высокоуровневые функции. То же самое с обработкой оплат, блокировками пользователей и т.д.

Можете вспомнить и рассказать свой распорядок дня, когда нашли первую работу разработчиком?

Я работал много, без праздников и выходных. Еще нужно со всеми здороваться, причем первым. Побольше слушать тех, кто непосредственно влияет на твое обучение, и поменьше – случайных посторонних. Пользоваться возможностями, которая дает фирма: ездить на конференции, посещать семинары.

Есть много понятий: парадигмы, архитектуры, паттерны/шаблоны, методологии… Можно ли выстроить все понятия в некую структуру, чтобы видеть картину в общем: что есть что, для чего нужно и как все это между собой связано? Например, для чего нужен SOLID, для чего TDD, для чего ООП, что есть общего у этих понятий, в какой последовательности учить?

Паттерны хороши тем, что задают некий уровень и дисциплину. Например, в проекте принято решать проблему этим патерном, и никаким другим. Это лучше, чем вечный срач в команде. Чтобы связать все паттерны в единую структуру, нужна долгая практика. На самом деле это приводит к пониманию того, что паттерны – очень условная вещь, и группе специалистов порой проще договориться и писать код так, как удобно им. Но для начинающих лучше прочесть паттерны и отвечать на собеседованиях то, что хотят услышать наниматели.

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

В дополнение к своему среднему или высшему образованию, которое он сейчас получает, так сказать. Здесь можно говорить о многом, например сайты с задачами, форумы, группы в соц.сетях, каналы в telegram и т.д. Это всё конечно можно найти в том же Интернете, но новичок зачастую не знает, что ему действительно нужно и с большей вероятностью будет распыляться, всё искать что то новое. Вот например необходимый минимум, зная который он может искать что то новое, что нибудь такое хотелось бы услышать на вебинаре.

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

Ну, Хекслет хорош. Новичку гораздо полезнее будет группа опытных коллег, а не форумы.

Здравствуйте! В последнее время у меня в голове крутится этот вопрос, особенно перед сном. Вопрос на мой взгляд достаточно непростой и связан скорее всего, я так думаю с образом нашего мышления. Вопрос: Как научиться достойно и качественно продавать свои знания? Как научиться ценить свои знания? Спасибо.

Хороший вопрос, и не только знания, а вообще – труд. Мы думаем об одной сумме, но в последний момент смущаемся и занижаем, пугаясь насмешек, неодобрения. Думаю, достаточно будет один раз набраться смелости и назвать ту цену, которую хотели изначально. Самое страшное – заказчик предложит немного меньше. Но гораздо чаще он соглашается, потому что даже то, что вы потребовали изначально, было для него дешево.

Есть на хабре интересная статья под названием “Опасности обучения на Java” Если очень кратко, то суть сводится к тому, что сейчас “порог вхождения” низок и слабая “общая база”. Алгоритмическая подготовка, математическая подготовка и т.д. Далеко ходить не надо. Подтверждение этому курсы на каждом углу вроде “Стань Java программистом за три недели”. Вопрос прост и сложен одновременно: что поможет кодеру быть программистом? Как найти то, что будет полезно на этом пути? И кто может в этом помочь.

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

Хотелось бы чтобы затронули немного вопрос про мотивацию, допустим как себя мотивировать кодить, выполнять таски и в этом роде. Бывает такие моменты когда “штурмуешь” одну задачку несколько дней и падает мотивация дальше делать курсы, ведь подглядывать задачки не ок, а если начнёшь смотреть решение, то за одной задачкой и сразу другая последует. Хотелось бы ещё узнать планируются ли курсы по TypeScript, Angular2 + версии, Vue. Хотелось бы ещё побольше рекомендованной литературы, может какие книги посоветуете для саморазвития, которые можно почитать в свободное время от кодинга. Например Правило 10x. Художественная литература тоже приветствуется.

Мотивировать себя особо не нужно, изучение должно быть в удовольствие. Если задача не поддается за осмысленное время, нужно обращаться за советом к коллегам или сообществу. На практике вам никто не позволит сидеть над задачей три дня в ожидании, когда же вы наконец ее разрешите.

Недавно заинтересовала тема “депривации”, т.е. временное (или нет) лишение определенной потребности в чем-либо. Например, недавно я пробовал не спать 2 дня. Получил опыт и узнал о себе что-то новое. Также в этом году планирую временно лишить себя зрения на 10 дней, думаю будет интересно. Буду продолжать делать подобные тесты над собой и дальше. Например, сегодня перестал есть соль и сахар (для меня это не легкий шаг). Таким образом, можно придумать себе какие-либо ограничения для эксперимента или профилактики.

Зависит, извините, от вашей упоротости. Не спать два дня – вредно. Не пользоваться зрением 10 дней – имеет смысл если вы пишете книгу про слепых или снимаете фильм о слабовидящих, то есть пытаетесь вжиться в образ. А так зачем оно вам? Не есть сахар хорошо, а вот соль нужна в малых количествах. Периодически лишать себя чего-то полезно, но у вас полный разброс. Это скорее баловство, и я не вижу смысла.

Как стать архитектором?

Нужно сделать несколько проектов, где вы будете не только писать код, но и заниматься деплоем, проектировать связи между подсистемами, разрешать проблемы блокировок, производительности, масштабирования. Тогда можно писать в резюме – архитектор. Кстати, архитектор – это своего рода приманка в крупных фирмах. Я знаю много разработчиков, которые решают архитектурные проблемы, но числятся просто девелоперами. Все зависит, до чего вы договоритесь с заказчиком.

Кирилл упоминал не раз что не стоит о себе говорить как о Java-разработчике или python-разработчике, а надо говорить что мол инженер. Что делать в таком случае если в вакансиях стоят конкретные требования а-ля 5 лет опыта в js или Obj-C, как убедить работодателей что переход на другой язык дело месяцев максимум?

Чтобы удовлетворить рекрутеров, пишите в резюме одно, а в разговоре с коллегами говорите другое. Хотят они увидеть сеньора – впишите его. Не вижу конфликта. Переход на другой язык – это не дело месяца. Формально вы пишете другой код, но мыслите старыми парадигмами. Я бы не утверждал столь категорично.

Как нащупать свою нишу для создания IT продукта? Хочу рано или поздно запустить что-то свое, но пока ввиду отсутствия опыта и достаточного кругозора непонятно, как откопать что-нибудь интересное, какую-то острую для отрасли/профессии проблематику.

Трудно советовать, потому что у меня нет собственного по-настоящему успешного проекта. Мне кажется, он должен быть о том, что интересно лично вам. Например, один чувак забыл флешку когда сел в поезд. Он взбесился и написал то, что потом стало Дропбоксом. А меня бесит читать новости с сайтов, поэтому все, что я пишу в свободное время, так или иначе связано с RSS. Как-то так. Любите игры – делайте сайт об играх, о котиках, и тд.

По какому пути, по вашему мнению, стоит идти при разработке своего проекта:

1. Помимо необходимых HTML, CSS, JS освоить как можно больше технологий (Back/Front фреймворки [Django, Vue], базы данных, Nginx, Git, Webpack, Ansible, Docker и пр.), чтобы потом, как говорится в мультике «Лучше день потерять, зато потом за пять минут долететь» и к тому же меньше переделывать в дальнейшем?

2. Или же для начала сделать что-то простое с помощью нативных возможностей и имеющихся навыков, чтобы оно уже хоть как-то работало, индексировалось поисковиками, а потом по мере набирания опыта уже совершенствовать и дорабатывать?

Второе. С помощью минимального набора технологий выкатить что-то простое, начать продавать, потом улучшить.

какие методы и инструменты существуют для проверки отдачи от фич на недавно стартанувшем приложении? как решать какие фичи отбрасывать, а какие реализовывать и проверять?

Надо внедрять фичи, которые приносят больше денег.

что рассказать на вопрос про ООП на собеседовании?

Уже было выше – не надо отсебятины, рассказывайте то, что написано в Википедии и книгах. Если собеседник не согласен – послушайте его точку зрения. Заодно разведаете обстановку в фирме.

Как победить закостенелось в команде из разряда “мы всегда так программировали”, когда это явно приносит не самые плохие, но далеко не выдающиеся результаты? И отсрочка проблем вида “сейчас некогда, потом поправим”, а потом никогда не наступает.

Никак, потому что это означает менять не код, а мышление людей. Это может быть слишком дорого. И потом, для проекта это может быть оптимальный вектор развития. В сети полно историй успеха, когда X переписывали на Y и все было круто. Но гораздо больше случаев, когда это кончалось фейлом. Проверьте, насколько успешно вы внедряете фичи, насколько держитесь графика. Возможно, проблемы можно подтянуть не сменой языка, а улучшением атмосферы в проекте, реорганизацией графика релизов и тд.