Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Як розвиватись технічно для Senior і вище інженерів?

Існує мільйони тем, курсів та іншого на тему «вайтіВайті», «яку мову програмування обрати», «Куди — QA чи Dev», «c++ за 21 день»

А як розвиваються в технічному напрямку інженери які сініори і вище, котрі не хочуть йти в менеджери?

LinkedIn

Лучшие комментарии пропустить

Выше Senior Software Engineer уже невозможно развиваться только технически.
Можно оставаясь Senior глубоко специализироваться и стать экспертом в отдельной технологии (например ML или computer vision). Это не дает новых «лычек», но дает возможность работать над задачами только по «своей» технологии, зато в нескольких проектах сразу. Так же можно брать доплату за консультации «на стороне».
Следующая ступень — это Lead Software Engineer или Tech Lead. Это значит — ведущий инженер, у которого в подчинении обычные инженеры (в том числе Senior). На этой позиции уже нужно не только педалить самому но и правильно распределять и координировать работу других. Обычно Lead разрабатывает архитектуру проекта, бьет на модули и делает ревью имплементации этих модулей. Лично участвует только в написании самых сложных кусков кода (имплементация алгоритмов). Углубленно изучает те технологии, которые используются на проекте.
Дальше уже идут ступени, на которых девелопер во-первых перестает работать над одним и тем же проектом. Во-вторых пишет все меньше кода и все больше «работает языком».
Различные Architect позиции (Software Architect, Big Data Architect, Solution Architect, Cloud Architect, Blockchain Architect и т.д.). Архитект — это больше про выбор технологий, выбор высоко-уровневой архитектуры (на уровне «квадратиков»), решений какой софт покупать а что писать самим... Но самое главное — архитект это уже про коммуникацию. Нужно уметь «продать» свои решения клиенту, менеджерам, команде разработчиков и т.д. И это про командировки к клиенту, к топ-менеджерам, на конференции, к распределенной команде. Чаще всего архитект работает на старте проекта. Когда проект уже стартанул, «скелет» архитектуры написан и команды вышла на стабильный режим — он только иногда проверяет что бы не ломали архитектуру и не накапливали технический долг. Поэтому один архитект ведет либо один очень большой проект с несколькими командами, либо много небольших.
dou.ua/...​rticles/how-i-work-boyko
Дальше идет CTO — это architect уже на уровне всей компании. Помимо проектов ему уже нужно решать о стратегии компании в целом: какие технологии потребуются завтра, какие методики разработки внедрять, какие проекты лучше НЕ брать (например сапорт старья), имеет ли смысл пытаться сделать какой-то свой продукт или работать только на заказ, какие прототипы имеет смысл написать что бы показать на конференциях и т.д. Полностью расписано тут:
dou.ua/...​ta/articles/cto-position
Вывод, который я сделал для себя: мой потолок — это Lead Software Engineer. Выше уже надо больше работать с людьми, чем с кодом, нужно уметь «лизать микрофон», нужно уговаривать и договариваться, нужно летать (!) в командировки, нужно рулить бюджетом (а я не люблю считать деньги) ... При этом нету четких критериев успеха: нельзя сказать что вот этот проект — мое «детище» и я сделал его идеально. На этом уровне перфекционистом уже быть не получится — когда код писал не сам, то идеальным он не получится.
Периодически мне приходит мысль «спекаться» в какую-то узкую область. Но это достаточно рискованный путь: на галере не всегда появляются такие задачи, в итоге потратив 80% времени на глубокое изучение, например, алгоритмов и технологий распознавания образов, по факту таких задач у тебя будет 20%. А 80% ты будешь чинить баги в жабаскрипте, как все остальные девелоперы.
Что бы быть настоящим экспертом — нужно работать консультантом, а значит — переходить на фриланс. Тогда можно будет выбирать задачи именно по своей специализации. Но для фриланса сначала придется набить себе «репу» и сделать пару пет-проектов что бы доказать что ты действительно эксперт. И далеко не факт что твоя специализация будет оставаться модной много лет. Завтра вместо блокчеина модным станет какая-нибудь квантовая криптография и все — придется переучиваться.

Блін чувак тіки шо побачив шо ти QA.

Для тебе очевидний розвиток це стати девелопером. QA та автоматизатори це добре корисно та цікаво але весь шум роблять девелопери та більше цінуються девелопери. Проект можна зробити без QA але не можна без девелопера.

Тому кидай своє тестування та йди на курси розробників.

Логічне питання шо далі робити розробнику? Приходь через 5 років сюди відповімо.

Я считаю что нужно стартапить, это хорошее развитие в качество а не в колличество
Ты как дев РОС мвп можешь клепать пачками, когда то да выстрелит, и новый опыт получишь, когда надо думать о целом продукте, даже если это пруф

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Я рекомендую смотреть видео, например с конференции GOTO www.youtube.com/...​er/GotoConferences/videos

Не факт, что синьор знает свою работу так детально, как это подразумевается. Надо открывать капот и лезть в мотор.

