Многие из нас не достаточно хорошо натасканы улавливать намеки, интерпретировать ваши истории как набор действий или читать между строк, чтобы понять, что вы имеете в виду. Извините. Неявно коммуницировать в технических вопросах означает напрашиваться на неприятности. Если вы размазано просите чего хотите, с большей вероятностью вы этого не получите.
Это перевод статьи "The bad reasons you’re forced to work long hours" от Itamar Turner-Trauring.
Работать сверхурочно — непродуктивно, нехорошо для здоровья и, к сожалению, широко распространено. Я настойчиво верю, что короткий рабочий день полезен вам и вашему начальнику, но многие компании и менеджмент заставляют вас работать дольше даже если это снижает продуктивность.
Так почему они это делают? Давайте разберём несколько причин.
Некоторые менеджеры просто не понимают, что работать слишком долго — контрпродуктивно. Возьмём, к примеру, основателей стартапов. Они любят свою работу: стартап – их ребёнок, и они счастливы беспрерывно работать, чтобы гарантировано добиться успеха. Это может быть неэффективным и контрпродуктивным, но они могут этого не осознавать.
Продолжаем серию статей о карьере. В этот раз поговорим о том, как объективно вычислить, на какую зарплату вы можете претендовать.
Начинаем серию статей, посвященных трудоустройству. Как составить хорошее резюме, как вести себя на собеседовании и как понравиться HR-у, нужно ли выполнять гигантское тестовое задание и другие мега-полезные вещи. Все статьи составлены из материалов Вероники Ильиной, опытного HR-специалиста. Вероника уже долгое время неутомимо отвечает на вопросы в канале hexlet-review нашего слак-чата, а еще у нее есть отличный канал в телеграм HR отвечает. Поэтому все заметки - это ответы на реальные вопросы участников слак-чата Хекслета и подписчиков Вероники в телеграм. В первой статье все, что касается резюме программиста. Опытные программисты, конечно, могут и не найти здесь ничего нового, а новичкам обязательно к прочтению.
Это перевод статьи Артёма Чистякова "The language of programming", породившей интересные дискуссии на HackerNews и Reddit.
Я помню, как изучал свой первый язык программирования. Мы должны были освоить какой-то из диалектов BASIC в рамках обязательной школьной программы по информатике для второго класса. Скрючившись на своих партах под тусклыми флуоресцентными лампами, мы нетерпеливо поглядывали на жужжащие компьютеры IBM, расставленные вдоль стен душной классной комнаты. Это был 1997 год, Россия. Ни у кого из нас не было домашнего компьютера. На доске в меловых разводах учитель написала:
SCREEN 15, 0
PSET (100, 100)
DRAW "R20 D20 L20 U20"
END
Многие люди обращаются к нам с одним и тем же вопросом: “А не поздно ли мне становиться разработчиком в X лет?”, этот же вопрос часто встречается на форумах, тостере и подобных сервисах. Часто почему-то “переломным” возрастом является именно 30. Вроде как люди думают, что в 28 еще все ок, а в 30 уже все, пиши пропало. Постарался ответить максимально подробно и честно, на своем опыте и опыте студентов Хекслета.
Спойлер для тех, кому лень читать дальше: стать программистом можно в любом возрасте. В 30 лет - не поздно!
Перевели для вас небольшой пост со StackExchange, в котором юзер под ником Etherable делится историей о своей нелегкой кодерской жизни.
«Сейчас я работаю в компании, где очень много легаси-кода. Система на самом деле очень старая, и хотя меня нанимали как программиста, по сути моя работа это самый обычный ввод данных. В итоге, я получаю набор требований, который по сути является просто массой таблиц с данными по месяцам, которые я должен внести в систему и заставить все это работать. И в целом это решается кучей SQL скриптов.
Многие люди, приходя на работу в новую компанию, сталкиваются с тем, что им не нравится сложившаяся инженерная культура. Люди годами работают так, как они работают, привыкли и им вполне удобно. Чаще всего они скептически относятся к предложениям изменений.
Как эффективно обучаться программированию, ведущий - Кирилл Мокевнин. Особенности языков программирования, ошибки новичков, правильные стратегии обучения, правильный подход к решению задач и многое другое.
Наглядная матрица компетентности программиста поможет вам адекватно оценить уровень своих навыков, и понять, куда двигаться дальше и что учить.
Ближе к ядру расположены навыки и знания, которыми должен обладать начинающий программист, дальше к краям идут навыки, необходимые для продвинутых разработчиков.
Привет! Собрал некоторые очевидные и не очень ошибки начинающих программистов. Это модели поведения и ложные представления, которые могут или вообще закрыть вам дорогу в программирование, или, по крайней мере, растянуть этот путь на много лет. Статья предназначена в первую очередь для новичков.
Это перевод статьи Даниэля Лебреро, которая также была опубликована на dev.to (там в комментариях есть интересное обсуждение на английском).
Меня удивил дядюшка Боб в посте под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".
Это утверждение не всем пришлось по душе. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы — как доказательства) делает юнит-тесты ненужными. Haskell даже утверждает, что "если скомпилировалось, то обычно работает".
Составление вакансии на junior позиции — более тонкое дело, чем может показаться на первый взгляд. Связано это с тем, что у ребят без соответствующего опыта работы есть особые тараканы, которые могут повлиять на их решение откликаться или нет.
Монокультура в программировании — это использование одного стека для решения всех возникающих задач. Она существует не только на уровне конкретного человека и его предпочтений, но также часто встречается на уровне компаний. В таких компаниях, как правило, все делается с использованием одной технологии.
Если вам интересно, как и почему монокультура может приводить к более дорогим и сложным решениям, то добро пожаловать под кат.
Кирилл Мокевнин рассказывает об аспектах поисковой оптимизации, которые должны быть известны всем веб-разработчикам.
Во время обучения бывают ситуации, когда ожидания не совпадают с реальностью и вы не видите нужного результата. Причин может быть масса, но среди них выделяется группа, связанная с когнитивными искажениями. Вот об этой группе мы и поговорим.
Свежий выпуск вопросов и ответов. Вопрос от Петра Алексеенко:
Я начинающий веб-программист, уже могу делать простые сайты и веб-сервисы на PHP, сейчас изучаю JavaScript. Много слышал про функциональное программирование, и как крут Хаскел и Clojure, посмотрел несколько уроков, сделал несколько упражнений. Интересно, прикольно, но не могу понять насколько это вообще имеет для меня смысл в реальной жизни. С одной стороны — очень интересно и есть приятное ощущение, что работаешь с элегантными штуковинами. С другой — прямо сейчас не могу ничего из этого применить, а сайты на PHP могу делать прямо сейчас. Стоит ли новичку лезть в дебри того же Clojure и ClojureScript, или сначала набрать достаточно опыта в обычных языках и фреймворках? Есть ли "правильное время" для изучения функционального программирования?
Отвечает Никита Прокопов (@tonsky)...
Недавно запущенные проекты на Хекслете очень хорошо показывают системные ошибки начинающих разработчиков. В этой статье я описал некоторые паттерны, следование которым поможет решать задачи быстрее и лучше.
Что самое трудное в работе программиста? Выдумывать имена для переменных.
Эта шутка пользуется популярностью среди программистов не случайно. Именование часто становится причиной целых баталий. И действительно, то, как мы именуем наши сущности (функции/переменные/константы/классы/модули), имеет большое значение, ведь большую часть времени мы читаем код, а не пишем.