• Почему разработчикам не нравится Agile?
    +2

    О проблемах с задачей можно сразу узнать из трекера, как уже написали в комменте выше и спросить у соответствующего разработчика лично что не получается, почему задача всё ещё в колонке doing. Имхо, это будет даже комфортнее для тех, кто умеет писать код, а не красиво разговаривать. Незачем отвлекать других из за одного, чаще всего, если разработчик сам не говорит что задача еще в процессе, это значит что у него всё под контролем и просто нужно ещё чуть больше времени на отладку, допиливание и т.д. А если нужно что-то от кого-то, он сам сообщит, если человек адекватный (исходим из того, что неадекватных в вашу компании не берут). Излишние вопросы каждый день со стороны менеджмента отвлекают, и время, которое человек посвятил бы допиливанию, он тратит на объяснение почему не успел, когда оценил в день, а надо еще доделать. Плюс лишний стресс с утра после такого объяснения и втыка от менеджмента негативно повлияет на следующие несколько минут/часов, которые будут не продуктивными для человека.


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

  • Почему разработчикам не нравится Agile?
    +12

    Лично для меня всё, что связано с agile, scrum — до свидания. Спасибо, наелся.
    По опыту работы в нескольких местах был скрам, везде одно и то же, одинаковые проблемы в командах. Почему? Недостижимые в реальной жизни требования:


    • точно оценить в часах задачи спринта, чтоб всё влезло в спринт, когда кода в глаза не видел или макета или тз.
    • точно отработать эти часы, а это 8 часов в день чистой работы, что абсолютно нереально в реальном мире. Если вы 8 часов в день проводите чисто в процессе работы над задачами без перерыва на кофе, совещания, помочь коллеге, подышать воздухом, размять ноги, поздравляю вы терминатор.

    А так как живем мы всё таки в реальном мире, то на каждой ретроспективе было одно и то же из недели в неделю: почему не успели и что надо делать чтобы успевать.


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

  • Менеджер-передаст
    0
    Листал ленту хабра, бегло взглянул на заголовок — фух, вроде показалось)
    А статья хорошая.
  • Современная сборка 2020 для frontend. Gulp4
    +1

    Webpack и gulp разные вещи. Webpack заточен под разработку приложения, сборку es модулей. Вебпак гораздо монструознее, он css обрабатывает через js лоадер.
    Gulp больше заточен под традиционный фронтенд, конфиг очень простой, указали путь к css, он без всяких лоадеров сделает минификацию, автопрефиксы и всё что вам нужно. И делает это быстрее вебпака.
    Сам использую gulp на всех проектах кроме SPA. Вот там только вебпак.

  • Почему мы пишем программы такого низкого качества?
    0
    ОКей, но я так и не понимаю причем здесь высокое/низкое качество решения и быстро/медленно разработать?

    Ваш вопрос имеет место быть, но он никак не влияет на то как (быстро/некачественно или наоборот) мы будет решать проблему клиента. Мы можем посоветовать клиенту лучшее решение, если оно есть в его вопросе, но всё равно нам придется дальше делать выбор как это решение сделать.

    Здесь вопрос больше про то, что бизнесу по большому счету вообще наплевать на качество наших приложений (я не беру в расчет космическую и медицинскую отрасль, где ошибка в программе стоит жизней). Просто больно смотреть как ребята, хорошие разработчики, дизайнеры и прочие хотят делать хорошо, а им за это дают по рукам.
  • Почему мы пишем программы такого низкого качества?
    0
    Нужно кому?
    Приведите пожалуйста пример того, что заказывают люди и почему оно не нужно (кому?). А то без примера ваша мысль непонятна.
  • Почему мы пишем программы такого низкого качества?
    +2
    Ваши слова да в уши всем руководителям :)
  • Почему мы пишем программы такого низкого качества?
    +14

    Слишком много текста. На вопрос статьи можно ответить одним предложением. Почему мы пишем программы такого низкого качества? — Потому что бизнесу не нужно высокое качество, нам не ставят задачи сделать высококачественно, но ставят задачи сделать быстро, быстрее, еще быстрее и как можно быстрее.


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

  • Получены самые детальные снимки поверхности Солнца
    +1
    Выглядит как расплавленное золото, просто океан жидкого золота, первое о чем подумал, когда посмотрел видео.
  • Стоит ли жаловаться на собеседования?
    0
    Тестовое задание по сравнение с написанием кода на интервью плохо тем, что отсутствует обратная связь.

    Совершенно неверно. Не знаю как по вашему опыту, а я всегда задаю уточняющие вопросы перед тем как делать задание, если они у меня есть. И мне всегда дают пояснения, уточнения и т.д.
  • Стоит ли жаловаться на собеседования?
    +1

    Большинство либо не читают, либо делают вид что не читают. Как иначе объяснить вопрос «вы работали с javascript?» или «какие css препроцессоры вы знаете?» когда у меня в резюме черным по белому написаны и препроцессоры и опыт с javascript в отдельном абзаце «навыки».

  • Стоит ли жаловаться на собеседования?
    +3

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

  • Кого вы пытаетесь впечатлить своими дедлайнами?
    +1

    Всегда не понимал эту спешку, а ещё не понимаю почему у нас в Российском бизнесе почти всегда скрам означает переработки и работу по выходным. Проблема возможно в менталитете еще со времен производства, не знаю.


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


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

  • Задачки по программированию — плохой способ оценки квалификации Senior Developer'а
    +1
    Очень часто люди, которые требуют, «чтобы потом не приходилось за кем то чего то там доделывать», они не комфортны в общении, с ними психологически тяжело работать, даже если они прямо таки суперспецы.

    Тысяча плюсов вам. Каждое слово поддерживаю. Кстати, по поводу дохода, он зачастую бывает либо на том же уровне либо даже выше чем у бюрократических машин корпораций (из собственного опыта). Главное чтобы было комфортно и спокойно работать.
  • Задачки по программированию — плохой способ оценки квалификации Senior Developer'а
    +5
    Ни разу не было алгоритмов, сортировок, олимпиадных задач потому что я сознательно игнорирую предложения от больших корпораций, которым 100% на меня будет начхать.
    Отдаю предпочтение mid компаниям, где ты являешься по-настоящему частью команды и от твоих решений и действий, как разработчика напрямую зависит работа бизнеса (прода). Могу отметить, что в таких компаниях ситуация на собеседованиях бывает разная, но у меня чаще всего была просто дружеская беседа, в ходе которой сразу видно как человек мыслит. А практические скиллы проверяются либо одной задачкой из реального кейса компании либо обсуждением github или pet проекта. Не встречал ещё опытного разработчика, у которого бы не было своего проекта для души.
    И на мой взгляд это гораздо интереснее, чем потеть на интервью, где за 20 минут надо вспомнить что-то, что никогда не пригодится тебе в работе.

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

    То есть компании не нужны люди, которые будут работать, создавать продукты, запускать проекты, а нужны люди, которые будут делать что-то неведомое, но явно не развивать компанию.
  • Собеседуем кандидата на должность Senior Software Developer
    0
    Про метаморфозы интересно. У меня по молодости, когда только начинал, была тяга ко всему новому: быстрая смена стеков, проектов, хотелось попробовать что-нибудь новое и тд. Сейчас по прошествии лет пришло некое умиротворение и спокойствие. Не хочется скакать по проектам, менять стеки, хочется чего-нибудь стабильного, чтобы на долгие годы и в спокойном темпе, благо нет скрама и удалёнка позволяет :))
  • Собеседуем кандидата на должность Senior Software Developer
    +3
    Кстати по поводу джунов, встречались такие собеседования да. Когда тебя собеседует человек, который несёт откровенную хню, и когда настает твой черед задавать вопросы, начинает дергаться и нервничать сам :) Как будто собеседующий пытается самоутвердиться в диалоге с тобой, выглядит это нелепо и смешно.
  • Собеседуем кандидата на должность Senior Software Developer
    +2
    Эх, еслиб они его еще читали… А то как обычно «Мы внимательно изучили ваше резюме, бла бла бла» и следом вопрос «А вы работали с javascript?»
  • Собеседуем кандидата на должность Senior Software Developer
    +8
    порой собеседующие не следуют основной цели собеседования — определить, будет ли разработчик полезен команде и насколько эта польза соотносится с затратами на данного разработчика. Вместо этого, собеседующий часто выявляет чего разработчик не знает, вместо того, чтобы выяснить, что он знает и умеет.

    Это надо золотыми буквами сделать на всех видных местах, где проходят собеседования. Чтобы собеседующий всегда помнил. Наверное самое главное предложение из всей статьи. Спасибо автор :)
  • Немного размышлений на тему модульного css и проблемы поддержки кода
    –1
    Скажем так: в данный момент препроцессоры не упрощают работу с css, а усложняют. Выше привели хороший пример про нежелание разгадывать ребусы из миксинов и функций scss. Как же это жизненно, когда тебе дают проект, в котором уже тысячи строк стилей с какой-то собственной логикой, которую разработал предыдущий человек и ты должен сидеть и разгадывать где там что.

    Золотой век препроцессоров пришелся на тот период, когда еще не было нативных переменных в css, не было postcss и web компонентов. Но сейчас всё изменилось. Уже сейчас спокойно можно использовать нативные переменные css, которые в разы удобнее и + поддерживаются в js. И миксины можно использовать, просто обычным классом. И функции есть. А самый чистый подход на мой взгляд — это конечно же нативные web компоненты с инкапсулированными стилями. Но увы не весь продакшн ещё до этого уровня дорос, так как нужно отбросить допотопные версии браузеров:) Да чёрт возьми, уже и без вебпака вполне можно обходиться с помощью es модулей, без бабеля, не таща за собой мегабайты лишнего кода, но это уже совсем другая история.
  • Встречайте Space — новый продукт от JetBrains
    +2
    Очень круто использовать интегрированные в ОС нативные фичи вроде месенджеров, заметок, календаря и прочего, когда у вас в организации у всех одна ОС стоит. Просто в командах кто-то на маке сидит, кто-то на винде, кто-то на убунте к примеру и использовать для работы нативные для ос приложения не представляется возможным. Именно поэтому так выстрелило облако и тот же электрон.
  • Встречайте Space — новый продукт от JetBrains
    0
    В том, что загружаете всё, тратятся ресурсы, особенно учитывая, что у них обёртка для десктопа на электроне. Вы не используете то что не нужно, а оно у вас в фоновых процессах всё равно висит и грузится при запуске.
  • Комментарий из публикации, перенесённой в черновики.
  • Удаленная работа здорового работодателя
    +3
    В удаленной работе здорового работодателя нет разделения на должности. В ИТ сейчас везде в 100% должностях можно работать удалённо. Не могу представить случай, когда нельзя какую-либо должность сделать удалённой, так как вся работа по интернету, вплоть до встреч с клиентами, заказчиками (zoom e.t.c.).

    Как обычно приводятся в пример нехватка общения, одиночество и т.д. Это всё проблемы конкретных людей, которые не могут общаться ни с кем кроме коллег по работе (если бы они сидели в офисе). Это не имеет никакого отношения к бизнесу и рабочим процессам удаленной работы. Просто надо вести активный образ жизни вне своего дома и общаться с друзьями, семьей, заводить новые знакомства, а не замкнуться в четырех стенах. А так называемых «бытовых раздражителей» в офисе гораздо больше, чем дома. Что дома может раздражать? соседи, жена, ребенок? Закройте дверь в комнату, оденьте наушники и все ваши раздражители пропадут. А в офисе (особенно опенспейс): постоянный фоновый шум, в любой момент кто-то может подойти отвлечь и от него уже не отгородишься наушниками, постоянные ненужные совещания, встречи и так далее.

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

    Настоящаяя удаленка здорового человека — это когда не надо никого контролировать, все увлечены процессом, люди работают в удовольствие, а не отсиживают часы.
  • Использование полифиллов при написании кросс-браузерных приложений
    0
    Пусть даже так. Что дороже: выгода с этих пары процентов или разработка/тестирование/поддержка ИЕ? Вопрос к менеджерам. Кто-нибудь считал, как выше заметили расходы разработчиков (затраченное время, нервы) и компании (деньги) на поддержку легаси браузеров?

    Просто приведу пример одного из давних проектов, ставят задачу новый сайт с 0 со всеми фишечками, компонентами и тд. Делаем за пару месяцев. Потом говорят надо ИЕ 11. Ещё пару месяцев натягивали/полифилили/***лись ради пары процентов ИЕшников. И я отчетливо могу сказать, так как в курсе аналитики по покупателям (не по просмотрам, а именно по покупателям, а их ровным счетом 0 было), что оно того не стоило.
  • Использование полифиллов при написании кросс-браузерных приложений
    +1
    Скажите пожалуйста те, кто работает под IE и прочем старье и топит за его поддержку, что быстрее и дешевле: пересадить клиента/сотрудника на хром/оперу/фф или выделять десятки часов в месяц и серьезные деньги на разработку, тестирование и поддержку всего этого добра под IE. Я просто хочу увидеть аргументы, почему не пересадить за современный брауз, а продолжать топить за IE. Напишите, если не трудно.

    Я просто хочу понять насколько сложно реализовать все эти вещи, которые у вас «только под ИЕ» в других браузерах. И что дешевле и выгоднее, ведь прогресс идёт, и с каждым месяцем всё сложнее и сложнее становится его поддерживать и нагружать сайт этим огромным оверхедом полифиллов, бабелей и прочим хламом.

    Как будто пересадить человека за другой более современный, быстрый и красивый браузер это так сложно (как написали выше), уверен, что они сами не рады мучиться в этом ИЕ на работе и с радостью перешли бы.
  • Зарплатная вилка. Ты ж у мамы программист
    +3
    Был один заказчик однажды. Говорит: надо просто скопировать «вот этот» сайт, но немного изменить текст. Когда объясняешь ему что это займет 3 месяца минимум и будет стоить nnn сумму, он такой говорит: так там же просто скопировать, это же быстро должно быть.

    И не знаешь что делать смеяться или плакать, потому что таких заказчиков чуть ли не через один.
  • Зарплатная вилка. Ты ж у мамы программист
    +3
    Вы абсолютно правы.
    Но, я ещё понимаю когда разница ну на 1-2к$. А когда разница в 3-5к$, да ещё и предложения ниже нашего локального рынка, то невольно начинаешь задумываться, а не оборзели ли они…
  • Зарплатная вилка. Ты ж у мамы программист
    +10
    все, кто приходят в компанию, пишут плохой, неподдерживаемый код.

    Так уж все? А компания достаточно времени даёт на написание хорошего качественного кода и на тестирование? Может проблема вовсе не в разработчиках. Я часто сталкивался с тем, что тебе банально времени не дают, говорят нам надо за 3 дня, и как ты им не объясняй, что за 3 дня не написать качественно, с документацией и тестами, а они тебе: у тебя же куча регалий и опыта, ты обязан уметь делать всё быстро и качественно! Я уже молчу про работу с легаси и поддержку старого кода. Почему-то многие менеджеры думают что новый опытный разработчик сходу вот так возьмёт и разберется во всём проекте, который писали годами, за пару дней и начнёт выдавать супер результат.
  • Зарплатная вилка. Ты ж у мамы программист
    0
    Имхо, работать из России с Европой или США нужно только и только на равных условиях с той оплатой, как если бы вы жили в стране работодателя. Иначе получается так, что умные дяденьки с запада идут на рынок РФ и СНГ и нанимают людей на 500%, а то и 1000% дешевле, чем у себя. А наши Васи и порой очень опытные разработчики и тому рады. Поэтому, даже не смотря на кажущийся высокий уровень ЗП в ИТ у нас, по факту он очень низкий по сравнению с западом. И так будет до тех пор, пока ребята будут соглашаться РАБотать на западных дядей задёшего. Печально, но факт.
  • Изоляция, тревожность и депрессия на удалённой работе
    0
    Обычно 5-6 часов без перерыва. Изредка бывает конечно что-нибудь срочное, но это скорее исключение. Ещё во времена работы в офисе у меня не получалось нормально работать после обеда. Самое продуктивное время было с 7 до 11, пока все не придут:) Дальше начинался опен-спейс хаос и комфортно работать было сложно.
  • Изоляция, тревожность и депрессия на удалённой работе
    0
    Неужели бывает настолько тяжело разграничить работу и личную жизнь?

    Я просто выделил себе отдельную комнату (в квартире) для работы, в которой закрываются двери, объяснил семье что с утра до обеда я на работе, купил себе второй смартфон для всех рабочих контактов и мессенджеров, который включается утром и выключается в обед, так как у меня самое эффективное время работы примерно с 8 утра и до обеда. Всё. Никаких проблем с тем, чтобы после обеда заниматься всем, чем угодно.

    Печально, что у многих всё общение и личная жизнь сводится только к посещению офиса, а если нет офиса, то наступает депрессия потому что не с кем пообщаться. Так не должно быть, работа — это всего лишь один из инструментов нашей жизни, который помогает нам заработать денег.
  • Как мы собрали суперкоманду на удаленке и ни разу об этом не пожалели
    0
    Так я не о том, что они были без инвесторов, а о том, что к большому сожалению не все инвесторы с уважением относятся к культуре и традициям компаний, в которые инвестируют. Очень хорошо, когда попадается действительно хороший инвестор, который близкий по духу к основателям той компании, в которую инвестирует.
  • Как мы собрали суперкоманду на удаленке и ни разу об этом не пожалели
    +3
    компания начинает идти не туда куда хочет инвестор

    Зачастую как раз инвестор заставляет компанию идти туда, куда не хочет идти сама компания и её основатели, полностью в разрез философии и принципам компании. Посмотрите на Blizzard, EA, APPLE, на российский VK и сотни других примеров. В прошлом передовые лидеры своей области, а сегодня просто очередные компании без души с целью высосать как можно больше денег из своих пользователей.
  • Как мы собрали суперкоманду на удаленке и ни разу об этом не пожалели
    +3
    После двух лет удалённой работы с уверенностью могу сказать: в офис больше не вернусь. Настолько прошлым веком кажутся ежедневные поездки на работу, пробки, очереди, офисный шум и прочая суета. Как прекрасно работать в удобном тебе режиме дня с комфортом и успевать заниматься еще и хобби за те 2-3 часа, которые раньше уходили на дорогу. Будущее IT определенно за удаленной работой. Не знаю почему в РФ так всё медленно, на западе давно уже многие специалисты (не только ИТ) работают дома, даже домашние офисы есть.
  • 10 способов защиты интеллектуальной собственности IT-стартапа
    0
    Подскажите пожалуйста, как вести себя в плане защиты ИС, если ты ИП и разрабатываешь коммерческий продукт, бренд и всё такое, но не в форме компании с ООО? Фактически разница для потребителя незаметна, разница лишь юридическая.
  • Кто он — убийца JavaScript?
    +2
    Как только в мире появится технология (язык, фреймворк, что угодно), что позволит одновременно: писать 100% кроссплатформенный код для android,ios,harmonyOS,fuchsia, windows,linux,mac e.t.c., создавать достойный интерфейс либо нативный для каждой платформы либо собственный, иметь низкий порог вхождения и удобный комфортный синтаксис, то эта технология тут же станет самой популярной и все на неё перейдут.

    Сейчас такой технологией является web со всеми плюсами и минусами. Кто бы что ни говорил, а мы живем в реальном мире, где никому не хочется реализовывать своё приложение три года, писать на 5 языках, мучиться с кривым GUI чтобы создать удобный и привлекательный дизайн и ещё разбираться в кучи нюансах, о которых уже позаботились разработчики того же браузера. Я тоже очень хочу и жду когда наконец мы сможем писать просплатформенно, быстро, красиво, чисто и без головной боли, да еще чтобы и весило всё в килобайтах, но пока этот день не настал.

    Есть же в этом всём нечто прекрасное, чего раньше нельзя было представить: каждый человек способен написать собственное приложение в кратчайшие сроки, работая всего с одним языком и одной средой исполнения. Пусть это приложение будет не без недостатков, но кто вас заставляет его использовать (я сейчас про скайп)? Лично я не представляю свою жизнь без этих приложений: Trello, Postman, Slack, Vscode, Discord, Figma, Avocode. И все они на electron и работают прекрасно, намного упрощают и улучшают мои рабочие процессы)
  • Зачем ходить на собеседования
    0
    И обычно оно проходит в стиле разговора по душам с тимлидом или руководителем.
    По личному опыту сужу: чем лучше условия работы и коллектив в команде, тем меньше всяких заморочек с процессом найма и тем проще и быстрее проходит собеседование, без всяких тестовых заданий, экзаменов, кодинга на бумаге и т.д.

    Знаете, забавную вещь заметил: вот часто попадаются статьи (на хабре) про то, как проводятся собеседования у компаний (всякие там олимпиадные задачки, кодинг на доске, 3-5 этапов прохождения и тд). При этом, руководство обычно подчеркивает, что эти этапы необходимы потому что дефицит хороших специалистов на рынке (так они считают). И при этом, будучи разработчиком, а значит кандидатом, я всё больше вижу дефицит именно нормальных рабочих условий, адекватного руководства и людей, с которыми приятно работать. Иногда поиск хорошего проекта может занять до трёх месяцев. Так как же обстоят дела на самом деле? (риторический вопрос) На рынке дефицит талантливых разработчиков или адекватных рабочих условий, в которых талантливый разработчик будет свои таланты развивать, а не губить…
  • Зачем ходить на собеседования
    0
    Я думаю под «хорошим» здесь имеется ввиду человек, у которого есть помимо опыта и навыков, завершенные проекты, которые можно продемонстрировать, а также возможно какой-нибудь open source. Плюс какая-то репутация в социальных кругах и некоторые связи. В этом случае человеку действительно нет необходимости что-то искать, обычно заинтересованные сами его находят.

    Но стоит отметить, что есть еще один способ, которым мало кто пользуется, но по своему опыту знаю, что это способ реально действенный, если у вас есть хорошая репутация. Можно самому выбрать компанию или проект над которым ты хочешь работать и попробовать связаться с его руководством по телефону, емайл, мессенджеру, либо как-то еще. Если правильно продать себя, то можно получить действительно тот проект и ту работу, которую сам хочешь, а не удалять десятки массовых спамов от рекрутеров компаний, которым в принципе всё равно на вас лишь бы хоть кого-то нанять.
  • Лёгкое программирование: канбан-доска для GitLab за один рабочий день
    +1
    А чем Trello не зашло?
    Ведь то, что у вас в итоге получилось ничем не отличается от trello с интеграцией gitlab.