Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:
Давайте вспомним некоторые типичные грабли, на которые мы все (ну или большинство) наступали сами того не замечая. Конечно, для опытных разработчиков многое покажется очевидным капитанством, однако молодых специалистов такие ловушки могут легко увести на темную сторону силы.
1. Человек-оркестр
Симптомы:
Небольшая фирма, набирают программистов без опыта работы. На собеседовании о будущих обязанностях вываливают гигантский список «поддержка по телефону, прокладка сети, тестирования, бизнес анализ, обучение пользователей… что программирование? А да… конечно, и программирование»
В чем грабли:
В лучшем случае, вас обманут как раз программирования в список ваших обязанностей и не входит, или входит по принципу если очень хочется в свое личное время можешь бесплатно нам что-нибудь накодить.
Почему в лучшем? Потому что в худшем, вы будите писать код левой пяткой, правой пяткой обжимая сеть, в левой руке держа трубку телефона, пытаясь понять проблему недовольного клиента, а правой рукой делая записи желаний клиента. Такая ситуация очень характерна для небольшой фирмы, которая пытается делать все подряд за счет небольших ресурсов. Вечный цейтнот, принцип фиг-два и в продакт, разброс от рисования страничек в вебе, до администрирования сайтов. Проблема в том, что учиться правильно программировать, когда ты работаешь человеком-оркестром очень сложно, да и не у кого обычно.
Плюсы:
После такой работы, любая другая покажется спокойной и неторопливой.
Рецепт:
По возможности ищите организации, где не пытаются совмещать роли программиста и грузчика. На крайний случай, учитесь всему чему сможете и подыскивайте новое место работы.
2. У нас в Греции все есть
Симптомы:
Крупная фирма, вплоть до кровавого Enterprise. На собеседовании вам долго рассказывают о своем замечательном ядре, сколько у них своих изобретений. Быстро можно понять, что в фирме вообще все свое: ORM, коллекции, фреймворк, интеграция, платформа, все естественно закрытое и проприетарное.
В чем грабли:
Первое время вы с интересом играетесь с чужим кодом, дописывайте его и разбираетесь в чужих идеях. Проходит год, два, пять, вы решаете сменить работу, приходите на собеседование и на все вопросы «а знаете ли вы открытый фреймворк А или библиотеку Б» отвечаете «нет, у нас все было свое», в конце концов, помрачневший интервьюер начинает задавать вам элементарные вопросы о коллекциях, но вы понимаете, что даже коллекции у вас были свои…
Плюсы:
Вы изучите богатый опыт велосипедостроения для самых разных задач, иногда это может быть полезным…
Рецепт:
Участвуйте в open-source проектах, используя популярные технологии и фреймворки. Всегда старайтесь обновлять знания современных технологии и фреймворков вашего языка.
3. Медные трубы и звездная болезнь
Симптомы:
Прошло пару месяцев на работе и вас за героические заслуги в кодинге перевели из джуниор в мидалы, ещё пару месяцев уже называют senior, потом ведущим программистов и т.д.
В чем грабли:
Оглянитесь. Это правда вы такой гений или руководство вашей фирмы, по старинной русской традиции, заменяет нормальную зарплату орденами и званиями? Проблема в том, что senior'ом не стать за год, так как одно из важнейших его качеств это профессиональная интуиция, умение находить золотую середину между паттернами и простотой, между комментированием всего подряд или наоборот полного отказа от комментариев, по заветам чистого кода. Это равносильно тому чтобы стать великолепным хирургом за год после института.
С одной стороны, в этом нет большой проблемы, но человек обычно редко включает здравый смысл и реально начинает верить, что он все знает и умеет. Сильно обижается минусам на код ревью и сильно удивляется если его другие фирмы не хотят брать senior'ом.
Плюсы:
Уверенность в своих силах — это замечательно, особенно когда она будет обоснованной
Рецепт:
Самокритика, самокритика и ещё раз самокритика…
4. Болото
Симптомы:
Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ. Технических собеседований про приеме на работу нет или их проводить явно слабый специалист… или старичок, который пытается спрашивать о языках программирования сгинувших вместе с перфокартами.
В чем грабли:
В таких компаниях людей у которых можно учиться нет, начальство зачастую не понимает, что и как делать, производственный процесс построен «спроси там у бухгалтеров, им нужно какую-то программку сделать», зачастую программисты и эникейщики в понимании руководства — это почти одно и тоже, и зачастую разработчиков заставляют делать презентации и переустанавливать ОС. Методологии разработки? Нет, не слышали…
Плюсы:
Даже самый средний junior в таком болоте может чувствовать себя крутым специалистом, так как все мало-мальски хорошие специалисты давно оттуда убежали (если вообще когда-то были), кроме того этот самый junior может попытаться разрабатывать приложение сразу во всех ролях, от бизнес-аналитика до тестера.
Минусы:
Учиться чему-либо в такой компании очень сложно, просто потому что не у кого.
Рецепт:
Вообще, сменить работу, но, если невозможно… Учиться самому где угодно и чему угодно.
5. Фриланс
Симптомы:
Вы Junior разработчик, собирающийся постоянно работать только во фрилансе.
В чем грабли:
Фриланс может быть полезен, если вы уже набрали опыта и состоялись как специалист, когда Junior разработчик начинает с фриланса, то начинается фриланс головного мозга, примеров старших разработчиков у него нет, на код заказчику по большому счету плевать, тот код что он видит написан, как правило, такими же Junior-фрилансирами что он сам. Короткие заказы/проекты формируют модель разработки «тут накостылять, тут заплатку сделать, деньги получить и забыть навсегда».
Плюсы:
В качестве дополнительного заработка, во фрилансе нет ничего плохого, так же как если у вас лет 5 промышленного программирования за спиной.
Минусы:
Молодому разработчику очень легко привыкнуть к тяп-ляп и в продакт, от чего потом сложно будет отучиться. Да и реальные работодатели к опыту во фрилансе относятся очень скептически, особенно если опыт только во фрилансе… тут вообще будут сомнения насколько человек способен работать в коллективе в принципе.
Рецепт:
Не уходить полностью во фриланс в начале карьеры или постоянно изучать материалы по написанию правильного кода.
6. Горизонтальный и диагональный рост
Симптомы:
К вам приходит твой начальник и говорит. «а давай ты станешь бизнес аналитиком/project manager'ом/дизайнером/техническим писателем и т.д.» Ура! — кричишь в душе ты, ведь тебя учили что повышение — это всегда хорошо.
В чем грабли:
Если перевести речь начальника в гугл-транслейте с дипломатического на русский, то она звучит так «а давай ты перестанешь быть программистом, выкинешь все годы опыта и диплом и начнешь учиться с нуля новой профессии»? Если вам кажется, что программирование — это как велосипед разучиться невозможно и вы сможете совмещать функции менеджера и программиста — вы ошибаетесь, через полгода-год без программирования ваш уровень упадет очень сильно. Если вам кажется, что менеджеру ничего уметь не нужно, только руководи — вы заблуждаетесь. В целом, менеджер — это совсем отдельная профессия, почти не связанная собственно с программированием, можно быть отличным менеджером проекта и вообще не уметь программировать. Даже совмещать работу программиста и team lead'а без потери для одной из специализаций уже сложно, для менеджера проекта совмещать свою работу и программирование вообще вредно.
Плюсы:
Если новая профессия — это то, о чем вы мечтали всю жизнь — вперед! Если вам надоела старая роль и вы потеряли мотивацию — вперед!
Минусы:
Вы можете потерять опыт прошлой профессии и не суметь быстро научиться навыкам новой профессии. Собственно, как только вы станете менеджером, вы перестанете быть программистом и ещё не факт, что сумеете стать реально хорошим руководителем.
Рецепт:
Или не уходить в менеджеры или если вам предложили, то от чего вы не можете отказаться, заниматься open source/своими личными коммерческими проектами для поддержания навыков программирования.
7. Потеря мотивации к развитию
Симптомы:
Вы работаете от звонка до звонка, вы считаете, что все уже знаете и учиться уже нечему, вас вполне все устраивает на текущей работе.
В чем грабли:
Программист как велосипед, как только он останавливает — падает. Перестав развиваться, программист неизбежно начинает деградировать, превращаясь в робота для написания кода. Проблема обычно в том, что сам он этого, как правило, не замечает, вроде работает и работает, копируя свои старые наработки из проекта в проект. Тут критерий простой, если за год вы не изучили/создали ни одной новой технологии/библиотеки/языка/фреймворка, то у вас с саморазвитием что-то не то.
Плюсы:
Вы в зоне комфорта, деньги есть, стабильная работа есть, у вас все хорошо.
Минусы:
Вы попали в машину времени и оказались в эпохе застоя Брежнева.
Рецепт:
Определитесь действительно ли это то что вам нужно, если нет меняйтесь — меняйте работу, открывайте свое дело, запускайте open source проекты, в конце концов становитесь менеджером.
…
N. ...
А тут каждый может вписать в комментариях свою любимую граблю. И да! Всех с ПЯТНИЦЕЙ!
| 23% (312) |
Да |
| 34% (480) |
True |
| 13% (187) |
Not false |
| 2% (30) |
Да!!! |
| 3% (39) |
Дзынь! |
| 7% (99) |
Бульк! |
| 2% (35) |
Ура! |
| 16% (219) |
Пяяяятниииицаааа!!! |
Проголосовал 1401 человек. Воздержалось 274 человека.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (70)
Extremum
20.11.2015 08:35+2Насчет фриланса верно, сам пришел туда с минимальными знаниями, ставил заплатки на чьи-то костыли, настраивал cms-ки гордо именуя себя «web-разработчик» и масса времени пролетело в бесполезной однотипной работе. Но хоть успел спохватиться и вырваться из этого замкнутого круга)
Scf
20.11.2015 09:32+13Я бы не был так однозначен по второму пункту. Выбирая между фреймворком и велосипедом, нужно оценивать временные затраты на освоение/настройку/допиливание первого и написания/отладки второго. Чем выше требования к ПО и чем выше квалификация девелоперов, тем чаще пишутся свои библиотеки.
Сеньорных программистов на собеседованиях часто вообще про фреймворки не спрашивают — спрашивают про языки программирования, концепции написания и оптимизации программ, опыт реальной разработки, мнения о правильной организации процесса разработки ПО.
Уже готовые фреймворки универсальны — за что часто приходится расплачиваться эффективностью, гибкостью и простотой.
lumini
20.11.2015 14:00+11> Чем выше требования к ПО и чем выше квалификация девелоперов, тем чаще пишутся свои библиотеки.
Видел команду, написавшую свой минималистичный движок базы данных для их продукта. Долго шутил про «велосипеды», пока не увидел результаты сравнения тестов их узкоспециализированной бд со стандартными SQL и NoSQL решениями. Разница на пару порядков не в пользу универсальных баз. С тех пор шучу осторожнее. :)
Scf
20.11.2015 09:35+4И про седьмой пункт — моё любимое:
«Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!»
Carroll, Lewis: Through the Looking-Glass and What Alice Found There
lumini
20.11.2015 10:08+8Некоторые соображения по поводу п.4, из личного опыта (делаю ЭТО уже семь лет подряд в НЕ айтишной компании и счастлив). Из плюсов:
— У многих (в том числе и у меня) есть комплекс «работы на дядю». Когда у тебя есть возможность выбора всего, начиная от платформы разработки, заканчивая временем прихода-ухода с работы, комплексы удается успешно подавить. Многие мои одногруппники работают в разработке в больших конторах типа мейла или майкрософта, но лично по мне гораздо приятнее в маленьком и уютном местечке, где есть возможность повлиять на все происходящие процессы.
— Учиться вообще не сложно, если есть личная мотивация. Плюралсайт, линда, codeacademy и так далее. В большинстве тру айти-компаний не будет возможности поиграться в новые технологии, так как — корпоративный стандарт — писать все на (условно) Java. Был опыт работы в месте, где ВСЕ писалось на макросах экселя и гнусном VBA, только потому что однажды большой team lead решил, что «скакать по технологиям нельзя».
— Возможность вникать в не-технические сферы. В общем случае, изучить новый js-фреймворк — это фиговое развитие, а вот занимаясь автоматизацией бухгалтерии (из примера в статье) можно узнать много интересного о функционировании этой самой бухгалтерии. Мир многогранен и не заканчивается на айти-сфере. Почему бы не изучать его, особенно, если за это еще и платят.
— Понимание, что программирование — это инструмент достижения цели, а не цель. Кодить — классно, но главное тут все же — бабло :) Сделать костыльно и дешево лучше, чем идеально и дорого (заложившись, естественно, что будут затраты в дальнейшем на поддержку костылей). Постоянно сталкиваюсь с энтузиастами, которые готовы просидеть неделю в оптимизациях производительности или «переписать все под линукс», но при этом не оценивают, например, затраты на собственную з/п против профита от этой оптимизации.
— На собеседованиях регулярно вижу людей, которые пять лет программируют, понимают внутренности MSIL, но при этом не знают, зачем в БД нужны индексы. Нафига? Они же в «большой компании» программисты, а базами занимаются другие люди. Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать? Этим же админы занимаются. Angular? Нет, фронтендом занимался отдельный человек. Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию… — на этом собеседник вежливо откланивается.
Минусы понятны. Не стать начальником отдела из двадцати кодеров, потому что здесь никогда не будет двадцати кодеров. Застрять в болоте и вечно программировать на «языках с перфокартами», если самому не вытаскивать себя из зоны комфорта. Все в собственных руках, в итоге.
webkumo
20.11.2015 12:33+5«Учиться вообще не сложно, если есть личная мотивация» — а в нормальных компаниях учиться будет ещё и легче — там можно будет почерпнуть опыт коллег. Ну а вообще не очень уверен, что на учебных сайтах можно реально чему-то научиться… впрочем, пользовался только интуитом, возможно другие дают знания лучше.
«Возможность вникать в не-технические сферы» — нужна далеко не всем, есть далеко не в каждом болоте, часть есть в нормальных компаниях. При этом изучить новый js-фреймворк бывает очень полезно, если в копилку к jQuery добавить Angular/Backbone/whatever. Об этом вы, кстати, пишете в конце своего комментария.
«Понимание, что программирование — это инструмент достижения цели, а не цель.» — нужно ПМу и сениорам. Джун и, зачастую, мидл не смогут корректно оценить и получится классическое «фигак-фигак и в продакшен». И да, очень нужно оценивать требования и платёжеспособность клиента. И в любом случае опыт правильной оценки надо где-то набирать.
«но при этом не знают, зачем в БД нужны индексы» — если вам нужен человек-оркестр/фуллстек, это не значит, что рынку нужно много таких специалистов. Каждый находит свою нишу — кто-то фуллстек, кто-то человек-оркестр, а кто-то — углубляется в какую-то нужную технологию. И плевать ему на индексы в БД (которые, кстати, проходятся в универе… и на практике разработчику действительно не нужны — оптимальный запрос он не напишет всё равно, так пусть этим всё-таки специалист занимается).
«Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать» — ещё один пример человека оркестра (причём здесь — уже именно человека-оркестра, а не фуллстека). Девопсы не занимаются разработкой сложных систем, программисты не занимаются настройкой серверов. Админы не занимаются программированием. Вы девопса ищете или программиста? Ну так если вам нужен девопс — не надо писать «senior developer» в вакансии!
«Angular? Нет, фронтендом занимался отдельный человек» — фуллстек он и есть фуллстек. Не все занимаются фуллстеком, слишком много нужно знать — глубина знаний конкретных технологий истончается.
«Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию…» — если вы искали java-программиста, то действительно, вежливо откланиваются — с таким работодателем работать — себе дороже. Конечно есть человеки-оркестры, но редко кто из них достаточно профессионален во всех своих навыках. Зачастую они даже один навык до приемлимого уровня не поднимают.
Ну и обращаю ваше внимание — очень у вас этот абзац диссонирует с абзацем о «не-технические сферы»… Вы бы определились и остановились на чём-то одном, а?
PS дополню только один момент — крупнае софтверная компания — тоже может оказаться болотом. Будьте бдительны, удачного рабочего опыта!lumini
20.11.2015 13:36> Ну а вообще не очень уверен, что на учебных сайтах можно реально чему-то научиться
Вот тут не соглашусь. Подписка на www.pluralsight.com окупает себя многократно (либо из торрентов при желании). Требуется лишь знание английского на уровне понимать техническую речь на слух (а часто еще и субтитры есть). И на телефон можно скачать.
> Не все занимаются фуллстеком, слишком много нужно знать
Классно же уметь все, начиная от покупки сервера, заканчивая микрооптимизациями в коде запросов, разве нет? Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану. Или желания самому с нуля создать законечнный продукт, хоть и маленький, хоть и не везде идеальный, но от А до Я свой (сразу оговорюсь, здесь не идет речь про «не использовать фреймворки», как раз наоборот — без фреймворков с таким подходом свой продукт можно годами делать).
Вообще, все что описано в вашем и моем комментариях — это конфликт концепции микросервисов vs концепции архитектуры со слоями. Аналогично и с распределением задач. Можно взять десять человек, где один хорошо знает БД, другой фронтэнд, третий data science и тд или взять десять «оркестров», которые будут работать в пределах небольших проектов (связанных с другими понятными и документированными интерфейсами), но внутри своего проекта делать все-все-все. Мне оказался ближе второй подход.webkumo
20.11.2015 14:38+7«Классно же уметь все, начиная от покупки сервера» — боже упаси.
«заканчивая микрооптимизациями в коде запросов, разве нет?» — микрооптимизациями в SQL тоже совсем не тянет заниматься.
«Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану» — на уровне небольших проектиков/экспериментов — да, а вот реально сложную интересную систему разработать… сложно иметь высокую квалификацию даже в двух сферах (фронтенд+бэкенд), вы же предложили ещё несколько сфер глубоко осваивать… Даже просто времени не хватит — тот же бэкенд постоянно развивается и знания/умения нужно постоянно обновлять.
«или взять десять «оркестров», которые будут работать в пределах небольших проектов» — а потом быть готовым привлекать профильных специалистов (БД/технологических/нагрузочников/...), т.к. при росте нагрузки есть неплохая вероятность, что кто-нибудь из оркестров сделал кучу бутылочных горлышек в каком-нибудь нагруженном сервисе. Впрочем это нужно не всем сервисам, поэтому оркестры остаются актуальными.
arielf
26.11.2015 01:52Никакой модуль сложной архитектуры нельзя проектировать в отрыве от остальных. Это не значит, что человк у нужно уметь писать все модули самому. Но он обязан знать принципы их функционирования и представлять общую архитектуру. Именно чтобы хорошу выполнять свою узкую работу.
lazexe
20.11.2015 15:51+4А зарплата Вас вообще интересует? Вы сравнивали зарплату программиста в средней ИТ-компании с зарплатой в средней Гос. организации? Они будут отличаться в 5 раз как минимум (в ИТ-компании будет больше, если кому то это очевидно не ясно). А Вам самим за одну и ту же работу не хотелось бы получать больше? Ах, да, забыл, теперь хочу поделиться своим горьким опытом по поводу четвертого пункта. К минусам четвертого пункта можна также отнести наличие кучи пенсионеров-теоретиков, которые забрасывают тебя вопросами по тем языкам которые были актуальны до Вашего рождения, а так же смотря на «магию» Вашего написания кода стоят за спиной. И никуда не деться от старшего поколения, у которых версия их познания в области программирования не обновлялась больше 10 лет, и которая будет рассказывать как тебе делать твою работу. А также сам коллектив у которого из за низкого порога зарплат нет мотивации к работе и они просто 8 часов рабочего дня могут без угрызения совести, простите за выражение, ковыряться в носу/считать дырки в потолке и т.д. И в связи с этим, тебя окружает неблагоприятная к работе атмосфера. Также в Гос. организациях ты не всегда можешь получить нормальный ПК, так как частенько бывают проблемы с финансированием и железо обновляется раз в 10 лет в лучшем случае. Также в таких колективах нет единомышлеников. А иногда в таких Гос. организация ИТ-отдел состоит из 7 человек, 6 из которых совершенно не связаны с этой проффесией и им абсолютно не интересно чем они занимают, а работают они там только потому что их посадили на эту должность. Вышел немного негативный комментарий, но у меня такие впечатления остались только…
lumini
20.11.2015 16:04+1Эээ, совсем мимо комментарий. Я писал о работе в компании, в которой разработка софта — побочная задача («не айтишная»). Про «гос. организации» вообще ни слова.
lazexe
20.11.2015 17:56+2Пункт 4, на который вы давали свой коментарий, а также описывали позитивные стороны:
Симптомы:
Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ. Технических собеседований про приеме на работу нет или их проводить явно слабый специалист… или старичок, который пытается спрашивать о языках программирования сгинувших вместе с перфокартами.
Я именно про такую и написал.olsamurai
20.11.2015 18:28+1А что в вашем понимании старички? 35? 40? 90? И языки, которые давно сгинули. Это какие? АДА и Кобол? Может с++?
lumini
20.11.2015 18:31+1> Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ
Я описал позитивные стороны того, что стоит в этом предложении после «либо». Опыта работы в государственных организациях у меня нет :)
vlivyur
20.11.2015 16:15+4Товарищ работает в медсанчасти сисадмином далеко от столиц, получает больше средней зарплаты сисадмина в айтишной конторе в Питере. Так что не всем это очевидно. Это ещё не упоминая местную айтишную компанию. Чем дальше от столицы, тем привлекательнее становится госсектор.
paranoik
20.11.2015 10:11Набрал 6 из 7, только во фриланс не уходил, а под остальными пунктами подпишусь
oldbay
20.11.2015 11:39+3Оркестр + болото: пишу код на python, скрипты на bash + еще циски конфигурирую… учиться и взаимодействовать с кем либо могу только по последнему пункту.
norlin
20.11.2015 12:24+2Повезло, начал «карьеру» почти с нулевого опыта, но далее приходилось расти, чтоб справляться с задачами. В итоге из перечисленного попал только в 7 (через несколько лет работы в одной крупной IT-компании), но всё-таки это осознал и сменил работу, хотя все говорили «да ты чего, это же дрим джоб!» – сразу всё пошло в гору.
Вообще, для себя решил, что в IT нет смысла держаться за работу – если у вас есть какой-никакой опыт, всегда найдёте что-нибудь даже в России. А если не бояться посмотреть на зарубежный рынок – там сразу скачок по зарплатам чуть ли не в разы, особенно сейчас.
Gorthauer87
20.11.2015 12:29+2Не знаю какие это грабли, но раньше я чаще всего на новой работе начинал проекты с нуля и имел непосредственное отношение к архитектуре, к выбору технологий и так далее. Хотя и приходилось лишь на своих ошибках часто учиться. В принципе на них достаточно многому научился.
Но вот, когда обвалился доллар в том году, такие проекты как-то сами собой отвалились.
Пришлось идти работать уже в более менее крупную компанию. Там у меня эта возможность творить как-то сама собой улетучилась. В конечном счете я ушел от туда уже в среднюю по размеру компанию, но как-то все равно до конца не нахожу себе места.
Хочется большего полета мысли, больших возможностей к экспериментам, да и скиллы охота улучшать. Пытался устраиваться в Яндекс, но на собеседовании мне чуть-чуть умений не хватило. Хочется их развивать, но это как раз подразумевает, что мне нужен простор для творчества. А где его взять-то?
Чтобы в болото не упасть периодически делаю реализации разных алгоритмов классических да всякий код на rust'е пишу. Но хочется большего.khim
21.11.2015 02:23+5В большой компании умение «творить» ценится в 10 раз выше, чем в маленькой, но только там оно другое. Вам никто не даст сесть, развалить всю систему и полгода пилить новую версию. Все ваши наработки должны влиться в уже существующий код так, чтобы каждый CL оставлял всю конструкцию работоспособной.
Как говорится: рекордсменом мира по бегу в мешке становится не тот, кто лучше всех бегает, а тот, кто лучше всех бегает в мешке!
norlin
20.11.2015 12:40+2впрочем, в контексте статьи, лично для программиста описанное в этом комменте будет как раз не граблями, а огромным плюсом и опытом. Но вот с точки зрения проекта – грабли ещё те.
Ещё из собственных граблей: если вы набрались сколько-нибудь опыта и попали в фирму, где с нуля делают какой-то проект – не беритесь запиливать в качестве основы проекта свой мега-крутой-фреймворк, который идеально подойдёт к задуманному. Возможно, вы сможете его спроектировать и закодить, но… 99% вероятность, что требования поменяются и ваш фреймворк уже не будет идеальным, появятся костыли и т.д.
В большинстве случаев будет лучше/выгоднее/быстрее взять что-то из готового опенсорсного кода.
Flammar
20.11.2015 16:42+3Прикол в том, что программист — по природе своей не читатель, а писатель, и взять что-то из готового опенсорсного кода по трудозатратам может оказаться дольше, чем запилить что-то своё.
norlin
20.11.2015 17:16+3В краткосрочной перспективе – возможно, но если проект развивается хотя бы полгода, то велика вероятность что велосипеды утянут на дно. Опенсорсные фреймворки/библиотеки развиваются и улучшаются долгое время, учитывают многие моменты о которых сходу даже не подумаешь.
khim
21.11.2015 02:25+1Именно так. Велосипеды — это не то, с чего нужно начинать, а то, чем нужно заканчивать. Когды вы твёрдо понимаете что у вас делает какой-то центральный компонент и знаете, что он меняться не будет — не грех для него и парочку своих контейнеров замутить. Но только нужно хорошо понимать что вы делаете…
arielf
26.11.2015 02:01Согласен, в начале лучше собрать прототип, используя открытые стандарты и библотеки, в силу гибкости настройки и универсальности с ними легче работать, а когда вы уже уверены в решениях, то можно заменять опен сорсные компоненты на свои, специализированные.
Mrrl
26.11.2015 07:47Это может привести к довольно плохим последствиям. Используя стандартные библиотеки, вы вынуждены использовать конкретное представление данных, конкретные разбиения алгоритма на этапы, и т.п. Например, библиотека может потребовать, чтобы какой-то объект целиком находился в памяти. Переделать потом программу на потоковую обработку этого объекта может быть не очень просто.
khim
26.11.2015 15:41+1Ничего страшного: если этот компонент вам настолько ценен и важен, то его не грех и два раза переписать. Если же на это ресурсов нет… то, может быть, в данном конкретном случае не так и важно, что библиотека не поддерживает потоковый доступ, а?
force
21.11.2015 12:30+1Тут сложный момент. Например, Angular, постоянно что-то меняется и отваливается в разных версиях, и намекают что в 2.0 будет всё совсем по-другому. В результате, остаётся два варианта — или зафиксировать Angular на фиксированной версии, что плохо, либо гнаться за версиями и тратить ресурсы на поддержку изменений ангуляра.
Свой велосипед, он может и не учитывает каких-то нюансов, то ты точно знаешь, что он не учитывает, как их можно обойти и стоит ли обходить. И изменяется он тоже, фиксированно и по ситуации.norlin
21.11.2015 12:46+3Терпеть не могу Angular, поэтому просто посоветую его не использовать. :-)
ты точно знаешь, что он не учитывает
Вот тут я бы не был так уверен. Если это ваш первый «собственный» проект (где вы с нуля что-то разрабатываете), почти наверняка многие моменты вы не учтёте и даже не подумаете о них, до тех пор, пока не столкнётесь с необходимостью «всё переписать»…force
21.11.2015 13:25+1Тут согласен. Я забыл уточнить важный момент. До своих велосипедов, естественно надо пробовать существующие и понимать почему они так сделали, и что они решали. Т.е. с нуля своё писать интересно в плане того, понять мысли разработчиков других решений, что они хотели решить и почему они сделали именно так. И после нескольких унылых велосипедов и нескольких фреймворков начинается понимание того, что вот под твои конкретные условия, действительно велосипед будет гораздо лучше, удобнее и понятнее. Но нужен опыт, да. И иногда переписывание кусков других фреймворков по частям.
mayorovp
21.11.2015 13:10Фиксировать версии внешних библиотек — это не плохо, а нормальная практика. Особенно если речь идет о мажорной версии.
Если понадобится фича, которой нет в старой версии — тут уже можно рассмотреть вопрос о переходе. Но зачем переходить на новую версию когда на старой все работает?
Есть, конечно, и обновления, содержащие исправления — но вменяемые библиотеки в багфиксах совместимость не ломают.force
21.11.2015 13:28+1Фиксировать плохо тем, что проекты движутся. Вы написали набор крутых компонентов под одну версию фреймворка, вы её зафиксировали. Потом начинается новый проект (может быть через год), и хочется использовать новую версию. А нельзя, потому что у вас есть стек компонентов, которые работают на старой. И вам надо их взять и переписать. И весь наработанный опыт идёт лесом. Даже если переписать нужно наполовину, или на треть, то получается что сущности начинают плодиться. В старый проект вы не можете ввести новые компоненты, в новый — старые.
norlin
21.11.2015 13:30+1Но зачем переходить на новую версию когда на старой все работает
Чтобы в тот момент, когда «понадобится новая фича» не оказалось, что вы отстали на пару мажорных релизов и придётся переписывать половину проекта, грубо говоря.
Вообще, проект с идеальной архитектурой вообще не должен зависить от внешних библиотек. То есть, такому проекту должно быть без разницы, какую библиотеку/фреймворк использовать (при наличии у того нужных фич, само собой).
Но лично я с такими проектами в реальной жизни не сталкивался. :-)
KonstantinSoloviov
20.11.2015 14:41+5Дан однобокий взгляд на профессию программиста. В статье программирование приравнено к кодированию. Можно говорить об языках, инструментах, библиотеках/велосипедах, но все это суть всего лишь кодирование той или иной степени эффективности. Инструменты и навыки — дело наживное, кодирование не цель, а средство. Думаю, что Junior и Senior программистов разнит прежде всего подход к работе: степень погруженности в предметную область, умение поставить себя на место пользователя/заказчика, кругозор — как знание того, что и как делают люди за соседними столами в соседних дружественных и конкурирующих командах. И, конечно, самое главное — ответственность, которую как известно невозможно дать, а можно только взять.
terryP
20.11.2015 19:22+3Ну, тут может получиться спор по понятиям. Есть роль программиста/разработчика в проекте, есть должность программиста. Если разделать по ролям, то teamlead это тот кто мотивирует и контролирует команду, бизнес-аналитик — тот кто угадывает желания клиента и создает бизнес требования, архитектор — тот кто создает архитектуру, программист — кодить по дизайну, тестер — его проверят и т.д.
То есть в идеализированном случае роль программиста не подразумевает ни угадывать желания клиента, ни знать чем занимаются соседи. Естественно, в реальном проекте чем опытней программист и меньше команда тем больше дополнительных ролей полностью и частично ложится на его плечи, но основная роль все-таки кодирование, все остальное это уже дополнения.
Тут надо понимать простую вещь если старший программист 50% обучает и мотивирует команду, 49% придумывает архитектуру и 1% времени тратит на написание кода, то это уже Team lead/Архитектор, которого просто не оформили официально (что бывает очень часто), а не программист.
Насчет Junior и Senior, видел я очень ответственных Junior'ов и «выгоревших» Senior'ов, которые знают что их все равно никогда не уволят и зар.плату кардинально уже не повысят. Нет, Senior это все-таки интуитивное понимание как сделать правильно, а не слепое повторение чужих методик, что характерно для Middle программистов.VolCh
22.11.2015 18:54+2Кодить по дизайну — это кодер, а не программист. Если угодно, программист или техник-программист, а не инженер-программист, Software Developer, а не Software Engineer.
И уж точно роль программиста (инженера-программиста) подразумевает и взаимодействие даже не столько с формальным заказчиком, сколько со специалистами предметной области, с пользователями продукта и участие в принятии архитектурных решений.
vedenin1980
22.11.2015 20:31+1Не буду спорить по понятиям это бесперспективно, тем более что на Западе Software Engineer это скорее тот кто поддерживает и допиливает всякие SAP'ы, а Software Developer это как раз тот кто создает код с нуля. Ну и роли программиста на разных проектах отличаются очень сильно.
vedenin1980
22.11.2015 20:37+1Кодить по дизайну — это кодер, а не программист
Кстати, это кажется что кодить по дизайну просто, на самом деле, как правило, дизайн не описывает внутреннею реализацию, максимум публичный API или что должно произойти при нажатии на кнопку пользователем, а что будет внутри это дело уже команды разработчиков (вплоть до языка и архитектуры).VolCh
23.11.2015 00:15Вы про визуальный дизайн что ли? Дизайн приложения — конечный результат работы архитекторов и программистов, описание «маст-хэв» программных сущностей типа объектов и их интерфейсов, он сочетает в себе описание самих сущностей, их взаимосвязей и спецификаций их поведения. Условно можно считать дизайн приложения набором автоматических функциональных, приемочных и модульных тестов, кодерами остаётся только сделать их зелеными. :)
vedenin1980
23.11.2015 01:13+1Дизайны бывают разными и разной проработанности. Бывает функциональный дизайн, бывает use сase, бывает дизайн ui, дизайн api, очень редко встречал дизайн, где бы расписываются все алгоритмы, классы и т.п., в частности unit test (вы это имеете в виду под модульными тестами) редко создаются на этапе дизайна, да и сам дизайн это конечный результат скорее работы бизнес аналитиков и архитекторов. Но опять-таки все это сильно зависит от проекта и методологии.
Flammar
20.11.2015 16:40+6В общем, основные грабли — «не у кого учиться», а самый ценный совет — участвовать в open-source проектах чтоб не отставать от новых технологий… Совет столь же прекрасный, сколь и трудновыполнимый…
terryP
20.11.2015 19:29+3Нет, главный совет «не ходит туда где снег на башка попадет, совсем мертвый будешь» или вовремя уйти оттуда где перестал развиваться. Дело в том, что молодому специалисту сложно распознать, что что-то не так в его первой работе и годами сидит в джунирах без всякого развития, практически не замечая этого.
Flammar
23.11.2015 11:38И где только водятся такие круто развивающие вакансии?.. Единственный язык, который я выучил на работе — это FoхPro 2.5, в 1994-95 годах. Правда, все работы с той поры и до 2004 были типа (4). Я даже рад, что из-за отсутствия «нормальных» работ смог выучить VB(A) и Java, иначе, подозреваю, завяз бы в Delphi и С++…
olsamurai
20.11.2015 18:20+5Немного однобоко получилось или все черно-белое. В реальной жизни все немного по другому.
Я начал программировать еще в институте (1995 год), попав в НИИ, в котором никто и никогда не программировал. Уже через год отдел был из 10 программистов на с/с++/asm. Причем были люди с очень хорошими знаниями, были новички, которые тянулись. И технологии изучали все и с жаждой! Turbo С, Borland C++, потом Visual. Полная свобода, делали что хотели: новые инструменты, языки, протоколы, техники и т.д. И это все далеко не в столице. Да, с зарплатой было иногда тяжело, иногда полегче (все таки девяностые). Проходилось писать под заказ. Потом пару лет работал в Москве и уже в софтверной конторе. Там все было статичнее. Нельзя было выбирать все и свободно, но компромисс находил. Держались все в тренде. Потом универ в Германии, все абсолютно новое! Язык, знакомства и прочее. После универа попадаю в небольшую ИТ компанию. Писал и на с/с++, java, php и js, потом и GWT. И для серверов, и для роутеров, и для встроенных систем и бэкэнд и фронтэнд. Старался изучать постоянно новое. Сейчас работаю в другой не очень большой софтверной фирме. Пишу только на с++. И все равно изучаю новое. Используем с++ 11. Мне сейчас сороковник и я стараюсь держаться в струе! Тут главное желание и целеустремленность. Даже просто вечером сериальчик посмотреть, то на английском, то на немецком, то на русском или украинском. Немного скомканно получилось, но, надеюсь, посыл понятен.terryP
20.11.2015 19:26+2Нее, вы не поняли, я не говорил что любая гос.организация это болото, в первую очередь тут речь о симптомах на которые нужно обращать внимание, если есть желания развиваться и соответственно как-то «лечить» то что вызывает эти симптомы, от ухода из такой компании до попытки сменить климат и организовать реальную работу.
Stas911
20.11.2015 23:17+4Хорошая статья!
Я бы еще добавил — что не нужно бояться меняться и менять свою жизнь. Если вас внезапно достало программирование — попробуйте себя в смежной специализации — руководителем проектов, аналитиком, деплоймент-инженером, да мало ли чего интересного в мире происходит. Насчет зарплаты не бойтесь — если вы занимаетесь делом, которое вам на самом деле нравится — зарабатывать будете не меньше. Кроме того, работодатели зачастую так же ищут людей, у которых блеск в глазах и которым действительно интересно то, что они делают (пусть даже временно в ущерб опыту и знаниям)
Squatch
21.11.2015 03:12+42 кейса в копилку)
Crunch-driven-development
Такое, по-моему не редкость. Условия, когда всё-должно-было-быть-сделано-вчера. Технический долг растёт. Система строится из workaround-ов. 1 добавляемая фича ломает 2 старых. 1 закрытый баг открывает 2 новых. Режим работы — «нет времени думать, надо делать!». Из плюсов — хорошая дзен-практика :)
Burnout-перфекционизм
Явление, мне кажется, более редкое, но не менее опасное. Условия работы — хорошие, развивайся не хочу. Работа — интересная, самому в кайф пофигачить не 8 часов, а 18, да ещё на выходных допилить пару вкусных фич. Как практика время от времени, оно даже полезно, наверно. Но если человек в некоторой степени упор(отый)ный, в жизни имеет место дисбаланс работы с не_работой, а подобный режим затягивается на N-месяцев — пол-года или более, — то выгорание будет болезненным, а восстановление долгим :)
В целом, согласен, что для развития, необходимы либо условия на работе, когда есть возможность:
— изучать новые технологии в своей области время от времени;
— думать над оптимальной реализацией фич;
— перенимать опыт старших коллег;
Либо, собственный/сторонний проект, который будет:
— не слишком маленьким (где был бы простор для проектирования архитектуры и применения новых технологий)
— не слишком большой (что бы было подъёмно и проект не оказался заброшен, на начавшись)
— и который будет поддерживаться в рабочем состоянии и развиваться (имхо, ничто не развивает навыки проектирования лучше, чем необходимость работать с написанным кодом, через промежутки времени, вновь и вновь).
Mrrl
21.11.2015 20:38+3Из граблей, пожалуй, натыкаюсь только на №2, зато в полный рост. В проекте, который развивается 15 лет, довольно сложно менять технологии и подключать новые фреймворки. На моё предложение всё-таки посмотреть, что же такое OpenCV (который, вероятно, можно было бы использовать в нескольких ключевых местах), начальник отвечает «пробовали 10 лет назад, не понравилось, ты напишешь лучше» :)
VolCh
22.11.2015 18:55+5Грабли: бросить институт, немного не дотянув до диплома, ради интересной работы.
namespace
22.11.2015 22:37-5Что за мода на Junior / Senior разделение? Это всего-лишь условность. Я знаю иностранных «джуниоров», которые могут на расслабоне русских «синьоров» попустить, причем тут это? Приведенные в статье типажи абсолютно очевидны любому, кто вообще занимается разработкой ПО, не понимаю, какую смысловую нагрузку несет статья. Ладно, пятница, я понимаю. А где юмор, где трэш, где угарные истории, где сиськи? Короче говоря, стетейки клепать — не мешки ворочить.
terryP
22.11.2015 22:53+6Это всего-лишь условность
Естестевнно, под Junior в данной статье подразумеваются программисты без опыта или с минимальным опытом
Я знаю иностранных «джуниоров», которые могут на расслабоне русских «синьоров» попустить
Значит, эти синьноры это всего лишь джуниоры с 15-летним поытом, такое бывает, особенно из-за падания в одну из «ловушек» выше.
Приведенные в статье типажи абсолютно очевидны любому, кто вообще занимается разработкой ПО
Вроде написано
Давайте вспомним некоторые типичные грабли, на которые мы все (ну или большинство) наступали сами того не замечая. Конечно, для опытных разработчиков многое покажется очевидным капитанством, однако молодых специалистов такие ловушки могут легко увести на темную сторону силы.
Поверьте, для молодого разработчика без опыта работы это все не далеко не очевидно, многое написано по собственному печальному опыту.
Короче говоря, стетейки клепать — не мешки ворочить.
Так клепайте, лучше, быстрее, веселее, какие проблемы? :)Flammar
23.11.2015 11:42+2Значит, эти синьноры это всего лишь джуниоры с 15-летним поытом, такое бывает, особенно из-за падания в одну из «ловушек» выше.
Вот прочитал, и подумал, что на Западе из-за большей концентрации софтверных фирм таких ловушек просто тупо меньше…
cyber-security
24.11.2015 14:55+3
просто так минутка смеха и так отвлечься от работы!!!
рекомендую к просмотру!!!
leremin
А у меня всего понемногу. Оборонное предприятие (4 — Болото). Пришел сюда вообще не программистом, но понял, что могу написать все лучше, чем оно есть. В итоге единственный программист в от деле (3 — Медные трубы и звездная болезнь). А операторы впервые начали хвалить софт, а не ругаться, что от тупит/глючит/не удобный (7 — Потеря мотивации к развитию). Помимо программирования занимаюсь другой работой, а так же являюсь заместителем начальника (1 — Человек-оркестр, 6 — Горизонтальный и диагональный рост). Своей платформы нет, но было куча ненужных велосипедов, от которых я избавился (
2 — У нас в Греции все есть).Simplevolk
У вас может получиться ветка развития «незаменимый» + зам начальника- неплохой карьерный рост.
aikixd
Mrrl
«незаменимый» может оказаться тупиком. Когда всё человечество полетит к звёздам, «незаменимым» придётся сидеть и поддерживать старые программы. Какой уж тут рост.
redmanmale
Читается, как набор статов у перса в игре, хех.
PHmaster
Это не статы, это перки. Не путайте ;)