Resume Driven Development

Один из частых вопросов у любого инженера (и не только) — как и когда учить новое? Технологии (по крайней мере внешне) обновляются довольно быстро, количество инструментов, которыми необходимо владеть для ежедневной работы растёт и нужно все это как-то изучать и применять. Для решения этой проблемы и была придумана методология RDD она же Resume Driven Development. Для начала ответим на вопрос “как?”, он же “форма обучения”. Я считаю, что всё нужно изучать на реальных и нужных кому-то проектах (e.

Как разжечь срач в интернете

Есть несколько тем на которые у любого человека есть что сказать: религия политика отношения Обсуждение любой из этих тем моментально провоцирует срач и в терминальных случаях приводит к “вычислю по ІР”. Два года назад в твиттер треде про women in tech мне люди на полном серьезе угрожали физической расправой хотя я вроде ничего оскорбительного или радикально-провокационного не говорил. Хотите пошуметь — выбирайте одну из этих тем и вперед —гарантированно получите мощнейшую дискуссию, правда совершенно деструктивную и бесполезную.

Главный язык который должен знать любой разработчик

Помимо английского. Язык который пригодится везде и всегда, бекендеру и фронтендеру, и даже не только разработчику, но и тестировщику, бизнес-аналитику, (дев)опсу и вообще кому угодно. Язык который можно сказать в своей базовой форме универсален посреди всех платформ и практически не изменялся десятилетиями. Язык, к вызовам которого сводится 80% всей разработки вообще. Это… SQL! Во времена JavaEE ходили шутки что вся разработка это пересылка XML из одной системы в другую. Описание это не совсем точное, потому что там упущен момент вытягивания данных с помощью SQL из базы, конвертации их в XML, отсылки куда надо по SOAP и обратной процедуре.

Полиглотопроблемы

Я “знаю” кучу языков программирования. Начал с синей книжки по С которую отец мне дал читать когда у меня еще компьютера не было, потом в школе Basic, Pascal и немного JS, потом в университете Pascal, asm х86 и микроконтролерный, Java, Ada, потом на работе Java, SQL, Bash, потом на другой работе Python, JS, Bash, потом на третьей работе Objective C, PHP, Ruby, JS, SQL. Сейчас 60/20/10/10 это Ruby/JS/Java/Python (SQL не считаем).

Продукт против платформы

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

О хвастовстве

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

Полумеры

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

Замаскированные сервисные компании

Есть такой тип сервисных компаний которые маскируются под продуктовые. Например, NC, где я работал (и даже может быть кто-то из присутствующих здесь работает сейчас) позиционирует себя как продуктовая компания. Хотя на самом деле разработкой продукта занимаются в свободное от проектов время, а 80% работы — это запил кастомных решений под потребности кастомера. Да, безусловно используется фреймворк, платформа и какие-то коробочные решения, но большинство людей занимаются кастомной разработкой и поддержкой конкретных заказчиков (иногда эти кастомные продукты по мощностям и сложностям сравниваются с коробочными а то и превосходят их) а вовсе не разработкой продукта.

10 смертных грехов спрашивателей вопросов на митапах и конференциях

После любого доклада дают время на вопросы-ответы докладчику. Человек, который задает вопрос распоряжается бесценными ресурсами — временем докладчика и вниманием аудитории. Секция вопросов — важная часть доклада которая дополняет и улучшает восприятие информации. Логичным будет проявить максимальную эмпатию к указанным категориям лиц и правильно задавать интересные вопросы. Однако вместо этого чаще всего мы наблюдаем следующие расклады: Человек начинает с “спасибо за за доклад, очень интересно, у меня есть вот такая ситуация” и дальше начинает расползаться на несколько минут, повторяя одно и то же, задавая риторические вопросы и тут же на них отвечая в итоге завершая “что вы можете сказать по этому поводу?

Почему я не люблю чаты и синхронное общение

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

Бессмысленный и беспощадный аутсорс

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

О реитерации идей и самоповторах

Когда я только первый раз наткнулся на Егора256, то залпом прочитал все посты в блоге (некоторые по два или три раза) и дальше читал уже по подписке + подписался на твиттер. Однако со временем я заметил что Егор в твиттере репостит ссылки на свои старые материалы, доклады делает примерно на одни и те же темы, а статьи новые дополняют и повторяют старые идеи. Тогда я подумал — ”нет, такое никуда не годится, подавайте мне новый контент, иначе дизлайк отписка!

Кого я читаю и откуда ворую идеи 3. Разное

Разное: Less Penguingy — чел исследует социальные взаимодействия. Пока что только несколько статей но надеюсь что будет еще. Очень интересная статья про типы хвастовства. Я применяю все ))) Дизайн инфографика инфостиль и тд: Grumpy Website — проект Никиты Прокопова про плохие интерфейсы. Раньше читал с удовольствием щас поднадоело. Доза безысходности на каждый день. Илья Бирман — дизайн, схемы, инфостиль и все такое. Схемы карты фотки и тд. Люто бесит его манера писать ПХП и Энджинкс вместо php и nginx но шо поделать…

Кого я читаю и откуда ворую идеи. Норм типы

Околодевелоперское: vas3k — многие из вас пришли от него. Вастрику спасибо за возможность пиариться через донаты. Пишет что-то вроде научпопа, довольно интересным и живым языком. Когда я только его нашел то залип и прочитал все “инсайды” за раз. Лонгриды на мой взгляд не такие интересные как “инсайды”, может быть потому что это все-таки научпоп а я вроде как чуть шарю в теме. Делает клёвые иллюстрации и вообще основательно подходит к подготовке материала.

Кого я читаю и откуда ворую идеи. Топчики

Я уже писал (раз, два) о том, что читать (tl;dr: хакерньюз), теперь пройдусь по списку конкретных авторов и людей которых я котирую. Я еще помню времена гугл ридера, и после печального закрытия этого замечательного проекта переехал на feedly и все читаю через него. RSS решает. Самые топ чуваки: Артемий Лебедев — тут все понятно. Вообще, я считаю Тёму самым топовым из всей этой компании. Он смог построить прибыльный и успешный бизнес, отлично качественно и интересно пишет уже десятилетиями, при этом живет в своё удовольствие а не гробит себя в офисе 24х7.

Выступление на конференции. Заметки для начинающего спикера.

Само выступление — это как результат сложного взаимодействия спикера, продакшн команды, публики и помещения. В каждом из этих звеньев что-то может пойти не так и нужно стараться нивелировать все риски. Однозначно не стоит выступать первым. Причина не только и столько в том что публика еще не разогрета (может быть у вас митап который проходит вечером), а в том, что техническая часть может быть не отлажена. На вышеупомянутом Zlit например первые докладчики страдали от того, что были проблемы с кликером.