Представьте, что вот уже долгие месяцы вы – единственный разработчик на проекте. И вроде бы все замечательно: вы вовремя завершаете задачи, пишете качественный код и получаете удовольствие от работы. Но однажды все меняется. Заказчик решает увеличить нагрузку на проект, добавить больше функциональности, и, как результат, отправляет вам на подмогу двух молодых специалистов. Вы больше не один. Теперь интересные задачи придется делить с двумя неопытными троглодитами. Знакомство с командой Чтобы новички сразу прониклись к вам уважением и даже трепетным страхом, вам следует придерживаться ряда простых правил, описанных ниже. Для начала пусть кто-нибудь из ваших коллег посадит их в одном кабинете. Но не делайте это сами! Новичкам нежелательно видеть вас до момента…

В прошлый раз я писал про разницу между опытом и стажем, и почему первый гораздо важнее второго. Сегодня хочу поговорить о людях, которые не ценят свое время и работают исключительно или в большей степени на стаж, не особо вдумываясь в суть задачи и не стремясь изучить что-либо новое для себя. Для таких специалистов вполне приемлемо довести задачу до стадии «вроде работает» и на этом остановиться, не задумываясь о возможных последствиях такого решения. Здесь я расскажу об этих самых последствиях, а также о том, чем такой подход опасен для будущего проекта и для будущего специалиста.

Вася работает программистом 5 лет, а Петя – 7. Вроде как Петя работает аж на два года дольше, и по идее он должен быть Васиным начальником и отдавать распоряжения. Но нет. Пост начальника занимает именно Вася. Несправедливость, скажете вы? А что, если наш Вася за пять лет развился так, как Пете не развиться и за десять? Что такое опыт, а что такое стаж? Почему опыт – это то, к чему вы должны стремиться, а стаж – это лишь цифры в вашем резюме?

Наша жизнь кардинально изменилась, когда нас повсюду начали окружать высокие технологии. Ты – поэт и хочешь поделиться своим творчеством с широкой публикой? Тебе в сеть, товарищ. Может быть, ты – бизнес-тренер и тоже желаешь распространить свою чудодейственную методику, как заработать легкие деньги? Тебе снова в сеть. А что, если тебе 12 лет, твоих карманных расходов не хватает на новый гаджет, и ты грезишь о легкой наживе? В сеть! Любой человек может реализовать себя в сети, и это здорово. Но разве когда-нибудь было что-то хорошее, на чем не хотел бы поспекулировать хотя бы один лентяй в поисках легкой выгоды? Представляю вам небольшую подборку лодырей в этом посте.

Недавно я давал вредные советы на тему того, как быстро заработать повышение: «всегда добавляйте фичи в последний момент», «забейте на структуру и тестирование» и так далее. Настало время всерьез поговорить об этом и разобрать, почему вам на самом деле стоит крепко задуматься, прежде чем согласиться что-то добавить накануне релиза и сказать твердое «нет» своему начальнику.

Недавно наткнулся на пост про отношение программистов к такой базовой штуке, как инкапсуляция. Собственно, все ее уважают и стараются соблюдать, но складывается впечатление, что не все до конца понимают, зачем оно все-таки нужно на самом деле. В этом посте попробую привести простую аналогию, чтобы у вас сразу отпало желание эту самую инкапсуляцию нарушать.

Запомните, орлы, что на каждой работе можно весьма и весьма быстро заработать повышение. Вам нужно всего лишь постоянно соглашаться со своим начальником, ОСОБЕННО когда он просит добавить важную фичу перед релизом. В этом посте мы рассмотрим паттерны вашего поведения, которые непременно приведут к успеху.

Много в свое время говорили про Blockchain, да и сейчас наши деды иногда вспоминают это слово. Обещали, что вся эта технология поможет нам стать наконец свободным людьми и избавиться от централизованного контроля. Однако, на деле все вышло немного по-другому. Вся эта многообещающая штука скатилась с биржу типа форекс, где серьезные дядьки с большими портфелями могут менять доллары на токены и торговать ими. А еще где-то была кафешка, продающая кофе за биткоины. Но самое лучшее применение blockchain изобрел один (а может, и не один) мамкин хакер, и здесь я хочу рассказать, каков же его взгляд на применение этой замечательной технологии.

На днях я столкнулся с весьма загадочным и мистическим явлением в лучших традициях сериала «Секретные материалы». Аж кровь в жилах застыла. В общем, удалили пользователя из системы, а душа его осталась плутать по закоулкам и пугать все входящие API запросы. Да так, что сторонние системы, которые эти запросы слали, в ужасе шарахались и бросали NullPointerException. Если не хотите спать сегодня ночью, то смело заглядывайте сюда и узрите сию жуткую историю.

Мне действительно повезло – когда я впервые трудоустроился по профилю в 2010 году, я попал в хорошую компанию и работал рядом с профессионалами высокого уровня и просто хорошими людьми. Рядом с ними я быстро рос. Мне всегда показывали хорошие практики и действительно уделяли мне время. Почти во всех компаниях, в которых я работал, практиковался такой же подход. Но не всем так повезло – многие начинали свою карьеру в конторах довольно паршивого уровня, где их попросту было некому учить. Или вовсе не хотелось. Собственно, из таких историй и родился предыдущий пост в стиле вредных советов. Здесь я хочу рассмотреть несколько реальных случаев из жизни начинающих разработчиков, которые я видел, и сравнить…