Две недели назад к нам в New.HR пришел Егор Толстой (YourDestiny) и попросил собрать данные для его доклада на TeamLeadConf.
Егора интересовало:
• Сколько вакансий тимлидов есть на рынке.
• Какое количество вакансий закрывается внешними кандидатами, а какое – внутренними.
У нас было всего две недели до конференции, желание сделать интересный анализ рынка тимлидов, и вот что мы успели за это время:
Читать полностью »
ххх: на чём пишешь фронтенд?
yyy: на костылях и велосипедах
ххх: ммм, хороший фреймворк!
Bash.im
Когда приходит мысль стать программистом, ты вдохновенно открываешь справочник Шилдта по С, заказываешь толстую книгу Страуструпа по С++ и учишься шутить про указатель на указатель на указатель и про рекурсию. Жёсткая романтика первого времени… Но всё меняется, когда в твою жизнь случайно приходит JavaScript. «Какой он простой, понятный, какой классный синтаксис! Всё, решено, буду писать сайты», — думает начинающий программист и решает стать гуру всея веба. Но потом выбранный стек меняет своё дружелюбное лицо, и чем дальше, тем больше. Но ты уже не можешь остановиться, потому что ты один из них — фронтенд-разработчиков. Тех самых, которые «смотрящие за мордой сайта». Ну что, захотелось присоединиться? Тогда для вас 2 серия нашего спецраздела «Профессия:…»
Мы уже готовили эту статью, когда в среду вышел пост «Хабр Карьеры» с интервью представителя онлайн-школы о работе фронтенда, что не могло не радовать: значит, в нашей серии «Профессия:..» появится очередной нужный, полезный, актуальный материал. Кстати, первый выпуск был посвящён профессии системного администратора.
Читать полностью »
Если попытаться составить список всего, о чем можно сказать «лучше меньше, да лучше», то вряд ли в него войдет рабочее общение вживую: во многих компаниях оно считается ключевым компонентом в организации обмена идеями, решения проблем и группового анализа.
Но что, если правильно примененное удаленное общение делает обмен идеями, решение проблем и групповой анализ более плодотворными?
В отчете Buffer за 2019 г. 99% из почти 2500 респондентов ответили, что хотели бы иметь возможность работать удаленно хотя бы время от времени, а ведь это уже не синоним работы в одиночку — благодаря быстрому распространению цифровых инструментов совместной работы.
Научившись пользоваться такими инструментами, можно фактически устранить некоторые препятствия в коммуникации (и, следовательно, в продуктивности), с которыми приходится сталкиваться в привычном офисном окружении.
Переведено в Alconost
Читать полностью »
Самое дурацкое занятие на свете – изменять. Оно даёт необычайно сильные эмоции, с одной стороны, а с другой – способно начисто выхолостить, опустошить, лишить друзей и даже любимой работы.
Пару историй расскажу. На истину в высшей инстанции не претендую, разумеется.Читать полностью »
Я прослушал книгу "Культурный код" Даниела Койла ("The Culture Code: The Secrets of Highly Successful Groups" by Daniel Coyle) после прочтения отрывка, который оставил впечатление «вот оно!»
Вся книга оказалась на том же уровне, что и вступление. Она полностью поменяла мое представление о работе в командах. Пока из всех книг о работе которые я прочитал, я думаю что «Культурный код» повлиял на меня больше всего. На второе место и третье место я бы поставил "В работу с головой" Кэла Ньюпорта ("Deep Work" by Cal Newport) и "Принципы" Рэя Далио ("Principles: Life and Work" by Ray Dalio).
На мой взгляд, «Культурный код» обязателен к прочтению всем, кто работает в команде.
Этот пост — мои заметки из книги.
Читать полностью »
Мы, в ProtocoleOne, пишем разные проекты и почти все они Open Source.
И так уж сложилось, что крутые специалисты живут в разных городах и даже странах и не только в столицах.
Один из таких проектов — PaySuper. Проект для монетизации игровых проектов и упрощения приема платежей.
Я каждый день работаю с множеством крутых парней, списываюсь и разговариваю на утренних созвонах, и, приехав как то раз в офис, из всех них я встретил… одного.
Все остальные были где-то в “виртуальном” мире соединенным со мной оптоволоконной линией. И при всем этом нам удается разрабатывать сложные, долгие и крутые (ну по крайней мере я так думаю :) ) проекты.
Как? Давайте попробуем разобраться.
В общем и целом, эта статья — мой личный опыт, но я попробовал его разбавить мнением с “другой стороны”, а именно со стороны тим-лидов и технического директора.
Многие люди думают о волнующих их проблемах перед сном или по пробуждении. Я не исключение. Сегодня с утра у меня в голове всплыл один коммент с Хабра:
Коллега в чате поделился историей:
У меня в позапрошлом году был офигенный клиент, это ещё когда я брал чистый «кризис».
У клиента в девгруппе две команды, каждая занимается своей частью продукта (условно, бэкофис и сторфронт, т.е. софт работающий над формированием заказа и софт, работающий над исполнением заказа), изредка между собой интегрирующийся.
Команда бэкофиса прям вот совсем в днище ушли: полгода сплошных косяков, собственники грозятся всех уволить, наняли консультанта, после консультанта наняли более другого (меня). Причём вторая команда (сторфронт) работала норм и продолжала работать норм, именно бэкофисная, которая до этого тоже норм работала, стала косячить. Команды в разных офисах сидят, друг на друга привыкли псить.Причина: стор и бэк это одна система, в ней куча зависимостей, команды в разных офисах, между собой не общались. На сторфронт все время «смотрят» собственники, соответственно у них там новые фичи, идеи и контроль. В ней был мальчик-на-все-руки, такая комбинация из БА, дизайнера и «принеси нам кофе». Вот этот мальчик, незаметно для своей команды, выполнял кучу мелких задач типа «предупредить вторую команду о деплое», «проапдейтиь документацию» и т.п. рутину, вплоть до «внести в жире в тикет всякие номера версий и компоненты». Но код мальчик не писал и в один момент собственники решили его оптимизировать, нафиг уволив. Для команды стора ниче не поменялось, они просто не вносили и не апдейтили доки, а команда бэкофиса оказалась в ситуации, когда релизы стора ломают у них что-то, и это их проблемы, а если их релизы ломают что-то у стора, это опять их проблемы, потому что стор на виду у собственников :)
Чем меня зацепил этот коммент и что обрящет ищущий из заголовка — под катом.
Иллюстрация Лорейн Йоу. Суслик-талисман языка Go адаптирован из работ Рене Френч
Два года назад автор этой статьи Майкл Линч (Michael Lynch) уволился с должности инженера-программиста в Google, чтобы начать собственный бизнес (см. статью «Почему я ушёл из Google и начал работать на себя», 443 комментария на Хабре, +216). Вместо «Google» в заголовок можно поставить название любой крупной компании — фабрики программного обеспечения, где каждый программист считается винтиком в большой машине, будь то Microsoft, EPAM, etc…
Мы решили перевести вторую часть статьи — посмотрим, что получилось у автора в качестве независимого разработчика. В первой части он упоминал о проекте Indie Hackers: это онлайн-сообщество для основателей маленьких предприятий по разработке ПО. Ключевое слово «маленьких». Это не будущие цукерберги, не основатели стартапов, а те, кто хочет построить скромный прибыльный бизнес, дающий средства к существованию.
Интересно, что стало с его проектами. Об этом ниже в оригинальном тексте автора.
Читать полностью »
Переезд в другую страну, был моей мечтой с детства. И если к чему-то сильно стремиться, то это становится явью. Я расскажу о том, как искал работу, как проходил весь процесс релокации, какие документы нужны и какие вопросы решали после переезда.
(Много фото)
Читать полностью »
Эта статья поможет специалистам сэкономить время и подготовиться к поискам работы в IT. А компаниям избежать ошибок при найме и лучше выстроить свои процессы.
Читать полностью »