Мы привыкли большинство сложных вещей воспринимать просто и использовать бездумно. Если в начале обучения копать сразу вглубь — каждая новая кучка песка (мусор) будет вызывать раздражение. А вот если начать копать во взрослом состоянии, когда уже умеешь отличать мусор от золотоносной руды — ...

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

Главное умение синьер разработчика — уметь себя продать.

Це головний скіл взагалі будь-кого.

Главное достижение в жизни — продать себя максимально дорого... упс — продано!

Блін чувак тіки шо побачив шо ти QA.

Для тебе очевидний розвиток це стати девелопером. QA та автоматизатори це добре корисно та цікаво але весь шум роблять девелопери та більше цінуються девелопери. Проект можна зробити без QA але не можна без девелопера.

Тому кидай своє тестування та йди на курси розробників.

Логічне питання шо далі робити розробнику? Приходь через 5 років сюди відповімо.

Смотри в чем проблема такого перехода. У человека скорее всего 5+ лет опыта и 3к+ з.п. Еще минимум год-два никто ему столько денег не даст как девелоперу, что и справедливо.
Мне пару раз предлагали переход из QA в Dev, но было слишком поздно, т.к. деградация в з.п.
Т.е. это имеет смысл только в первые пару лет, пока нечего терять.
А кто там шум делает не суть важно, для скилловых QA есть з.п. даже на уровне дев архитекторов.

Мне пару раз предлагали переход из QA в Dev, но было слишком поздно, т.к. деградация в з.п.

Лол ну і сидіть в дупі та пишіть на доу топіки «куди розвиватися».

Еще минимум год-два никто ему столько денег не даст как девелоперу, что и справедливо.

Типова логіка «хапай і біжи» та нездатність думати на перспективу.

Давайте визнаємо шо QA це QA і вони не будуть мати такі перспективи як девелопери як би вам не хотілося говорити про зворотнє.

для скилловых QA есть з.п. даже на уровне дев архитекторов

))))

Чувак який був толковим QA а потім прокачався до крутого девелоперу нанесе проекту значно більше користі ніж просто окремо QA або просто окремо девелопер. Люди на межі компетенцій цінуються.

Лол ну і сидіть в дупі

Чувак, возможно это ты сидишь «в дупі» если у тебя такие ограниченные взгляды.
QA граничит со множеством специализаций: Product management/BA/UX, Ops/DevOps, Security etc. Плюс само по себе QA — это не только мануальное тестирование и автотесты на селениуме.
Оно включает множество направлений: несколько разновидностей аналитики, менеджмента, автоматизация на разных уровнях, перфоменс, пентестинг, архитектура.
Ниже я написал что изучение смежных специальностей и есть очень эффективный способ повысить свою квалификацию и получить хорошую отдачу, в т.ч. материальную. Для этого не нужно уходить из QA.

по себе QA — это не только мануальное тестирование и автотесты на селениуме.

)))))))

Сидіть далі в своєму манямірку. Хто на ринку топчик? Девелопер! Кого шукають рекрутери? Девелопера! Хто пише сотні гавнокода для аплікейшенів якими ви користуєтеся? Девелопер!

Хто це все продає? Підприємець та продажник!

Отакий ланцюжок. QA в цій схемі не обов’язковий.

Сидіть далі в своєму манямірку. Хто на ринку топчик? Девелопер!
QA в цій схемі не обов’язковий.

Вот это и называется ограниченность)
QA нужен для определенного уровня качества продукта. Если проект беден и не может позволить себе QA — ничего страшного, мы с удовольствием идем на крутые проекты, которые понимают значение качества и вкладываются в него.
Само качество — оно многогранно, это не просто «сделать как написано в спеке». QA тестируют в том числе требования, процессы и множество других вещей. Я выше уже написал все разнообразие задач. Можешь перечитать и попробовать расширить кругозор.

Вот это и называется ограниченность)

хаха дядь я знаю шо таке куа, я працював в ентерпрайзі де куа все роблять по методам, трейсабіліті матриці, северіті пріоріті, їхав ексель через ексель і тд і тп сидять дівчатка нажимають кнопки та пишуть автотести а хлопчики пишуть фреймворки для автотестів а потім девелоперів дрючать за баги.

Тільки ти не дуже зрозумів що я хотів сказати.

QA — це обслуговуючий клас. Так само як девопси, просто опси, дівчинка на ресепшені та сисадмін який тобі мережу в офісі проводить.
QA — не творці. Творці — це підприємці які пхають то все вперед, продакт менеджери які придумують як пофарбувати кнопки, бізнес аналісти, дизайнери та девелопери. А всі інші просто їх обслуговють.

Це гірка правда але воно так і є як би вам не хотілося думати.

От завів ти багу а далі шо?)))) А далі нічо, сидиш і чекаєш поки девелопер пофіксить. А він не пофіксить тому що в бізнеса інші задачі. І до сраки те шо ти там клікав та пентести робив і стратегію тестування сидів два дні писав а потім топ менеджерам презентував, нам фічі треба х*ярити і гроші заробляти а не звіти тестувальників дрочити.

