Комментарии 51
Кажется, случись вам менять работу, будет очень сложно. Дело не столько к докере или NoSQL, сколько в том, что современные компании ценят умение тащить в постоянно изменяющейся среде и софт-скиллы, которые приходят, по моему опыту, от взятия на себя ответственности и работы с разными людьми в разных проектах. Вы об этом упоминаете совсем мало.
Поиск работы и прохождение собеседований — это тоже совершенно отличный от обычной работы навык. Советую начать тренироваться и собеседоваться, если вы всерьёз настроены когда-то поменять работу.
В любом случае удачи!
Очень забавно: опубликовал комент и понял, что обратился фактически к переводчику
Возможно, я в чем-то не прав, но «постоянно изменяющаяся среда» — немного переоцененное понятие. Фундаментальным основам, на которых строится современная CS, где-то полвека (к счастью или к сожалению). Поэтому, если есть понимание этих основ, то никакие NoSQL с докерами пугать не должны. По крайней мере вас — как соискателя на проект, в котором количество кода, в котором предостоит разбираться, априори на порядки больше API (контрактов, [недокументированных] особенностей, и т.д.) сторонних сервисов. А если это пугает потенциального работодателя, то, возможно, вам просто с ним не по пути.
Что касается софт-скиллов, то <тут нецензурно>. В общем, эмулировать их на собеседовании не очень сложно. А дальше, если умеете работать, они не очень нужны.
Что касается софт-скиллов, то <тут нецензурно>. В общем, эмулировать их на собеседовании не очень сложно. А дальше, если умеете работать, они не очень нужны.
Почему это софт-скиллы нецензурно? Похожий каждый хороший программист мнит, что он в одиночку может построить Эйфелову башню, только на это у него уйдет 40 лет, а ждать некогда. И вдруг неожиданно оказывается, что надо делить работу, работать в команде, оценивать сильные и слабые стороны своих напарников и почему-то «софт-скиллы» — нецензурное слово.
Объясните, пожалуйста.
Объясните, пожалуйста.
Видимо, у нас с вами разное понимание вот этого вот термина.
Я глубоко убежден, что по сугубо рабочим моментам, как то: высказать свою гипотезу, задать технический вопрос или ответить на него — может коммуницировать любой человек, не отягощённый грузом серьезных психических заболеваний.
Поэтому поделить работу не проблема, алгоритмов много: «я такое уже пилил, так что давайте», «кто первый встал, того и тапки», «мне всё равно делать нефиг / я перегружен». В случае дедлока (в реальности — редкого) проблема эскалируется на уровень выше в виде тим-лида. Который, кстати, и принимает решение, опираясь на сильные и слабые стороны работников и прочие методы научного тыка. То есть какого-то экстраординарного опыта общения от технических сотрудников это не требует.
Теперь о работе в команде. Тоже очень спорный термин. Кто-то видит в этом механизм манипуляции вида«часть корабля, часть команды» «мы команда, мы пашем до победного без перерыва на обед и выходных, кто против — враг», «в слове команда нет буквы Я, поэтому все молодцы, а премия, чтобы никого не обидеть — менеджеру».
Но, как мне кажется, успешной команда становится тогда, когда в ней четко кристаллизуются роли, что помогает обрабатывать поступающие задачи на конвейере. Так что это, скорее, заслуга полученного опыта, а не каких-то абстрактных софт-скиллов.
Это был ответ к первой части вашего сообщения. Теперь о «нецензурщине».
Тут всё просто: шильдик «да он троглодит какой-то без софт-скиллов» вешают всякие феечки, которые рациональные аргументы не понимают, поэтому они взамен ищут повод оскорбиться на наименования переменных. Поэтому вместо конструктивного диалога вида: «код — г@вно, причины: вот, вот и вот, поправь плиз», — приходится пороть чушь вида «привет-какдила? ты проделал замечательную работу, просто прекрасную! а как ты думаешь, нельзя ли сделать её еще лучше, например тут? И там, смотри, какое у тебя вот здеееееесь интересненькое решеньице».
А это выливается не только в исключительное словоблудие и потерю времени, но и в то, что исчезает любая действенная обратная связь: действительно ли всё у меня хорошо, или надо копаться глубже в этом словесном поносе, додумывать и искать скрытый смысл?
Поэтому, резюмируя: общаться конструктивно по делу ни для кого не проблема, не надо для этого выдумывать отдельные «скиллы». Advanced-уровень словоблудия, называемый «софт-скиллами», мешает по-настоящему эффективной технической коммуникации.
Я глубоко убежден, что по сугубо рабочим моментам, как то: высказать свою гипотезу, задать технический вопрос или ответить на него — может коммуницировать любой человек, не отягощённый грузом серьезных психических заболеваний.
Поэтому поделить работу не проблема, алгоритмов много: «я такое уже пилил, так что давайте», «кто первый встал, того и тапки», «мне всё равно делать нефиг / я перегружен». В случае дедлока (в реальности — редкого) проблема эскалируется на уровень выше в виде тим-лида. Который, кстати, и принимает решение, опираясь на сильные и слабые стороны работников и прочие методы научного тыка. То есть какого-то экстраординарного опыта общения от технических сотрудников это не требует.
Теперь о работе в команде. Тоже очень спорный термин. Кто-то видит в этом механизм манипуляции вида
Но, как мне кажется, успешной команда становится тогда, когда в ней четко кристаллизуются роли, что помогает обрабатывать поступающие задачи на конвейере. Так что это, скорее, заслуга полученного опыта, а не каких-то абстрактных софт-скиллов.
Это был ответ к первой части вашего сообщения. Теперь о «нецензурщине».
Тут всё просто: шильдик «да он троглодит какой-то без софт-скиллов» вешают всякие феечки, которые рациональные аргументы не понимают, поэтому они взамен ищут повод оскорбиться на наименования переменных. Поэтому вместо конструктивного диалога вида: «код — г@вно, причины: вот, вот и вот, поправь плиз», — приходится пороть чушь вида «привет-какдила? ты проделал замечательную работу, просто прекрасную! а как ты думаешь, нельзя ли сделать её еще лучше, например тут? И там, смотри, какое у тебя вот здеееееесь интересненькое решеньице».
А это выливается не только в исключительное словоблудие и потерю времени, но и в то, что исчезает любая действенная обратная связь: действительно ли всё у меня хорошо, или надо копаться глубже в этом словесном поносе, додумывать и искать скрытый смысл?
Поэтому, резюмируя: общаться конструктивно по делу ни для кого не проблема, не надо для этого выдумывать отдельные «скиллы». Advanced-уровень словоблудия, называемый «софт-скиллами», мешает по-настоящему эффективной технической коммуникации.
Кроме упора на технологический стек вполне эффективная стратегия изучать предметную область. И желательно не одну. В этом плане подрастающее поколение программистов вам не сможет составить конкуренцию и такие люди на рынке востребованы.
А какую? :)
Тут засада вот в чем: хороший опыт в разработке можно приложить к любой предметной области, а предметная область кроме самой себя особо ни к чему хорошо не прикладывается.
Так что, скажем, авансом штудировать банковское дело «просто так», не планиря строить там карьеру и не разрабатывая сейчас банковское ПО — сомнительная инвестиция.
Тут засада вот в чем: хороший опыт в разработке можно приложить к любой предметной области, а предметная область кроме самой себя особо ни к чему хорошо не прикладывается.
Так что, скажем, авансом штудировать банковское дело «просто так», не планиря строить там карьеру и не разрабатывая сейчас банковское ПО — сомнительная инвестиция.
Базовые знания по экономике;
Основы бухучета (без глубины, просто приципы как считают деньги профессиональные счетоводы);
Основы менеджмента
А человек, допустим, игрушки разрабатывает. Или CAD-системы. Или вообще на микроконтроллерах специализируется.
Какова вероятность, что его будущая карьера будет зависеть от знаний бухучета?
Плюс еще такой момент, что бухгалтерия — это зависимая от страны дисциплина. Российскую изучать априори смысла нет, а гадать, где придется работать в будущем — вообще лотерея.
Какова вероятность, что его будущая карьера будет зависеть от знаний бухучета?
Плюс еще такой момент, что бухгалтерия — это зависимая от страны дисциплина. Российскую изучать априори смысла нет, а гадать, где придется работать в будущем — вообще лотерея.
На мой взгляд ответ очевиден. В игрушках порой очень много экономики. Даже просто баланс бойцов — это тоже своего рода экономика, я не говорю уж про экономические стратегии типо Цезарь, Цивилизация и т.п.
Микроконтроллеры — тем более — если в проекте кроме софта (нематериальных активов) еще и материальные ценности задействованы — то Профессионалу не помешает умение оценивать успешность своего проекта не только по факту что он сделал, но и с учетом всех затрат.
Бухгалтерия, опять же повторю — без глубины, изучать не детали российского/любого другого законодательства, а принципы подсчета денег. Счета, проводки, актив, пассив, баланс и т.п.
Про менеджмент, даже если вы не руководите ни кем, а только руководят вами — вам точно не помешает понимать как они это делают.
Микроконтроллеры — тем более — если в проекте кроме софта (нематериальных активов) еще и материальные ценности задействованы — то Профессионалу не помешает умение оценивать успешность своего проекта не только по факту что он сделал, но и с учетом всех затрат.
Бухгалтерия, опять же повторю — без глубины, изучать не детали российского/любого другого законодательства, а принципы подсчета денег. Счета, проводки, актив, пассив, баланс и т.п.
Про менеджмент, даже если вы не руководите ни кем, а только руководят вами — вам точно не помешает понимать как они это делают.
Просто с такой логикой надо обязательно изучать
И так далее, и тому подобное.
Я тут не за то, что надо быть исключительно узким специалистом, не интересующимся ничем вообще. Любые знания могут оказаться полезными. А могут и не оказаться. Поэтому надо критически относиться к тому, что вы тащите на свой чердак, как завещал советский Холмс. Вам, возможно, бухучет помог. Кому-то он окажется совсем не нужен.
- медицину — собственное тело не молодеет, у молодых докторов «дипломы куплены».
- юриспруденцию — чтобы отстаивать свои права.
- квантовую физику — в последнее время популярны теории, что сознание — суть квантовый процесс в нейронах. А работаем мы, по большей части, головой.
- строительство — ну, мы же все в домах живем, да?
- агропромышленное производство — ибо кушаем.
И так далее, и тому подобное.
Я тут не за то, что надо быть исключительно узким специалистом, не интересующимся ничем вообще. Любые знания могут оказаться полезными. А могут и не оказаться. Поэтому надо критически относиться к тому, что вы тащите на свой чердак, как завещал советский Холмс. Вам, возможно, бухучет помог. Кому-то он окажется совсем не нужен.
НЛО прилетело и опубликовало эту надпись здесь
Да, логика именно такая.
И с Правом и Медициной — я тоже согласен что надо в основах разбираться.
Просто изначальный вопрос был «что изучать на работе чтобы пригодилось на другой работе» — поэтому из всего вашего списка я выбрал только три пункта.
Вобщем, в моей позиции нет противоречия вашей :-)
И с Правом и Медициной — я тоже согласен что надо в основах разбираться.
Просто изначальный вопрос был «что изучать на работе чтобы пригодилось на другой работе» — поэтому из всего вашего списка я выбрал только три пункта.
Вобщем, в моей позиции нет противоречия вашей :-)
Ага, тонкая нотка иронии, похоже, оказалась практически неуловимой. :)
К чему приводит, например, «разбирательство» в медицине — показано в классическом «Трое в лодке». Так что иногда все-таки лучшежевать, чем говорить признать свою некомпетентность в теме и обратиться к специалисту.
А глобально противоречие тут следующиее: вы утверждаете (скорее всего, на основании собственного опыта), что ряд предметных областей наподобие бухучета нужен всем и всегда. А мой опыт подсказывает, что нет, не всем, и изредка. Бухучетом, например, я занимался давным давно, когда шабашил по 1С… И, в общем, после той работы эти сакральные знания не пригодились вообще.
Поэтому мне кажется, что более эффективно поднимать собственную ценность в свободное время изучением именно профильных дисциплин, которых в CS на сей день, в общем-то, немало. А вот за втыкание в конкретную предметную область пусть уже платит работодатель.
К чему приводит, например, «разбирательство» в медицине — показано в классическом «Трое в лодке». Так что иногда все-таки лучше
А глобально противоречие тут следующиее: вы утверждаете (скорее всего, на основании собственного опыта), что ряд предметных областей наподобие бухучета нужен всем и всегда. А мой опыт подсказывает, что нет, не всем, и изредка. Бухучетом, например, я занимался давным давно, когда шабашил по 1С… И, в общем, после той работы эти сакральные знания не пригодились вообще.
Поэтому мне кажется, что более эффективно поднимать собственную ценность в свободное время изучением именно профильных дисциплин, которых в CS на сей день, в общем-то, немало. А вот за втыкание в конкретную предметную область пусть уже платит работодатель.
А свободного времени у меня не так много, как было в молодости – уже не посидишь ночами над личными проектами, чтобы освоить новый инструмент. Многие разработчики, которые отпраздновали тридцатилетие и обзавелись семьёй, меня здесь поймут.
У меня есть для вас хорошая новость, всё еще впереди. Ближе к 50 годам дети уже вырастают и опять появляется свободное время для личных проектов! Знаю на своём опыте.
Странно, что не рассматривается вариант перехода в область преподования(в западных и топовых российских университетах вполне адекватная зарплата) или переход на уровень «эксперта из индустрии» с почасовой ставкой/уход в менеджмент
Мне кажется что он просто ленивый… Сделать проектик, где попробовать новые технологии, залить все это на cloud и использовать docker — вот и проблемы не будет и будут знания. При этом, давайте скажем честно что делать такие вещи можно в рабочее время, конечно не в ущерб основной работе, но я не поверю что он сидит 8 часов и только делает свою работу.
Неа. Это так не работает. «Написать HelloWorld» и «изучить технологию» — это две большие разницы. Качественно пройтись по граблям на абстрактном и никому не нужном примере не получится.
кто сказал «Написать HelloWorld»? Я написал сделать проектик. Размер проекта никто не запрещает сделать достаточным для изучения. Да и время на разработку можно тратить хоть сколько, новые технологии не появляются каждый месяц. Можно и год попилить свой проект для изучения, либо вообще поработать над каким-то open source (это каждый сам может решать). Просто он сидит годами на одной и том же и ноет что новое не получается изучить. А вот не надо так… Надо годами новое изучать :)
HelloWorld по идеологии, а не по объему. Технологии обычно начинают изучать либо по документации, либо по книжкам. И там, и там, ввиду размера и привлекательности, описывается некий стандартный workflow безо всяких «странных» пожеланий, характерных для любого живого и настоящего проекта.
При этом, как правило, эти «странные» пожелания у изучающего либо не возникают вовсе, либо он от них подсознательно отмахивается.
Ну а иногда на уровне домашнего проекта набить некоторые шишки не получается в принципе. Как, например, на уровне домашнего проекта убедиться, что балансировка нагрузки работает хорошо? Или что, допустим, staged rollouts действительно работают и помогают?
При этом, как правило, эти «странные» пожелания у изучающего либо не возникают вовсе, либо он от них подсознательно отмахивается.
Ну а иногда на уровне домашнего проекта набить некоторые шишки не получается в принципе. Как, например, на уровне домашнего проекта убедиться, что балансировка нагрузки работает хорошо? Или что, допустим, staged rollouts действительно работают и помогают?
Кто мешает провести performance testing своего проекта и протестировать? Это кстати добавит знаний, какими средствами это сделать и как. И балансировку можно проверить и staged rollouts, было бы желание.
Плюс еще не стоит кидаться в крайности, если он пойдет искать работу то никто его не возьмет архитектором если проект на этих новых технологиях, но вот рядовым программистом его возьмут без проблем если он пройдет интервью и у него будет опыт только своего проекта. Конечно вопрос надо ему это или нет, но у него хоть будет возможность выбирать. Сейчас он сидит без выбора и не хочет делать ничего чтобы изменить ситуацию.
Плюс еще не стоит кидаться в крайности, если он пойдет искать работу то никто его не возьмет архитектором если проект на этих новых технологиях, но вот рядовым программистом его возьмут без проблем если он пройдет интервью и у него будет опыт только своего проекта. Конечно вопрос надо ему это или нет, но у него хоть будет возможность выбирать. Сейчас он сидит без выбора и не хочет делать ничего чтобы изменить ситуацию.
Я так понимаю, он и сейчас рядовой программист (а, может, даже и не рядовой вовсе). То есть морковки спереди нет, а угрожает ли моркова сзади — вопрос.
Но у меня речь о том, что не имея экспертизы в какой-то области, очень сложно оценить реалистичность performance testing и вот этого вот всего. То есть если у человека синдром самозванца, то даже развестистый pet-project может не помочь с самооценкой. И это не говоря о том, что в процессе таких изысканий можно действительно зарулить проект куда-то не туда.
С другой стороны, собес можно пройти, просто предварительно почитав конспекты про всякие модные buzzwords — особенно, обладая развитой фантазией.
Но у меня речь о том, что не имея экспертизы в какой-то области, очень сложно оценить реалистичность performance testing и вот этого вот всего. То есть если у человека синдром самозванца, то даже развестистый pet-project может не помочь с самооценкой. И это не говоря о том, что в процессе таких изысканий можно действительно зарулить проект куда-то не туда.
С другой стороны, собес можно пройти, просто предварительно почитав конспекты про всякие модные buzzwords — особенно, обладая развитой фантазией.
Ну он пишет что " у меня хорошая должность сениора в компании", для меня это означает что он вполне может иметь опыт чтобы и свой проект сделать приличным. Он может просто взять текущий свой проект на работе (или часть его) и сделать на новых технологиях и заодно сравнить.
В общем, под лежачий камень вода не течет…
В общем, под лежачий камень вода не течет…
Вот и пришли к тому, что «ахера ему не переписать свой текущий проект на модную технологию». А может и в прод раскатать, и командой тестеров стать, и менеджментом и вобще хозяином бизнесов. Вот он ленивый какой паскуда =)
А свободного времени у меня не так много, как было в молодости – уже не посидишь ночами над личными проектами, чтобы освоить новый инструмент.
Многие разработчики, которые отпраздновали тридцатилетие и обзавелись семьёй, меня здесь поймут.
Мужик, я тебя отлично понимаю! У самого вон проект забуксовал.
Поверьте vpedak, тут дело не в лени. С детьми и правда личного времени не остается.
Бывает так же, но печальнее, когда старый и не программист.
Смешна эта трагедия программиста, который пытается быстро бежать, чтобы оставаться на месте.
Есть три стадии карьеры мудрого разработчика.
— Если вам от 20 до 30: вы пилите проект, иногда не спя ночами. И учитесь, учитесь, учитесь. Вас не ценят, ибо таких как вы — сотни.
— От 30 до 45 — потихонечку переползаете в область мидлов и сеньоров. Тут как хватит наследсвенности и своего ума. Появляется опыт в разработке, но это фигня. Самое главное, — вы начинаете разбираться в командной работе, у вас формируется понимания: как работает организация, разрабатывающая софт; как работает бизнес заказчиков. И вас начинают ценить не за то, что вы офигительно программируете (или вообще не умееете), а за то, что вы умеете поставить процесс, разделить зоны ответственности, создать спецификации протоколов, API и т.п. и просто организовать бестолковых юниоров и добиться от них полезной работы.
от 45… Тут вершина умного и мудрого разработчика. Вам просто платят денег за то что вы есть в штате компании. Иногда вы, конечно, выдаете идеи как обустроить рабфак и даже пишете код.
Но, в целом, вы обычно проводите время на даче, на рыбалке или в поездке на Байкал или Камчатку и с вами консультируются, как лучше поступить в том или ином случае и просят посидеть на том или ином митинге, чтобы послушать, что говорят и потом высказать свое мнение.
Вечерами, когда внуки ложатся спать, вы. конечно, открываете Lisp, Haskell, Smalltalk и делаете очередной, архитектурно выверенный код, идеально декомпозированный, легко читаемый… Но с утра, внуки вновь будут теребить на речку, надо газонокосилку посмотреть, да сосед просил с компом его разобраться, а чачу он делает шикарную. Соседка опять таки же… Мягко закрывается крышка ноута, шлепки, ворчание собаки…
Есть три стадии карьеры мудрого разработчика.
— Если вам от 20 до 30: вы пилите проект, иногда не спя ночами. И учитесь, учитесь, учитесь. Вас не ценят, ибо таких как вы — сотни.
— От 30 до 45 — потихонечку переползаете в область мидлов и сеньоров. Тут как хватит наследсвенности и своего ума. Появляется опыт в разработке, но это фигня. Самое главное, — вы начинаете разбираться в командной работе, у вас формируется понимания: как работает организация, разрабатывающая софт; как работает бизнес заказчиков. И вас начинают ценить не за то, что вы офигительно программируете (или вообще не умееете), а за то, что вы умеете поставить процесс, разделить зоны ответственности, создать спецификации протоколов, API и т.п. и просто организовать бестолковых юниоров и добиться от них полезной работы.
от 45… Тут вершина умного и мудрого разработчика. Вам просто платят денег за то что вы есть в штате компании. Иногда вы, конечно, выдаете идеи как обустроить рабфак и даже пишете код.
Но, в целом, вы обычно проводите время на даче, на рыбалке или в поездке на Байкал или Камчатку и с вами консультируются, как лучше поступить в том или ином случае и просят посидеть на том или ином митинге, чтобы послушать, что говорят и потом высказать свое мнение.
Вечерами, когда внуки ложатся спать, вы. конечно, открываете Lisp, Haskell, Smalltalk и делаете очередной, архитектурно выверенный код, идеально декомпозированный, легко читаемый… Но с утра, внуки вновь будут теребить на речку, надо газонокосилку посмотреть, да сосед просил с компом его разобраться, а чачу он делает шикарную. Соседка опять таки же… Мягко закрывается крышка ноута, шлепки, ворчание собаки…
> от 45… Тут вершина умного и мудрого разработчика. Вам просто платят денег за то что вы есть в штате компании. Но, в целом, вы обычно проводите время на даче, на рыбалке или в поездке на Байкал или Камчатку
нет. вы ошибаетесь. в жизни так не бывает. только в сказке
нет. вы ошибаетесь. в жизни так не бывает. только в сказке
Я к тому, что не все после 45 будут в таком дзене находятся. Третьей ступени достигают единицы. Большинство остается на второй ступени. Так как не все хотят, не все умеют, не всем дано.
Согласен, что многие после 45 достигают такой «ступени». Проект они свой знают, все могут быстро и хорошо сделать и все супер. До поры пока не придется искать новую работу, а это может случиться по независящим от них причинам. И потом они выясняют что рынок то уже давно ждет от соискателей другого и никого не волнует их прошлый опыт в какой-то там системе в которой он хорошо разбирается.
И вот тут начинаются все эти стоны и плачи… А надо просто понимать что индустрия у нас такая, требует она себя держать в форме постоянно.
И вот тут начинаются все эти стоны и плачи… А надо просто понимать что индустрия у нас такая, требует она себя держать в форме постоянно.
Э-э-э, так корову не продашь…
Свидетельство, маркер, если хотите, что разработчик близок к третьей ступени в своей карьере это то, что он больше на работу не устраивается. Он переходит из компании в компанию потому что его приглашают поработать. И приглашает не эйчары, а ключевой игрок. Например, в компании «БыстроЧисто» тим-лид всей разработки говорит, что есть знакомый Иван Иванович, который дельный дядька и его бы пригласить разобрать наши авгиевы конюшни и он это сделает. Эйчаров только ставят в известность, что в штат приходит новый человек и не надо до него докапываться.
Рынок ждет другого технологического стека, тут быстрая эволюция и надо быстро бежать, чтобы остаться на месте. А вопросы организации людей и процессов — вечны.
Разработчик в на третьей стадии, это Мистер Вульф из «Криминального чтива». Он смотрит на проблемы работы команды и дает ценные советы по их решению и присматривает, чтобы сеньоры следовали его советам.
Свидетельство, маркер, если хотите, что разработчик близок к третьей ступени в своей карьере это то, что он больше на работу не устраивается. Он переходит из компании в компанию потому что его приглашают поработать. И приглашает не эйчары, а ключевой игрок. Например, в компании «БыстроЧисто» тим-лид всей разработки говорит, что есть знакомый Иван Иванович, который дельный дядька и его бы пригласить разобрать наши авгиевы конюшни и он это сделает. Эйчаров только ставят в известность, что в штат приходит новый человек и не надо до него докапываться.
Рынок ждет другого технологического стека, тут быстрая эволюция и надо быстро бежать, чтобы остаться на месте. А вопросы организации людей и процессов — вечны.
Разработчик в на третьей стадии, это Мистер Вульф из «Криминального чтива». Он смотрит на проблемы работы команды и дает ценные советы по их решению и присматривает, чтобы сеньоры следовали его советам.
сказки хороши на ночь… В реальной жизни все бывает проще, закроют компанию и надо будет этому крутейшему разработчику искать работу срочно и не факт что у всех его друзей будут вакансии.
:) Возможно, еще будет время когда вы увидете путь к третьей ступени жиненного пути разработчика ). Удачи!
сколько снисхожденья :) прежде чем давать советы кому-либо надо бы понять сперва а насколько они ему необходимы. Я понимаю что хочется показать всем какой вы крутой, но не надо самоутверджаться за чужой счет. А то может оказаться что собеседник уже давно прошел эту третью ступень и уже далеко впереди ;)
> Он переходит из компании в компанию потому что его приглашают поработать.
в сентябре 2008 года в результате самого большого банкротства в истории на улице оказалось 80.000 сотрудников банка Lehman Brothers в том числе программисты третьего уровня и супер-пупер архитекторы. и не всем потом повезло в новой компании — банке конкуренте Barclays или Nomura достичь тех же высот — так как там своих таких же архитекторов третьего уровня было. а тут за дешево удалось прикупить классных программистов готовых за еду работать.
в сентябре 2008 года в результате самого большого банкротства в истории на улице оказалось 80.000 сотрудников банка Lehman Brothers в том числе программисты третьего уровня и супер-пупер архитекторы. и не всем потом повезло в новой компании — банке конкуренте Barclays или Nomura достичь тех же высот — так как там своих таких же архитекторов третьего уровня было. а тут за дешево удалось прикупить классных программистов готовых за еду работать.
Это про доктора Комаровского?
Вы прочитали фанфик на тему "вот я вырасту и уж точно классным стану". Действительно, ведь основной признак, определяющий уровень разработчика — это его возраст, поэтому даже не думайте переползать в миддлы до 30.
Ну и конечно, вы только немного потерпите, а там позврослеете и как станете ого-го. А там уже ещё немного потерпеть и в рай, уж там-то точно будет хорошо.
Что делать если до 30 еще 3 года, а ты уже нечаянно начал разбираться в командной работе и… и теперь жутко горит когда видишь очевидные вещи, которые никто никогда не станет слушать так как нос не дорос :(
Тут постом выше проехались на тему «почему возраст определяет ступени в карьере».
Хороший разработчик, посмотрев мельком на код, может сразу сказать какие паттерны разработки (и банды 4-х тоже) можно применить в коде и какие уже применены. Так и для команды людей на третьей стадии сразу видит паттерны в работе людей, команды.
Неважно разработчик вы или пекарь, медик. Какие паттерны уже используются, какие можно применить и, самое главное, какие применять не надо. И этому, сидя ночами за компом, не научиться. Только живое общение с коллегами.
Если вы уже видите паттерны в работе команды — вы умница. Я этому научился сильно позже вас и до сих пор не всегда хорошо вижу. Но я на третью ступень и не претендую.
В целом, лучше это считать фанфиком. Меньше вопросов будет :)neg
Хороший разработчик, посмотрев мельком на код, может сразу сказать какие паттерны разработки (и банды 4-х тоже) можно применить в коде и какие уже применены. Так и для команды людей на третьей стадии сразу видит паттерны в работе людей, команды.
Неважно разработчик вы или пекарь, медик. Какие паттерны уже используются, какие можно применить и, самое главное, какие применять не надо. И этому, сидя ночами за компом, не научиться. Только живое общение с коллегами.
Если вы уже видите паттерны в работе команды — вы умница. Я этому научился сильно позже вас и до сих пор не всегда хорошо вижу. Но я на третью ступень и не претендую.
В целом, лучше это считать фанфиком. Меньше вопросов будет :)neg
Превращение в старейшину программирования (мне такой титул нравится больше, чем «старый программист»)
Кстати, действительно отличный титул, с удовольствием носил бы такой.
«Сегодня на совете старейшин было решено начать проект по переписыванию нашей кодовой базы на актуальный PHP 5.2 и попросить кого-нибудь из джунов рассказать что это за загадочный ка-восемь-эс как доллар, о котором говорят все дети в песочнице. Так же мы переименовываем вакансию заправлятеля картриджей для принтера в дево-пса, потому что во-первых так смешнее, во-вторых, говорят, молодежь на это ведется»
работа со средой сборки, контроль версий
Раньше такие вещи просто подразумевались. Неужели все настолько деградировало? Хотя, это же юзеры фреймворков…
Docker, AWS, Azure
Оно все простое, как палка — даже фронтэндщик осилит. Да, а докер таки не нужен, и пора бы ему уже на свалку.
Хорошая статья, хороший перевод. Есть над чем задуматься.
Но, мне кажется, страх перед «старостью» обычно разбивается о собственно развитие жизни — подходят годы, ты когда то переживал за них, а ничего… работаешь, изучаешь, как то живешь.
Но, мне кажется, страх перед «старостью» обычно разбивается о собственно развитие жизни — подходят годы, ты когда то переживал за них, а ничего… работаешь, изучаешь, как то живешь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я вдруг осознал, что я – старый программист