Size: a a a

2018 September 30

K

Koote in Alprog I/O
Здраствуйте. Направьте пожалуйста. Я уже год работаю над проектом и имею столько же опыта в пайтоне. Подскажите как из джуна вырости в мидла и как это определить самому?
источник

K

Koote in Alprog I/O
From Jun to The Moon кароче)
источник

P

Pavel in Alprog I/O
Koote
Здраствуйте. Направьте пожалуйста. Я уже год работаю над проектом и имею столько же опыта в пайтоне. Подскажите как из джуна вырости в мидла и как это определить самому?
пока не подошел кто-то поумнее, выскажу свое IMHO
1) многие люди понимают эти уровни (джуниор, мидл, ...) по своему, так что оценка может быть субъективной и одного и того же человека в одной компании могут назвать джуниором, в другой миддлом. Кроме того, обычно на конкретном месте работы нужны знания определенных технологий. То есть, если человек, который пять лет профессионально пишет игры придет делать Web, то то как он себя оценивает в gamedev не будет особенно применимо на новом месте. В реальности перемены обычно не такие кардинальные, но они почти всегда есть.
То есть я как бы намекаю "А сильно ли это важно знать?"

2) Есть много разных статей, которые описывают разницу между разными уровнями разработчика (например вот эта неплохая: http://sijinjoseph.com/programmer-competency-matrix/), но все эти статьи основываются на опыте (и уровне) конкретного автора и для любой из таких статей найдется большое количество несогласных.

Я лично бы разделил описанные два уровня следующим образом:

джуниор
- способен решать простые задачи, но при решении нетривиальных задач могут возникать трудности
- так как не имеет опыта, не может представить как архитектурные решения, написанные сейчас, могут повлиять на систему по ходу ее развития
- плохо знает паттерны используемые в своей области и часто прибегает к антипаттернам и велосипедам если самостоятельно пишет подсистемы
- то есть может писать код, но не может отличить хороший код от плохого

миддл
- успешно решает сложные задачи, способен довольно точно оценить время необходимое на решение задачи
- способен оценить последствия применения многих архитектурных решений и может объяснить почему он выбрал то или иное решение
- знает наиболее используемые подходы к разработке, паттерны и архитектурные решения, используемые в своей области, знает их сильные и слабые стороны
- уверенно пользуется необходимыми в работе инструментами (система контроля версий, отладчик, ...)
источник

K

Koote in Alprog I/O
Pavel
пока не подошел кто-то поумнее, выскажу свое IMHO
1) многие люди понимают эти уровни (джуниор, мидл, ...) по своему, так что оценка может быть субъективной и одного и того же человека в одной компании могут назвать джуниором, в другой миддлом. Кроме того, обычно на конкретном месте работы нужны знания определенных технологий. То есть, если человек, который пять лет профессионально пишет игры придет делать Web, то то как он себя оценивает в gamedev не будет особенно применимо на новом месте. В реальности перемены обычно не такие кардинальные, но они почти всегда есть.
То есть я как бы намекаю "А сильно ли это важно знать?"

