Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
А у меня всего понемногу. Оборонное предприятие (4 — Болото). Пришел сюда вообще не программистом, но понял, что могу написать все лучше, чем оно есть. В итоге единственный программист в от деле (3 — Медные трубы и звездная болезнь). А операторы впервые начали хвалить софт, а не ругаться, что от тупит/глючит/не удобный (7 — Потеря мотивации к развитию). Помимо программирования занимаюсь другой работой, а так же являюсь заместителем начальника (1 — Человек-оркестр, 6 — Горизонтальный и диагональный рост). Своей платформы нет, но было куча ненужных велосипедов, от которых я избавился (2 — У нас в Греции все есть).
Интересно, в голосовании воздержались те, у кого еще четверг?
Насчет фриланса верно, сам пришел туда с минимальными знаниями, ставил заплатки на чьи-то костыли, настраивал cms-ки гордо именуя себя «web-разработчик» и масса времени пролетело в бесполезной однотипной работе. Но хоть успел спохватиться и вырваться из этого замкнутого круга)
Я бы не был так однозначен по второму пункту. Выбирая между фреймворком и велосипедом, нужно оценивать временные затраты на освоение/настройку/допиливание первого и написания/отладки второго. Чем выше требования к ПО и чем выше квалификация девелоперов, тем чаще пишутся свои библиотеки.
Сеньорных программистов на собеседованиях часто вообще про фреймворки не спрашивают — спрашивают про языки программирования, концепции написания и оптимизации программ, опыт реальной разработки, мнения о правильной организации процесса разработки ПО.
Уже готовые фреймворки универсальны — за что часто приходится расплачиваться эффективностью, гибкостью и простотой.
Сеньорных программистов на собеседованиях часто вообще про фреймворки не спрашивают — спрашивают про языки программирования, концепции написания и оптимизации программ, опыт реальной разработки, мнения о правильной организации процесса разработки ПО.
Уже готовые фреймворки универсальны — за что часто приходится расплачиваться эффективностью, гибкостью и простотой.
> Чем выше требования к ПО и чем выше квалификация девелоперов, тем чаще пишутся свои библиотеки.
Видел команду, написавшую свой минималистичный движок базы данных для их продукта. Долго шутил про «велосипеды», пока не увидел результаты сравнения тестов их узкоспециализированной бд со стандартными SQL и NoSQL решениями. Разница на пару порядков не в пользу универсальных баз. С тех пор шучу осторожнее. :)
Видел команду, написавшую свой минималистичный движок базы данных для их продукта. Долго шутил про «велосипеды», пока не увидел результаты сравнения тестов их узкоспециализированной бд со стандартными SQL и NoSQL решениями. Разница на пару порядков не в пользу универсальных баз. С тех пор шучу осторожнее. :)
И про седьмой пункт — моё любимое:
«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
«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
Некоторые соображения по поводу п.4, из личного опыта (делаю ЭТО уже семь лет подряд в НЕ айтишной компании и счастлив). Из плюсов:
— У многих (в том числе и у меня) есть комплекс «работы на дядю». Когда у тебя есть возможность выбора всего, начиная от платформы разработки, заканчивая временем прихода-ухода с работы, комплексы удается успешно подавить. Многие мои одногруппники работают в разработке в больших конторах типа мейла или майкрософта, но лично по мне гораздо приятнее в маленьком и уютном местечке, где есть возможность повлиять на все происходящие процессы.
— Учиться вообще не сложно, если есть личная мотивация. Плюралсайт, линда, codeacademy и так далее. В большинстве тру айти-компаний не будет возможности поиграться в новые технологии, так как — корпоративный стандарт — писать все на (условно) Java. Был опыт работы в месте, где ВСЕ писалось на макросах экселя и гнусном VBA, только потому что однажды большой team lead решил, что «скакать по технологиям нельзя».
— Возможность вникать в не-технические сферы. В общем случае, изучить новый js-фреймворк — это фиговое развитие, а вот занимаясь автоматизацией бухгалтерии (из примера в статье) можно узнать много интересного о функционировании этой самой бухгалтерии. Мир многогранен и не заканчивается на айти-сфере. Почему бы не изучать его, особенно, если за это еще и платят.
— Понимание, что программирование — это инструмент достижения цели, а не цель. Кодить — классно, но главное тут все же — бабло :) Сделать костыльно и дешево лучше, чем идеально и дорого (заложившись, естественно, что будут затраты в дальнейшем на поддержку костылей). Постоянно сталкиваюсь с энтузиастами, которые готовы просидеть неделю в оптимизациях производительности или «переписать все под линукс», но при этом не оценивают, например, затраты на собственную з/п против профита от этой оптимизации.
— На собеседованиях регулярно вижу людей, которые пять лет программируют, понимают внутренности MSIL, но при этом не знают, зачем в БД нужны индексы. Нафига? Они же в «большой компании» программисты, а базами занимаются другие люди. Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать? Этим же админы занимаются. Angular? Нет, фронтендом занимался отдельный человек. Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию… — на этом собеседник вежливо откланивается.
Минусы понятны. Не стать начальником отдела из двадцати кодеров, потому что здесь никогда не будет двадцати кодеров. Застрять в болоте и вечно программировать на «языках с перфокартами», если самому не вытаскивать себя из зоны комфорта. Все в собственных руках, в итоге.
— У многих (в том числе и у меня) есть комплекс «работы на дядю». Когда у тебя есть возможность выбора всего, начиная от платформы разработки, заканчивая временем прихода-ухода с работы, комплексы удается успешно подавить. Многие мои одногруппники работают в разработке в больших конторах типа мейла или майкрософта, но лично по мне гораздо приятнее в маленьком и уютном местечке, где есть возможность повлиять на все происходящие процессы.
— Учиться вообще не сложно, если есть личная мотивация. Плюралсайт, линда, codeacademy и так далее. В большинстве тру айти-компаний не будет возможности поиграться в новые технологии, так как — корпоративный стандарт — писать все на (условно) Java. Был опыт работы в месте, где ВСЕ писалось на макросах экселя и гнусном VBA, только потому что однажды большой team lead решил, что «скакать по технологиям нельзя».
— Возможность вникать в не-технические сферы. В общем случае, изучить новый js-фреймворк — это фиговое развитие, а вот занимаясь автоматизацией бухгалтерии (из примера в статье) можно узнать много интересного о функционировании этой самой бухгалтерии. Мир многогранен и не заканчивается на айти-сфере. Почему бы не изучать его, особенно, если за это еще и платят.
— Понимание, что программирование — это инструмент достижения цели, а не цель. Кодить — классно, но главное тут все же — бабло :) Сделать костыльно и дешево лучше, чем идеально и дорого (заложившись, естественно, что будут затраты в дальнейшем на поддержку костылей). Постоянно сталкиваюсь с энтузиастами, которые готовы просидеть неделю в оптимизациях производительности или «переписать все под линукс», но при этом не оценивают, например, затраты на собственную з/п против профита от этой оптимизации.
— На собеседованиях регулярно вижу людей, которые пять лет программируют, понимают внутренности MSIL, но при этом не знают, зачем в БД нужны индексы. Нафига? Они же в «большой компании» программисты, а базами занимаются другие люди. Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать? Этим же админы занимаются. Angular? Нет, фронтендом занимался отдельный человек. Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию… — на этом собеседник вежливо откланивается.
Минусы понятны. Не стать начальником отдела из двадцати кодеров, потому что здесь никогда не будет двадцати кодеров. Застрять в болоте и вечно программировать на «языках с перфокартами», если самому не вытаскивать себя из зоны комфорта. Все в собственных руках, в итоге.
«Учиться вообще не сложно, если есть личная мотивация» — а в нормальных компаниях учиться будет ещё и легче — там можно будет почерпнуть опыт коллег. Ну а вообще не очень уверен, что на учебных сайтах можно реально чему-то научиться… впрочем, пользовался только интуитом, возможно другие дают знания лучше.
«Возможность вникать в не-технические сферы» — нужна далеко не всем, есть далеко не в каждом болоте, часть есть в нормальных компаниях. При этом изучить новый js-фреймворк бывает очень полезно, если в копилку к jQuery добавить Angular/Backbone/whatever. Об этом вы, кстати, пишете в конце своего комментария.
«Понимание, что программирование — это инструмент достижения цели, а не цель.» — нужно ПМу и сениорам. Джун и, зачастую, мидл не смогут корректно оценить и получится классическое «фигак-фигак и в продакшен». И да, очень нужно оценивать требования и платёжеспособность клиента. И в любом случае опыт правильной оценки надо где-то набирать.
«но при этом не знают, зачем в БД нужны индексы» — если вам нужен человек-оркестр/фуллстек, это не значит, что рынку нужно много таких специалистов. Каждый находит свою нишу — кто-то фуллстек, кто-то человек-оркестр, а кто-то — углубляется в какую-то нужную технологию. И плевать ему на индексы в БД (которые, кстати, проходятся в универе… и на практике разработчику действительно не нужны — оптимальный запрос он не напишет всё равно, так пусть этим всё-таки специалист занимается).
«Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать» — ещё один пример человека оркестра (причём здесь — уже именно человека-оркестра, а не фуллстека). Девопсы не занимаются разработкой сложных систем, программисты не занимаются настройкой серверов. Админы не занимаются программированием. Вы девопса ищете или программиста? Ну так если вам нужен девопс — не надо писать «senior developer» в вакансии!
«Angular? Нет, фронтендом занимался отдельный человек» — фуллстек он и есть фуллстек. Не все занимаются фуллстеком, слишком много нужно знать — глубина знаний конкретных технологий истончается.
«Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию…» — если вы искали java-программиста, то действительно, вежливо откланиваются — с таким работодателем работать — себе дороже. Конечно есть человеки-оркестры, но редко кто из них достаточно профессионален во всех своих навыках. Зачастую они даже один навык до приемлимого уровня не поднимают.
Ну и обращаю ваше внимание — очень у вас этот абзац диссонирует с абзацем о «не-технические сферы»… Вы бы определились и остановились на чём-то одном, а?
PS дополню только один момент — крупнае софтверная компания — тоже может оказаться болотом. Будьте бдительны, удачного рабочего опыта!
«Возможность вникать в не-технические сферы» — нужна далеко не всем, есть далеко не в каждом болоте, часть есть в нормальных компаниях. При этом изучить новый js-фреймворк бывает очень полезно, если в копилку к jQuery добавить Angular/Backbone/whatever. Об этом вы, кстати, пишете в конце своего комментария.
«Понимание, что программирование — это инструмент достижения цели, а не цель.» — нужно ПМу и сениорам. Джун и, зачастую, мидл не смогут корректно оценить и получится классическое «фигак-фигак и в продакшен». И да, очень нужно оценивать требования и платёжеспособность клиента. И в любом случае опыт правильной оценки надо где-то набирать.
«но при этом не знают, зачем в БД нужны индексы» — если вам нужен человек-оркестр/фуллстек, это не значит, что рынку нужно много таких специалистов. Каждый находит свою нишу — кто-то фуллстек, кто-то человек-оркестр, а кто-то — углубляется в какую-то нужную технологию. И плевать ему на индексы в БД (которые, кстати, проходятся в универе… и на практике разработчику действительно не нужны — оптимальный запрос он не напишет всё равно, так пусть этим всё-таки специалист занимается).
«Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать» — ещё один пример человека оркестра (причём здесь — уже именно человека-оркестра, а не фуллстека). Девопсы не занимаются разработкой сложных систем, программисты не занимаются настройкой серверов. Админы не занимаются программированием. Вы девопса ищете или программиста? Ну так если вам нужен девопс — не надо писать «senior developer» в вакансии!
«Angular? Нет, фронтендом занимался отдельный человек» — фуллстек он и есть фуллстек. Не все занимаются фуллстеком, слишком много нужно знать — глубина знаний конкретных технологий истончается.
«Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию…» — если вы искали java-программиста, то действительно, вежливо откланиваются — с таким работодателем работать — себе дороже. Конечно есть человеки-оркестры, но редко кто из них достаточно профессионален во всех своих навыках. Зачастую они даже один навык до приемлимого уровня не поднимают.
Ну и обращаю ваше внимание — очень у вас этот абзац диссонирует с абзацем о «не-технические сферы»… Вы бы определились и остановились на чём-то одном, а?
PS дополню только один момент — крупнае софтверная компания — тоже может оказаться болотом. Будьте бдительны, удачного рабочего опыта!
> Ну а вообще не очень уверен, что на учебных сайтах можно реально чему-то научиться
Вот тут не соглашусь. Подписка на www.pluralsight.com окупает себя многократно (либо из торрентов при желании). Требуется лишь знание английского на уровне понимать техническую речь на слух (а часто еще и субтитры есть). И на телефон можно скачать.
> Не все занимаются фуллстеком, слишком много нужно знать
Классно же уметь все, начиная от покупки сервера, заканчивая микрооптимизациями в коде запросов, разве нет? Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану. Или желания самому с нуля создать законечнный продукт, хоть и маленький, хоть и не везде идеальный, но от А до Я свой (сразу оговорюсь, здесь не идет речь про «не использовать фреймворки», как раз наоборот — без фреймворков с таким подходом свой продукт можно годами делать).
Вообще, все что описано в вашем и моем комментариях — это конфликт концепции микросервисов vs концепции архитектуры со слоями. Аналогично и с распределением задач. Можно взять десять человек, где один хорошо знает БД, другой фронтэнд, третий data science и тд или взять десять «оркестров», которые будут работать в пределах небольших проектов (связанных с другими понятными и документированными интерфейсами), но внутри своего проекта делать все-все-все. Мне оказался ближе второй подход.
Вот тут не соглашусь. Подписка на www.pluralsight.com окупает себя многократно (либо из торрентов при желании). Требуется лишь знание английского на уровне понимать техническую речь на слух (а часто еще и субтитры есть). И на телефон можно скачать.
> Не все занимаются фуллстеком, слишком много нужно знать
Классно же уметь все, начиная от покупки сервера, заканчивая микрооптимизациями в коде запросов, разве нет? Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану. Или желания самому с нуля создать законечнный продукт, хоть и маленький, хоть и не везде идеальный, но от А до Я свой (сразу оговорюсь, здесь не идет речь про «не использовать фреймворки», как раз наоборот — без фреймворков с таким подходом свой продукт можно годами делать).
Вообще, все что описано в вашем и моем комментариях — это конфликт концепции микросервисов vs концепции архитектуры со слоями. Аналогично и с распределением задач. Можно взять десять человек, где один хорошо знает БД, другой фронтэнд, третий data science и тд или взять десять «оркестров», которые будут работать в пределах небольших проектов (связанных с другими понятными и документированными интерфейсами), но внутри своего проекта делать все-все-все. Мне оказался ближе второй подход.
«Классно же уметь все, начиная от покупки сервера» — боже упаси.
«заканчивая микрооптимизациями в коде запросов, разве нет?» — микрооптимизациями в SQL тоже совсем не тянет заниматься.
«Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану» — на уровне небольших проектиков/экспериментов — да, а вот реально сложную интересную систему разработать… сложно иметь высокую квалификацию даже в двух сферах (фронтенд+бэкенд), вы же предложили ещё несколько сфер глубоко осваивать… Даже просто времени не хватит — тот же бэкенд постоянно развивается и знания/умения нужно постоянно обновлять.
«или взять десять «оркестров», которые будут работать в пределах небольших проектов» — а потом быть готовым привлекать профильных специалистов (БД/технологических/нагрузочников/...), т.к. при росте нагрузки есть неплохая вероятность, что кто-нибудь из оркестров сделал кучу бутылочных горлышек в каком-нибудь нагруженном сервисе. Впрочем это нужно не всем сервисам, поэтому оркестры остаются актуальными.
«заканчивая микрооптимизациями в коде запросов, разве нет?» — микрооптимизациями в SQL тоже совсем не тянет заниматься.
«Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану» — на уровне небольших проектиков/экспериментов — да, а вот реально сложную интересную систему разработать… сложно иметь высокую квалификацию даже в двух сферах (фронтенд+бэкенд), вы же предложили ещё несколько сфер глубоко осваивать… Даже просто времени не хватит — тот же бэкенд постоянно развивается и знания/умения нужно постоянно обновлять.
«или взять десять «оркестров», которые будут работать в пределах небольших проектов» — а потом быть готовым привлекать профильных специалистов (БД/технологических/нагрузочников/...), т.к. при росте нагрузки есть неплохая вероятность, что кто-нибудь из оркестров сделал кучу бутылочных горлышек в каком-нибудь нагруженном сервисе. Впрочем это нужно не всем сервисам, поэтому оркестры остаются актуальными.
Никакой модуль сложной архитектуры нельзя проектировать в отрыве от остальных. Это не значит, что человк у нужно уметь писать все модули самому. Но он обязан знать принципы их функционирования и представлять общую архитектуру. Именно чтобы хорошу выполнять свою узкую работу.
И плевать ему на индексы в БД (которые, кстати, проходятся в универе… и на практике разработчику действительно не нужны — оптимальный запрос он не напишет всё равно, так пусть этим всё-таки специалист занимается).
Я лично не понимаю как можно писать сервер-сайд приложения работающие с базой и не понимать элементарных вещей — как работает индекс и зачем он нужен. Зачем такой разработчик которому нужен еще один? Специалист (DBA) не знает всей специфики приложения — он не знает сколько данных может быть в таблице, какие операции будут преобладать.
Одно дело — создать простейший индекс по полям, указанным в запросе; другое дело — настроить материализованное представление с агрегацией, полнотекстовый поиск или просто ускорить поиск по произвольным атрибутам. Последняя задача может вообще оказаться столь же сложной, как и вся остальная серверная часть.
DBA на то и администратор, что он должен мониторить базу и тюнить её согласно объективной реальности, а не представлениям разработчиков и(или) заказчиков о том, сколько данных может быть в какой таблице и какие операции будут преобладать. В зависимости от процессов в организации DBA может быть полноценным членом команды разработки, с правом решающего голоса или даже требования, а может делать «своё тёмное дело» чисто на уровне СУБД, но только он может сказать, что вообще нуждается в оптимизации.
Если прикладной разработчик лезет в боевую базу, чтобы посмотреть какие запросы реально тормозят, написать новые индексы и (или) удалить старые, а то и изменить схему, то это он просто совмещает роли разработчика и DBA.
Если прикладной разработчик лезет в боевую базу, чтобы посмотреть какие запросы реально тормозят, написать новые индексы и (или) удалить старые, а то и изменить схему, то это он просто совмещает роли разработчика и DBA.
А зарплата Вас вообще интересует? Вы сравнивали зарплату программиста в средней ИТ-компании с зарплатой в средней Гос. организации? Они будут отличаться в 5 раз как минимум (в ИТ-компании будет больше, если кому то это очевидно не ясно). А Вам самим за одну и ту же работу не хотелось бы получать больше? Ах, да, забыл, теперь хочу поделиться своим горьким опытом по поводу четвертого пункта. К минусам четвертого пункта можна также отнести наличие кучи пенсионеров-теоретиков, которые забрасывают тебя вопросами по тем языкам которые были актуальны до Вашего рождения, а так же смотря на «магию» Вашего написания кода стоят за спиной. И никуда не деться от старшего поколения, у которых версия их познания в области программирования не обновлялась больше 10 лет, и которая будет рассказывать как тебе делать твою работу. А также сам коллектив у которого из за низкого порога зарплат нет мотивации к работе и они просто 8 часов рабочего дня могут без угрызения совести, простите за выражение, ковыряться в носу/считать дырки в потолке и т.д. И в связи с этим, тебя окружает неблагоприятная к работе атмосфера. Также в Гос. организациях ты не всегда можешь получить нормальный ПК, так как частенько бывают проблемы с финансированием и железо обновляется раз в 10 лет в лучшем случае. Также в таких колективах нет единомышлеников. А иногда в таких Гос. организация ИТ-отдел состоит из 7 человек, 6 из которых совершенно не связаны с этой проффесией и им абсолютно не интересно чем они занимают, а работают они там только потому что их посадили на эту должность. Вышел немного негативный комментарий, но у меня такие впечатления остались только…
Эээ, совсем мимо комментарий. Я писал о работе в компании, в которой разработка софта — побочная задача («не айтишная»). Про «гос. организации» вообще ни слова.
Пункт 4, на который вы давали свой коментарий, а также описывали позитивные стороны:
Я именно про такую и написал.
Симптомы:
Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ. Технических собеседований про приеме на работу нет или их проводить явно слабый специалист… или старичок, который пытается спрашивать о языках программирования сгинувших вместе с перфокартами.
Я именно про такую и написал.
А что в вашем понимании старички? 35? 40? 90? И языки, которые давно сгинули. Это какие? АДА и Кобол? Может с++?
> Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ
Я описал позитивные стороны того, что стоит в этом предложении после «либо». Опыта работы в государственных организациях у меня нет :)
Я описал позитивные стороны того, что стоит в этом предложении после «либо». Опыта работы в государственных организациях у меня нет :)
Товарищ работает в медсанчасти сисадмином далеко от столиц, получает больше средней зарплаты сисадмина в айтишной конторе в Питере. Так что не всем это очевидно. Это ещё не упоминая местную айтишную компанию. Чем дальше от столицы, тем привлекательнее становится госсектор.
Набрал 6 из 7, только во фриланс не уходил, а под остальными пунктами подпишусь
К счастью не собрал ни одной грабли! Спасибо судьбе. Простите за оффтоп: исправьте большое количество орфографических и пунктуационных ошибок в вашем тексте.
Оркестр + болото: пишу код на python, скрипты на bash + еще циски конфигурирую… учиться и взаимодействовать с кем либо могу только по последнему пункту.
Повезло, начал «карьеру» почти с нулевого опыта, но далее приходилось расти, чтоб справляться с задачами. В итоге из перечисленного попал только в 7 (через несколько лет работы в одной крупной IT-компании), но всё-таки это осознал и сменил работу, хотя все говорили «да ты чего, это же дрим джоб!» – сразу всё пошло в гору.
Вообще, для себя решил, что в IT нет смысла держаться за работу – если у вас есть какой-никакой опыт, всегда найдёте что-нибудь даже в России. А если не бояться посмотреть на зарубежный рынок – там сразу скачок по зарплатам чуть ли не в разы, особенно сейчас.
Вообще, для себя решил, что в IT нет смысла держаться за работу – если у вас есть какой-никакой опыт, всегда найдёте что-нибудь даже в России. А если не бояться посмотреть на зарубежный рынок – там сразу скачок по зарплатам чуть ли не в разы, особенно сейчас.
Не знаю какие это грабли, но раньше я чаще всего на новой работе начинал проекты с нуля и имел непосредственное отношение к архитектуре, к выбору технологий и так далее. Хотя и приходилось лишь на своих ошибках часто учиться. В принципе на них достаточно многому научился.
Но вот, когда обвалился доллар в том году, такие проекты как-то сами собой отвалились.
Пришлось идти работать уже в более менее крупную компанию. Там у меня эта возможность творить как-то сама собой улетучилась. В конечном счете я ушел от туда уже в среднюю по размеру компанию, но как-то все равно до конца не нахожу себе места.
Хочется большего полета мысли, больших возможностей к экспериментам, да и скиллы охота улучшать. Пытался устраиваться в Яндекс, но на собеседовании мне чуть-чуть умений не хватило. Хочется их развивать, но это как раз подразумевает, что мне нужен простор для творчества. А где его взять-то?
Чтобы в болото не упасть периодически делаю реализации разных алгоритмов классических да всякий код на rust'е пишу. Но хочется большего.
Но вот, когда обвалился доллар в том году, такие проекты как-то сами собой отвалились.
Пришлось идти работать уже в более менее крупную компанию. Там у меня эта возможность творить как-то сама собой улетучилась. В конечном счете я ушел от туда уже в среднюю по размеру компанию, но как-то все равно до конца не нахожу себе места.
Хочется большего полета мысли, больших возможностей к экспериментам, да и скиллы охота улучшать. Пытался устраиваться в Яндекс, но на собеседовании мне чуть-чуть умений не хватило. Хочется их развивать, но это как раз подразумевает, что мне нужен простор для творчества. А где его взять-то?
Чтобы в болото не упасть периодически делаю реализации разных алгоритмов классических да всякий код на rust'е пишу. Но хочется большего.
В большой компании умение «творить» ценится в 10 раз выше, чем в маленькой, но только там оно другое. Вам никто не даст сесть, развалить всю систему и полгода пилить новую версию. Все ваши наработки должны влиться в уже существующий код так, чтобы каждый CL оставлял всю конструкцию работоспособной.
Как говорится: рекордсменом мира по бегу в мешке становится не тот, кто лучше всех бегает, а тот, кто лучше всех бегает в мешке!
Как говорится: рекордсменом мира по бегу в мешке становится не тот, кто лучше всех бегает, а тот, кто лучше всех бегает в мешке!
обвалился долларВы хотите сказать рубль?
впрочем, в контексте статьи, лично для программиста описанное в этом комменте будет как раз не граблями, а огромным плюсом и опытом. Но вот с точки зрения проекта – грабли ещё те.
Ещё из собственных граблей: если вы набрались сколько-нибудь опыта и попали в фирму, где с нуля делают какой-то проект – не беритесь запиливать в качестве основы проекта свой мега-крутой-фреймворк, который идеально подойдёт к задуманному. Возможно, вы сможете его спроектировать и закодить, но… 99% вероятность, что требования поменяются и ваш фреймворк уже не будет идеальным, появятся костыли и т.д.
В большинстве случаев будет лучше/выгоднее/быстрее взять что-то из готового опенсорсного кода.
Ещё из собственных граблей: если вы набрались сколько-нибудь опыта и попали в фирму, где с нуля делают какой-то проект – не беритесь запиливать в качестве основы проекта свой мега-крутой-фреймворк, который идеально подойдёт к задуманному. Возможно, вы сможете его спроектировать и закодить, но… 99% вероятность, что требования поменяются и ваш фреймворк уже не будет идеальным, появятся костыли и т.д.
В большинстве случаев будет лучше/выгоднее/быстрее взять что-то из готового опенсорсного кода.
Я бы сказал — вообще не пилите фреймворки. Пилите библиотеки.
Прикол в том, что программист — по природе своей не читатель, а писатель, и взять что-то из готового опенсорсного кода по трудозатратам может оказаться дольше, чем запилить что-то своё.
В краткосрочной перспективе – возможно, но если проект развивается хотя бы полгода, то велика вероятность что велосипеды утянут на дно. Опенсорсные фреймворки/библиотеки развиваются и улучшаются долгое время, учитывают многие моменты о которых сходу даже не подумаешь.
Именно так. Велосипеды — это не то, с чего нужно начинать, а то, чем нужно заканчивать. Когды вы твёрдо понимаете что у вас делает какой-то центральный компонент и знаете, что он меняться не будет — не грех для него и парочку своих контейнеров замутить. Но только нужно хорошо понимать что вы делаете…
Согласен, в начале лучше собрать прототип, используя открытые стандарты и библотеки, в силу гибкости настройки и универсальности с ними легче работать, а когда вы уже уверены в решениях, то можно заменять опен сорсные компоненты на свои, специализированные.
Это может привести к довольно плохим последствиям. Используя стандартные библиотеки, вы вынуждены использовать конкретное представление данных, конкретные разбиения алгоритма на этапы, и т.п. Например, библиотека может потребовать, чтобы какой-то объект целиком находился в памяти. Переделать потом программу на потоковую обработку этого объекта может быть не очень просто.
Тут сложный момент. Например, Angular, постоянно что-то меняется и отваливается в разных версиях, и намекают что в 2.0 будет всё совсем по-другому. В результате, остаётся два варианта — или зафиксировать Angular на фиксированной версии, что плохо, либо гнаться за версиями и тратить ресурсы на поддержку изменений ангуляра.
Свой велосипед, он может и не учитывает каких-то нюансов, то ты точно знаешь, что он не учитывает, как их можно обойти и стоит ли обходить. И изменяется он тоже, фиксированно и по ситуации.
Свой велосипед, он может и не учитывает каких-то нюансов, то ты точно знаешь, что он не учитывает, как их можно обойти и стоит ли обходить. И изменяется он тоже, фиксированно и по ситуации.
Терпеть не могу Angular, поэтому просто посоветую его не использовать. :-)
ты точно знаешь, что он не учитываетВот тут я бы не был так уверен. Если это ваш первый «собственный» проект (где вы с нуля что-то разрабатываете), почти наверняка многие моменты вы не учтёте и даже не подумаете о них, до тех пор, пока не столкнётесь с необходимостью «всё переписать»…
Тут согласен. Я забыл уточнить важный момент. До своих велосипедов, естественно надо пробовать существующие и понимать почему они так сделали, и что они решали. Т.е. с нуля своё писать интересно в плане того, понять мысли разработчиков других решений, что они хотели решить и почему они сделали именно так. И после нескольких унылых велосипедов и нескольких фреймворков начинается понимание того, что вот под твои конкретные условия, действительно велосипед будет гораздо лучше, удобнее и понятнее. Но нужен опыт, да. И иногда переписывание кусков других фреймворков по частям.
Фиксировать версии внешних библиотек — это не плохо, а нормальная практика. Особенно если речь идет о мажорной версии.
Если понадобится фича, которой нет в старой версии — тут уже можно рассмотреть вопрос о переходе. Но зачем переходить на новую версию когда на старой все работает?
Есть, конечно, и обновления, содержащие исправления — но вменяемые библиотеки в багфиксах совместимость не ломают.
Если понадобится фича, которой нет в старой версии — тут уже можно рассмотреть вопрос о переходе. Но зачем переходить на новую версию когда на старой все работает?
Есть, конечно, и обновления, содержащие исправления — но вменяемые библиотеки в багфиксах совместимость не ломают.
Фиксировать плохо тем, что проекты движутся. Вы написали набор крутых компонентов под одну версию фреймворка, вы её зафиксировали. Потом начинается новый проект (может быть через год), и хочется использовать новую версию. А нельзя, потому что у вас есть стек компонентов, которые работают на старой. И вам надо их взять и переписать. И весь наработанный опыт идёт лесом. Даже если переписать нужно наполовину, или на треть, то получается что сущности начинают плодиться. В старый проект вы не можете ввести новые компоненты, в новый — старые.
Но зачем переходить на новую версию когда на старой все работаетЧтобы в тот момент, когда «понадобится новая фича» не оказалось, что вы отстали на пару мажорных релизов и придётся переписывать половину проекта, грубо говоря.
Вообще, проект с идеальной архитектурой вообще не должен зависить от внешних библиотек. То есть, такому проекту должно быть без разницы, какую библиотеку/фреймворк использовать (при наличии у того нужных фич, само собой).
Но лично я с такими проектами в реальной жизни не сталкивался. :-)
Дан однобокий взгляд на профессию программиста. В статье программирование приравнено к кодированию. Можно говорить об языках, инструментах, библиотеках/велосипедах, но все это суть всего лишь кодирование той или иной степени эффективности. Инструменты и навыки — дело наживное, кодирование не цель, а средство. Думаю, что Junior и Senior программистов разнит прежде всего подход к работе: степень погруженности в предметную область, умение поставить себя на место пользователя/заказчика, кругозор — как знание того, что и как делают люди за соседними столами в соседних дружественных и конкурирующих командах. И, конечно, самое главное — ответственность, которую как известно невозможно дать, а можно только взять.
А почему минусуют? Очень разумный комментарий.
Ну, тут может получиться спор по понятиям. Есть роль программиста/разработчика в проекте, есть должность программиста. Если разделать по ролям, то teamlead это тот кто мотивирует и контролирует команду, бизнес-аналитик — тот кто угадывает желания клиента и создает бизнес требования, архитектор — тот кто создает архитектуру, программист — кодить по дизайну, тестер — его проверят и т.д.
То есть в идеализированном случае роль программиста не подразумевает ни угадывать желания клиента, ни знать чем занимаются соседи. Естественно, в реальном проекте чем опытней программист и меньше команда тем больше дополнительных ролей полностью и частично ложится на его плечи, но основная роль все-таки кодирование, все остальное это уже дополнения.
Тут надо понимать простую вещь если старший программист 50% обучает и мотивирует команду, 49% придумывает архитектуру и 1% времени тратит на написание кода, то это уже Team lead/Архитектор, которого просто не оформили официально (что бывает очень часто), а не программист.
Насчет Junior и Senior, видел я очень ответственных Junior'ов и «выгоревших» Senior'ов, которые знают что их все равно никогда не уволят и зар.плату кардинально уже не повысят. Нет, Senior это все-таки интуитивное понимание как сделать правильно, а не слепое повторение чужих методик, что характерно для Middle программистов.
То есть в идеализированном случае роль программиста не подразумевает ни угадывать желания клиента, ни знать чем занимаются соседи. Естественно, в реальном проекте чем опытней программист и меньше команда тем больше дополнительных ролей полностью и частично ложится на его плечи, но основная роль все-таки кодирование, все остальное это уже дополнения.
Тут надо понимать простую вещь если старший программист 50% обучает и мотивирует команду, 49% придумывает архитектуру и 1% времени тратит на написание кода, то это уже Team lead/Архитектор, которого просто не оформили официально (что бывает очень часто), а не программист.
Насчет Junior и Senior, видел я очень ответственных Junior'ов и «выгоревших» Senior'ов, которые знают что их все равно никогда не уволят и зар.плату кардинально уже не повысят. Нет, Senior это все-таки интуитивное понимание как сделать правильно, а не слепое повторение чужих методик, что характерно для Middle программистов.
Кодить по дизайну — это кодер, а не программист. Если угодно, программист или техник-программист, а не инженер-программист, Software Developer, а не Software Engineer.
И уж точно роль программиста (инженера-программиста) подразумевает и взаимодействие даже не столько с формальным заказчиком, сколько со специалистами предметной области, с пользователями продукта и участие в принятии архитектурных решений.
И уж точно роль программиста (инженера-программиста) подразумевает и взаимодействие даже не столько с формальным заказчиком, сколько со специалистами предметной области, с пользователями продукта и участие в принятии архитектурных решений.
Не буду спорить по понятиям это бесперспективно, тем более что на Западе Software Engineer это скорее тот кто поддерживает и допиливает всякие SAP'ы, а Software Developer это как раз тот кто создает код с нуля. Ну и роли программиста на разных проектах отличаются очень сильно.
Кодить по дизайну — это кодер, а не программист
Кстати, это кажется что кодить по дизайну просто, на самом деле, как правило, дизайн не описывает внутреннею реализацию, максимум публичный API или что должно произойти при нажатии на кнопку пользователем, а что будет внутри это дело уже команды разработчиков (вплоть до языка и архитектуры).
Вы про визуальный дизайн что ли? Дизайн приложения — конечный результат работы архитекторов и программистов, описание «маст-хэв» программных сущностей типа объектов и их интерфейсов, он сочетает в себе описание самих сущностей, их взаимосвязей и спецификаций их поведения. Условно можно считать дизайн приложения набором автоматических функциональных, приемочных и модульных тестов, кодерами остаётся только сделать их зелеными. :)
Дизайны бывают разными и разной проработанности. Бывает функциональный дизайн, бывает use сase, бывает дизайн ui, дизайн api, очень редко встречал дизайн, где бы расписываются все алгоритмы, классы и т.п., в частности unit test (вы это имеете в виду под модульными тестами) редко создаются на этапе дизайна, да и сам дизайн это конечный результат скорее работы бизнес аналитиков и архитекторов. Но опять-таки все это сильно зависит от проекта и методологии.
В голосовалке не хватает варианта [Сарказм]
В общем, основные грабли — «не у кого учиться», а самый ценный совет — участвовать в open-source проектах чтоб не отставать от новых технологий… Совет столь же прекрасный, сколь и трудновыполнимый…
Нет, главный совет «не ходит туда где снег на башка попадет, совсем мертвый будешь» или вовремя уйти оттуда где перестал развиваться. Дело в том, что молодому специалисту сложно распознать, что что-то не так в его первой работе и годами сидит в джунирах без всякого развития, практически не замечая этого.
И где только водятся такие круто развивающие вакансии?.. Единственный язык, который я выучил на работе — это FoхPro 2.5, в 1994-95 годах. Правда, все работы с той поры и до 2004 были типа (4). Я даже рад, что из-за отсутствия «нормальных» работ смог выучить VB(A) и Java, иначе, подозреваю, завяз бы в Delphi и С++…
Немного однобоко получилось или все черно-белое. В реальной жизни все немного по другому.
Я начал программировать еще в институте (1995 год), попав в НИИ, в котором никто и никогда не программировал. Уже через год отдел был из 10 программистов на с/с++/asm. Причем были люди с очень хорошими знаниями, были новички, которые тянулись. И технологии изучали все и с жаждой! Turbo С, Borland C++, потом Visual. Полная свобода, делали что хотели: новые инструменты, языки, протоколы, техники и т.д. И это все далеко не в столице. Да, с зарплатой было иногда тяжело, иногда полегче (все таки девяностые). Проходилось писать под заказ. Потом пару лет работал в Москве и уже в софтверной конторе. Там все было статичнее. Нельзя было выбирать все и свободно, но компромисс находил. Держались все в тренде. Потом универ в Германии, все абсолютно новое! Язык, знакомства и прочее. После универа попадаю в небольшую ИТ компанию. Писал и на с/с++, java, php и js, потом и GWT. И для серверов, и для роутеров, и для встроенных систем и бэкэнд и фронтэнд. Старался изучать постоянно новое. Сейчас работаю в другой не очень большой софтверной фирме. Пишу только на с++. И все равно изучаю новое. Используем с++ 11. Мне сейчас сороковник и я стараюсь держаться в струе! Тут главное желание и целеустремленность. Даже просто вечером сериальчик посмотреть, то на английском, то на немецком, то на русском или украинском. Немного скомканно получилось, но, надеюсь, посыл понятен.
Я начал программировать еще в институте (1995 год), попав в НИИ, в котором никто и никогда не программировал. Уже через год отдел был из 10 программистов на с/с++/asm. Причем были люди с очень хорошими знаниями, были новички, которые тянулись. И технологии изучали все и с жаждой! Turbo С, Borland C++, потом Visual. Полная свобода, делали что хотели: новые инструменты, языки, протоколы, техники и т.д. И это все далеко не в столице. Да, с зарплатой было иногда тяжело, иногда полегче (все таки девяностые). Проходилось писать под заказ. Потом пару лет работал в Москве и уже в софтверной конторе. Там все было статичнее. Нельзя было выбирать все и свободно, но компромисс находил. Держались все в тренде. Потом универ в Германии, все абсолютно новое! Язык, знакомства и прочее. После универа попадаю в небольшую ИТ компанию. Писал и на с/с++, java, php и js, потом и GWT. И для серверов, и для роутеров, и для встроенных систем и бэкэнд и фронтэнд. Старался изучать постоянно новое. Сейчас работаю в другой не очень большой софтверной фирме. Пишу только на с++. И все равно изучаю новое. Используем с++ 11. Мне сейчас сороковник и я стараюсь держаться в струе! Тут главное желание и целеустремленность. Даже просто вечером сериальчик посмотреть, то на английском, то на немецком, то на русском или украинском. Немного скомканно получилось, но, надеюсь, посыл понятен.
Нее, вы не поняли, я не говорил что любая гос.организация это болото, в первую очередь тут речь о симптомах на которые нужно обращать внимание, если есть желания развиваться и соответственно как-то «лечить» то что вызывает эти симптомы, от ухода из такой компании до попытки сменить климат и организовать реальную работу.
Хорошая статья!
Я бы еще добавил — что не нужно бояться меняться и менять свою жизнь. Если вас внезапно достало программирование — попробуйте себя в смежной специализации — руководителем проектов, аналитиком, деплоймент-инженером, да мало ли чего интересного в мире происходит. Насчет зарплаты не бойтесь — если вы занимаетесь делом, которое вам на самом деле нравится — зарабатывать будете не меньше. Кроме того, работодатели зачастую так же ищут людей, у которых блеск в глазах и которым действительно интересно то, что они делают (пусть даже временно в ущерб опыту и знаниям)
Я бы еще добавил — что не нужно бояться меняться и менять свою жизнь. Если вас внезапно достало программирование — попробуйте себя в смежной специализации — руководителем проектов, аналитиком, деплоймент-инженером, да мало ли чего интересного в мире происходит. Насчет зарплаты не бойтесь — если вы занимаетесь делом, которое вам на самом деле нравится — зарабатывать будете не меньше. Кроме того, работодатели зачастую так же ищут людей, у которых блеск в глазах и которым действительно интересно то, что они делают (пусть даже временно в ущерб опыту и знаниям)
2 кейса в копилку)
Crunch-driven-development
Такое, по-моему не редкость. Условия, когда всё-должно-было-быть-сделано-вчера. Технический долг растёт. Система строится из workaround-ов. 1 добавляемая фича ломает 2 старых. 1 закрытый баг открывает 2 новых. Режим работы — «нет времени думать, надо делать!». Из плюсов — хорошая дзен-практика :)
Burnout-перфекционизм
Явление, мне кажется, более редкое, но не менее опасное. Условия работы — хорошие, развивайся не хочу. Работа — интересная, самому в кайф пофигачить не 8 часов, а 18, да ещё на выходных допилить пару вкусных фич. Как практика время от времени, оно даже полезно, наверно. Но если человек в некоторой степени упор(отый)ный, в жизни имеет место дисбаланс работы с не_работой, а подобный режим затягивается на N-месяцев — пол-года или более, — то выгорание будет болезненным, а восстановление долгим :)
В целом, согласен, что для развития, необходимы либо условия на работе, когда есть возможность:
— изучать новые технологии в своей области время от времени;
— думать над оптимальной реализацией фич;
— перенимать опыт старших коллег;
Либо, собственный/сторонний проект, который будет:
— не слишком маленьким (где был бы простор для проектирования архитектуры и применения новых технологий)
— не слишком большой (что бы было подъёмно и проект не оказался заброшен, на начавшись)
— и который будет поддерживаться в рабочем состоянии и развиваться (имхо, ничто не развивает навыки проектирования лучше, чем необходимость работать с написанным кодом, через промежутки времени, вновь и вновь).
Crunch-driven-development
Такое, по-моему не редкость. Условия, когда всё-должно-было-быть-сделано-вчера. Технический долг растёт. Система строится из workaround-ов. 1 добавляемая фича ломает 2 старых. 1 закрытый баг открывает 2 новых. Режим работы — «нет времени думать, надо делать!». Из плюсов — хорошая дзен-практика :)
Burnout-перфекционизм
Явление, мне кажется, более редкое, но не менее опасное. Условия работы — хорошие, развивайся не хочу. Работа — интересная, самому в кайф пофигачить не 8 часов, а 18, да ещё на выходных допилить пару вкусных фич. Как практика время от времени, оно даже полезно, наверно. Но если человек в некоторой степени упор
В целом, согласен, что для развития, необходимы либо условия на работе, когда есть возможность:
— изучать новые технологии в своей области время от времени;
— думать над оптимальной реализацией фич;
— перенимать опыт старших коллег;
Либо, собственный/сторонний проект, который будет:
— не слишком маленьким (где был бы простор для проектирования архитектуры и применения новых технологий)
— не слишком большой (что бы было подъёмно и проект не оказался заброшен, на начавшись)
— и который будет поддерживаться в рабочем состоянии и развиваться (имхо, ничто не развивает навыки проектирования лучше, чем необходимость работать с написанным кодом, через промежутки времени, вновь и вновь).
Из граблей, пожалуй, натыкаюсь только на №2, зато в полный рост. В проекте, который развивается 15 лет, довольно сложно менять технологии и подключать новые фреймворки. На моё предложение всё-таки посмотреть, что же такое OpenCV (который, вероятно, можно было бы использовать в нескольких ключевых местах), начальник отвечает «пробовали 10 лет назад, не понравилось, ты напишешь лучше» :)
Грабли: бросить институт, немного не дотянув до диплома, ради интересной работы.
Что за мода на Junior / Senior разделение? Это всего-лишь условность. Я знаю иностранных «джуниоров», которые могут на расслабоне русских «синьоров» попустить, причем тут это? Приведенные в статье типажи абсолютно очевидны любому, кто вообще занимается разработкой ПО, не понимаю, какую смысловую нагрузку несет статья. Ладно, пятница, я понимаю. А где юмор, где трэш, где угарные истории, где сиськи? Короче говоря, стетейки клепать — не мешки ворочить.
Это всего-лишь условность
Естестевнно, под Junior в данной статье подразумеваются программисты без опыта или с минимальным опытом
Я знаю иностранных «джуниоров», которые могут на расслабоне русских «синьоров» попустить
Значит, эти синьноры это всего лишь джуниоры с 15-летним поытом, такое бывает, особенно из-за падания в одну из «ловушек» выше.
Приведенные в статье типажи абсолютно очевидны любому, кто вообще занимается разработкой ПО
Вроде написано
Давайте вспомним некоторые типичные грабли, на которые мы все (ну или большинство) наступали сами того не замечая. Конечно, для опытных разработчиков многое покажется очевидным капитанством, однако молодых специалистов такие ловушки могут легко увести на темную сторону силы.
Поверьте, для молодого разработчика без опыта работы это все не далеко не очевидно, многое написано по собственному печальному опыту.
Короче говоря, стетейки клепать — не мешки ворочить.
Так клепайте, лучше, быстрее, веселее, какие проблемы? :)
пункт 8: Битрикс
просто так минутка смеха и так отвлечься от работы!!!
рекомендую к просмотру!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типичные грабли на пути программиста от Junior'а к Senior'у