А девелопер може все пофіксити. Може все зробити. Пушо девелопер це кріейтор, це творець, це ремісник який є*ашить глиняні миски власноруч.

А QA тіки ходять і шатнгенциркулями міряють чи миска рівна чи крива, строчать звіти і придумують автоматичні лазерні вимірювачі рівності мисок.

Сорян, але такі справи. Все профессии нужны все профессии важны але деякі важливіші інших.

хаха дядь я знаю шо таке куа, я працював в ентерпрайзі де куа все роблять по методам, трейсабіліті матриці, северіті пріоріті, їхав ексель через ексель
От завів ти багу а далі шо?

Вот ты претендуешь на какой-то уровень, называешь себя инфлюенсером, что само по себе смешно, конечно.
И тут же палишься насколько незрел в целостном понимании процесса создания софта (не кодинга, как ты можешь подумать). Тут тебе фору даст даже миддл QA, а твоя логика заканчивает работать на уровне мелких проектов, которые можно сделать в одиночку и все будет худо-бедно работать.
Чем серьезней проект тем важнее все остальное что окружает девелопмент.
Ты можешь пилить свой кусочек энтерпрайза и не видеть всей картины, а QA ее видит и здесь уже от него и от другой «прислуги» (BA, релиз и деливери менеджеров, оперейшнзов и других) зависит успех проекта. Чтобы это осилить нужно самому поработать какое-то время в этих ролях. Но чтобы понять важность этого достаточно быть просто адекватным синьором. Ты, видимо, еще не достиг этого уровня (

Вот ты претендуешь на какой-то уровень, называешь себя инфлюенсером, что само по себе смешно, конечно.

дадада дядь, про таких як ти в мене скоро буде пост називається «Старшокласники в дитсадку» дописуйся читай скоро-скоро буде )))))

Чем серьезней проект тем важнее все остальное что окружает девелопмент.

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

Ты, видимо, еще не достиг этого уровня (

дада дядь, куда мені до тебе )))))

Ти ж не знаєш де я працював, а в мене були проекти на пару років та команду в 30 людей в тому числі серед яких куа лід з купкою тестувальників та автоматизаторів були і я то все менеджив )))) Зараз правда підуть аргументи що я працював в неправильних дрібних проектах і шо я нічо не шарю а от у нас в галері на дві сотні гребців ти би зрозумів шо «нє достіг уровня», ну-ну )))))

Тіки ти зовсім не зрозумів що я хотів скзавати )))

Ты, видимо, еще не достиг этого уровня (

«Мне жаль Вас» ага, класний аргумент, давно вже такого не чув ))) Пильнуй свій рівень а за мій не переживай ))))

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

Собственно, все — твой уровень понимания и недостаток адекватности видны из комментов.

дададада дядь, я нічо не розумію бо ще малий а ти — типовий старшокласник у дитсадку ))))) на забудь дописатися на канал, нас вже 2700 )))))

і на ютуб теж дописуйся скоро буду відоси робити ))))

pikabu.ru

)))))))))))))))))))))))))))

девопси ... — то все обслуга

Ну-ну... И кого ты будешь звать, когда инфраструктура упадёт? Девелоперов? С танцами а-ля Стив Баллмер?

Ну-ну... И кого ты будешь звать, когда инфраструктура упадёт?

Так, буду Балмера косплеїти і примушувати девів вчити кубернетеси )))) А то понаписують коду а потім кидають його девопсам щоб ті деплоїли ))) Зовсім розлінилися, макаки, нічо вчити не хочуть....

а к кому приходят дев опсы когда все упало? к девелоперам

Всё — это само приложение, или инфраструктура, на которой их условный кубернетис крутится? Во втором случае от девелоперов, как бы, немного толку...

инфраструктуры нынче на aws/google cloud/azure — и там пишут в тех поддержку, а когда падает приложение то к девелоперам

норм девелопер и сам все может сделать, а норм девопс проект не накодит

Спасибо, не надо. Видел печальную картину, что потом из этого получается.

Нет, если вы, конечно, об отдельных «самородках» — то я не спорю, но их единицы.

И тут же палишься насколько незрел в целостном понимании процесса создания софта 

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

Просто у каждого своя «жиза». Можно поставить себе планку и работать на более-менее приличных проектах, а можно исключительно на трешовых. Естественно, представления будут отличаться.

бізнес аналісти

Вот их я бы точно к творцам не причислял.

Є ті шо за касмтомером бігають та рекваєрменти під диктову записують а є ті шо більше до продакт менеджерів.

це кріейтор, це творець

"Творцы нам тут на*** не нужны, давай криэйтором" ©

продакт менеджери які придумують як пофарбувати кнопки, бізнес аналісти, дизайнери

Почему это PM кнопки красит? В таком ключе и PM и BA и дизайнеры, как и QA — не творцы, а обслуживающий персонал для улучшения проекта.