2) Есть много разных статей, которые описывают разницу между разными уровнями разработчика (например вот эта неплохая: http://sijinjoseph.com/programmer-competency-matrix/), но все эти статьи основываются на опыте (и уровне) конкретного автора и для любой из таких статей найдется большое количество несогласных.

Я лично бы разделил описанные два уровня следующим образом:

джуниор
- способен решать простые задачи, но при решении нетривиальных задач могут возникать трудности
- так как не имеет опыта, не может представить как архитектурные решения, написанные сейчас, могут повлиять на систему по ходу ее развития
- плохо знает паттерны используемые в своей области и часто прибегает к антипаттернам и велосипедам если самостоятельно пишет подсистемы
- то есть может писать код, но не может отличить хороший код от плохого

миддл
- успешно решает сложные задачи, способен довольно точно оценить время необходимое на решение задачи
- способен оценить последствия применения многих архитектурных решений и может объяснить почему он выбрал то или иное решение
- знает наиболее используемые подходы к разработке, паттерны и архитектурные решения, используемые в своей области, знает их сильные и слабые стороны
- уверенно пользуется необходимыми в работе инструментами (система контроля версий, отладчик, ...)
Огромное пасибо
источник

K

Koote in Alprog I/O
источник

АТ

Александр Тужик in Alprog I/O
Koote
Здраствуйте. Направьте пожалуйста. Я уже год работаю над проектом и имею столько же опыта в пайтоне. Подскажите как из джуна вырости в мидла и как это определить самому?
Выше правильно сказали: деление очень условное.
Джуниор — начинающиий, тот, за кем надо присматривать, обучать и направлять.
Мидл — самостоятельный боец, способный решать большинство задач.
Сеньор — ветеран, человек, с которым советуются и просят помощи в сложных ситуациях. Также некоторые сеньоры занимаются архитектурой проекта и/или распределением задач среди остальных программистов.

Обычно подобная иерархия образуется в компаниях сама собой естественным образом. К примеру, два человека работает в компании более 10 лет, пятеро от 3 до 6 лет и ещё есть трое студентов, которые только что пришли. Как выстроятся отношения и распределяться роли между сотрудниками в этом случае, думаю, очевидно.

Некоторые компании закрепляют эти отношения в виде должностей и указывают соответствующий уровень в вакансиях. Как правило, проработав где-нибудь 2-3 года, человек способен пройти собеседование на позицию мидла в большинство компаний из той же сферы. В этот момент уместно сказать, что человек перестал быть джуном объективно.

Граница между мидлом и сеньором более расплывчата. Это связано с тем, что количество сеньорских мест в компаниях ограничено, и эту роль обычно выполняют те, кто дольше работает в компании и заслужил больше доверия у начальства. Таким образом, перейдя из компании в компанию, даже имея больше опыта, человек вряд ли сразу получит сеньорскую должность. То есть ему вряд ли сразу доверят архитектуру и стратегические решения, что довольно логично. Но если он в принципе мог бы потянуть эти задачи, то, наверное, можно говорить, что этот человек сеньор по скиллам. И соответствующем образом позиционировать себя в резюме.
источник

K

Koote in Alprog I/O
То есть если я целый год пишу CRM, сам ее в одно лицо разрабатываю, придумываю архитектуру но при этом только вот прихожу к паттернам и ооп, пишу кучу велосипедов, стреляю себе в ноги то я типо джун?
источник

K

Koote in Alprog I/O
при этом даю таски фронтендеру, ибо через пол года думаю сваливать как проект допишу а честно не знаю как себя позиционировать
источник

K

Koote in Alprog I/O
то есть у меня за год набрался неплохой стек который я знаю чуть более среднего
источник

K

Koote in Alprog I/O
но при этом дикие пробелы в паттернах, структурах данных, алгоритмах
источник

K

Koote in Alprog I/O
было дело даже либо приходилось под себя дописывать
источник

АТ

Александр Тужик in Alprog I/O
Одному работать на старте карьеры довольно плохая идея. В коллективе более опытные товарищи подскажут/направят/предостерегут от ошибок. К тому же будет легче понять, где ты по знаниям относительно них. А когда ты работаешь один, никто не знает, чего ты там понаписал за год. Может ты на самообучнии развился так, что теперь дашь фору любому мидлу, а может там бред и говнокод. Пока не покажешь код кому-то опытному или не попробуешь пройти собеседование куда-нибудь, оценить твой уровень сложно.
источник

K

Koote in Alprog I/O
ну я работал месяц в конторе помимо этой работы
источник

K

Koote in Alprog I/O
на код говорили что норм
источник

K

Koote in Alprog I/O
относительно тех людей то там мидлы в 19 лет с 6 годами опыта)
источник

K

Koote in Alprog I/O
Александр Тужик
Одному работать на старте карьеры довольно плохая идея. В коллективе более опытные товарищи подскажут/направят/предостерегут от ошибок. К тому же будет легче понять, где ты по знаниям относительно них. А когда ты работаешь один, никто не знает, чего ты там понаписал за год. Может ты на самообучнии развился так, что теперь дашь фору любому мидлу, а может там бред и говнокод. Пока не покажешь код кому-то опытному или не попробуешь пройти собеседование куда-нибудь, оценить твой уровень сложно.
тут я согласен с вами конечно, стоит походить на собеседования
источник

АТ

Александр Тужик in Alprog I/O
Koote
относительно тех людей то там мидлы в 19 лет с 6 годами опыта)
Есть такой мем «23-летние сеньоры». Означает мамкиных сеньоров, которые никакие не сеньоры на самом деле, а просто не работали на нормальных проектах. Мидл в 19 лет это тоже что-то из этой оперы. Я в 19 был совсем зелёный джун. Это при том, что программирую любительски с 12. Только это стажем не считается.
источник

K

Koote in Alprog I/O
Александр Тужик
Есть такой мем «23-летние сеньоры». Означает мамкиных сеньоров, которые никакие не сеньоры на самом деле, а просто не работали на нормальных проектах. Мидл в 19 лет это тоже что-то из этой оперы. Я в 19 был совсем зелёный джун. Это при том, что программирую любительски с 12. Только это стажем не считается.
слышал но я например знаю действительно сильных программистов которым по 23 года.
источник

АТ

Александр Тужик in Alprog I/O
А почему ты решил, что они сильные?
источник

АТ

Александр Тужик in Alprog I/O
Скорее всего просто эффект Даннинга-Крюгера в действии.
источник