Часть 1/3. Какие бывают 'плюшки'.
Часть 2/3. Подводные камни для «новичка».
Какие бывают работодатели. Характерные особенности.
Вместо краткого вступления, одну закономерность можно назвать сразу: чем длиннее и крупнее проект, тем древнее технологии. Хотите на практике освоить новые технологии — участвуйте в стартующих проектах длиной 3-6 месяцев.
-
Фирмы, работающие на Министерство обороны и подобные структуры
Секретность, используется относительно узкий набор технологий — которые сертифицированы в ФСБ. Например, Java 1.6 и Tomcat сертифицированы, а EJB-контейнеры не сертифицированы, вместо них может использоваться самописная недо-пародия. Что хорошего в самописных недо-пародиях — разработчик, что называется, “под боком” и доступен для общения, что плохого — какая-то мелкая функция, которая есть, но её пока (почти год) не использовали, но которая внезапно понадобилась тебе, — может просто тупо не работать (но можно заставить разработчика быстро починить).
-
Фирмы, разрабатывающие продукт на собственных, старых и кастомных платформах
Бывают и EJB 2.0 без аннотаций и собственные недо-ORM 1999 года выпуска и прочие самописные недо-пародии и “системы, управляемые метаданными”. Самое плохое в этих платформах (кроме качества кода с методами по 2000 строк и интенсивным переиспользованием переменных: они, точнее, их первые версии, написаны ещё до того, как понятие “качество кода” стало в России в ходу) с точки зрения человека, привыкшего оценивать платформы в значительной степени по лёгкости рефакторинга (поклонники PHP, Python, Ruby и NodeJS могут выказать недовольство, но я пишу в первую очередь про Java), — это отсутствие поддерживающих эти изобретения нормальных плагинов для IDE для редактирования метаданных не в сыром текстовом виде и недостаточный уровень средств отладки и диагностики этих систем (как если бы виртуальная машина Java вместо бросания NPE с дампом стека просто бы падала из-за ошибки уже в самом своём бинарнике, вызванной попыткой всё же получить что-то там от объекта, который находился бы по этому указателю “в никуда” (о безопасности, разумеется, при этом можно забыть), скупо что-то сообщая об этой вызванной входными данными ошибке в интерпретаторе — так что даже поиск ответа на вопрос “в каком месте метаданных программы находится ошибка” может сам по себе оказаться нелёгкой задачей).
-
Фирмы, работающие по заказам от гос- и муниципальных структур.
Разные сочетания длительности проекта и новизны технологий. Практически неизбежна, на определённом этапе, интеграция через SOAP с серверами госведомств с геморроем на тему что делать с участком этой интеграции на стадии отладки и тестирования. Иногда строгий дресс-код с пиджаком и галстуком. Нередко требуется писать на других языках, кроме Java.
-
Околобиллинговые софтверные фирмы.
Хитрые заморочки с безопасностью типа инкапсуляции доступа к, в общем случае, чужой БД через серверные процедуры и нескольких слоёв авторизации. Некоторый упор на быстродействие. Большой упор на корректность, целостность данных и аккуратность работы с памятью. Для примера, тарифный план может воплощаться классом, реализующим специальный интерфейс, и после того, как план устареет и с него уйдёт последний пользователь, этот класс выгружается контейнером.
-
Фирмы, разрабатывающие софт (на Java) для работы на финансовых рынках
Ключевые требования к софту — быстрота (в частности, по части оптимизации под сборщик мусора) и многопоточность. Может требоваться разработка встроенного мета-языка то ли пере-настроек то ли недо-программирования.
-
Фирмы-оффшорные разработчики
Основное требование — встраиваться в бизнес-процессы заказчика. Для этого нужно не отличаться от заказчика на взгляд руководства заказчика, т.е. по крайней мере не отличаться от заказчика больше, чем одни его подразделения отличаются от других подразделений.
Качество кода — особый “пойнт”. Писать код нужно лучшего качества, чем программисты самого заказчика. Основное требование к качеству — чтобы не было в коде ничего такого, к чему можно было бы придраться, в основном сходу: чтоб никто из штатных работников заказчика не мог просто так подойти, ткнуть в какое-нибудь место в коде и с полным на то правом сказать “а чо за хрень они тут написали”. Бывает, дело доходит до требований писать комментарии к геттерам и сеттерам. Ещё момент: нужна овер-коммуникация — чтобы заказчик был (у)спокоен. Несколько напоминает ситуацию обращения с “VIP-пациентом в психушке”, но именно этот “VIP-пациент” и платит деньги.
В некоторых особых случаях возможна не особо чёткая постановка задачи, где оно слово может влечь создание дополнительной четверти объема и архитектуры системы, но это бывает редко и когда автор постановки со стороны заказчика — лицо совершенно не-техническое.
Это опыт который стоит иметь. «Культура производства» тут обычно выше, чем в российских компаниях, потому что намного сильнее поставлены учёт и отчётность: тот, кто платит деньги, хочет знать, на что их потратили. Технологии тоже новее: ориентация на короткие проекты повышает формализованность и “свежесть” используемых технологий.
-
Подразделения иностранных компаний
В основном похоже на отечественные “Фирмы, разрабатывающие продукт на собственных, старых и кастомных платформах”, только несколько получше с формализацией, проработанностью решений, технологической дисциплиной и прочей культурой производства. Используемые технологии тоже новизной не блещут. Но платят обычно неплохо.
-
“ИТ-компании”, обслуживающие итернет-тотализаторы
“Хитрая” работа с БД — без domain-объектов, с domain-методами и “голыми” идентификаторами, на зато быстро. “Экзотические” и малораспространённые web-фреймворки. Большая “текучка новичков” (испытательный срок проходит около половины принятых на работу) и некоторая ориентация рабочего процесса на эту большую “текучку новичков”.
-
“Программистские” отделы не-ИТ-компаний
Бывает разное. Самое плохое, что вы будете подчиняться распорядку рабочего дня предприятия, а не тому, который удобен для работы программиста. Особенно же “веселит” ситуация с соответствующими отделами компаний, держащих во внутренней сети компании (единой для всех предприятие) клиентские базы и прочую «чувствительную» конфиденциальную информацию, и этого из-за замороченных на безопасности. Там “рулят” безопасники. С их точки зрения нет понятия “разработчик”, а есть только понятие “сотрудник”. Представления у безопасников такие: Рабочая среда настраивается один раз и по запросу обновляется сотрудниками хэлпдеск… Каждый должен заниматься своим делом — программист программировать на предоставленном инструменте, техподдержка — поддерживать актуальное состояние ПО и решать технические вопросы пользователей, системные администраторы — администрировать инфраструктуру, а сотрудник отдела ИБ — контролировать соблюдение условий безопасной работы IT-сервисов предприятия. Заметим: «программировать на предоставленном инструменте». Т.е. чтобы не висеть у программиста “гирей на ногах”, пресловутый «хэлпдеск» должен не хуже, чем программисты, разбираться в “предоставленном инструменте” — средах разработки, виртуальных машинах, средствах работы с базами данных типа SQL Developer и прочем инструментарии. Ведь такая же картина с уровнем знания софта имеется в отношении других “сотрудников” типа секретарей, инженеров, юристов, продажников и снабженцев. Далее вопрос: зачем с такими скиллами работать в техподдержке, если программистом с ними же заработать можно больше? Поэтому нормальная, в общем-то, «техподдержка» для нормального, в общем-то, программиста непременно будет «дубиноголовым вахтёром», постоянно мешающим работать.
Из-за этого в таких компаниях постепенно приходят к разумному выводу, что лучше «внутри» ничего не разрабатывать, разработку отдавать “вовне”, а «внутри» только ставить задания подрядчику, взаимодействовать с ним и готовить для него специально обезличенные “игральные” данные для отладки.
Но ради строчки в резюме (хотя кто ещё из знающих реальный расклад на неё “поведётся”?) поработать можно…
-
Аутсорсинговые фирмы
Могут заниматься не только сдачей персонала в аренду, а ещё и сами что-то разрабатывать. Ну тут как повезёт (на том проекте, куда «зааутсорсят»). Из минусов — практически никакой перспективы служебного роста (и по части профессионального роста перспективы слабые) и полоховато со стабильностью. Из возможных плюсов — могут «зааутсорсить» за границу, можно посмотреть IT-культуру разных народов, в этом варианте пока ждёшь визы или старта проекта — можно вообще не появляться на работе, только оставаться «в пределах досягаемости».
Вместо заключения
Хотелось бы выразить надежду, что число тех, кому эта статья окажется полезной, будет не сильно мало.
Часть 1/3. Какие бывают 'плюшки'.
Часть 2/3. Подводные камни для «новичка».
Автор: Flammar