Для проекта много кто нужен, но бессмысленно спорить с тем фактом, что разработчик может быть самостоятельным юнитом. Собственно так и было на заре ИТ.
Конечно, такой самодельный продукт скорее всего окажется неказистым и кривым, не будет «Enterprise Grade», но он по крайней мере появится, пусть даже в виде PoC.

Имхо, но существуют ситуации, где или QA делает эти вещи хуже, чем эти узкие специалисты или делает неплохо, но от него ожидают фокусировки на тестировании и менеджменте внутри проекта, а не размазывания обязанностей по такому широкому спектру. В среднем хороший QA должен приложить не меньше усилий, чем разработчик, чтобы хорошо проявить себя в devops, security и других технических сферах, то какой смысл держаться за тестирование, если при таких скиллах можно уже проявлять себя как разраб и влиять на гораздо больше вещей? Тут можно остаться если реально душой прикипел к тестированию и могу только порадоваться за тестеров, которых ценят и не обрезают крылья

Верно, есть разные ситуации.
Если один человек вынужден делать все — это нехорошо, будь он девелопер или QA.
Я говорю о более качественной организации, когда на проекте есть специалисты по каждому из направлений, но при этом они неплохо разбираются в смежных областях. Почему это важно? Потому что если девелопер совсем не шарит в UX — он даже следуя дизайну сделанному профессиональным UX-дизайнером допустит ошибки в реализации деталей.
Если QA не разбирается в бизнес-анализе, он не сможет хорошо протестировать требования или предложить качественные улучшения. Есть еще множество примеров из жизни.
Что касается того что QA со скиллами, по вашим словам может влиять на больше вещей, если бы стал разработчиком, здесь я не соглашусь, т.к. с нормально поставленными процессами разработчика не будут грузить лишним, это более сфокусированная работа чем QA.
Задачи QA более разнообразны, он проникает в разные части проекта с целью найти проблемы влияющие на качество. Поэтому здесь кому что нравится больше. Кого-то это разнообразие напрягает — тогда лучше девелопмент.

Если один человек вынужден делать все — это нехорошо, будь он девелопер или QA.

Скажіть це чуваку який зробив nomadlist.com )))) От почитайте шо розумна людина пише levels.io/diy

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

На мой взгляд там не помешало бы подключить

Саме тому ти нонейм без продуктів а Пітер чувак який всамотужки запустив купу прибуткових проектів і підняв на цьому мільони, більше ніж ти та я заробимо за все наше життя.

Ну и сравни эти пару продуктов-одиночек, которые выжили, с множеством реально успешных продуктов, которые делаются и поддерживаются командами.

Тоді вже порівняй скільки продуктів які були зроблені командами не полетіли )))) А таких точно більше ніж тих що робилися всамотужки.

Аргумент «сперва добейся»?)
В данном случае я говорю конкретно о том что даже крутой чувак не может быть одинаково хорошо прошарен в дизайне, тестировании и т.д. Плюс вложить во все это достаточно времени.
Странно что ты не понимаешь преимуществ командной работы. Продолжай верить в супергероев.

Аргумент «сперва добейся»?)

Це дуже хороший тип аргументів. Ти ж не запустив жодного свого продукту, як ти можеш говорити про маркетинг про дизайнерів та про інше? Ти ж і зарплату зі своєї кишені людям ніколи не платив. Легко кидатися фразами коли гроші платиш не ти.

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

Можна не бути в топ 1% верхніх але в топ 20% — легко.

Продолжай верить в супергероев.

Я й сам такий супергерой дядь. А ти копай далі свої автотести навпіл з стратегіями та планами.

Це дуже хороший тип аргументів

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

Ти ж і зарплату зі своєї кишені людям ніколи не платив

Если у тебя закончились деньги на з.п. сотрудникам, это значит ты херовый бизнесмен, а не то что командная работа — отстой.

Я й сам такий супергерой дядь

Зафейлить все что можно и до сих пор не понимать базовых вещей.
Супергерои уже не те.

Чтобы сказать что продукт хреновый для пользователя

Можливо, але щоб радити чуваку винайняти маркетологів то треба мати з цим прямий досвід. А в тебе його немає бо ти не бізнесмен а просто анонім з інтернетів.

а не то что командная работа — отстой

а ти мене походу так і не зрозумів ))))

Мне Вас жаль )))))

але щоб радити чуваку винайняти маркетологів то треба мати з цим прямий досвід

Я маркетологов не советовал, хотя у меня и с ними опыт работы есть. Я говорил о продактах, дизайнерах и тестировщиках. С ними всеми я работал еще больше. У этого чувака проекты выстрелили не благодаря, а вопреки одиночной работе. Это систематическая ошибка выжившего — считать что это рецепт успеха.

а ти мене походу так і не зрозумів

Возможно, ты говоришь не то что имеешь в виду, будь конкретнее если действительно хочешь донести какую-то мысль.
А то у тебя все начинается с категоричности и очень быстро скатывается в оскорбления и попытки троллинга.
Ты можешь думать что это good publicity, но по сути зарабатываешь себе репутацию мудачка. А как известно, с мудаками лучше не работать. Даже книга такая есть)

