Чем отличается работа джуниора от синьора

Чем отличается работа джуниора от синьора? Отчасти ответ на этот вопрос помогает определить, кто такие джуниоры и чем они отличаются от синьор-программистов. Мне приходилось начинать свою карьеру с самого начала дважды – первый раз в 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. Джуниорам дают задачи, в которых нужно делать все и даже если они не знают данную область – это отличный способ познакомится с ней. Синьоры работают наравне с джуниорами и в случае необходимости выполняют роль менторов. 

Как ты понимаешь, конечно же лучше попасть в компанию второго типа, если ты джуниор, быстрее можно вырасти и получить на работе доступ к мозгам, которые будут подсказывать и учить бесплатно, а компания еще и платит за это. 

С точки зрения синьора интереснее работать наверно в первого типа компаниях, потому что тут все нудные задачи можно сбрасывать на более слабых программистов и заниматься чем-то интересным. Я нормально отношусь к тому, что приходится заниматься всем – и простыми и сложными вещами, такие переключения между задачами помогают не выгорать. 



Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание

Комментарии

Паника, что-то случилось!!! Ничего не найдено в комментариях. Срочно нужно что-то добавить, чтобы это место не оставалось пустым.

Добавить Комментарий

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповедания, на русском или английском языке.

Пишите мне