Про "средненько" - это всё-таки про зарплаты в IT. Может конечно 2 года назад 240к были не самой плохой зарплатой в IT, но и не "в разы больше средней". Как раз около 3 лет назад собеседовался на зп около 250к на уровень middle+ в Москве.
Что-то как-то не очень современно. Вспомнили grunt и gulp, даже такого динозавра, как CSS Spriting. HTTP/2 уже тоже давно нормально поддерживается и в продакшене используется.
Alright незаслуженно забыли, одно из самых нейтральных слов в этом плане. Не слышал, чтобы в деловом разговоре использовали превосходные формы вроде wonderful, admirable и terrific, а вот alright — постоянно.
Вот тут возникает вопрос: зачем мне тратить своё время на исправление багов в линуксе, если я за день зарабатываю на дистрибутив винды? Сомневаюсь, что мне понадобится меньше дня, чтобы выкачать сорцы, разобраться в них, отдебажить и пофиксить.
Всё, что Вы описали к коммунизму отношения имеет очень мало. Как идеология коммунизм никак не предполагает диктаторов, закрытость и т.п.
Всё выше перечисленное никак не относится к экономической формации и может с таким же успехом существовать и при капитализме.
А что, если разработчик занимался отладкой и разбирался в куче говно-уникального кода после такого же товарища, который не утруждал себя тем, чтобы «думать над архитектурой» и «шариться по зависимостям»? Допустим, он исправил несколько критических багов несколькими строчками кода за несколько дней. Получается, что он работал с крайне низкой производительностью, а тот, кто написал весь этот код — Д`Артаньян.
Если бы Вы работали на проекте, где количество строк измеряется сотнями тысяч и Вам нужно было бы разработать какой-то функционал, то вы бы с ходу взялись за написание кода? Хорошо, если там всё покрыто тестами и они сразу все упали, а если бы проблемы вскрылись на регрессе или, о боже, в продакшене? Насколько эффективной Вы сможете считать свою работу после такого?
Я понимаю, что можно много рассуждать о полезности той или иной методологии разработки, но подвергать сомнению необходимость стандартных процессов вроде отладки, проектирования архитектуры и анализа существующего кода по меньшей мере странно.
Я надеюсь, что Вы не станете в ближайшее время менеджером, иначе с таким подходом это приведёт к тому, что производительность на вашем проекте будет измеряться количеством написанных строк.
вы делаете своим коллегам плохо: они обесцениваются, на вашем фоне выглядят бледно, к тому же остро вас ненавидят и боятся.
Так они же сами не хотят делать свою работу должным образом, почему я должен их жалеть? Ясно, что если не работать, то обесценишься.
Вообще я по многим признакам попадаю под описание трудоголика, но меньше всего смотрю на окружающих. Мне всё равно, что кто-то будет смотреть ютуб, пока я буду делать его работу. Через год-другой у меня будет ценный опыт и работа с зарплатой в полтора раза выше, а этот человек всё так же будет смотреть ютуб на том же месте
У одного очень известного бодишопа это работает ровно так, как вы и описали. При этом, чтобы заслужить повышение, нужно собирать доказательства своей состоятельности.
Я не говорил, что они могут выявить что-то особенное, хотя некоторые вещи куда проще проверить с помощью юнит тестов.
Дело в том, что есть пирамида тестирования и она появилась из практики. Она обусловлена тем, что юнит-тесты легче писать, они реже ломаются и, самое главное, проходят быстрее в несколько тысяч раз, чем UI-тесты. Так получилось, что на нашем проекте за стратегию автотестирования отвечают индусы и они заставляли писать селениумы на всё. В результате, за год время прогона тестов выросло в 3 раза и теперь при изменении в коде за день все тесты уже не прогнать. В то же время, юнит-тесты прогоняются всего за 15 минут. К тому же, UI-тесты часто требуют ещё и настройки среды, в отличие от юнитов.
На эту тему на хабре есть статья https://m.habr.com/ru/post/358950/. Сам прочитал по диагонали, но, вроде, неплохая.
Чтобы писать, к примеру, UI тесты, код знать не нужно, а вот чтобы писать юниты, его нужно знать и иногда реыакторить. Я бы тестировщики к такому не допустил. Юниты — отнюдь не чуть. Они могут проверить за несколько миллисекунд сложную логику, которую тестировщик может проверять целый час.
Автомобили-роботы лишают работы водителей, кассы самообслуживания лишают работы кассиров… Вы вообще не задумывались, что тестировщики — одни из самых низкоквалифицированных работников IT и существуют лишь потому, что разработчикам самостоятельно заниматься тестированием было бы намного дороже?
Как-то у Вас всё наоборот получается. Сразу видно, что человек не особо знаком с. NET, его рынком труда и трендами. Мне нравится десктоп разработка, но более 90% попадающихся мне вакансий — это вэб. Про зрелость веб стека и количество компонентов слышать просто смешно — всё уже много лет как написано. С выходом core ситуация стала ещё лучше. В плане развития, ближайшие изменения как раз должны коснуться десктопа, а точнее принести его в .NET Core на Windows.
Хм, «предел полезности»? Для меня это бюджетный телефон за 20к, который в наше время уже имеет неплохое железо, NFC, сканер отпечатков и хорошую камеру. А всё, что мне нужно в смартфоне — чтобы не тормозил и хорошо открывал страницы в браузере. В принципе, это можно получить даже за 15к.
А я с автором категорически не согласен. Он очень любит во всех своих статьях обобщать и категорично заявлять о том, что лучше других знает, как устроен этот мир.
Я, например, никогда не разносил разрабов на ревью из-за самолюбия. Во-первых, я действительно хочу, чтобы люди чему-то учились, а, во-вторых, пока код не попал в общую базу — это ответственность конкретного человека, а когда его смержили — это общие проблемы и общий технический долг.
Я часто пишу комментарии на ревью и замечаю, что нормальные разрабы перестают допускать ошибки, на которые я им ранее указывал. Но однажды мне пришлось работать с человеком, который был неисправим. Даже после моих комментариев он делал по-своему и не хотел переделывать. Его задачи висели до последнего, потому что он просто не хотел писать нормальный код, хотя я в комментариях порой даже просто приводил нужные куски кода. Его не уволили, но если бы я принимал решение, то сделал бы это.
С семьями - это только с женой? А если есть несколько маленьких детей, например?
Про "средненько" - это всё-таки про зарплаты в IT. Может конечно 2 года назад 240к были не самой плохой зарплатой в IT, но и не "в разы больше средней". Как раз около 3 лет назад собеседовался на зп около 250к на уровень middle+ в Москве.
Что-то как-то не очень современно. Вспомнили grunt и gulp, даже такого динозавра, как CSS Spriting. HTTP/2 уже тоже давно нормально поддерживается и в продакшене используется.
Грустно за вас. Если в свободное время заниматься только собственными проектами, то да, нелегко.
Alright незаслуженно забыли, одно из самых нейтральных слов в этом плане. Не слышал, чтобы в деловом разговоре использовали превосходные формы вроде wonderful, admirable и terrific, а вот alright — постоянно.
Вот тут возникает вопрос: зачем мне тратить своё время на исправление багов в линуксе, если я за день зарабатываю на дистрибутив винды? Сомневаюсь, что мне понадобится меньше дня, чтобы выкачать сорцы, разобраться в них, отдебажить и пофиксить.
Всё, что Вы описали к коммунизму отношения имеет очень мало. Как идеология коммунизм никак не предполагает диктаторов, закрытость и т.п.
Всё выше перечисленное никак не относится к экономической формации и может с таким же успехом существовать и при капитализме.
говно-уникального кода после такого же товарища, который не утруждал себя тем, чтобы «думать над архитектурой» и «шариться по зависимостям»? Допустим, он исправил несколько критических багов несколькими строчками кода за несколько дней. Получается, что он работал с крайне низкой производительностью, а тот, кто написал весь этот код — Д`Артаньян.Если бы Вы работали на проекте, где количество строк измеряется сотнями тысяч и Вам нужно было бы разработать какой-то функционал, то вы бы с ходу взялись за написание кода? Хорошо, если там всё покрыто тестами и они сразу все упали, а если бы проблемы вскрылись на регрессе или, о боже, в продакшене? Насколько эффективной Вы сможете считать свою работу после такого?
Я понимаю, что можно много рассуждать о полезности той или иной методологии разработки, но подвергать сомнению необходимость стандартных процессов вроде отладки, проектирования архитектуры и анализа существующего кода по меньшей мере странно.
Я надеюсь, что Вы не станете в ближайшее время менеджером, иначе с таким подходом это приведёт к тому, что производительность на вашем проекте будет измеряться количеством написанных строк.
Так они же сами не хотят делать свою работу должным образом, почему я должен их жалеть? Ясно, что если не работать, то обесценишься.
Вообще я по многим признакам попадаю под описание трудоголика, но меньше всего смотрю на окружающих. Мне всё равно, что кто-то будет смотреть ютуб, пока я буду делать его работу. Через год-другой у меня будет ценный опыт и работа с зарплатой в полтора раза выше, а этот человек всё так же будет смотреть ютуб на том же месте
Я не говорил, что они могут выявить что-то особенное, хотя некоторые вещи куда проще проверить с помощью юнит тестов.
Дело в том, что есть пирамида тестирования и она появилась из практики. Она обусловлена тем, что юнит-тесты легче писать, они реже ломаются и, самое главное, проходят быстрее в несколько тысяч раз, чем UI-тесты. Так получилось, что на нашем проекте за стратегию автотестирования отвечают индусы и они заставляли писать селениумы на всё. В результате, за год время прогона тестов выросло в 3 раза и теперь при изменении в коде за день все тесты уже не прогнать. В то же время, юнит-тесты прогоняются всего за 15 минут. К тому же, UI-тесты часто требуют ещё и настройки среды, в отличие от юнитов.
На эту тему на хабре есть статья https://m.habr.com/ru/post/358950/. Сам прочитал по диагонали, но, вроде, неплохая.
Чтобы писать, к примеру, UI тесты, код знать не нужно, а вот чтобы писать юниты, его нужно знать и иногда реыакторить. Я бы тестировщики к такому не допустил. Юниты — отнюдь не чуть. Они могут проверить за несколько миллисекунд сложную логику, которую тестировщик может проверять целый час.
Автомобили-роботы лишают работы водителей, кассы самообслуживания лишают работы кассиров… Вы вообще не задумывались, что тестировщики — одни из самых низкоквалифицированных работников IT и существуют лишь потому, что разработчикам самостоятельно заниматься тестированием было бы намного дороже?
Какие библиотеки юзать? В основном те же, что и на Windows, т.к. большинство библиотек уже давно поддерживают .NET Standard.
В списке новых фич будущих версий .NET MS как раз говорила о расширении количества поддерживаемых платформ.
Как-то у Вас всё наоборот получается. Сразу видно, что человек не особо знаком с. NET, его рынком труда и трендами. Мне нравится десктоп разработка, но более 90% попадающихся мне вакансий — это вэб. Про зрелость веб стека и количество компонентов слышать просто смешно — всё уже много лет как написано. С выходом core ситуация стала ещё лучше. В плане развития, ближайшие изменения как раз должны коснуться десктопа, а точнее принести его в .NET Core на Windows.
Я, например, никогда не разносил разрабов на ревью из-за самолюбия. Во-первых, я действительно хочу, чтобы люди чему-то учились, а, во-вторых, пока код не попал в общую базу — это ответственность конкретного человека, а когда его смержили — это общие проблемы и общий технический долг.
Я часто пишу комментарии на ревью и замечаю, что нормальные разрабы перестают допускать ошибки, на которые я им ранее указывал. Но однажды мне пришлось работать с человеком, который был неисправим. Даже после моих комментариев он делал по-своему и не хотел переделывать. Его задачи висели до последнего, потому что он просто не хотел писать нормальный код, хотя я в комментариях порой даже просто приводил нужные куски кода. Его не уволили, но если бы я принимал решение, то сделал бы это.