по сути зарабатываешь себе репутацию мудачка

а ти собі ніяку репутацію не заробляєш пушо ти анонім і звати тебе ніяк )))) а за мою не переживай )))

С ними всеми я работал еще больше.

ага, тільки гроші ти їм не платив зі своєї кишені ))) і продукт ти не власний не робив.

У этого чувака проекты выстрелили не благодаря, а вопреки одиночной работе.

у цього чувака проекти вистрілили пушо він крутий чувак. А на цвинтарі стартапів покоїться вагон проектів які робились кваліфікованими командами та все по книгам.

ага, тільки гроші ти їм не платив зі своєї кишені

Платили другие, речь ведь о продуктах, а не обо мне. Получился самый крупный продукт в Европе в своей сфере. Полмиллиарда дохода в год. Один человек никак не осилил бы это сделать. Даже 10 человек. Поэтому работала почти сотня людей, каждый шарил в своей специальности плюс немного в соседних, о чем я и говорил.

Полмиллиарда дохода в год.

з яких ви отримали свої нещасні крихти у вигляді хай буде 3к на місяць ))))))))))))))

пишайтеся далі своїм проектом.

Речь шла о продуктах, но ты снова съезжаешь на личности

Классный сайт, красивее и удобней аналогичных. Неужели дизайнера он не нанимал?

Неужели дизайнера он не нанимал?

Ні.

А ще в нього є купка сайдпроектів.

Очень круто. Но таких талантливых людей очень мало. Большинство разработчиков и даже компаний для пользователя могут только унитаз из колючей проволоки соорудить.

для пользователя могут только унитаз из колючей проволоки соорудить.

пушо вони просто не пробували щось нормальне робити.
крім того для типових задач, наприклад дашбордів, є готові шаблони з яких можна зліпити нормальні інтерфейси.

Я говорю о более качественной организации, когда на проекте есть специалисты по каждому из направлений,

правда в жизни в том, что обычно такое есть только в ужасно унылых проектах...

Мені вчора прислали вакансію на Senior Microservices Engineer ))))

Я не в дупі. ЗП не маленька, знайти роботу не складає проблеми. Перспективи qa це йти в менеджери, чого я не хочу на даний момент. Йти в девелопмент — для мене це не проблема, якщо говорити про .net . Хіба досвіду мало, але я не бачу це як розвиток, це швидше зміна напрямку.
От власне цікавить рух на межі компетенцій. І цікаво почути як інші це роблять

В темі напиши шо ти QA тому що поради для девелоперів тобі не підійдуть.

Я не в дупі.

Нічого, пройде стадія заперечення, далі гнів на мене («сам дурак!»), потім компроміс про який Родрігез нижче написав (нібито QA є куди розвиватися), далі депресія усвідомлення дійсного положення речей та від того шо нічого тобі не світить ну і потім прийняття девелопменту як логічної та правильної кар’єри.

Приходь на четвертій стадії, допоможемо.

Поради для девів також підійдуть. Я з будь яких порад черпаю досвід.
На рахунок дупи. Ну якщо ти вважаєш, що я в дупі це твоя думка. Я не бачу проблем у своїй кар’єрі, пропозицій та оферів достатньо.
Просто не бачу розвиток у вивченні нового фремворка чи була. Якщо це потрібно для проекту — це без проблем. А просто це приносить мало сенсу.
Тому мені цікаво як до цього підходять інші

Просто не бачу розвиток у вивченні нового фремворка

Это очередной миф после собесов с дебилами. Изучение фреемверков это вообще подскилл или просто обыденность разработчика, особого развития оно не несет.

Даже те же алгоритмические задачки на продяк больше толка дадут чем надрачивание очередного фреемверка.

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

Все правильно і тут, і нижче. Говорю як людина яка працює ~5 років в автоматизації тестування.

«Правильний-толковий» девелопер по своїх технологіях і про інфраструктуру повинен знати, і про CI/CD з норм процесами по код ревю, статичних аналізаторах, тестах на всіх рівнях і тд і тп.

Проблема що таких девелоперів дуже мало. Писати автотести і тестити за собою для девелоперів зашквар, корона з голови впаде. + такі люди часто своїх помилок не бачать (мало б вирішитись коли один девелопер перевіряє роботу іншого). Звідси, і тільки звідси й виходить що є хороші гроші для інших — обслуговуючих напрямків (різного роду куа, опси, техрайтери і тому подібне).

При зменшенні бюджету обійдуться тільки девелоперами — навчаться і правильні вимоги вибити, і задеплоїти, і протестувати, і документацію напишуть.

Поки бабло коситься — треба косити. Але якби знав що відбувається в айті (загалом, а не тільки в Україні) куа напрям необирав би. Зі старту тебе дьоргають то по деплою, то по стратегіях, то навіть по конфігурації джири. В результаті знаєш про все але конкретно й нічого. Jack of all trades master of none. В той час девелопер спокійно педалить і набирає досвід в свому напрямку. Куа може мати тіж гроші, що має девелопер, але поприсідати треба набагато більше. І ціниться це рідко де.

