В своем резюме разработчику важно не только рассказывать про опыт работы, но и подробно описывать свои хард-скиллы — чтобы на это обращали внимание как рекрутеры, так и HR-боты. В галерее рассказываем, как правильно программисту говорить о своих плюсах и на чем делать упор в резюме.
👍25💩3
Давайте вспомним наших учителей по информатике. Какие они были? Повлияли ли они на ваш выбор профессии?
Мы в партнерстве с образовательной платформой Инфоурок проводим короткий опрос о том, какое влияние учителя информатики оказали на вас при выборе профессии после окончания школы. Будет здорово, если вы поучаствуете🔥
Опрос анонимный и займет не больше 3 минут: https://forms.gle/asntncCA5ckumj3L6
Мы в партнерстве с образовательной платформой Инфоурок проводим короткий опрос о том, какое влияние учителя информатики оказали на вас при выборе профессии после окончания школы. Будет здорово, если вы поучаствуете🔥
Опрос анонимный и займет не больше 3 минут: https://forms.gle/asntncCA5ckumj3L6
⚡2💩2🤷♂1
Программисты на работе не только пишут код, но и постоянно используют уже существующий, написанный другими программистами из разных городов и стран. Причем такого кода в проектах значительно больше, чем написанного именно изнутри команды. Этот код приходит к нам из библиотек и фреймворков, которые используются в работе.
Если бы все проекты писались полностью самостоятельно, то ни один из них не был бы завершен. Программисты это поняли очень давно и с самого начала начали обмениваться общими кусками, которые решают распространенные задачи. Со временем этого кода становилось больше, в него включались люди со всего света, и на выходе мы получили миллионы библиотек для разных языков программирования, тысячи самих языков разработки, десятки тысяч фреймворков под них и, внезапно, операционную систему Linux.
Все это стало возможным благодаря концепции открытых проектов. Компании и отдельные программисты выкладывают на GitHub исходный код, который можно использовать и в других местах. Это позволяет подключаться к разработке таких компонентов программистам из любых других компаний. Так все остаются в выигрыше — компании сосредотачиваются на своих бизнес-задачах, а код общего назначения поддерживается сообществом. Поэтому цена его создания и сопровождения значительно падает для всех участников.
Например, у Хекслета есть проект Code Basics, который специально выложен в открытый доступ. Это помогает тратить меньше времени на его сопровождение, так как наши студенты и другие люди участвуют в его доработке. Даже курсы, выложенные на этом сервисе, являются открытыми. Любой человек может пойти и поправить их. Или даже может написать целиком новый курс, что иногда случается.
Самое интересное в открытых проектах — это какую ценность они дают для разработчиков, которые их развивают. Дело в том, что открытые проекты — это невероятный опыт. Вот лишь некоторые плюсы:
- Командная работа. Нужно договариваться, обсуждать, предлагать решения, участвовать в код ревью;
- Открытые проекты используются большим числом людей. Вам придется учитывать множество вариантов использования и возникающие риски при изменениях. Это очень быстрый путь в сторону сеньорности;
- Ваш код проверяют люди со всего мира, и многие из них очень прокаченные разработчики. Открытые проекты сильно влияют на качество кодирования
- Бывает, что открытые проекты технически более сложные, чем проекты на работе. Там получается бесценный и новый опыт.
Все эти пункты хорошо видны не только вам, но и тем, кто нанимает. Люди, которые участвуют в открытых проектах, ценятся на рынке труда. Чем более известный и популярный проект, тем больше шансов, что вас просто завалят предложениями о работе и возьмут много куда даже без особого технического собеседования.
А представьте, как это звучит: «Я контрибьютор в React». И кстати, один из студентов Хекслета действительно стал контрибьютором React.
Если бы все проекты писались полностью самостоятельно, то ни один из них не был бы завершен. Программисты это поняли очень давно и с самого начала начали обмениваться общими кусками, которые решают распространенные задачи. Со временем этого кода становилось больше, в него включались люди со всего света, и на выходе мы получили миллионы библиотек для разных языков программирования, тысячи самих языков разработки, десятки тысяч фреймворков под них и, внезапно, операционную систему Linux.
Все это стало возможным благодаря концепции открытых проектов. Компании и отдельные программисты выкладывают на GitHub исходный код, который можно использовать и в других местах. Это позволяет подключаться к разработке таких компонентов программистам из любых других компаний. Так все остаются в выигрыше — компании сосредотачиваются на своих бизнес-задачах, а код общего назначения поддерживается сообществом. Поэтому цена его создания и сопровождения значительно падает для всех участников.
Например, у Хекслета есть проект Code Basics, который специально выложен в открытый доступ. Это помогает тратить меньше времени на его сопровождение, так как наши студенты и другие люди участвуют в его доработке. Даже курсы, выложенные на этом сервисе, являются открытыми. Любой человек может пойти и поправить их. Или даже может написать целиком новый курс, что иногда случается.
Самое интересное в открытых проектах — это какую ценность они дают для разработчиков, которые их развивают. Дело в том, что открытые проекты — это невероятный опыт. Вот лишь некоторые плюсы:
- Командная работа. Нужно договариваться, обсуждать, предлагать решения, участвовать в код ревью;
- Открытые проекты используются большим числом людей. Вам придется учитывать множество вариантов использования и возникающие риски при изменениях. Это очень быстрый путь в сторону сеньорности;
- Ваш код проверяют люди со всего мира, и многие из них очень прокаченные разработчики. Открытые проекты сильно влияют на качество кодирования
- Бывает, что открытые проекты технически более сложные, чем проекты на работе. Там получается бесценный и новый опыт.
Все эти пункты хорошо видны не только вам, но и тем, кто нанимает. Люди, которые участвуют в открытых проектах, ценятся на рынке труда. Чем более известный и популярный проект, тем больше шансов, что вас просто завалят предложениями о работе и возьмут много куда даже без особого технического собеседования.
А представьте, как это звучит: «Я контрибьютор в React». И кстати, один из студентов Хекслета действительно стал контрибьютором React.
👍29🔥9💩2
Поиск ответов на вопросы и решение проблем с помощью Гугла — важнейший навык для программиста. Большинство проблем, с которыми сталкивается новичок, уже решены и описаны. Нужно лишь научиться находить эти решения и ответы. #programming #it #github
🔥32👍7💩2👎1🤔1
Отзовитесь, кто здесь играет в Elvenar?
Каждое обновление у них находятся ошибки вроде текста, вышедшего за рамки, или английских надписей, которые не перевелись на русский. Причем до обновлений этих ошибок никто не замечал. Неужели код игры может так постоянно «ломаться», или его специально «ломают», чтобы оправдать выпуск очередного обновления?
Такой вопрос нам задали в одном из комментариев в ВК. Давайте поговорим об этом.
Короткий ответ: разработка программного обеспечения — сложная штука, которая не сводится просто к написанию кода. В ней задействовано множество разных людей, которые участвуют в разных процессах. Все это неизбежно ведет к ошибкам, которые затем исправляются. Скорость и качество исправления зависят от того, как эффективно все работает в конкретном месте.
Возьмем пример «текст вышел за рамки». Как такое может быть? А очень легко. В играх очень много текста, и он не хранится «внутри» игры. Тексты лежат в отдельных файлах, с которыми работают переводчики, а не разработчики игры. Переводчики получают эти файлы и переводят тексты в соответствии со своими внутренними правилами. Иногда это приводит к тому, что на каком-то из языков слово становится слишком длинным и не помещается в интерфейс.
Возникает вопрос, почему переводчик не смотрит, как оно потом выглядит? Наверное, иногда смотрит, но в общем случае это почти нереально. Текстов много, переводить надо много. Лазить по игре и смотреть все тексты практически нереально, так как это займет очень много времени. Представьте, что вы правите название какого-нибудь доспеха, который еще надо найти в этой игре. Не будет же переводчик сидеть неделями и проходить игру, чтобы дойти до нужного места. В теории, можно было бы сразу поместить его куда надо — так, конечно, стараются делать. Но, к сожалению, не существует универсального способа поставить любую часть игры в любой момент времени. Это требует усилий разработчиков по подготовке так называемых «стендов», где заранее забиты возможные «сохраненные игры», в которые можно загрузиться. Либо специальных интерфейсов для проверок, что опять же влечет за собой дополнительные усилия разработки и кучу времени на проверку.
В итоге намного проще допускать такие ошибки и потом исправлять их по факту, так как глобально на игру они не влияют, а пользователи сами напишут, если увидят ошибку.
Насколько нормально так поступать? Весь вопрос в ресурсах и сроках. Экономически такой подход часто оправдан, иначе изменения делались бы очень долго, и пользователей бесило бы это еще больше, хотя они этого и не осознают.
Кроме программистов, в таких проектах всегда присутствуют тестировщики. Могут ли они выявлять подобные ошибки? Да, часть таких ошибок они точно замечают — особенно учитывая, что тестировщиками являются в том числе «особые» пользователи, которые получают изменения раньше остальных и помогают находить в них ошибки. Но даже в этом случае они не могут проводить полный анализ всех изменений, которые вносят переводчики.
А теперь представьте, мы говорим только про переводы, а ведь это далеко не самая сложная и страшная часть. Они влияют лишь на внешний вид, а не поведение. Кроме переводов в играх огромное количество логики, которую тестировать не перетестировать. Полное тестирование какого-нибудь крупного проекта типа игры может занимать недели работы десятков человек (в простых случаях). Поэтому его практически никогда не делают, что и приводит к пропускам ошибок.
Раз уж мы заговорили о тестировании. На Хекслете есть программа для ручных тестировщиков, а скоро запустим и автоматическое тестирование
https://ru.hexlet.io/programs/qa-engineer
Каждое обновление у них находятся ошибки вроде текста, вышедшего за рамки, или английских надписей, которые не перевелись на русский. Причем до обновлений этих ошибок никто не замечал. Неужели код игры может так постоянно «ломаться», или его специально «ломают», чтобы оправдать выпуск очередного обновления?
Такой вопрос нам задали в одном из комментариев в ВК. Давайте поговорим об этом.
Короткий ответ: разработка программного обеспечения — сложная штука, которая не сводится просто к написанию кода. В ней задействовано множество разных людей, которые участвуют в разных процессах. Все это неизбежно ведет к ошибкам, которые затем исправляются. Скорость и качество исправления зависят от того, как эффективно все работает в конкретном месте.
Возьмем пример «текст вышел за рамки». Как такое может быть? А очень легко. В играх очень много текста, и он не хранится «внутри» игры. Тексты лежат в отдельных файлах, с которыми работают переводчики, а не разработчики игры. Переводчики получают эти файлы и переводят тексты в соответствии со своими внутренними правилами. Иногда это приводит к тому, что на каком-то из языков слово становится слишком длинным и не помещается в интерфейс.
Возникает вопрос, почему переводчик не смотрит, как оно потом выглядит? Наверное, иногда смотрит, но в общем случае это почти нереально. Текстов много, переводить надо много. Лазить по игре и смотреть все тексты практически нереально, так как это займет очень много времени. Представьте, что вы правите название какого-нибудь доспеха, который еще надо найти в этой игре. Не будет же переводчик сидеть неделями и проходить игру, чтобы дойти до нужного места. В теории, можно было бы сразу поместить его куда надо — так, конечно, стараются делать. Но, к сожалению, не существует универсального способа поставить любую часть игры в любой момент времени. Это требует усилий разработчиков по подготовке так называемых «стендов», где заранее забиты возможные «сохраненные игры», в которые можно загрузиться. Либо специальных интерфейсов для проверок, что опять же влечет за собой дополнительные усилия разработки и кучу времени на проверку.
В итоге намного проще допускать такие ошибки и потом исправлять их по факту, так как глобально на игру они не влияют, а пользователи сами напишут, если увидят ошибку.
Насколько нормально так поступать? Весь вопрос в ресурсах и сроках. Экономически такой подход часто оправдан, иначе изменения делались бы очень долго, и пользователей бесило бы это еще больше, хотя они этого и не осознают.
Кроме программистов, в таких проектах всегда присутствуют тестировщики. Могут ли они выявлять подобные ошибки? Да, часть таких ошибок они точно замечают — особенно учитывая, что тестировщиками являются в том числе «особые» пользователи, которые получают изменения раньше остальных и помогают находить в них ошибки. Но даже в этом случае они не могут проводить полный анализ всех изменений, которые вносят переводчики.
А теперь представьте, мы говорим только про переводы, а ведь это далеко не самая сложная и страшная часть. Они влияют лишь на внешний вид, а не поведение. Кроме переводов в играх огромное количество логики, которую тестировать не перетестировать. Полное тестирование какого-нибудь крупного проекта типа игры может занимать недели работы десятков человек (в простых случаях). Поэтому его практически никогда не делают, что и приводит к пропускам ошибок.
Раз уж мы заговорили о тестировании. На Хекслете есть программа для ручных тестировщиков, а скоро запустим и автоматическое тестирование
https://ru.hexlet.io/programs/qa-engineer
ru.hexlet.io
Курс ручного тестирования с нуля — обучение тестировщика | Хекслет
Курс «Инженер по ручному тестированию»: 4 месяца, 2 проекта, тест-кейсы, поиск багов и работа с документацией. Первый шаг в IT без программирования.
👍12❤2⚡1💩1
Нужно ли читать что-то еще, кроме того, что дается на курсах? Такой вопрос иногда задают студенты. Короткий ответ: да, обязательно. И на это есть несколько причин.
Как бы хорошо не был проработан материал конкретного курса, он всегда подает тему с угла, который выбрал автор. Этот взгляд может быть правильным с методической точки зрения, но все равно он подойдет не всем, или его будет недостаточно. Происходит это по нескольким причинам.
Во-первых, не существует универсальных принципов объяснения сложных вещей, которые одинаково хорошо подходят для всех. Одна и та же аналогия может для одних быть лучшим способом что-то рассказать, а для других — худшим.
Во-вторых, некоторые темы заходят только после двух или даже трех подходов к теории. Можно пытаться читать одно и то же, но придется слишком сильно напрягаться. Гораздо лучше иметь рядом какой-то материал от другого автора, чтобы он дополнял основную часть. Как правило, таким материалом выступает книга по основам конкретного языка.
Кстати, подробно о том, как создается контент, мы рассказываем в нашей школе авторов: https://making.hexlet.io/authors
Как бы хорошо не был проработан материал конкретного курса, он всегда подает тему с угла, который выбрал автор. Этот взгляд может быть правильным с методической точки зрения, но все равно он подойдет не всем, или его будет недостаточно. Происходит это по нескольким причинам.
Во-первых, не существует универсальных принципов объяснения сложных вещей, которые одинаково хорошо подходят для всех. Одна и та же аналогия может для одних быть лучшим способом что-то рассказать, а для других — худшим.
Во-вторых, некоторые темы заходят только после двух или даже трех подходов к теории. Можно пытаться читать одно и то же, но придется слишком сильно напрягаться. Гораздо лучше иметь рядом какой-то материал от другого автора, чтобы он дополнял основную часть. Как правило, таким материалом выступает книга по основам конкретного языка.
Кстати, подробно о том, как создается контент, мы рассказываем в нашей школе авторов: https://making.hexlet.io/authors
👍16❤2💩1
Обзор на книгу «Грокаем функциональное мышление»
Всем привет, это Сергей. Когда я увидел книгу «Грокаем функциональное мышление» в магазине, то сразу решил ее приобрести. Во-первых, предыдущая книга из той же серии про алгоритмы была отличным приобретением. И, во-вторых, я надеялся, что эта книга введет меня в мир функционального программирования также легко и просто, как книга про гроканье алгоритмов вводит в алгоритмы.
Если вы не знакомы с книгой «Грокаем алгоритмы», то этот абзац для вас. Сама эта книга известна как бестселлер и своеобразный мастрид для новичка. Все дело в том, что автору удалось рассказать про относительно сложную тему (алгоритмы и структуры данных), максимально простым языком и даже картинками. На самом деле, если убрать из этой книги рисунки, то ее объем сократится вдвое, и она станет больше похожа на тетрадку, но здесь и заключается один из ее плюсов и секретов популярности. Несмотря на малый объем, автор доходчиво объясняет читателю, что такое алгоритмы, зачем они нужны и прекрасно вводит в эту область знаний.
В понимании функционального программирования (ФП) есть одна грубая ошибка – думать, что оно сводится к функциям и противопоставлено ООП. На самом деле ФП противопоставляется скорее императивному стилю программирования, и для него огромное значение имеет неизменяемость данных, чистые функции, ограничение сайд-эффектов и тому подобное. Я знал все это перед чтением и надеялся, что сей опус введет меня в мир лямбда-исчислений и каррирования, расскажет про монады и всякие такие интересности, но я ошибся.
Начну с плюсов: в книге не так много картинок, как в «Грокаем алгоритмы», что во многом связано со спецификой содержания. Речь зачастую идет о более абстрактных вещах, прежде всего об архитектуре программ, но при этом объем достигает 600 страниц. Другим плюсом является простота и доходчивость, с которой автор рассказывает о том, что такое функциональное мышление – многие темы повторяются по несколько раз, в книге щедро представлены примеры кода и упражнения, а разделы книги пересекаются друг с другом. Приятным является и то, что книга издана в этом, то есть 2023 году. Наконец, акцент на практическом применении функционального мышления в реальной разработке тоже является своеобразным плюсом, поскольку автор подробно на примерах показывает способы изоляции сайд-эффектов, построения кода, и лично я увидел для себя несколько новых вопросов для размышления. Но здесь-то мы и переходим плавно к минусам сего труда.
Прежде всего, указанный акцент на практике лишает читателя самой истории функционального программирования, его концепций, красоты и математического контекста. Все что остается – это код корзины в интернет-магазине, которую мы пишем в функциональном стиле всю книгу, из одной главы в другую, попутно решая возникающие проблемы. Из теории мы получаем только пространную речь про разделение кода на данные, чистые функции и сайд-эффекты, методологию ограничения сайд-эффектов, некоторые архитектурные паттерны и вполне себе обыденное знакомство с функциями высшего порядка и рекурсией.
Вот и все. Маловато содержания для 600 страниц, и совсем уж мало для такой темы, учитывая, что я так и не прочитал про лямбда-исчисления, не увидел примеров каррирования, не познал монады. Тем не менее я получил от книги определенное удовольствие и вполне могу ее порекомендовать и вам, поскольку она не является тратой времени, но по-своему приятна в качестве познавательной литературы.
Всем привет, это Сергей. Когда я увидел книгу «Грокаем функциональное мышление» в магазине, то сразу решил ее приобрести. Во-первых, предыдущая книга из той же серии про алгоритмы была отличным приобретением. И, во-вторых, я надеялся, что эта книга введет меня в мир функционального программирования также легко и просто, как книга про гроканье алгоритмов вводит в алгоритмы.
Если вы не знакомы с книгой «Грокаем алгоритмы», то этот абзац для вас. Сама эта книга известна как бестселлер и своеобразный мастрид для новичка. Все дело в том, что автору удалось рассказать про относительно сложную тему (алгоритмы и структуры данных), максимально простым языком и даже картинками. На самом деле, если убрать из этой книги рисунки, то ее объем сократится вдвое, и она станет больше похожа на тетрадку, но здесь и заключается один из ее плюсов и секретов популярности. Несмотря на малый объем, автор доходчиво объясняет читателю, что такое алгоритмы, зачем они нужны и прекрасно вводит в эту область знаний.
В понимании функционального программирования (ФП) есть одна грубая ошибка – думать, что оно сводится к функциям и противопоставлено ООП. На самом деле ФП противопоставляется скорее императивному стилю программирования, и для него огромное значение имеет неизменяемость данных, чистые функции, ограничение сайд-эффектов и тому подобное. Я знал все это перед чтением и надеялся, что сей опус введет меня в мир лямбда-исчислений и каррирования, расскажет про монады и всякие такие интересности, но я ошибся.
Начну с плюсов: в книге не так много картинок, как в «Грокаем алгоритмы», что во многом связано со спецификой содержания. Речь зачастую идет о более абстрактных вещах, прежде всего об архитектуре программ, но при этом объем достигает 600 страниц. Другим плюсом является простота и доходчивость, с которой автор рассказывает о том, что такое функциональное мышление – многие темы повторяются по несколько раз, в книге щедро представлены примеры кода и упражнения, а разделы книги пересекаются друг с другом. Приятным является и то, что книга издана в этом, то есть 2023 году. Наконец, акцент на практическом применении функционального мышления в реальной разработке тоже является своеобразным плюсом, поскольку автор подробно на примерах показывает способы изоляции сайд-эффектов, построения кода, и лично я увидел для себя несколько новых вопросов для размышления. Но здесь-то мы и переходим плавно к минусам сего труда.
Прежде всего, указанный акцент на практике лишает читателя самой истории функционального программирования, его концепций, красоты и математического контекста. Все что остается – это код корзины в интернет-магазине, которую мы пишем в функциональном стиле всю книгу, из одной главы в другую, попутно решая возникающие проблемы. Из теории мы получаем только пространную речь про разделение кода на данные, чистые функции и сайд-эффекты, методологию ограничения сайд-эффектов, некоторые архитектурные паттерны и вполне себе обыденное знакомство с функциями высшего порядка и рекурсией.
Вот и все. Маловато содержания для 600 страниц, и совсем уж мало для такой темы, учитывая, что я так и не прочитал про лямбда-исчисления, не увидел примеров каррирования, не познал монады. Тем не менее я получил от книги определенное удовольствие и вполне могу ее порекомендовать и вам, поскольку она не является тратой времени, но по-своему приятна в качестве познавательной литературы.
⚡23👍17❤2🤮1