Чем отличается работа джуниора от синьора? Отчасти ответ на этот вопрос помогает определить, кто такие джуниоры и чем они отличаются от синьор-программистов. Мне приходилось начинать свою карьеру с самого начала дважды – первый раз в 90-е годы, когда я впервые знакомился с программированием и второй раз уже в 2009-м году, когда переехал в Канаду сразу после кризиса.
С точки зрения выполняемых задач начинающие программисты и синьор программисты очень часто делают примерно одни и те же задачи. У меня почти ничего не менялось с точки зрения отношения должности к обязанностям. Сейчас на работе примерно та же идея в отношении джуниор программистов, потому что требования к ним достаточно высокие.
У нас на работе интерны могут тупить, писать не самый идеальный код и по своей должности они не знают проект. Интерны – это студенты, которых мы берем на несколько месяцев, чтобы они получили практику. Компания платит им какие-то деньги и какие именно я не знаю, но что-то точно платят. Так как они приходят на несколько месяцев, сильно глубокие знания проекта им не нужны. Так как они еще студенты, знания обычно у интернов неплохие, но все же они студенты.
Это чтобы вы понимали, что ниже джуниоров на работе могут быть еще интерны и вот к ним практически никаких требований. Джуниоры – это все же уже полноценные программисты, которые закончили институт и/или имеют хоть какой-то опыт работы. Образование в Канаде желательно, но не является необходимым.
В разных компаниях разные градации, но обязанности практически одни и те же – писать код. Отложить в сторону редактор кода на работе могут себе позволить уже более старшие позиции, типа менеджеров, а все, что ниже всегда пишут код.
Не могу говорить за все компании в США или Канаде, но скажу за те, где я работал и с кем я работал.
В России у меня не было должностей, просто программист и все. В Канаде я начал с самых низов простого программиста и побывал на таких должностях как Software Developer. Senior Software Developer, Team Lead, Technical Architect, Solution Architect, снова Senior Software Developer, Lead Developer. И кем бы я ни был – всегда писал код.
Когда я вырос до Technical Architect единственное, что добавилось – совещания с клиентом раз в три месяца, когда менеджмент приезжал в офис и мы обсуждали будущие проекты и думали о том, как их реализовывать и оценивали время на разработку методом – пальцем в небо. Тут не нужно было давать точные оценки, просто сказать – эта работа легкая, можно сделать за пару дней, а эта сложная, займет пару месяцев. Тогда я еще не знал о скраме и даже не слышал о нем, но уже использовал метод оценки размера проекта, что часто называют sizing. В зависимости от размера и важности клиент решал – это сделаем сейчас, а это потом.
Собирать всю команду ради сайзинга в консалтинговой компании мало кто решиться. Обычно тут сайзинг делают архитекторы, потому что они по своей должны знать, на сколько сложный проект и они должны знать лучше простых программистов.
Когда решение принято, вот тогда уже происходила более детальная оценка, которую делал программист, даже программисты с простой должностью Software Developer делали оценку.
Остальное время я писал код и реализовывал проекты, которые уже утвердили. Каждый день код и только код.
То же самое было и с другими компаниями, с которыми я сталкивался. Было как-то совещание с очень крупной ИТ компанией, и мы обсуждали проект, а там архитектор оказался тоже русскоговорящий парень с Прибалтики (не помню точно Латвия или Литва) и заговорили о том, чем он занимаемся, и он тоже пишет код. Правда у них есть деление на то, кто какой код пишет. Когда ты архитектор, то вроде бы должен писать поверхностно решение, а потом отдавать его менее квалифицированным программистам и контролировать процесс. То есть там все пишут код, но задачи все же варьируются от того, какая у тебя должность – простой программист, синьор-программист или архитектор. В какой-то степени это верно, потому что от каждого по возможностям можно получить максимальный эффект.
Я так понял, что в этой компании работают по-разному и эта команда была не самой показательной, но все же.
Я считаю такой подход не самым лучшим, потому что более продвинутые программисты занимаются более серьезными вещами и не отвлекаются на такие банальные и однотипные вещи. Для опытных программистов это реально большой полюс, но вот для начинающих – им приходиться заниматься банальными вещами и меньше пространства для роста на работе, нужно что-то учить и пробовать дома.
Есть такое мнение, что компании платят деньги не за то, чтобы программисты учились на работе, а чтобы они писали код. Все обучение должно быть в свободное время. А как узнать, научился джуниор уже на столько, чтобы брать на себя более сложные задачи?
В компаниях, где я работал, проекты обычно даются программистам под ключ, чтобы они писали весь код, и программисты с должностью Software Developers пишут не только HTML или JS, но и C# от А до Я – включая бизнес логику. Конечно же на первых порах все пытаются давать таким программистам проекты попроще, за счет работы над всем проектом от начала до конца они растут очень быстр в профессиональном плане и с точки зрения опыта и знаний.
Если джуниор застревает, то тут всегда есть синьор-программисты или просто более опытный коллега, который всегда готов помочь. В какой-то степени получается, что у джуниоров всегда есть ментор по мере необходимости.
Я уже несколько раз говорил, что у нас в команде грань между простым программистом и синьором очень тонкая. Если человек обладает лидерскими качествами, берет на себя ответственность, начинает тянуть проекты и помогать одновременно другим, то он становится реальным кандидатом на Синьора.
Так что из личного опыта мне приходилось встречаться с двумя типами команд:
1. Джуниорам дают работу проще, синьоры берут на себя более сложные задачи и банальный кодинг сбрасывают на более слабых программистов. Как я уже сказал, в таких командах страдает развитие джуниоров, потому что большую часть времени они работают кодерами и выполняют задачи, которые и так умеют делать.
2. Джуниорам дают задачи, в которых нужно делать все и даже если они не знают данную область – это отличный способ познакомится с ней. Синьоры работают наравне с джуниорами и в случае необходимости выполняют роль менторов.
Как ты понимаешь, конечно же лучше попасть в компанию второго типа, если ты джуниор, быстрее можно вырасти и получить на работе доступ к мозгам, которые будут подсказывать и учить бесплатно, а компания еще и платит за это.
С точки зрения синьора интереснее работать наверно в первого типа компаниях, потому что тут все нудные задачи можно сбрасывать на более слабых программистов и заниматься чем-то интересным. Я нормально отношусь к тому, что приходится заниматься всем – и простыми и сложными вещами, такие переключения между задачами помогают не выгорать.
Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание
Паника, что-то случилось!!! Ничего не найдено в комментариях. Срочно нужно что-то добавить, чтобы это место не оставалось пустым.
Добавить Комментарий