При зменшенні бюджету обійдуться тільки девелоперами — навчаться і правильні вимоги вибити, і задеплоїти, і протестувати, і документацію напишуть.

В начале 2000х бюджеты были куда скромнее, а разработчики — куда толковее. Но без независимого тестирования не обходились и тогда. И, поверьте, тестировщики и в те годы зря свой хлеб не ели.

Техрайтеров тоже нанимали как отдельную специализацию ещё во второй половине нулевых — на прошлой работе даже целый небольшой отдел был.

Вот с деплоем всё было куда проще, да — не было контейнеров, докеров, кубернетисов и вот этого всего. Поэтому, с этим сами разработчики справлялись без проблем. Хотя вот, как сейчас помню — availability cluster для SQL Server нам настраивали админы, и нас, разработчиков, никто к этим настройкам без наблюдения админами не подпускал.

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

Все сводится к чему душа лежит. Тогда готов будешь и усилия вкладывать, и жертвовать доходом и т.д. ради каких-то изменений вроде перехода в девелопмент.
Это норм, имхо, главное понять что это твое реальное стремление или там призвание.
Если такого нет, то нечем просто окупить эти потери. Хз ведь как оно, инвестиция или нет, я ж говорю QA иногда зарабатывают на уровне дев архитекторов. Сколько там времени должно пройти пока он достигнет этого в девелопменте (если вообще достигнет — разные бывают блокеры).
Я вот знаю чувака, который при хороших скиллах автомейшна свичнулся в девелопмент. Но не зашло, вернулся, и зарабатывает больше чем в девелопменте. Раза в полтора, причем.
Не я, если что)

ну дык как девелопер он может 6к зарабатывать, а как куа на 3к так и останется

QA.

Для тебе очевидний розвиток це стати девелопером

Product Ownerом

Чи продакт менеджером (не впевнений яка між ними різниця). Теж норм варік, я нижче писав що

Творці — це ... продакт менеджери які придумують як пофарбувати кнопки
Для тебе очевидний розвиток це стати девелопером. QA та автоматизатори це добре корисно та цікаво але весь шум роблять девелопери та більше цінуються девелопери.

Мне кажется для QA более простой и логичный переход — это в DevOps.
Уважающий себя QA уже и так хорошо разбирается в сетях, безопасности, скриптовании, мониторинге, логировнии, конфигурации окружений и т.д.
Причём можно расти в DevOps не переставая быть QA. С разработкой так не получится и придётся страдать.

Мне кажется для QA более простой и логичный переход — это в DevOps.

турбо лол.

ви точно куа з адмінами не поплутали?

Уважающий себя QA уже и так хорошо разбирается в сетях

Если он тестирует проект связанный с сетями.

безопасности

Это вообще отдельная специальность.

мониторинге, логировнии, конфигурации окружений и т.д.

Девопс. Если Куа все это делает, значит он и так Девопс, который почему-то с лычкой «Куа» веслает.

Выше Senior Software Engineer уже невозможно развиваться только технически.
Можно оставаясь Senior глубоко специализироваться и стать экспертом в отдельной технологии (например ML или computer vision). Это не дает новых «лычек», но дает возможность работать над задачами только по «своей» технологии, зато в нескольких проектах сразу. Так же можно брать доплату за консультации «на стороне».
Следующая ступень — это Lead Software Engineer или Tech Lead. Это значит — ведущий инженер, у которого в подчинении обычные инженеры (в том числе Senior). На этой позиции уже нужно не только педалить самому но и правильно распределять и координировать работу других. Обычно Lead разрабатывает архитектуру проекта, бьет на модули и делает ревью имплементации этих модулей. Лично участвует только в написании самых сложных кусков кода (имплементация алгоритмов). Углубленно изучает те технологии, которые используются на проекте.
Дальше уже идут ступени, на которых девелопер во-первых перестает работать над одним и тем же проектом. Во-вторых пишет все меньше кода и все больше «работает языком».
Различные Architect позиции (Software Architect, Big Data Architect, Solution Architect, Cloud Architect, Blockchain Architect и т.д.). Архитект — это больше про выбор технологий, выбор высоко-уровневой архитектуры (на уровне «квадратиков»), решений какой софт покупать а что писать самим... Но самое главное — архитект это уже про коммуникацию. Нужно уметь «продать» свои решения клиенту, менеджерам, команде разработчиков и т.д. И это про командировки к клиенту, к топ-менеджерам, на конференции, к распределенной команде. Чаще всего архитект работает на старте проекта. Когда проект уже стартанул, «скелет» архитектуры написан и команды вышла на стабильный режим — он только иногда проверяет что бы не ломали архитектуру и не накапливали технический долг. Поэтому один архитект ведет либо один очень большой проект с несколькими командами, либо много небольших.
dou.ua/...​rticles/how-i-work-boyko
Дальше идет CTO — это architect уже на уровне всей компании. Помимо проектов ему уже нужно решать о стратегии компании в целом: какие технологии потребуются завтра, какие методики разработки внедрять, какие проекты лучше НЕ брать (например сапорт старья), имеет ли смысл пытаться сделать какой-то свой продукт или работать только на заказ, какие прототипы имеет смысл написать что бы показать на конференциях и т.д. Полностью расписано тут:
dou.ua/...​ta/articles/cto-position
Вывод, который я сделал для себя: мой потолок — это Lead Software Engineer. Выше уже надо больше работать с людьми, чем с кодом, нужно уметь «лизать микрофон», нужно уговаривать и договариваться, нужно летать (!) в командировки, нужно рулить бюджетом (а я не люблю считать деньги) ... При этом нету четких критериев успеха: нельзя сказать что вот этот проект — мое «детище» и я сделал его идеально. На этом уровне перфекционистом уже быть не получится — когда код писал не сам, то идеальным он не получится.
Периодически мне приходит мысль «спекаться» в какую-то узкую область. Но это достаточно рискованный путь: на галере не всегда появляются такие задачи, в итоге потратив 80% времени на глубокое изучение, например, алгоритмов и технологий распознавания образов, по факту таких задач у тебя будет 20%. А 80% ты будешь чинить баги в жабаскрипте, как все остальные девелоперы.
Что бы быть настоящим экспертом — нужно работать консультантом, а значит — переходить на фриланс. Тогда можно будет выбирать задачи именно по своей специализации. Но для фриланса сначала придется набить себе «репу» и сделать пару пет-проектов что бы доказать что ты действительно эксперт. И далеко не факт что твоя специализация будет оставаться модной много лет. Завтра вместо блокчеина модным станет какая-нибудь квантовая криптография и все — придется переучиваться.

