Comments 42
Хорошая и интересная статья. И хочу добавить что всё относително… старший архитектор в моей компании будет разносить пончики в гугле :) а джуниор из гугла вероятно сможет заменить некоторых CTO в России на раз!
Полностью согласен. Когда-то, работая тимлидом, я думал что все знаю и все умею, обучал джуниоров и чувствовал себя ужасно крутым. А потом пошел работать в компанию уровнем намного выше, стал обычным разработчиком и очень болезненно переживал разрыв шаблонов, заново осознавал, сколько же я еще всего не знаю.
И это только на 7-м году. Возможно, на 10-м и на 15-м снова предстоит очередной, болезненный, но все же левел-ап!
И это только на 7-м году. Возможно, на 10-м и на 15-м снова предстоит очередной, болезненный, но все же левел-ап!
Аналогично, профессор! А если вы не наблюдали аналогичных разрывов своего мозга, значит вы либо просто гений либо, что вероятнее, еще ни разу не переходили на следующий лвл!
+1 Но если бы в нашей профессии не было таких левелапов, я бы всерьез задумался про другую карьеру.
Левелапы есть, наверное, почти в любой профессии.
Да, только самая динамичная область, где знания устаревают со скоростью света — IT.
Это верно. Хотя иногда мелькает предательская мысль, как бы хорошо было чему-нибудь одному очень хорошо научиться — пусть не за год, пусть за два, но знать и идеале — и этим зарабатывать.
C/C++ + программирование контроллеров?
на самом деле знания не устаревают (если конечно не гнаться за хайпом типа: ааа! все уже на nodeJS+mongo а я на php+mysql! омг я же УСТАРЕЛ!), просто появляются новые концепции, которые почти всегда являются небольшой пристройкой к существующим, и опять же почти всегда вписываются в язык, которым ты пользуешься. Почти всегда. А если не вписываются,- изучить новый язык раз в в 2-3 года, это не только полезно, но и просто приятно.
на самом деле знания не устаревают (если конечно не гнаться за хайпом типа: ааа! все уже на nodeJS+mongo а я на php+mysql! омг я же УСТАРЕЛ!), просто появляются новые концепции, которые почти всегда являются небольшой пристройкой к существующим, и опять же почти всегда вписываются в язык, которым ты пользуешься. Почти всегда. А если не вписываются,- изучить новый язык раз в в 2-3 года, это не только полезно, но и просто приятно.
Ну вот нифига ведь нет.
Во-первых: вы наверное недопонимаете круг задач CTO. Это не главный программист. Да и старший архитектор может не программировать вообще.
Во-вторых: Не стоит боготворить людей из какой-то компании просто из-за того что они там работают. Я смотрю на потуги гугла писать javascript и понимаю что даже старший инженер по js из гугла может просто не пройти собеседование в мою компанию.
Во-первых: вы наверное недопонимаете круг задач CTO. Это не главный программист. Да и старший архитектор может не программировать вообще.
Во-вторых: Не стоит боготворить людей из какой-то компании просто из-за того что они там работают. Я смотрю на потуги гугла писать javascript и понимаю что даже старший инженер по js из гугла может просто не пройти собеседование в мою компанию.
Ну вы вообщем то поняли ведь суть.
А про гугл… ну ладно не гугл… ну ладно не моя компания. А компания X и компания Y.
Я к тому что всё относительно в этом мире…
А про гугл… ну ладно не гугл… ну ладно не моя компания. А компания X и компания Y.
Я к тому что всё относительно в этом мире…
Если архитектор перестает писать код, то в какой-то не очень отдаленный момент времени он перестанет быть архитектором. Это же не менеджер, а специалист высшего класса, а специалист, чтобы оставаться на высоте, должен писать код.
Понятно, но это не прямая его обязанность
Поддерживаю. Два примера из личного опыта:
Случай 1, успешный. Участвовал в разработке некоего портала, большая часть функций которого была знакома нашим разработчикам — вбивалка данных, то, что мы клепали и в других Системах. В команде я был на роли разработчика, одного из 6-10 (в разные моменты процесса развития Системы). Но потребовалась новая подсистема, идеология которой шла вразрез опыту любого человека в компании (не только разработчиков, но и аналитиков, менеджеров и т.д.). Никто не хотел браться, т.к. не знали с какой стороны вообще подойти, а время шло. Была еще проблема со сроками, начав с нуля через пару месяцев надо было показать работающий продукт. В общем я решился войти архитектором в подсистему, хотя так же, как и остальные понятия не имел от чего плясать. Начал анализировать как требования Заказчика могут выглядеть после реализации, пытаться рисовать структуру БД, прикидывать структуру кода и т.д. Потихоньку-помаленьку (но укладываясь в сроки) подсистема начала вырисовываться, в конце-концов абсолютно непонятный функционал удалось уложить в привычные всем считал/изменил/сохранил. Подсистема оказалась, на мой взгляд, самым успешным проектом подразделения за многие годы, причем не только в части качественной разработки, но и по удовлетворенности клиента, соблюдению сроков, закрытию контрактов. Так вот, будучи на роли архитектора, я постоянно программировал. Первые строчки кода и основная структура БД были целиком моими, остальные стали подключаться позже. Постепенно я кодил все меньше, и в конце-концов, когда все было поставлено на поток, вышел из команды проекта, еще до окончательной сдачи подсистемы. Где-то читал, что только реализация может раскрыть все недочеты проектирования, и этот случай подтверждает это на 100%.
Случай 2, провальный. Архитектор в нашей компании спроектировал систему в общем, выдав это в виде документа. А непосредственно кодинг отдал младшему разработчику. И вроде архитектуру кода контролировал, и как-то присматривал за разработчиком, но сам если и кодил, то только интерфейсы. Систему в конце концов сдали в промышленную эксплуатацию, и она работает долгие годы. Можно сказать, что «где же тут провал»? Система работает, деньги за нее получены, а что там внутри — дело десятое. Мне довелось спустя годы попасть на дальнейшее развитие и поддержку этой системы, и то, с чем я там столкнулся, повергло меня в шок. Я никогда в жизни не видел более страшного кода, а его поддержка — пытка. Любое сколь-нибудь серьезное изменение в большинстве случаев тянет за собой также и хороший рефакторинг, причем большая часть времени занимает именно рефакторинг, а не требующаяся доработка. Провал — поддержка кривого кода требует гораздо больше времени, и, соответственно денег. И конечно же, очень часто даже небольшие изменения несут побочные эффекты в виде ошибок в совершенно неожиданных местах. Провал — неудовлетворенность конечного пользователя, дополнительное время (и деньги) на тестирование, поиск и исправление ошибок, повторные сборки и передачи обновлений. Я думаю, что если бы архитектор непосредственно участвовал в реализации, хотя бы на начальных этапах, и программировал сам, то все было бы по-другому.
Случай 1, успешный. Участвовал в разработке некоего портала, большая часть функций которого была знакома нашим разработчикам — вбивалка данных, то, что мы клепали и в других Системах. В команде я был на роли разработчика, одного из 6-10 (в разные моменты процесса развития Системы). Но потребовалась новая подсистема, идеология которой шла вразрез опыту любого человека в компании (не только разработчиков, но и аналитиков, менеджеров и т.д.). Никто не хотел браться, т.к. не знали с какой стороны вообще подойти, а время шло. Была еще проблема со сроками, начав с нуля через пару месяцев надо было показать работающий продукт. В общем я решился войти архитектором в подсистему, хотя так же, как и остальные понятия не имел от чего плясать. Начал анализировать как требования Заказчика могут выглядеть после реализации, пытаться рисовать структуру БД, прикидывать структуру кода и т.д. Потихоньку-помаленьку (но укладываясь в сроки) подсистема начала вырисовываться, в конце-концов абсолютно непонятный функционал удалось уложить в привычные всем считал/изменил/сохранил. Подсистема оказалась, на мой взгляд, самым успешным проектом подразделения за многие годы, причем не только в части качественной разработки, но и по удовлетворенности клиента, соблюдению сроков, закрытию контрактов. Так вот, будучи на роли архитектора, я постоянно программировал. Первые строчки кода и основная структура БД были целиком моими, остальные стали подключаться позже. Постепенно я кодил все меньше, и в конце-концов, когда все было поставлено на поток, вышел из команды проекта, еще до окончательной сдачи подсистемы. Где-то читал, что только реализация может раскрыть все недочеты проектирования, и этот случай подтверждает это на 100%.
Случай 2, провальный. Архитектор в нашей компании спроектировал систему в общем, выдав это в виде документа. А непосредственно кодинг отдал младшему разработчику. И вроде архитектуру кода контролировал, и как-то присматривал за разработчиком, но сам если и кодил, то только интерфейсы. Систему в конце концов сдали в промышленную эксплуатацию, и она работает долгие годы. Можно сказать, что «где же тут провал»? Система работает, деньги за нее получены, а что там внутри — дело десятое. Мне довелось спустя годы попасть на дальнейшее развитие и поддержку этой системы, и то, с чем я там столкнулся, повергло меня в шок. Я никогда в жизни не видел более страшного кода, а его поддержка — пытка. Любое сколь-нибудь серьезное изменение в большинстве случаев тянет за собой также и хороший рефакторинг, причем большая часть времени занимает именно рефакторинг, а не требующаяся доработка. Провал — поддержка кривого кода требует гораздо больше времени, и, соответственно денег. И конечно же, очень часто даже небольшие изменения несут побочные эффекты в виде ошибок в совершенно неожиданных местах. Провал — неудовлетворенность конечного пользователя, дополнительное время (и деньги) на тестирование, поиск и исправление ошибок, повторные сборки и передачи обновлений. Я думаю, что если бы архитектор непосредственно участвовал в реализации, хотя бы на начальных этапах, и программировал сам, то все было бы по-другому.
Сейчас меня окончательно в минус вгонят, но всё-таки вы путаете архитектуру и дизайн. Плюс, судя по всему, во втором случае никто не писал тесты, это уже провал CTO.
Мне кажется, что разница между архитектурой и дизайном есть только в случае если у вас есть и архитекторы и дизайнеры. В описанных мной случаях была система и был один ответственный за архитектуру/дизайн/идеологию, как это не назови.
Насчет тестов: чтобы купить что-нибудь хорошее, надо сначала продать что-нибудь хорошее. На проекте были определенные ресурсы, если бы их затратили на написание тестов, то проект не был бы сдан в срок. К тому же, я уже сказал про качество кода, уверен, что тесты были бы еще хуже.
И, кстати, в первом случае тестов тоже не было (вообще в проекте, а не конкретно в подсистеме). И не только в этом проекте, а вообще во всех проектах компании. Как-то пробовали «на вкус», но так и не прижилось. Мое личное мнение — наличие тестов занимает далеко не самую важную роль в успешности проекта.
Насчет тестов: чтобы купить что-нибудь хорошее, надо сначала продать что-нибудь хорошее. На проекте были определенные ресурсы, если бы их затратили на написание тестов, то проект не был бы сдан в срок. К тому же, я уже сказал про качество кода, уверен, что тесты были бы еще хуже.
И, кстати, в первом случае тестов тоже не было (вообще в проекте, а не конкретно в подсистеме). И не только в этом проекте, а вообще во всех проектах компании. Как-то пробовали «на вкус», но так и не прижилось. Мое личное мнение — наличие тестов занимает далеко не самую важную роль в успешности проекта.
У меня было много бумажных званий и громких титулов, но я, по сути, младший разработчик, создающий тонны программного бреда.
Я до сих пор получаю удовольствие от этого процесса.
Ну да. Не меньшее удовольствие отсечь все лишнее от тонн бреда и выплавить килограмм неплохого продукта.
Когда удовольствие проходит, разработчики становятся менеджерами и архитекторами проектов.
Каждому свое. Одному — беспорядочные флирты. Другому — стабильный семейный уклад. Главное — определиться со своим талантом. Талант есть у всех.
Я до сих пор получаю удовольствие от этого процесса.
Ну да. Не меньшее удовольствие отсечь все лишнее от тонн бреда и выплавить килограмм неплохого продукта.
Когда удовольствие проходит, разработчики становятся менеджерами и архитекторами проектов.
Каждому свое. Одному — беспорядочные флирты. Другому — стабильный семейный уклад. Главное — определиться со своим талантом. Талант есть у всех.
UFO just landed and posted this here
Помоему в IT не может быть опыта больше чем в 3 года. За 3 года технологии меняются совершенно, меняется видение.
Принципы от этого не меняются. По этому опыт играет роль всегда.
Т.е. хороший программист это не тот который «опытный», а тот который хорошо знает базовые понятия CS и мотивирован на изучение новых технологий.
Может даже соглашусь с Вами, но в любом случае без опытного акитекта, лида или еще кого — только большая удача может спасти проэкт.
В IT опыта может быть больше десятка лет, а вот в рнр версии 5.12, да, возможно и поменьше. И да, кстати, меняющиеся технологии не обязательно призывают менять инструменты. От того, что появился руби на рельсах не значит, я мы повально должны переписать всё на них. 90% задач независимы от реализации. И, исходя их этого посыла, можно опровергнуть ваш второй абзац: стартап — это не про язык или плату разводки, это про удовлетворение потребностей клиентов. А на этом поприще важен как раз опыт заваленных проектов, а не правильно выбранная технология.
Поэтому, хороший программист — это тот, который в команде выполняет эффективно возложенные на него задачи. А то будет у тебя отдел проектировки 30% времени продумывать всё тщательно, а мегамотивированный прогер замутит на бутстрапе некое подобие очень приблизительно к документу и будет считать всех взрослых дядек редисками, зря потратившими время на доводку проекта на бумаге. Лучше опытный программист на Си, чем молодняк без спецификаций, метающийся между Haxe-Angular-Node.js
Поэтому, хороший программист — это тот, который в команде выполняет эффективно возложенные на него задачи. А то будет у тебя отдел проектировки 30% времени продумывать всё тщательно, а мегамотивированный прогер замутит на бутстрапе некое подобие очень приблизительно к документу и будет считать всех взрослых дядек редисками, зря потратившими время на доводку проекта на бумаге. Лучше опытный программист на Си, чем молодняк без спецификаций, метающийся между Haxe-Angular-Node.js
сексуальные синглтоны
В данном контексте слово «sexy» нельзя так переводить. Оно имеет вполне нейтральное значение «классный», не намекающее на взаимоотношение полов.
… и супер-пупер уверенный на счет своей работы идешь прямиком к «старшему» разработчику..
Затем, к твоему удивлению, она говорит..
Мое удивление усилил тот факт, что старший разработчик — она.
Я даже возвращался выше из-за этого — решил, что потерял нить повествования.
Это сбивающий с толку перевод.
В американской тех.литературе нынче ради политкорректности некую неизвестную персону принято называть she, а не he.
В американской тех.литературе нынче ради политкорректности некую неизвестную персону принято называть she, а не he.
мой скрам мастер vivienne van der vooren, «senior software engineer», гражданка голландии. даже не заметил «подвоха», пока не наткнулся на ваш комментарий.
Сейчас как раз ищем Junior'a и опытного программиста. Очень забавно было прочитать про то, что я наблюдаю каждый день на собеседованиях. Очень мало адекватных людей, причем те кто приходит на вакансию Junior'a чаще более адекватны (они отдают себе отчет в том, каков их уровень). А вот на вакансию опытного разработчика, столько джуниоров с манией величия претендует (то, что они джуниоры я не по возрасту сужу, а по реальным знаниям). Еще попадаются люди, которые считают что они уже опытные программисты, потому что им 40 лет и больше. А начинаешь разговаривать, вообще непонятно, чем человек все эти годы занимался (хотя работал вроде как программистом).
А на сайтах резюме чего только не напишут, столько у нас 21-летних ТимЛидов развелось, просто страна гениев.
P.S.: но в целом попадаются очень толковые ребята, и что удивительно даже девушки. Вообще девушки гораздо более адекватны в оценке своего уровня.
А на сайтах резюме чего только не напишут, столько у нас 21-летних ТимЛидов развелось, просто страна гениев.
P.S.: но в целом попадаются очень толковые ребята, и что удивительно даже девушки. Вообще девушки гораздо более адекватны в оценке своего уровня.
Думаю все по делу написано, но есть одно НО: несмотря на то, что рынок программистов перегрет и зарплаты у программистов приличные, джуниорам платят традиционно мало. Настолько маленькие, что неквалифицированный менеджер торгового зала(читай продавец консультант) может получать значительно больше. И перепрыгивать с хорошего дохода фрилансера, на, по сути, копеечную зарплату джуниора, но с возможностью чему-то научиться у крутых спецов ой как не хочется. Особенно учитывая, что в компанию попроще с текущим багажом знаний легко берут на позиции полноценного инженера с соответствующим окладом.
Очень похоже на отцов и детей в разные годы: xkstech.blogspot.com/2011/12/blog-post_23.html
Лол, рекламу сока то в статье зачем оставили.
меня одного убивает анимация среди текста?
Для себя я вывел такое определение «старшего» — инженер, способный ответить на многие конкретные вопросы или направить в нужном направлении или к нужному человеку. Незатейливое, тривиальное определение, но с несколькими важными (для меня) моментами: он способен не сделать сам, а объяснить, он способен ответить на конкретные вопросы, а не долго и красочно сравнивать несколько фреймворков и главное — у него есть «контакты» с другими «старшими», если он не может справиться сам.
«джуниоры» редко могут помочь в работе другим, несмотря на огромный багаж их «энциклопедических» знаний.
«джуниоры» редко могут помочь в работе другим, несмотря на огромный багаж их «энциклопедических» знаний.
Давненько я не видел, чтобы НЛО прилетало. Добро пожаловать!
Sign up to leave a comment.
Что это действительно значит быть «младшим программистом»