Продолжение… Благодаря всяким активностям я быстро довел офис компании до 50 разработчиков, большую часть из которых обучал с очень базового уровня. Мы начали активно вести людей из других городов, брать студентов на летнюю стажировку и, в целом, создавать ореол самой технологичной компании в городе с самой развитой инженерной культурой. Экстремальное программирование, DevOps, функциональное программирование — все это мы разгоняли так сильно, что остальные компании начали брать с нас пример, чтобы люди перестали уходить к нам.
Про то, как было устроено обучение внутри Undev, я расскажу в будущих постах. А сейчас просто скажу, что к концу всей этой движухи в городе появилось около 5 новых филиалов московских и международных компаний с суммарным количеством Ruby разработчиков > 200. В Google Trends видно, как в эти годы резко скаканул интерес к Rails в городе.
Забавно, но я стал специалистом по открытию филиалов. Успех офиса Undev привел к тому, что ко мне стали обращаться разные компании, которые хотели повторить эту схему. Всем было интересно, как у нас получается находить и обучать людей в таком количестве. А желающих работать в Undev тогда было уже столько, что они стояли в очереди. Как только появлялся очередной филиал, я пускал этот поток туда. Помнится, даже в то время мне написал Epam (вроде бы) и предложил открыть и возглавить их филиал в Аргентине, но почему-то не срослось. Постепенно я понимал, что все это добро хочется сохранить и масштабировать. Я начал думать о том, чтобы такое замутить.
Как раз в 2012 году Рахим Давлеткалиев запустил проект Hexlet.ru. Я прочитал о нем на
Хабре и расстроился. Подумал: «Черт, этот чувак обогнал меня, теперь непонятно, что делать». А дальше случилось следующее: меня пригласили выступить на конференцию Happydev в 2013 году. По счастливой случайности туда ехал и Рахим. Нас познакомили и мы поняли, что хотим заниматься примерно одним и тем же. Спустя какое-то время Рахим позвонил мне и предложил стать партнером. И примерно в середине 2013 года мы начали работать над новым Хекслетом, который спустя примерно два года приобрел тот вид, который он имеет сейчас.
Зачем я написал этот пост? Хотел, чтобы эта история не пропала и стала для кого-то вдохновением. Кроме того, вам будет лучше понятно и мою мотивацию, и то, как появился тот Хекслет, который вы знаете (или узнаете). Как видите история началась задолго до и у нее не было шансов не выйти наружу.
Про то, как было устроено обучение внутри Undev, я расскажу в будущих постах. А сейчас просто скажу, что к концу всей этой движухи в городе появилось около 5 новых филиалов московских и международных компаний с суммарным количеством Ruby разработчиков > 200. В Google Trends видно, как в эти годы резко скаканул интерес к Rails в городе.
Забавно, но я стал специалистом по открытию филиалов. Успех офиса Undev привел к тому, что ко мне стали обращаться разные компании, которые хотели повторить эту схему. Всем было интересно, как у нас получается находить и обучать людей в таком количестве. А желающих работать в Undev тогда было уже столько, что они стояли в очереди. Как только появлялся очередной филиал, я пускал этот поток туда. Помнится, даже в то время мне написал Epam (вроде бы) и предложил открыть и возглавить их филиал в Аргентине, но почему-то не срослось. Постепенно я понимал, что все это добро хочется сохранить и масштабировать. Я начал думать о том, чтобы такое замутить.
Как раз в 2012 году Рахим Давлеткалиев запустил проект Hexlet.ru. Я прочитал о нем на
Хабре и расстроился. Подумал: «Черт, этот чувак обогнал меня, теперь непонятно, что делать». А дальше случилось следующее: меня пригласили выступить на конференцию Happydev в 2013 году. По счастливой случайности туда ехал и Рахим. Нас познакомили и мы поняли, что хотим заниматься примерно одним и тем же. Спустя какое-то время Рахим позвонил мне и предложил стать партнером. И примерно в середине 2013 года мы начали работать над новым Хекслетом, который спустя примерно два года приобрел тот вид, который он имеет сейчас.
Зачем я написал этот пост? Хотел, чтобы эта история не пропала и стала для кого-то вдохновением. Кроме того, вам будет лучше понятно и мою мотивацию, и то, как появился тот Хекслет, который вы знаете (или узнаете). Как видите история началась задолго до и у нее не было шансов не выйти наружу.
🔥104👍30❤15💩3
Вы знали, что программисты могут работать в парах? Такая техника называется парное программирование и она регулярно используется профессиональными программистами.
Парное программирование работает так: один программист пишет код, а второй находится у него за спиной — возможно виртуально, если программисты не сидят рядом. Он смотрит на код, дает, если надо, подсказки и указывает на ошибки, если их видит.
В чем преимущество парного программирования? Разве это не трата времени? Оказывается, это эффективная техника, которая дает массу плюсов:
Фокусировка. Программисты, не отвлекаясь, доводят задачу до конца. Из-за этого, кстати, оно энергозатратно. С непривычки достаточно тяжело продержаться хотя бы час.
Скорость принятия решений. Два программиста значительно быстрее находят баги и принимают сложные архитектурные решения. То, что у одного может занять часы и дни, у двоих программистов занимает считанные минуты. Не всегда, но значительно чаще, чем поодиночке.
Взаимное обучение. Сюда входит все — начиная от эффективного использования, заканчивая какими-то приемами программирования. Парное программирование — лучший способ распространять знания в команде. Особенно эффективно это работает в паре новичок-опытный.
Последний пункт для нас особенно важен. Обучение работает эффективнее всего в парах даже для двух новичков. Новички часто имеют пробелы в базовых концепциях и у разных людей эти пробелы в разных местах. Там, где один будет тупить часами, второй найдет проблему сразу, потому что прочитает сообщение об ошибке.
Кстати, парное программирование применяется и на собеседованиях тоже
Вот несколько советов о том, как правильно проводить парное программирование:
1. До начала работы важно убедиться, что у пары совпадают стандарты кодирования, иначе это может повлечь за собой ненужные споры
2. Парное программирование не стоит делать, если задача слишком легкая и понятная для обоих
3. Парное программирование не стоит делать, если задача слишком сложная и требует постоянного чтения документации/анализа/думания
4. Пары должны меняться ролями каждые 20 минут
5. Пока один пишет, второй наблюдает, а не занимается своими делами
6. По началу лучше ограничиваться 1-2 часами парного кодинга
Посмотрите видео с лучшими практиками от Atlassian
Парное программирование работает так: один программист пишет код, а второй находится у него за спиной — возможно виртуально, если программисты не сидят рядом. Он смотрит на код, дает, если надо, подсказки и указывает на ошибки, если их видит.
В чем преимущество парного программирования? Разве это не трата времени? Оказывается, это эффективная техника, которая дает массу плюсов:
Фокусировка. Программисты, не отвлекаясь, доводят задачу до конца. Из-за этого, кстати, оно энергозатратно. С непривычки достаточно тяжело продержаться хотя бы час.
Скорость принятия решений. Два программиста значительно быстрее находят баги и принимают сложные архитектурные решения. То, что у одного может занять часы и дни, у двоих программистов занимает считанные минуты. Не всегда, но значительно чаще, чем поодиночке.
Взаимное обучение. Сюда входит все — начиная от эффективного использования, заканчивая какими-то приемами программирования. Парное программирование — лучший способ распространять знания в команде. Особенно эффективно это работает в паре новичок-опытный.
Последний пункт для нас особенно важен. Обучение работает эффективнее всего в парах даже для двух новичков. Новички часто имеют пробелы в базовых концепциях и у разных людей эти пробелы в разных местах. Там, где один будет тупить часами, второй найдет проблему сразу, потому что прочитает сообщение об ошибке.
Кстати, парное программирование применяется и на собеседованиях тоже
Вот несколько советов о том, как правильно проводить парное программирование:
1. До начала работы важно убедиться, что у пары совпадают стандарты кодирования, иначе это может повлечь за собой ненужные споры
2. Парное программирование не стоит делать, если задача слишком легкая и понятная для обоих
3. Парное программирование не стоит делать, если задача слишком сложная и требует постоянного чтения документации/анализа/думания
4. Пары должны меняться ролями каждые 20 минут
5. Пока один пишет, второй наблюдает, а не занимается своими делами
6. По началу лучше ограничиваться 1-2 часами парного кодинга
Посмотрите видео с лучшими практиками от Atlassian
👍38🔥5💩2❤1
Воу воу, Хабр оценил школы программирования. Угадайте кто на первом месте 🙂 https://habr.com/ru/post/710330/
Хабр
Лучшие школы программирования в 2024 (голосование)
Вы интересуетесь программированием, но не знаете, с чего начать? Сейчас с этим сложности не возникают. В интернете можно найти курсы программирования и приобрести ценные...
👍54🔥30❤12🎉7💩3
В одном из прошлых постов кто-то спросил: «Почему про Хекслет так мало отрицательных отзывов?». Вопрос появился из-за того, что это выглядит подозрительным со стороны. Давайте я отвечу, почему так происходит.
Первое, что хочется сказать — люди по собственной воле в основном оставляют только отрицательные отзывы. Положительные оставляют тоже, но все же компаниям для этого приходится прилагать дополнительные усилия, например, просить оставить отзыв. Чаще всего мы с этим сталкиваемся в мобильных приложениях, которые то и дело спрашивают «как мы вам?»,
Из чего вообще складываются отзывы на обучающие курсы, подобные Хекслету? Может показаться, что людей интересует только само обучение, но это не так. Отзыв обычно включает в себя отношение к следующим моментам:
Продажа. Как человек поговорил с продажником по телефону, как его провели по всему пути до момента оплаты.
Онбординг. Как человек попал внутрь системы и приступил к обучению.
Процесс обучения. Не с точки зрения программы и знаний, а именно то, как его ведут, как помогают, как заботятся о нем и решают возникающие проблемы. А такое бывает, например, когда человек не успевает и просит дать академ.
Само обучение. Как студента непосредственно учат, проверяют, наставляют и выполняют все те обещания, которые были красиво описаны на лендингах.
Платформа. Сюда входят тренажеры, автоматизации, оповещения, уроки и все остальное. Такие системы называются LMS (Learning Management Systems).
Возврат денег. Часть, которая таит в себе наибольшее число сюрпризов со стороны многих компаний. Стоит особняком, потому что она сильнее всего отражается на том, в каком настроении уйдет человек и что он будет говорить про компанию.
Вернемся к нашему вопросу. Почему о Хекслете мало негатива? Ответ кроется в том, что устройство Хекслета не дает нам шансов облажаться сразу во всех этих аспектах. Если про нас пишут негатив, то почти всегда видят и плюсы, и минусы, а не только одни минусы:
Продажа. У наших продавцов нет задачи «продать любой ценой», скорее они выступают в роли консультантов, которые помогают понять, надо человеку или нет. Если они видят, что не надо, то скорее отговорят от покупки. Вы не поверите, но у нас (как и в других компаниях) встречаются ситуации, когда клиенту просто не нравится, как работает компания, например, что продажа идет через банковскую рассрочку. В итоге такие клиенты могут не просто пойти написать отзыв негодования, но они еще иногда позволяют себе кричать матом на наших ребят, что нас сильно расстраивает.
Онбординг. Здесь признаюсь честно, у нас были косяки в начале 2022 года. Тогда мы только отстраивали процесс и иногда теряли ребят в суматохе, а им приходилось самим раскапывать, куда идти и что делать. Сейчас же это автоматизированный, полностью контролируемый процесс. Да, ошибки по прежнему случаются, но это скорее исключение.
Процесс обучения. Здесь бывает, что жалуются на медленность ответов или «бесполезность наставников». По факту часто оказывается, что все сложнее, так как человек сам не задает вопросов или ждет, что ответ придет в течение 5 минут. Откуда мы это знаем? Все ходы записаны) Другой вопрос, что с этим мало что можно поделать, максимум попытаться связаться с человеком или написать ответ на отзыв. В любом случае часть с наставниками у нас контролируется целой командой, более того, я сам провел более 400 собеседований наставников и отобрал лучших. На моем ютубе лежит аж три видео с разбором этих собесов. Ну а тех наставников, которые действительно не справляются, мы отслеживаем и расстаемся с ними.
Само обучение. Большую часть курсов я писал сам, в другой части участвовал как со-автор и эксперт, который контролирует происходящее. За свой контент мы ручаемся, он самобытный и при этом создан по собственной методике, о которой я рассказываю в нашей школе авторов. Плюс этого контента в том, что он по большей части текстовый. Такой контент не может стать хуже сам по себе, он становится только лучше благодаря постоянным доработкам. Основная претензия здесь к непонятности формулировок заданий или сложной практике.
Первое, что хочется сказать — люди по собственной воле в основном оставляют только отрицательные отзывы. Положительные оставляют тоже, но все же компаниям для этого приходится прилагать дополнительные усилия, например, просить оставить отзыв. Чаще всего мы с этим сталкиваемся в мобильных приложениях, которые то и дело спрашивают «как мы вам?»,
Из чего вообще складываются отзывы на обучающие курсы, подобные Хекслету? Может показаться, что людей интересует только само обучение, но это не так. Отзыв обычно включает в себя отношение к следующим моментам:
Продажа. Как человек поговорил с продажником по телефону, как его провели по всему пути до момента оплаты.
Онбординг. Как человек попал внутрь системы и приступил к обучению.
Процесс обучения. Не с точки зрения программы и знаний, а именно то, как его ведут, как помогают, как заботятся о нем и решают возникающие проблемы. А такое бывает, например, когда человек не успевает и просит дать академ.
Само обучение. Как студента непосредственно учат, проверяют, наставляют и выполняют все те обещания, которые были красиво описаны на лендингах.
Платформа. Сюда входят тренажеры, автоматизации, оповещения, уроки и все остальное. Такие системы называются LMS (Learning Management Systems).
Возврат денег. Часть, которая таит в себе наибольшее число сюрпризов со стороны многих компаний. Стоит особняком, потому что она сильнее всего отражается на том, в каком настроении уйдет человек и что он будет говорить про компанию.
Вернемся к нашему вопросу. Почему о Хекслете мало негатива? Ответ кроется в том, что устройство Хекслета не дает нам шансов облажаться сразу во всех этих аспектах. Если про нас пишут негатив, то почти всегда видят и плюсы, и минусы, а не только одни минусы:
Продажа. У наших продавцов нет задачи «продать любой ценой», скорее они выступают в роли консультантов, которые помогают понять, надо человеку или нет. Если они видят, что не надо, то скорее отговорят от покупки. Вы не поверите, но у нас (как и в других компаниях) встречаются ситуации, когда клиенту просто не нравится, как работает компания, например, что продажа идет через банковскую рассрочку. В итоге такие клиенты могут не просто пойти написать отзыв негодования, но они еще иногда позволяют себе кричать матом на наших ребят, что нас сильно расстраивает.
Онбординг. Здесь признаюсь честно, у нас были косяки в начале 2022 года. Тогда мы только отстраивали процесс и иногда теряли ребят в суматохе, а им приходилось самим раскапывать, куда идти и что делать. Сейчас же это автоматизированный, полностью контролируемый процесс. Да, ошибки по прежнему случаются, но это скорее исключение.
Процесс обучения. Здесь бывает, что жалуются на медленность ответов или «бесполезность наставников». По факту часто оказывается, что все сложнее, так как человек сам не задает вопросов или ждет, что ответ придет в течение 5 минут. Откуда мы это знаем? Все ходы записаны) Другой вопрос, что с этим мало что можно поделать, максимум попытаться связаться с человеком или написать ответ на отзыв. В любом случае часть с наставниками у нас контролируется целой командой, более того, я сам провел более 400 собеседований наставников и отобрал лучших. На моем ютубе лежит аж три видео с разбором этих собесов. Ну а тех наставников, которые действительно не справляются, мы отслеживаем и расстаемся с ними.
Само обучение. Большую часть курсов я писал сам, в другой части участвовал как со-автор и эксперт, который контролирует происходящее. За свой контент мы ручаемся, он самобытный и при этом создан по собственной методике, о которой я рассказываю в нашей школе авторов. Плюс этого контента в том, что он по большей части текстовый. Такой контент не может стать хуже сам по себе, он становится только лучше благодаря постоянным доработкам. Основная претензия здесь к непонятности формулировок заданий или сложной практике.
making.hexlet.io
Образовательные проекты Хекслета
Делитесь своим опытом в программировании, развивайте новые навыки и компетенции, растите в цене и получайте дополнительный доход!
👍28❤11🔥3💩2🤔1💯1
Продолжение.
В этом есть доля правды, и над этой задачей трудится внутренняя команда, которая каждый день вносит десятки изменений в разные курсы. Иногда жалобы связаны с тем, что людям не нравится набор технологий, которым мы учим или даже порядок, в котором мы что-то объясняем. Но такие претензии почти всегда связаны с представлениями людей о программировании, которые искажены чем-то, например, «а вот там по-другому» или «а мой друг сказал, что рекурсия не нужна».
Платформа. Здесь у Хекслета, пожалуй, самая сильная позиция на рынке. Я не встречал ни одного человека, который бы объективно хаял нашу платформу. Она создавалась много лет, тренажер работает как часы, автоматизировано практически все, даже проекты, которые сами из себя представляют достаточно сложные системы. В целом, этот пункт идет в плюс почти во всех отрицательных отзывах.
Возврат денег. С этим пунктом у нас полный порядок. Мы всегда возвращаем неиспользуемые деньги с расчетом по дням, а в первые две недели делаем полный возврат в соответствии с законодательством. Да, мы, конечно же, в начале спросим, что случилось и попробуем исправить ошибку, но мы всегда возвращаем деньги. И я подозреваю, это ключевая причина того, что никто никогда не обрушивался с яростью на Хекслет.
Видно, что облажаться сразу во всех этих пунктах для одного клиента просто нереально. В итоге отрицательные отзывы отрицательны всегда по части вещей. При этом часто эта отрицательность является не нашим недостатком, а отношением человека к тому, что мы делаем, например, «они учат фреймворку A, а нужно учить фреймворку B».
Даже более того, у нас недавно был созвон, на котором мы разбирали ситуацию с одним отзовиком, где появилось сразу несколько таких отзывов. Мы написали этим ребятам с просьбой подтвердить подлинность отзывов, и сразу после этого они их молча удалили. То есть получается, что эти ребята сами накатали отрицательные отзывы.
В любом случае, каждый отрицательный отзыв проходит у нас внутреннюю проверку, мы пытаемся связаться с автором, выяснить, что пошло не так, и разобраться с первопричиной проблемы. И, конечно, такие отзывы помогают нам становиться лучше.
Расскажите, с чем вы сталкивались сами на Хекслете и не только.
В этом есть доля правды, и над этой задачей трудится внутренняя команда, которая каждый день вносит десятки изменений в разные курсы. Иногда жалобы связаны с тем, что людям не нравится набор технологий, которым мы учим или даже порядок, в котором мы что-то объясняем. Но такие претензии почти всегда связаны с представлениями людей о программировании, которые искажены чем-то, например, «а вот там по-другому» или «а мой друг сказал, что рекурсия не нужна».
Платформа. Здесь у Хекслета, пожалуй, самая сильная позиция на рынке. Я не встречал ни одного человека, который бы объективно хаял нашу платформу. Она создавалась много лет, тренажер работает как часы, автоматизировано практически все, даже проекты, которые сами из себя представляют достаточно сложные системы. В целом, этот пункт идет в плюс почти во всех отрицательных отзывах.
Возврат денег. С этим пунктом у нас полный порядок. Мы всегда возвращаем неиспользуемые деньги с расчетом по дням, а в первые две недели делаем полный возврат в соответствии с законодательством. Да, мы, конечно же, в начале спросим, что случилось и попробуем исправить ошибку, но мы всегда возвращаем деньги. И я подозреваю, это ключевая причина того, что никто никогда не обрушивался с яростью на Хекслет.
Видно, что облажаться сразу во всех этих пунктах для одного клиента просто нереально. В итоге отрицательные отзывы отрицательны всегда по части вещей. При этом часто эта отрицательность является не нашим недостатком, а отношением человека к тому, что мы делаем, например, «они учат фреймворку A, а нужно учить фреймворку B».
Даже более того, у нас недавно был созвон, на котором мы разбирали ситуацию с одним отзовиком, где появилось сразу несколько таких отзывов. Мы написали этим ребятам с просьбой подтвердить подлинность отзывов, и сразу после этого они их молча удалили. То есть получается, что эти ребята сами накатали отрицательные отзывы.
В любом случае, каждый отрицательный отзыв проходит у нас внутреннюю проверку, мы пытаемся связаться с автором, выяснить, что пошло не так, и разобраться с первопричиной проблемы. И, конечно, такие отзывы помогают нам становиться лучше.
Расскажите, с чем вы сталкивались сами на Хекслете и не только.
❤32👍19🔥4💩2
А давайте снова решим задачку)
Источник: https://braingames.ru/?path=comments&puzzle=371
Источник: https://braingames.ru/?path=comments&puzzle=371
braingames.ru
Задача Шесть шариков [Категория Взвешивания]
Есть 2 синих, 2 красных и 2 зеленых шарика. В каждом цвете один из шариков тяжелее другого. Все легкие шарики имеют одинаковый вес, все тяжелые — тоже. Есть также весы с двумя чашками без гирь. Сколько взвешиваний минимально необходимо для гарантированного…
💩4🤔2👍1🤮1
https://twitter.com/mokevnin/status/1620959918399361024 Что вы об этом думаете ребята?
Twitter
Кстати давно хотел сказать. У новичков в головах есть понятие "устроился на мидла" из-за вот таких историй. Можно устроиться на зарплату мидла это правда, но человек не станет от этого мидлом по факту. Мидл это не зарплата или запись в трудовой, это степень…
🤔2💩2😁1
Какие зарубежные источники читать, если хочется быть в теме происходящего в программировании? Давайте об этом поговорим.
Сначала небольшой интересный факт. В англоязычном мире IT не обозначает то, к чему мы с вами привыкли. Разработка в том виде, в котором мы себе ее представляем, это Tech.
Самый очевидный пример англоязычного источника информации — это Stackoverflow https://stackoverflow.com. Тут хочешь не хочешь, а все равно туда попадешь, если начинаешь гуглить ошибки и технические детали. Специально сидеть на этом сайте не нужно, но он так или иначе будет появляться в вашей ежедневной работе.
Следующий, уже неочевидный для внешнего человека проект — это Reddit https://reddit.com. Он охватывает все аспекты жизни. Это свой целый мир, где можно найти сообщество практически по всему, чему угодно. Реддит делится на сабреддиты, которые выступают в роли своих отдельных сообществ. Там люди задают вопросы, постят интересную информацию и в целом получают ответы от реальных людей. Например, если я что-то гуглю и хочу увидеть отношение к этому людей, а не заказные статьи, то я ищу на реддите. Пример сабреддита, посвященному обучению программированию, можно посмотреть тут https://www.reddit.com/r/learnprogramming/
Дальше идет Dev https://dev.to — проект, который напоминает Хабр. На нем значительно меньше активности в плане комментариев, но встречаются неплохие посты от разных ребят.
Много технических статей можно найти на проекте HackerNoon https://hackernoon.com. Здесь не только само программирование, но и технологии, бизнес, и много чего еще.
Hacker News https://news.ycombinator.com — здесь публикуются ссылки на какие-то интересные статьи пользователям. Дальше их очень подробно обсуждают. В комментариях часто можно встретить очень известных людей.
Ну и последнее — это https://twitter.com. Так повелось, что твиттер — это основной способ распространения любой технической информации и даже обучение. Если фоловить правильных людей как в русскоязычном, так и в англоязычном мире, то можно начать неплохо разбираться в происходящем вокруг. Между тем мы планируем в ближайшем будущем создать такой список и поделиться им с вами.
#заметки
Сначала небольшой интересный факт. В англоязычном мире IT не обозначает то, к чему мы с вами привыкли. Разработка в том виде, в котором мы себе ее представляем, это Tech.
Самый очевидный пример англоязычного источника информации — это Stackoverflow https://stackoverflow.com. Тут хочешь не хочешь, а все равно туда попадешь, если начинаешь гуглить ошибки и технические детали. Специально сидеть на этом сайте не нужно, но он так или иначе будет появляться в вашей ежедневной работе.
Следующий, уже неочевидный для внешнего человека проект — это Reddit https://reddit.com. Он охватывает все аспекты жизни. Это свой целый мир, где можно найти сообщество практически по всему, чему угодно. Реддит делится на сабреддиты, которые выступают в роли своих отдельных сообществ. Там люди задают вопросы, постят интересную информацию и в целом получают ответы от реальных людей. Например, если я что-то гуглю и хочу увидеть отношение к этому людей, а не заказные статьи, то я ищу на реддите. Пример сабреддита, посвященному обучению программированию, можно посмотреть тут https://www.reddit.com/r/learnprogramming/
Дальше идет Dev https://dev.to — проект, который напоминает Хабр. На нем значительно меньше активности в плане комментариев, но встречаются неплохие посты от разных ребят.
Много технических статей можно найти на проекте HackerNoon https://hackernoon.com. Здесь не только само программирование, но и технологии, бизнес, и много чего еще.
Hacker News https://news.ycombinator.com — здесь публикуются ссылки на какие-то интересные статьи пользователям. Дальше их очень подробно обсуждают. В комментариях часто можно встретить очень известных людей.
Ну и последнее — это https://twitter.com. Так повелось, что твиттер — это основной способ распространения любой технической информации и даже обучение. Если фоловить правильных людей как в русскоязычном, так и в англоязычном мире, то можно начать неплохо разбираться в происходящем вокруг. Между тем мы планируем в ближайшем будущем создать такой список и поделиться им с вами.
#заметки
Stack Overflow
Newest Questions
Stack Overflow | The World’s Largest Online Community for Developers
👍40❤8💩3
Как вы думаете, сильно ли совпадает то, сколько зарабатывает компания, и то, какого качества у нее продукт? Вы знаете, что среди обучающих компаний, есть такой рейтинг, в который также входит Хекслет. Угадайте, на каком мы месте) https://edtechs.ru/
🤔13👍3🤮3
Кирилл, можешь написать о том как научиться выделять абстракции и декомпозировать задачи? Как лучше подходить к задаче, пробовать написать сразу, а потом рефакторить и пытаться выделить из монолита абстракции или сначала подумать подольше основательно и сразу выделять абстракции ? может какие-то книги или языки хорошо прокачивают в этом?
Такой вопрос был в одном из комментариев к посту. Речь идет про написание фронтенда с помощью React.
Действительно существует два подхода: снизу-вверх и сверху-вниз. Первый когда мы детально прорабатываем элементы системы, а потом соединяем их во что-то одно большое. Второй наоборот - сначала делаем общую картину, затем детализируем.
Часто, желание сделать хорошо, приводит программистов к мысли, что код нужно сразу разделять на множество независимых частей, которые хорошо друг от друга отделены и могут использоваться независимо если понадобится. Звучит красиво, но на практике не работает. Почему?
Причин этому довольно много, но есть одна главная. Дело в том, что программист всегда находится в режиме обучения. Новые задачи, новые сложности, новые сущности, новые абстракции, новые взаимодействия и так далее. Крайне редко заранее можно понять куда все повернет и как лучше будет организовать все это дело. Основной способ разобраться это получить реальный опыт, увидеть ограничения и на их основе все разложить по модулям/системам/компонентам/сервисам.
Когда программист разбивают систему на куски не имея представления о вариантах использования, он перестает учиться. Проблема в том, что если мы сразу “выделили абстракции”, это значительно усложняет рефлексию на тему “а в ту ли сторону мы идем”. Все уже разбито и воспринимается как данность.
И даже если мы поймем, что разбиение на куски прошло неудачно, нам все равно будет сложно. Монолит разделять намного легче, чем любую разделенную систему. Это легко видеть по открытым проектам на github. Почти всегда, когда кто-то начинает пилить новый фреймворк или тяжелую библиотеку, он делает их как единое целое прямо описывая “для простоты мы все храним в одном месте, когда фреймворк будет готов и мы поймем какая часть за что отвечает, мы разделим все это по независимым компонентам”.
Такой вопрос был в одном из комментариев к посту. Речь идет про написание фронтенда с помощью React.
Действительно существует два подхода: снизу-вверх и сверху-вниз. Первый когда мы детально прорабатываем элементы системы, а потом соединяем их во что-то одно большое. Второй наоборот - сначала делаем общую картину, затем детализируем.
Часто, желание сделать хорошо, приводит программистов к мысли, что код нужно сразу разделять на множество независимых частей, которые хорошо друг от друга отделены и могут использоваться независимо если понадобится. Звучит красиво, но на практике не работает. Почему?
Причин этому довольно много, но есть одна главная. Дело в том, что программист всегда находится в режиме обучения. Новые задачи, новые сложности, новые сущности, новые абстракции, новые взаимодействия и так далее. Крайне редко заранее можно понять куда все повернет и как лучше будет организовать все это дело. Основной способ разобраться это получить реальный опыт, увидеть ограничения и на их основе все разложить по модулям/системам/компонентам/сервисам.
Когда программист разбивают систему на куски не имея представления о вариантах использования, он перестает учиться. Проблема в том, что если мы сразу “выделили абстракции”, это значительно усложняет рефлексию на тему “а в ту ли сторону мы идем”. Все уже разбито и воспринимается как данность.
И даже если мы поймем, что разбиение на куски прошло неудачно, нам все равно будет сложно. Монолит разделять намного легче, чем любую разделенную систему. Это легко видеть по открытым проектам на github. Почти всегда, когда кто-то начинает пилить новый фреймворк или тяжелую библиотеку, он делает их как единое целое прямо описывая “для простоты мы все храним в одном месте, когда фреймворк будет готов и мы поймем какая часть за что отвечает, мы разделим все это по независимым компонентам”.
👍71❤11💩2🔥1🤔1👌1
Насколько сложно быть фулстеком? Этот вопрос не раз становился яблоком раздора между разными людьми. Одни говорят, что это невозможно, другие — что компании просто хотят экономить. Третьи же пишут фронт, бэк и еще успевают заниматься администрированием. Разберемся и подискутируем?)
Короткий ответ: конечно да, таких людей вокруг нас полно.
Теперь чуть подробнее. Обычно все происходит так: когда человек начинает программировать и делает это год или два, то он находится в состоянии постоянного ощущения «как же все это можно выучить». Это нормальное состояние, которое рано или поздно заканчивается. Программист входит в режим того, что задачи становятся понятны, в голове всегда есть примерный план решения, а нужные инструменты чувствуются на кончиках пальцев.
Это тот самый момент, когда возможна развилка. Кто-то продолжает просто работать и читать статьи на Хабре, кто-то еще серьезнее закапывается в свою область, изучает соседние фреймворки, другие подходы. Кто-то даже доходит до того, что включается в разработку инструментария, библиотек и фреймворков. И вот тут и есть люди, которые понимают, что было бы неплохо узнать другую сторону.
Вдруг оказывается, что с другой стороны все устроено не так уж и сложно. Да, есть свои особенности, в бэкенде это базы данных, а во фронтенде — DOM и событийная модель, но глобально тоже самое программирование. Постепенно эти люди включаются в разработку обеих частей и перестают об этом переживать.
У меня этот путь занял около семь лет, что довольно долго. То есть я пять лет занимался только бэкендом. HTML/CSS туда немного входили, но JS — нет. И только потом я взялся за фронтенд. Правда, справедливости ради, до фронтенда я изучил администрирование и функциональное программирование. Сейчас же написать бэк на Elixir, настроить Kubernetes кластер или запилить приложение на React — как раз плюнуть :) На это хватило «всего-то» 15 лет жизни.
Есть несколько распространенных заблуждений, которые транслируют, если речь заходит про фулстеков. Вот некоторые из них:
> Фулстек — это недопрограммист, он плохо разбирается и в бэке, и во фронте.
В жизни все с точностью до наоборот. Фулстеками становятся обычно тогда, когда уже являются экспертами в одной из частей. Более того, фулстеки благодаря широте знаний лучше понимают возможности и ограничения системы. Они могут быстрее работать, за счет того, что им нужно меньше с кем-то синхронизироваться или ждать кого-то.
> Понятие «фулстек» придумал бизнес, чтобы экономить.
Фулстек — это часть профессионального пути. И на самом деле, человек с 10 годами опыта должен быть уже не только фулстеком, но и всестеком + тимлидом и, может быть, техническим директором.
Короткий ответ: конечно да, таких людей вокруг нас полно.
Теперь чуть подробнее. Обычно все происходит так: когда человек начинает программировать и делает это год или два, то он находится в состоянии постоянного ощущения «как же все это можно выучить». Это нормальное состояние, которое рано или поздно заканчивается. Программист входит в режим того, что задачи становятся понятны, в голове всегда есть примерный план решения, а нужные инструменты чувствуются на кончиках пальцев.
Это тот самый момент, когда возможна развилка. Кто-то продолжает просто работать и читать статьи на Хабре, кто-то еще серьезнее закапывается в свою область, изучает соседние фреймворки, другие подходы. Кто-то даже доходит до того, что включается в разработку инструментария, библиотек и фреймворков. И вот тут и есть люди, которые понимают, что было бы неплохо узнать другую сторону.
Вдруг оказывается, что с другой стороны все устроено не так уж и сложно. Да, есть свои особенности, в бэкенде это базы данных, а во фронтенде — DOM и событийная модель, но глобально тоже самое программирование. Постепенно эти люди включаются в разработку обеих частей и перестают об этом переживать.
У меня этот путь занял около семь лет, что довольно долго. То есть я пять лет занимался только бэкендом. HTML/CSS туда немного входили, но JS — нет. И только потом я взялся за фронтенд. Правда, справедливости ради, до фронтенда я изучил администрирование и функциональное программирование. Сейчас же написать бэк на Elixir, настроить Kubernetes кластер или запилить приложение на React — как раз плюнуть :) На это хватило «всего-то» 15 лет жизни.
Есть несколько распространенных заблуждений, которые транслируют, если речь заходит про фулстеков. Вот некоторые из них:
> Фулстек — это недопрограммист, он плохо разбирается и в бэке, и во фронте.
В жизни все с точностью до наоборот. Фулстеками становятся обычно тогда, когда уже являются экспертами в одной из частей. Более того, фулстеки благодаря широте знаний лучше понимают возможности и ограничения системы. Они могут быстрее работать, за счет того, что им нужно меньше с кем-то синхронизироваться или ждать кого-то.
> Понятие «фулстек» придумал бизнес, чтобы экономить.
Фулстек — это часть профессионального пути. И на самом деле, человек с 10 годами опыта должен быть уже не только фулстеком, но и всестеком + тимлидом и, может быть, техническим директором.
👍67🔥5💩3❤2🤩2⚡1😱1
Хотел поделиться видео, в котором Саша, который делал хекслет очень много лет, показывает в прямом эфире как он разрабатывает платформу https://www.youtube.com/watch?v=SKLH1C1sl0o
YouTube
Hexlet Live #1. Делаем Hexlet в прямом эфире
Первый пробный стрим Hexlet Live. Ведущий стрима - главный разработчик Hexlet Александр Вагин
Начните изучать программирование бесплатно: https://ru.hexlet.io/courses_free?utm_source=youtube&utm_medium=social&utm_campaign=freemium&utm_content=video-stream1…
Начните изучать программирование бесплатно: https://ru.hexlet.io/courses_free?utm_source=youtube&utm_medium=social&utm_campaign=freemium&utm_content=video-stream1…
👍26❤5🔥4💩2
Написал большую статью про то как организовывать доски в ноушене. Рекомендую для прочтения https://vc.ru/services/605683-kak-pravilno-organizovyvat-doski-v-notion-i-ne-tolko
vc.ru
Как правильно организовывать доски в Notion и не только? — Сервисы на vc.ru
Хекслет Сервисы 13.02.2023
❤35👍7💩2
Одна из краеугольных тем в программирование это состояния системы. Тема глубокая, повсеместная и ее понимание может сильно изменить взгляд на вещи. Разберемся с ней на примере страницы курса на Хекслете. Откройте для примера этот https://ru.hexlet.io/courses/js-ddd
На этой странице есть описание курса, состав уроков, отзывы, справа цена кнопка и какая-то другая полезная информация. Как вы думаете, насколько сложно создать такую страницу? На первый взгляд не сложно, но самое интересное начинается в тот момент, когда мы начинаем задумываться о том, какие состояния возможны на этой странице.
Возьмем кнопку справа. Что у вас там отображается прямо сейчас? Например я сейчас вижу “зарегистрироваться”. Но если я залогинюсь, то увижу уже другую кнопку, там будет что-то другое. Причем это другое тоже будет зависеть от того, вступал ли я в этот курс или нет, платил ли я за него или нет.
Все это называется состояниями и особенность состояний в том, что их нужно программировать. Каждое новое состояние любого элемента на странице это дополнительная работа, это условие в коде “если это то сделай вот это”, это дополнительная поддержка кода и это дополнительное тестирование.
Кнопка о которой мы говорим имеет 5 состояний! Это значит, что даже для банальной проверки, того как она выглядит, нужно проделать множество действий. А кроме кнопки на странице множество других элементов. Если уроки пройдены, то они отмечаются специальным образом. Если пользователь вступил в курс, у него добавляется сверху блок, который показывает статистику прохождения этого курса. Суммарно все это может приводить к десяткам состояний на одной странице. С точки зрения сроков разработки, стоимости поддержки и сложности тестирования, изначальная оценка вырастает сразу в несколько раз как минимум. А может даже на порядок.
Помимо самих состояний, каждый переход из одного состояния в другое это программный код: вступление в курс, оплата курса, регистрация. Все это процессы, которые переводят состояния элементов на той же странице курса. И конечно же, других страницах сайта.
С состояниями связана еще одна забавная история. Профессиональные программисты видят многие состояния буквально сразу, как только им обозначили задачу. Из-за этого те кто с ними работают недоумевают как, на первый взгляд, простая задача, внезапно превращается в месяц разработки.
На этой странице есть описание курса, состав уроков, отзывы, справа цена кнопка и какая-то другая полезная информация. Как вы думаете, насколько сложно создать такую страницу? На первый взгляд не сложно, но самое интересное начинается в тот момент, когда мы начинаем задумываться о том, какие состояния возможны на этой странице.
Возьмем кнопку справа. Что у вас там отображается прямо сейчас? Например я сейчас вижу “зарегистрироваться”. Но если я залогинюсь, то увижу уже другую кнопку, там будет что-то другое. Причем это другое тоже будет зависеть от того, вступал ли я в этот курс или нет, платил ли я за него или нет.
Все это называется состояниями и особенность состояний в том, что их нужно программировать. Каждое новое состояние любого элемента на странице это дополнительная работа, это условие в коде “если это то сделай вот это”, это дополнительная поддержка кода и это дополнительное тестирование.
Кнопка о которой мы говорим имеет 5 состояний! Это значит, что даже для банальной проверки, того как она выглядит, нужно проделать множество действий. А кроме кнопки на странице множество других элементов. Если уроки пройдены, то они отмечаются специальным образом. Если пользователь вступил в курс, у него добавляется сверху блок, который показывает статистику прохождения этого курса. Суммарно все это может приводить к десяткам состояний на одной странице. С точки зрения сроков разработки, стоимости поддержки и сложности тестирования, изначальная оценка вырастает сразу в несколько раз как минимум. А может даже на порядок.
Помимо самих состояний, каждый переход из одного состояния в другое это программный код: вступление в курс, оплата курса, регистрация. Все это процессы, которые переводят состояния элементов на той же странице курса. И конечно же, других страницах сайта.
С состояниями связана еще одна забавная история. Профессиональные программисты видят многие состояния буквально сразу, как только им обозначили задачу. Из-за этого те кто с ними работают недоумевают как, на первый взгляд, простая задача, внезапно превращается в месяц разработки.
ru.hexlet.io
Курс «JS: Предметно-ориентированное проектирование»: обучение онлайн
На этом курсе вы изучите предметно-ориентированное программирование. Вы узнаете больше об инверсии зависимостей и репозиториях. В итоге научитесь использовать шаблон Service Lay...
👍32❤4💩2
Предлагаю размять мозги. Многомерная задача с несколькими уровнями ответа: Есть два стеклянных шарика и 100-этажный дом. Вы бросаете шарик с разных этажей этого дома, чтобы выяснить, при падении с какого этажа шарик начинает разбиваться (например, на пятом уже разбивается, а на четвёртом ещё нет). Вопрос: какое точное минимальное количество шагов понадобится для того, чтобы точно узнать на каком именно этаже шарики начинают разбиваться?
❤16👍8💩5
Хекслет запустил свой онлайн-тренажер в далеком 2013 году. С тех пор мы его сильно улучшили, и на текущий момент он является одним из самых интересных элементов экосистемы Хекслета. Что он из себя представляет?
Со стороны может показаться, что тренажер — это просто редактор кода, который умеет запускать его на выполнение. Это будет правдой, если мы говорим про https://code-basics.com. Там тренажер устроен действительно просто: по кнопке «запустить» написанный код отправляется на сервер, где он и запускается. Результат отправляется обратно в браузер, где уже выводится пользователю.
На Хекслете тренажер устроен значительно сложнее. Он включает в себя множество элементов:
Редактор, у которого есть фронтенд и бэкенд часть
Фронтенд-код для взаимодействия с редактором со стороны Хекслета. Он получает от редактора различную информацию — например, успешность прохождения тестов.
Сами задания, которые разрабатывает выделенная команда внутри Хекслета
Бэкенд-код для обслуживания заданий внутри Хекслета. Он загружает задания внутрь системы, обновляет их, запускает и выполняет другие служебные задачи.
Инфраструктуру из примерно 10 серверов, на которых запускается практика.
Зачем все это нужно? Тренажер Хекслета специально создавался как универсальный инструмент, с помощью которого можно запускать практически любую задачу — от простого выполнения функций до разработки полноценных приложений с базами данных и веб-серверами. И у нас это получилось.
Каждое задание на Хекслете представляет из себя мини-сервер (технически, это Docker-контейнер), который запускается при старте практики. Редактор запускается внутри этого сервера для каждой задачи. С его помощью можно не только писать код в каких-то файлах, но и получить полный доступ к внутренностям «сервера» через терминал.
Кроме того, каждое задание имеет выход в интернет, через который можно выставить наружу, например, приложение, которое разрабатывается внутри. Подобная возможность доступна по кнопке «веб-доступ» в соответствующих практиках. Иногда эта возможность используется и другим способом. Например, тестировщики так получают доступ к мини-сайтам, которые им нужно проанализировать в рамках конкретного задания.
Вот примеры задач, которые мы создаем для наших пользователей:
Написать кусок кода в рамках приложения
Разработать приложение с использованием какого-то фреймворка
Научиться пользоваться командами Bash
Изучить работу Git
Протестировать сайт
Изучить инструменты управления конфигурацией, например, Ansible
Изучить команды SQL
Все это позволяет автоматизировать выполнение всех задач в рамках профессий, а не только первые простые модули, как это часто бывает.
Со стороны может показаться, что тренажер — это просто редактор кода, который умеет запускать его на выполнение. Это будет правдой, если мы говорим про https://code-basics.com. Там тренажер устроен действительно просто: по кнопке «запустить» написанный код отправляется на сервер, где он и запускается. Результат отправляется обратно в браузер, где уже выводится пользователю.
На Хекслете тренажер устроен значительно сложнее. Он включает в себя множество элементов:
Редактор, у которого есть фронтенд и бэкенд часть
Фронтенд-код для взаимодействия с редактором со стороны Хекслета. Он получает от редактора различную информацию — например, успешность прохождения тестов.
Сами задания, которые разрабатывает выделенная команда внутри Хекслета
Бэкенд-код для обслуживания заданий внутри Хекслета. Он загружает задания внутрь системы, обновляет их, запускает и выполняет другие служебные задачи.
Инфраструктуру из примерно 10 серверов, на которых запускается практика.
Зачем все это нужно? Тренажер Хекслета специально создавался как универсальный инструмент, с помощью которого можно запускать практически любую задачу — от простого выполнения функций до разработки полноценных приложений с базами данных и веб-серверами. И у нас это получилось.
Каждое задание на Хекслете представляет из себя мини-сервер (технически, это Docker-контейнер), который запускается при старте практики. Редактор запускается внутри этого сервера для каждой задачи. С его помощью можно не только писать код в каких-то файлах, но и получить полный доступ к внутренностям «сервера» через терминал.
Кроме того, каждое задание имеет выход в интернет, через который можно выставить наружу, например, приложение, которое разрабатывается внутри. Подобная возможность доступна по кнопке «веб-доступ» в соответствующих практиках. Иногда эта возможность используется и другим способом. Например, тестировщики так получают доступ к мини-сайтам, которые им нужно проанализировать в рамках конкретного задания.
Вот примеры задач, которые мы создаем для наших пользователей:
Написать кусок кода в рамках приложения
Разработать приложение с использованием какого-то фреймворка
Научиться пользоваться командами Bash
Изучить работу Git
Протестировать сайт
Изучить инструменты управления конфигурацией, например, Ansible
Изучить команды SQL
Все это позволяет автоматизировать выполнение всех задач в рамках профессий, а не только первые простые модули, как это часто бывает.
Code-Basics
Free programming courses for beginners, simulator and AI assistant | Code Basics
Learn programming for free: Python, JavaScript, Java, and 11 more languages. Theory, browser-based practice, and an AI assistant. From scratch for kids and adults.
👍48❤7🤮2
Как-то здесь написали, что пет-проекты — это всё, что нужно, чтобы стать мидлом. В реальности всё чуть сложнее, поэтому пришлось встать с дивана и написать этот пост.
Мидл действительно должен знать и уметь больше, чем джун. Конкретного критерия при этом нет, в одной компании ваши знания и умение работать с React будут достаточными для мидл-уровня, в другой их оценят на уровень джуна. В любом случае это самая простая часть, которая может в немалой степени быть прокачана своими проектами.
Но есть другая сторона, которая намного более важная, так как прокачать ее самостоятельно не получится. Сюда входят:
>> Риски и ошибки, связанные с обслуживанием приложения, которым пользуются в реальном времени
Пет-проекты не несут никаких рисков. Упал сайт? Просто перезапустили. Случайно стерли базу данных? Ничего страшного. Нужно обновиться? Остановили сайт.
Всё это невозможно в реальной среде, где есть настоящие пользователи. Остановка сервиса может повлечь за собой потери миллионов, уничтожение инфраструктуры — потери всего бизнеса. Здесь нужно думать о бэкапах, о том, как новые изменения отразятся на старых пользователях.
Помимо прочего, реальные сервисы — это вопросы, связанные с безопасностью, нагрузкой, масштабированием, отказоустойчивостью, логами, ошибками в продакшене. Представьте себе ситуацию, пользователь наткнулся на серьезный баг, который приводит к появлению страницы 500. Как вы об этом узнаете? В этот момент сразу можно понять, новичок перед вами или нет, так как новичок даже не задумывался над такими вопросами. Опытный разработчик знает о том, как отслеживают ошибки, и команда узнает об этом через системы мониторинга и алертинга.
Как говорится: «Не ронял прод, не мидл».
>> Процессы разработки.
Сюда входит всё, начиная от того, как совместно работать в git до выкатки в продакшен. В реальной разработке обязательно присутствует процесс непрерывной интеграции, этап тестирования на стейджинге. Сам процесс выкладки сайта на продакшен представляет из себя целую историю, которую вот так на пет-проекте не реализуешь.
Про git стоит сказать отдельно. Для собеседующих это один из самых простых способов понять, насколько программист в теме. Умение с закрытыми глазами оперировать ветками, черрипикать и выполнять другие задачи в гите очень сильно коррелирует с его продакшен-опытом.
В разных компаниях уровень этих процессов разный. То есть может получиться так, что джуниор попал в компанию с низкой культурой и за год не научился правильным процессам. Дальше он придет в другое место, где на собеседовании станет понятно, что он слаб в этом вопросе.
В любом случае, на пет-проектах получить такой опыт не удастся.
>> Взаимодействие с другими членами команды: программистами, тестировщиками, администраторами.
Здесь то же самое. Пет-проект — это работа в одного. Ни с кем не надо советоваться и согласовывать технические моменты. Можно в любой момент что-то переписать, перейти на другой стиль кодирования, выкатить без проверки. Естественно, нет никакого код-ревью.
В команде нужно уметь договариваться, совместно искать архитектурные решения, идти на компромисс. В этой части всегда присутствует элемент спора, а иногда конфликта. Все это помогает прокачать софт-скиллы и стать частью корабля.
Кстати, на эту тему есть хорошая книга от Роберта Мартина, называется «Идеальный программист»: https://ru.hexlet.io/pages/recommended-books
>> Взаимодействие с заказчиками, это могут быть как внешние люди, так и внутренние заказчики, например, продакт- и проджект-менеджеры.
Только тут программист начинает понимать всю сущность бытия. Оказывается, идеального ТЗ не бывает. Никто не знает, как оно должно работать, есть только хотелки. Нужно уметь превратить их в техническое описание, нужно увидеть потенциальные проблемы, донести их до заказчика, подумать над решением. Нужно уметь отстаивать свою позицию, упрощать и предлагать более оптимальные решения, нужно погружаться в предметную область и бизнес. Нужно уметь оценивать, ставить сроки и исполнять их.
На всё это накладываются инструменты проектного менеджмента, такие как jira или trello.
Мидл действительно должен знать и уметь больше, чем джун. Конкретного критерия при этом нет, в одной компании ваши знания и умение работать с React будут достаточными для мидл-уровня, в другой их оценят на уровень джуна. В любом случае это самая простая часть, которая может в немалой степени быть прокачана своими проектами.
Но есть другая сторона, которая намного более важная, так как прокачать ее самостоятельно не получится. Сюда входят:
>> Риски и ошибки, связанные с обслуживанием приложения, которым пользуются в реальном времени
Пет-проекты не несут никаких рисков. Упал сайт? Просто перезапустили. Случайно стерли базу данных? Ничего страшного. Нужно обновиться? Остановили сайт.
Всё это невозможно в реальной среде, где есть настоящие пользователи. Остановка сервиса может повлечь за собой потери миллионов, уничтожение инфраструктуры — потери всего бизнеса. Здесь нужно думать о бэкапах, о том, как новые изменения отразятся на старых пользователях.
Помимо прочего, реальные сервисы — это вопросы, связанные с безопасностью, нагрузкой, масштабированием, отказоустойчивостью, логами, ошибками в продакшене. Представьте себе ситуацию, пользователь наткнулся на серьезный баг, который приводит к появлению страницы 500. Как вы об этом узнаете? В этот момент сразу можно понять, новичок перед вами или нет, так как новичок даже не задумывался над такими вопросами. Опытный разработчик знает о том, как отслеживают ошибки, и команда узнает об этом через системы мониторинга и алертинга.
Как говорится: «Не ронял прод, не мидл».
>> Процессы разработки.
Сюда входит всё, начиная от того, как совместно работать в git до выкатки в продакшен. В реальной разработке обязательно присутствует процесс непрерывной интеграции, этап тестирования на стейджинге. Сам процесс выкладки сайта на продакшен представляет из себя целую историю, которую вот так на пет-проекте не реализуешь.
Про git стоит сказать отдельно. Для собеседующих это один из самых простых способов понять, насколько программист в теме. Умение с закрытыми глазами оперировать ветками, черрипикать и выполнять другие задачи в гите очень сильно коррелирует с его продакшен-опытом.
В разных компаниях уровень этих процессов разный. То есть может получиться так, что джуниор попал в компанию с низкой культурой и за год не научился правильным процессам. Дальше он придет в другое место, где на собеседовании станет понятно, что он слаб в этом вопросе.
В любом случае, на пет-проектах получить такой опыт не удастся.
>> Взаимодействие с другими членами команды: программистами, тестировщиками, администраторами.
Здесь то же самое. Пет-проект — это работа в одного. Ни с кем не надо советоваться и согласовывать технические моменты. Можно в любой момент что-то переписать, перейти на другой стиль кодирования, выкатить без проверки. Естественно, нет никакого код-ревью.
В команде нужно уметь договариваться, совместно искать архитектурные решения, идти на компромисс. В этой части всегда присутствует элемент спора, а иногда конфликта. Все это помогает прокачать софт-скиллы и стать частью корабля.
Кстати, на эту тему есть хорошая книга от Роберта Мартина, называется «Идеальный программист»: https://ru.hexlet.io/pages/recommended-books
>> Взаимодействие с заказчиками, это могут быть как внешние люди, так и внутренние заказчики, например, продакт- и проджект-менеджеры.
Только тут программист начинает понимать всю сущность бытия. Оказывается, идеального ТЗ не бывает. Никто не знает, как оно должно работать, есть только хотелки. Нужно уметь превратить их в техническое описание, нужно увидеть потенциальные проблемы, донести их до заказчика, подумать над решением. Нужно уметь отстаивать свою позицию, упрощать и предлагать более оптимальные решения, нужно погружаться в предметную область и бизнес. Нужно уметь оценивать, ставить сроки и исполнять их.
На всё это накладываются инструменты проектного менеджмента, такие как jira или trello.
👍37🔥2🤮2
Где-то здесь появляются слова Agile, Scrum и Kanban, которые превращаются в конкретные процедуры того, как движется процесс разработки.
Глядя на описание выше, должно быть понятно, почему бизнес хочет нанимать хотя бы мидлов, а не джунов. Они знают про тот путь, который предстоит пройти, и хотят его сократить. Особенно это касается неизбежных ошибок, которые делают любые новички.
К сожалению, все это невозможно прокачать на курсах или пет-проектах. Для этого понадобится погружение в реальные проекты, имеющие реальные финансовые риски.
Из-за этого организовать обучение “до мидла” достаточно сложно. Фактически, ни у кого пока это не получилось. Но есть луч надежды. Когда-то подобное обучение на продакшене было организовано в компании андев, в 2011 году. Мы сейчас работаем над тем, чтобы повторить этот опыт уже для Хекслета.
p.s. В нашем блоге есть статья, дополняющая этот пост https://ru.hexlet.io/blog/posts/developers-business-value
Глядя на описание выше, должно быть понятно, почему бизнес хочет нанимать хотя бы мидлов, а не джунов. Они знают про тот путь, который предстоит пройти, и хотят его сократить. Особенно это касается неизбежных ошибок, которые делают любые новички.
К сожалению, все это невозможно прокачать на курсах или пет-проектах. Для этого понадобится погружение в реальные проекты, имеющие реальные финансовые риски.
Из-за этого организовать обучение “до мидла” достаточно сложно. Фактически, ни у кого пока это не получилось. Но есть луч надежды. Когда-то подобное обучение на продакшене было организовано в компании андев, в 2011 году. Мы сейчас работаем над тем, чтобы повторить этот опыт уже для Хекслета.
p.s. В нашем блоге есть статья, дополняющая этот пост https://ru.hexlet.io/blog/posts/developers-business-value
ru.hexlet.io
Классификация программистов по их ценности для бизнеса
В мире существует множество классификаций программистов — простые и сложные, фокусирующиеся на какой-то одной стороне деятельности (например, на технических навыках) или комплексные. Ни в коей мере не умаляя их значения, хочу предложить вам свой вариант,…
👍36🔥9🤮3
Недавно я писал пост, как поднимал IT-целину в Ульяновске. В этом посте я хочу чуть более конкретно рассказать, как мне удалось обучить под сотню Ruby-программистов за несколько лет и создать крупнейший кластер рубистов в отдельно взятом городе. Многие из тех рубистов сейчас уже являются техническими директорами и владельцами своих компаний.
Исходные данные: ребята из компании Undev, в которой я работал в Москве, связались со мной и попросили помочь выстроить техническое представительство в Ульяновске. Мне предстояло собрать большую команду Ruby-разработчиков, так как именно Ruby был основным языком в компании. Засада была в том, что во всем городе было ровно 3 Ruby-разработчика. Было понятно, что для планируемого роста нужно искать перспективных ребят из других компаний, переманивать их и растить.
Почти все ребята, которые ко мне попадали, приходили из маленьких компаний, в основном веб-студий, где они работали от нескольких месяцев до нескольких лет. Были и студенты последних курсов местного политеха, правда с опытом работы.
С одной стороны, это уже какой-то уровень. С другой — даже те, кто работал год-два в веб-студиях, с точки зрения наших запросов, были очень слабыми. Это типичная история для студий, где тогда в основном работали с битриксом и другими CMS. Был один случай, когда человек в такой студии разрабатывал внутреннюю систему тикетов, которая хранилась в одном файле на 35 000 строк кода. Кстати, этот парень потом стал одним из лучших и сейчас руководит разработкой одного американского стартапа.
Обучение я строил так. Первые две-три недели было изучение самого языка + сопутствующих технологий — например, Git, командная строка и так далее. Для этого были подобраны книги, интернет-ресурсы и различные обучающие сервисы. Не курсы, скорее это были либо специализированные тренажеры, либо Kata
Почему на язык так мало времени? Тут все прост: в отличие от студентов на курсах, эти ребята пришли работать работу, и если задержать обучение, то резко падает мотивация. Им хочется быстрее переходить к задачам, и эти люди в целом способны находить проблемы и самостоятельно их решать. Поэтому доучивать язык в процессе для них совершенно естественно.
Самое интересное — это то, что происходило во время этого обучения. Фактически я проводил 70% своего времени с этими ребятами, которых могло одновременно обучаться до 15 человек. Два раза в день я проверял, что происходит, направлял, подсказывал с настройкой окружения, давал дополнительные задания, если надо. Если у них были общие вопросы или какие-то затыки, мы собирались у доски и вместе разбирались с этими вопросами в бурных обсуждениях с рисованием.
Как только заканчивался этот этап, мы начинали погружаться в Ruby on Rails — наш основной рабочий фреймворк. Ребята делали тестовое приложение, которое постепенно обрастало разными функциями. Здесь мы часто работали в парах и проводили время у доски. Обычно они изучали возможности фреймворка через онлайн-туториалы, затем мы обсуждали концепции и после этого приступали к реализации.
Помимо этого, раз в несколько недель мы проводили воркшопы, где я учил ребят проектированию и архитектурным вещам вне фреймворка. Здесь мы за день создавали веб-сервер, event loop, тестовый фреймворк, тесты которого написаны на нем же. Вся эта работа велась только в парах, что значительно увеличивало эффективность работы и обучения.
Примерно через четыре месяца они были готовы погрузиться в реальные проекты компании. Я передавал их руководителям проектов, но при этом продолжал полностью ревьювить весь код, который они писали. Это продолжалось примерно еще пару месяцев после окончания основного обучения.
Исходные данные: ребята из компании Undev, в которой я работал в Москве, связались со мной и попросили помочь выстроить техническое представительство в Ульяновске. Мне предстояло собрать большую команду Ruby-разработчиков, так как именно Ruby был основным языком в компании. Засада была в том, что во всем городе было ровно 3 Ruby-разработчика. Было понятно, что для планируемого роста нужно искать перспективных ребят из других компаний, переманивать их и растить.
Почти все ребята, которые ко мне попадали, приходили из маленьких компаний, в основном веб-студий, где они работали от нескольких месяцев до нескольких лет. Были и студенты последних курсов местного политеха, правда с опытом работы.
С одной стороны, это уже какой-то уровень. С другой — даже те, кто работал год-два в веб-студиях, с точки зрения наших запросов, были очень слабыми. Это типичная история для студий, где тогда в основном работали с битриксом и другими CMS. Был один случай, когда человек в такой студии разрабатывал внутреннюю систему тикетов, которая хранилась в одном файле на 35 000 строк кода. Кстати, этот парень потом стал одним из лучших и сейчас руководит разработкой одного американского стартапа.
Обучение я строил так. Первые две-три недели было изучение самого языка + сопутствующих технологий — например, Git, командная строка и так далее. Для этого были подобраны книги, интернет-ресурсы и различные обучающие сервисы. Не курсы, скорее это были либо специализированные тренажеры, либо Kata
Почему на язык так мало времени? Тут все прост: в отличие от студентов на курсах, эти ребята пришли работать работу, и если задержать обучение, то резко падает мотивация. Им хочется быстрее переходить к задачам, и эти люди в целом способны находить проблемы и самостоятельно их решать. Поэтому доучивать язык в процессе для них совершенно естественно.
Самое интересное — это то, что происходило во время этого обучения. Фактически я проводил 70% своего времени с этими ребятами, которых могло одновременно обучаться до 15 человек. Два раза в день я проверял, что происходит, направлял, подсказывал с настройкой окружения, давал дополнительные задания, если надо. Если у них были общие вопросы или какие-то затыки, мы собирались у доски и вместе разбирались с этими вопросами в бурных обсуждениях с рисованием.
Как только заканчивался этот этап, мы начинали погружаться в Ruby on Rails — наш основной рабочий фреймворк. Ребята делали тестовое приложение, которое постепенно обрастало разными функциями. Здесь мы часто работали в парах и проводили время у доски. Обычно они изучали возможности фреймворка через онлайн-туториалы, затем мы обсуждали концепции и после этого приступали к реализации.
Помимо этого, раз в несколько недель мы проводили воркшопы, где я учил ребят проектированию и архитектурным вещам вне фреймворка. Здесь мы за день создавали веб-сервер, event loop, тестовый фреймворк, тесты которого написаны на нем же. Вся эта работа велась только в парах, что значительно увеличивало эффективность работы и обучения.
Примерно через четыре месяца они были готовы погрузиться в реальные проекты компании. Я передавал их руководителям проектов, но при этом продолжал полностью ревьювить весь код, который они писали. Это продолжалось примерно еще пару месяцев после окончания основного обучения.
Codewars
What is Kata? | The Codewars Docs
On Codewars, kata are code challenges focused on improving skill and technique. Some train programming fundamentals, while others focus on complex problem solving. Others are puzzles meant to test your creative problem solving, while others are based on real…
👍40💩5🔥1