гарне пояснення. Десь так і я це бачу.
Тобто, дальше сініора це більше бізнес та комунікації, ніж код та фреймворки

Выше Senior Software Engineer уже невозможно развиваться только технически.
Можно оставаясь Senior глубоко специализироваться и стать экспертом в отдельной технологии (например ML или computer vision). Это не дает новых «лычек»

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

Я считаю что нужно стартапить, это хорошее развитие в качество а не в колличество
Ты как дев РОС мвп можешь клепать пачками, когда то да выстрелит, и новый опыт получишь, когда надо думать о целом продукте, даже если это пруф

Твой первый меседж тоже правильно звучит))))

Стартапи це не про технології та не про сеньйорність.

Про гуманитарии и джуниорность?)

Про чік чік і в продакшен.

Описал 99%

скрам-мастеров.

Пофиксил тебя :-)))))))))))

Скрам мастер в продакшн не лезут!)
Им не до этой нудотины с деплоями

Начать обсуждать экзистенциальные вопросы тракторного хозяйства на ДОУ. Все синьоры уже тут.

Начать обсуждать экзистенциальные вопросы тракторного хозяйства

от цікаво які рівні є в лідерів ринку і як ростуть у них

* вширь(смежные технологии, фреймворки) — чтоб узнавать, какие еще идеи есть; объединять и дополнять
* вглубь(новые или просто более сложные концепции, уход в архитектуру — а это новый дивный мир) — чтоб справляться со сложностью и, грубо говоря, не строить небоскребы из картона
* софт-скиллы(как касательно планирования/приоритезации, так и коммуникации/подачи информации) — чтоб переходить от «сказали — сделал» к «сам придумал — сам согласовал — другим объяснил»
* скорость(тренировка на коротких задачах или в условиях сжатых сроков) — ради снижения потерь времени на переключении контекста

1) В Luxoft Training есть курсы которые расчитаны на уровень senior и выше
2) Сертифткации разные, по Google Cloud, AWS, ElasticSearch или что там еще
3) Что-то по soft skills или управлению (delegation & supervision книга, с нее начать)
4) Вообще-то технологии не стоят на месте, и сеньору их нужно мониторить, а что забылось — повторять.
что вспомню еще напишу.
Точно помню что советуют Т-shaped развитие когда есть область которую хорошо знаешь «вглубь» а остальные «вширь»

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

А як розвиваються в технічному напрямку інженери які сініори і вище

якщо «сіньйор» задає такі питання — він ще не «сіньйор»

окай. може. а як визначити чи я сіньйор-помідор чи ще ні ?

наприклад однієюз ознак Senior QA є: «Research new tools, technologies, and testing processes» і якщо після ресерчу ви не знаєте куди розвиватись ви ще не сіньйор
також від Senior очікується допомога колегам в технічному розвитку, але якщо собі не можете допомогти, то як ви зможете допомогти іншим.
я не знаю чи ви сіньйор, чи ні, можливо цей топік і є ваш пошук нових трендів, але виглядає за дуже загальна тема як на питання від Senior.

Research new tools, technologies, and testing processes

бугага. после n-tools они вообще почти все одинаково выглядят, только методы иначе называются

власне. саме це і було поштовхом до теми.

Ось так деколи сиджу, почитую доу, попиваю каву, дивлюсь у вікно на дорожніх робітників, які працюють за 20 доларів за годину на морозі і думаю, що мені переплачують, але потім підходить qa лід і просить допомогти: то авторизація з Azure B2C не працює, то headless chrome грішить memory leaks, то звіти не формуються, то CI дивні помилки видає, бо вони змінили Selenium на Cypress і тільки назви методів поміняли. В цей час я думаю: «замість того щоб вдосконалювати технічні навички ти свої софт навички прокачував», але відповідаю: «так, звичайно, ми ж одна команда», а після цього,йду до свого начальника і кажу щось моя зарплата не достатня щоб копирсатися в Cypress, замість того щоб вчити 13 джаву. І поки будуть такі сіньйор qa, які думають, що фреймворки всі однакові і будуть такі інфлюенсери, які вважають, що девелопери повинні все робити, я буду спокійно сидіти біля вікна, попивати каву, почитувати доу, дивитись у вікно на дорожніх робітників, які працюють 20 доларів за годину і не мати цих дурних думок, що мені переплачують.

видно у тебя зп совсем мизер, если это для тебя проблемы, хотя кто знает — зп же к скилам не привязана )))

после n-tools они вообще почти все одинаково выглядят, только методы иначе называются

Что, вы и на асинхронных пишете, как на синхронных, и на функциональных как на процедурных?

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

Вот очень жаль, что при таком разнообразном опыте вы не видите, что новое таки поступает.

Research new tools

я дослідив і спробував багато фреймворків та тулів. Звісно, я не експерт у них, але якщо потрібно завтра писати на новому фреймворку чи новій мові — розберусь за короткий час. Що міг застосував на своїх проектах. Інші або не підходять, або використовуються аналоги

допомога колегам в технічному розвитку

допомагаю з цим колегам, але якось ТЕХНІЧНОГО розвитку воно мені не приность

виглядає за дуже загальна тема

можливо, не знав як краще оформити свої думки

допомога колегам в технічному розвитку

Просто ви вчите, показуєте тільки те що ви самі знаєте, як ментор, попробуйте допомогти в технологічному розвитку джуніор нет девелоперу, ви ж сіньйор інженер повинні вміти бути тренером (coach).

можливо, не знав як краще оформити свої думки

По вашим відповідям я зрозумів чого таке загальне питання, насправді ви не хочете технічно розвиватись у вашому напрямку, а просто шукаєте підтримку у вашому рішенні переходити в менеджери або девелопери, в цьому місцевий інфлюенсер вам допоможе.

duck-typing.
Личку на галері маєш? ЗП сеньорську маєш? Значить сеньор.

Как-то в коментах было, что надо еще ипать гусей. Но это не точно :-))))))))))))

Если в 2-3 толковых компаниях тебя берут на senior позицию, значит он самый

а если их нет? а перебератся в штаты и идти в кор тим гугла/нетфликс/остальных не хочется?

Со стороны QA могу сказать.
Изучать смежные специальности: BA, UX, Ops, Security. Девелопмент, собственно.
Очень повышает качество производимых решений. И з.п., чего уж там.

В будь-якій незрозумілій ситуації — блокчейн)))) [жарт]

ага с искусственным интеллектом в придачу

ИИ, который ломает блокчен через ИОТ микросервисы используя МЛ овер БигДата в облаке

исправил, не благодари

не кислый батл будет, будет на твитче стриминг?

В дев’ятому класі я якось на третьому турбопаскалі з графікою написав морський бій. А потім стравив два алгоритми.

Зібрався натовп. Правда, до ставок не дійшло.

Тільки вже не пам’ятаю, чи вміло воно добивати пораненого, чи тупий рандом... Здається, що вміло.

Делать свой стартап в виде фреймворка, аркестратора или очередного языка программирования и лоббировать их в кровавые энтерпрайзы

Переходять на ремоут та починають менше працювати.

Не обов’язково але бажано.

власне, мене не цікавила зміна роботи чи підходу до роботи. мені більше цікаво підняття технічних скілів

власне, мене не цікавила зміна роботи чи підходу до роботи. мені більше цікаво підняття технічних скілів

QA engineer? Перед тобою взагалі всі дороги відкриті
1. Автоматизацій
2. Бізнес-аналіз
3. менеджмент.
4. Секюріті-спеціаліст який небудь

Береш будь яку суміжну галузь і рухаєшся в неї. Можна без відриву від основної роботи.
А от що робити девелоперу... Блокчейн-МЛ-Стартап напевно

Блокчейн-МЛ-Стартап

никакого МЛ — исключительно искусственный интеллект — можно скайнет

Вообще в основном в меденжмент они растут, реже в автомейшен.

1. Автоматизацій
4. Секюріті-спеціаліст який небудь

власне, як AQA\QA багато чого пройдено.
питання вивчення нового фреймворка не стоїть, щоб розібратись з новим фреймворком чи іншим тулом треба 2 дні і можна працювати.

Якось не технічно :)

ідея для освітніх ІТ-курсів — курс «Техніка сплаву по Дніпру для Senior спеціалістів»

Подписаться на комментарии