Комментарии 84
Прям до слез…
Про чужой код конечно правда, но даже свой через какое то время начинает колоть в глаза.
От себя бы добавил:
Отсутствие интересных задач. Иногда везет, и ты разрабатываешь какой-то хитрый плагин или модуль, или оптимизируешь какое-то место в системе, что приводит к ускорению алгоритма в несколько раз.
Но когда доходит до: «сдвинь кнопочку на три пикселя вправо, добавьте то, добавьте это» — когда требуются чисто технические навыки без фактического размышления и оригинальности — подобные задачи просто выматывают за несколько часов.
Отсутствие интересных задач. Иногда везет, и ты разрабатываешь какой-то хитрый плагин или модуль, или оптимизируешь какое-то место в системе, что приводит к ускорению алгоритма в несколько раз.
Но когда доходит до: «сдвинь кнопочку на три пикселя вправо, добавьте то, добавьте это» — когда требуются чисто технические навыки без фактического размышления и оригинальности — подобные задачи просто выматывают за несколько часов.
6. Мержиться — действительно самое неприятное в профессии…
НЛО прилетело и опубликовало эту надпись здесь
Слияние двух веток от одного ствола — это еще терпимо. Гораздо хуже, когда есть две главные ветки проекта. Скажем, 1.х и 2.х. И временами надо добавлять изменения из версии 2.x в 1.х или наоборот. Скажем, патчи безопасности. И это всегда боль и страдание.
Самое худшее в моей жизни это патч 3.х кодом из 8.х. За пять лет там ВООБЩЕ ВСЕ поменялось. И вместо мержа пришлось переписывать код с тем же фиксом.
Еще более страшный случай делал мой коллега — патч 2.х из 8.х. Там были разные системы управления кодом.
Тут, на мой взгляд, вопрос к вашему подходу (gitflow) и необходимости таких операций.
Почти всегда когда что-то получается через боль и страдание стоит задуматься — может быть я что-то делаю не так?
Почти всегда когда что-то получается через боль и страдание стоит задуматься — может быть я что-то делаю не так?
Почти всегда когда что-то получается через боль и страдание стоит задуматься — может быть я что-то делаю не так?
Не автор, но no problem, let's go:
->патч 3.х
«Был молод и не опытен»/«технологическая эпоха была иной»
->из 8.х.
«уже все делается как надо»
может быть я что-то делаю не так?
Не смог продать клиенту v8 в силу различных причин?
Резюме — вовсе не обязательно, что человек делает что-то не так. Наоборот, пример, разбираемый выше, — это случай, когда даже древние системы пытаются патчить от текущих уязвимостей и/или ошибок.
Что-то не так вы мержите… Что может быть неприятного?
Попробуйте мёржить хромиум. В каком-нибудь своём браузере (производном от хромиума).
Раз в полтора месяца приходится дорабатывать свой замечательный, отлаженный код, просто чтобы он снова начал собираться. Потому что гугл взял и в очередной раз напрочь отрефакторил какой-нибудь кусок хромиума, который у вас используется.
НЛО прилетело и опубликовало эту надпись здесь
У меня вчера впервые появился баг, на который потратил ЦЕЛЫЙ день, но в конце таки нашёл причину (банально неожиданные входные данные). Это было так убийственно для нервов, что чуть не переросло в нервный срыв.
В статье написано, что иногда причина бага ищется даже дольше О_о
У кого-то такое было?
В статье написано, что иногда причина бага ищется даже дольше О_о
У кого-то такое было?
У всех, кто пренебрегает unit test-ами может легко и непринуждённо возникнуть баг вида «неожиданные входные данные». И без этих самых unit test-ов на его поиск может понадобиться и больше чем день.
P.S. Ник у вас хороший…
P.P.S. Есть намного более страшный сон программиста — когда надо делать мерж между двумя разными системами управления исходным кодом (и не спрашивайте меня, зачем компании понадобилось использовать две разных системы внутри одного проекта)
P.S. Ник у вас хороший…
P.P.S. Есть намного более страшный сон программиста — когда надо делать мерж между двумя разными системами управления исходным кодом (и не спрашивайте меня, зачем компании понадобилось использовать две разных системы внутри одного проекта)
У всех, кто пренебрегает unit test-ами может легко и непринуждённо возникнуть баг вида «неожиданные входные данные».
Это зависит не только от наличия юнит-тестов, но и от их качества. Да и не всё возможно покрыть автоматическими тестами, хотя таких случаев относительно мало.
И да: вряд ли невозможно покрыть тестами то, что должно проверять входные данные; здесь больше вопрос к качеству таких тестов.
НЛО прилетело и опубликовало эту надпись здесь
Всё-таки «юнит-тестами и сильной статической типизацией»
НЛО прилетело и опубликовало эту надпись здесь
Я согласен, что с сильной статической типизацией отпадает необходимость в значительной части юнит-тестов — например, нет необходимости проверять случаи, когда в функцию передают строку вместо int. Но входные данные могут подходить по типу, но быть «неожиданными» по значению.
НЛО прилетело и опубликовало эту надпись здесь
Я как-то потратил почти 3 дня на поиск бага. И там был полный треш связанный с тем, что usermode программа падала из-за кривого драйвера, который перетирал fpu-регистр в softirq. В общем, все это было очень и очень весело)
День — это не страшно. Были у меня баги которые кочевали от одной версии игры к другой, и таким образом жили один — два года. А ведь много редко-воспроизводимых багов так ни когда и не будет найдено
Целый день — это ещё по-божески. Я пару раз искал проблемы пару недель! Пару недель, чтобы где-то просто в коде добавить буквально пару строк! Вот это был полный абзац — уволиться хотелось, я кажется даже во сне анализом занимался)
Наверно, перепробовали всё, что можно? Локализовали-то хоть быстро?
В вышеприведённом случае было несколько плат с FPGA, стыки — самописные интерфейсы. Внутри ПЛИСов — модули ЦОС с интерфейсами частично на IP ядрах (например, fifo там всякие с SPI или FSL), частично — самописные интерфейсы. Внутри одного ПЛИСа процессор на HDL (IP ядро), внутри которого программа крутится. Источник данных — в одном из ПЛИСов, выход по финалу — в Ethernet. И в этой системе, на приличных скоростях, прокачивается немаленький объём данных и где-то портится иногда один пакет. Испортиться может где угодно) Год всё работало нормально и уже считалось надёжным. Когда локализовал проблему, дальше уже как-то попроще — либо аналитически в код пятилетней давности втыкать (не всегда результативно), а параллельно, раз не знаешь почему, встраиваешь по маршруту данных внутрисхемный отладчик, набираешь статистику и потом сидишь и думаешь. Работа по сути идиотская, но её делать больше просто некому, т.к. исследователь должен понимать работу системы на низком уровне.
Как-то вылез косяк — непонятно почему пропадал ВЧ сигнал на выходе. После переинициализации всё заводилось, но осадочек оставался, тем более у нас не та техника, в которой допустимо оставлять косяки. Пока это было не критично — этим не занимались. На протяжении пары месяцев заметили, что это вроде бы обычно в первой половине дня происходит. Последовательность команд, приводившая к ситуации могла быть любой. Когда занялся вплотную — неделя убилась на ловлю глюка. Он мог в один день пару раз проявиться, а мог 3-4 дня не проявляться. Я уже в отладчик вывел почти все сигналы управления — хрен знает, что делать, но что-то делать надо. Хотел свалить всё на аппаратчиков — какого фига что-то происходит, если мы ничем не управляем! Но нашёл) Девайс с утра стоял и грелся. Грелся и грелся… Когда прогревался до определённой температуры, в процессоре срабатывал алгоритм динамической подстройки выходной мощности, программа в процессоре крутилась по кругу и если после срабатывания алгоритма передать определённую команду в «неудачное» время, то кратковременно выдавалась команда на отключение. Понятно почему и проявлялось это исключительно до обеда — если эта ситуация «проскальзывала», то потом всё работало вполне себе спокойно)
Как-то разбирались почему после отправки команды на волшебный адрес вешалась вся система. Вот вообще вся. И всё бы ничего, но по телеметрии всё работало без нареканий и хоть каких-то намёков. Тут вот ушло только два дня. Один день ушёл на осознание и офигевание «как такое может быть»? А второй — уже более спокойно я выяснял какой и где интерфейс подвис. По финалу дня оказалось что на низком уровне система работает — телеметрия не врёт. «Чё за хрень»? Решилось аналитически, опять же надо было очень хорошо понимать низкий уровень. Один девайс отправляет другому пакет. Второй девайс должен его передать дальше, но в нём была старая прошивка с нескорректированной маршрутизацией и он этот пакет в соотвествии со своей таблицей маршрутизации заворачивал на первый девайс, переставляя адреса абонентов. Первый девай получал пакет, ну что делать — раз пришло, надо обрабатывать, системе управления типа виднее и в соответствии со своей таблицей маршрутизации происходила передача в блок обработки, который идентифицировал, что пакет мол не мой, переставлял адреса абонентов в пакете и выдавал обратно. Опять пакет улетал второму устройству и так далее. В результате одна команда передачи данных запускала в систему пакет, который там летал по петле на сумашедших скоростях, не давая отбиться таймаутам в интерфейсах. Ситуация красивая в том плане, что, когда набралось понимание по низкому уровню пришлось реально головой подумать и пофантазировать, а во-вторых — это не баг и не косяк, это кто-то, возможно даже я, не обновил везде прошивку на актуальную, но соль ситуации такова, что уже всем было на это пофиг если это починилось )))
Я думаю у каждого разработчика есть таких случаев в кармане тележечка. А если уж с железом плотно работаешь — и того подавно.
Как-то вылез косяк — непонятно почему пропадал ВЧ сигнал на выходе. После переинициализации всё заводилось, но осадочек оставался, тем более у нас не та техника, в которой допустимо оставлять косяки. Пока это было не критично — этим не занимались. На протяжении пары месяцев заметили, что это вроде бы обычно в первой половине дня происходит. Последовательность команд, приводившая к ситуации могла быть любой. Когда занялся вплотную — неделя убилась на ловлю глюка. Он мог в один день пару раз проявиться, а мог 3-4 дня не проявляться. Я уже в отладчик вывел почти все сигналы управления — хрен знает, что делать, но что-то делать надо. Хотел свалить всё на аппаратчиков — какого фига что-то происходит, если мы ничем не управляем! Но нашёл) Девайс с утра стоял и грелся. Грелся и грелся… Когда прогревался до определённой температуры, в процессоре срабатывал алгоритм динамической подстройки выходной мощности, программа в процессоре крутилась по кругу и если после срабатывания алгоритма передать определённую команду в «неудачное» время, то кратковременно выдавалась команда на отключение. Понятно почему и проявлялось это исключительно до обеда — если эта ситуация «проскальзывала», то потом всё работало вполне себе спокойно)
Как-то разбирались почему после отправки команды на волшебный адрес вешалась вся система. Вот вообще вся. И всё бы ничего, но по телеметрии всё работало без нареканий и хоть каких-то намёков. Тут вот ушло только два дня. Один день ушёл на осознание и офигевание «как такое может быть»? А второй — уже более спокойно я выяснял какой и где интерфейс подвис. По финалу дня оказалось что на низком уровне система работает — телеметрия не врёт. «Чё за хрень»? Решилось аналитически, опять же надо было очень хорошо понимать низкий уровень. Один девайс отправляет другому пакет. Второй девайс должен его передать дальше, но в нём была старая прошивка с нескорректированной маршрутизацией и он этот пакет в соотвествии со своей таблицей маршрутизации заворачивал на первый девайс, переставляя адреса абонентов. Первый девай получал пакет, ну что делать — раз пришло, надо обрабатывать, системе управления типа виднее и в соответствии со своей таблицей маршрутизации происходила передача в блок обработки, который идентифицировал, что пакет мол не мой, переставлял адреса абонентов в пакете и выдавал обратно. Опять пакет улетал второму устройству и так далее. В результате одна команда передачи данных запускала в систему пакет, который там летал по петле на сумашедших скоростях, не давая отбиться таймаутам в интерфейсах. Ситуация красивая в том плане, что, когда набралось понимание по низкому уровню пришлось реально головой подумать и пофантазировать, а во-вторых — это не баг и не косяк, это кто-то, возможно даже я, не обновил везде прошивку на актуальную, но соль ситуации такова, что уже всем было на это пофиг если это починилось )))
Я думаю у каждого разработчика есть таких случаев в кармане тележечка. А если уж с железом плотно работаешь — и того подавно.
А я дней 10 ждал, пока симуляция post-translate добежит до нужной точки, на которой сбой наблюдался. Причём симуляция полной модели нехилой такой системы из нескольких плат с парой десятков FPGA. Когда в итоге нашёл косяк в одной из прошивок (не моего авторства) с трудом сдержался от членовредительства, т.к. автор этой прошивки был убеждён, что проблема в моей части.
Я так наоборот всегда радуюсь, когда нахожу не свой косяк. Идёшь к кому надо и радостно делегируешь проблему. Правда бывает, что к кому идти непонятно, а чуть позже следствие устанавливает, что человек уже уволился пару лет назад, никто ничего естественно не знает (в том числе не помнит и сам создатель проблемы) и теперь этот косяк — твоя проблема ;)
Я не разбираюсь в таких устройствах. С моей колокольни в идеале, наверное, было бы протестировать каждое устройство отдельно для всех случаев.
Всё верно, каждый программный модуль должен моделироваться и в тесте, перебирая различные входные воздействия, должно становиться понятно, что он будет нормально работать. Проблема в том, что порой тесты получаются времязатратны, а порой чуть ли не сложнее самих этих модулей. А так же есть небольшой момент: когда вроде бы оттестированные модули собираешь в проект где-то что-то может вылезть — или в тесте такую ситуацию не догадались посмотреть, или изначально не продумали протокол стыковки, или теперь надо быстренько и качественно кое что изменить. Жизнь, в общем, она такая, да)
У меня в начале карьеры был баг, который я не мог исправить в течение наверно недель двух или трех. Причина была в том, что где-то в коде из-за вызова static_cast вместо dynamic_cast портилась память.
Самое смешное, что когда натыкаешься на такие баги, то через некоторое время поиска причины, то тебе начинает казаться, что причина во фреймворке, ос, драйверах, но не в твоем коде.
Самое смешное, что когда натыкаешься на такие баги, то через некоторое время поиска причины, то тебе начинает казаться, что причина во фреймворке, ос, драйверах, но не в твоем коде.
Я в прошлом году потратил три дня на поиска проблемы которая проявлялась в том что сообщения между двумя частями в browser extension переставали приходить после примерно 2-3 сообщений. С учётом того что из-за особенностей платформы (Firefox WebExtensions который на тот момент ещё не зарелизился) единственным доступным мне способом отладки была запись в логи — это было "весело", к третьему дню я реально начал сомневаться — а не сошёл ли я, случаем, с ума?
В итоге причину я всё-таки нашёл и она, как и почти всегда в подобных случаях, была тривиальной, но неожиданной:
Для передачи сообщений между частями browser extension используется отсылка сообщений через порт. Для передачи / получения сообщений открывается порт и в обработчике события открытия порта на него вешается обработчик для получения сообщений. Всё было настроено и работало, но я не учёл что во внешней библиотеке, которую я использовал, открывался аналогичный порт, но позже чем мой порт (как раз я за время пока второй порт не открылся успевал передать те 2-3 сообщения которые проходили). В момент открытия порта мой обработчик события открытия порта вызывался, сохранял ссылку на новый порт и вешал на него свои обработчики. Но поскольку порт был уже другим — я начинал получать не свои сообщения, а сообщения внешней библиотеки которые мне были не нужны.
В общем всё решилось банальной проверкой корректности имени порта (1 условие), но нервов на эту строчку ушло очень много :) В коде приложения до сих пор стоит подробный комментарий с припиской: "Takes me 3 days of debugging to figure it out, valuable information :) "
Напоминает главное огорчение миллиардеров — бриллианты мелкие.
«Обнаружение трудновоспроизводимого или, что хуже всего, проявляющегося на интеграционном тесте бага, который случайно проходит или сбоит на одном и том же куске кода!!! Потом создаётся ощущение, что ты никогда не сможешь найти эти проклятые таинственные баги, прячущиеся где-то в коде. Фу!» Emmanuel Ngwane
Особенно весело бывает, когда причина сбоя обнаруживается на совсем другом куске кода, а не на том, на котором сбоит.
Хуже всего, когда трудновоспроизводимый баг оказывается заложен в микросхеме от крупного производителя, а техподдержка не отвечает ничего более вразумительного чем «обычно эту микросхему используют вот так, и всё работает». Приходится долго танцевать с бубном или переделывать пол проекта.
«Обнаруживать код, написанный кем-то, кто вообще не имел должной квалификации для его создания…» — лично для меня — самое неприятное и затратное по времени. Человек пишет код типа Вообще, если работали с западными заказчиками — там количество копи-пасты зашкаливает все разумные пределы!
Необходимость переключаться с одной задачи на другую — более срочную. А потом через месяц, когда ты основательно «выпал из контекста», возвращаться к той недоделанной. И, конечно, потом это всё мёрджить!
Это еще по божески.
Был пару лет назад случай. Прилетает задача, срочно бросай все и срочно делай. Делаю, реализую, передаю, а заказчик ушел в декрет. И как спустя еще неделю переписки выяснилось, никому кроме заказчика эта фича не была нужна.
Но что самое веселое. Месяца 3 назад, задача прилетает обратно, заказчик вышел из декрета.
Хорошо не потерял свои наработки еще за 2 года.
Был пару лет назад случай. Прилетает задача, срочно бросай все и срочно делай. Делаю, реализую, передаю, а заказчик ушел в декрет. И как спустя еще неделю переписки выяснилось, никому кроме заказчика эта фича не была нужна.
Но что самое веселое. Месяца 3 назад, задача прилетает обратно, заказчик вышел из декрета.
Хорошо не потерял свои наработки еще за 2 года.
11. Когда ты хочешь с кем-нибудь пообщаться, все вокруг заняты какой-то ерундой, но делают вид, что работают. А стоит тебе заняться задачей, от которой вот-вот закипит мозг, как все начинают лезть к тебе с дурацкими разговорами или болтать между собой о всякой ерунде…
Работа с чужим кодом вызывает большее раздражение, когда автор его не только не документирует, но и использует странный стиль, который не используется другими разработчиками. Тем более, когда код почти или полностью состоит из «костылей», которые вот-вот могут сломаться из-за перехода на что-то новое.
Был как-то один проект на чистом С, с неблокируемыми сокетами, с реализацией одного закрытого протокола методом реверс-инжиниринга и подглядыванием в «какую-то версию сервера, исходники которого получилось достать»… и так понравился чистый С..., ЛЮБОЙ баг — и он ругается Segmentation Fault… спасал только gdb и доста детальные логи…
но один из «мистических багов» искался недели 2-3, возникал где-то каждые 2-3 часа при 10 000 активных ТСР соединений, в одном их них… после бесконечных крешдампов, килограмов логов была обнаружена ошибка: в каком-то одном забитом месте вместо int надо было поставить unsigned int )))))
В этом жеж проекте было особенно весело находить баги и дыры в безопасности в самом протоколе, и в тех-жеж проектах которые мы «реверс-инжинирили»)))
но один из «мистических багов» искался недели 2-3, возникал где-то каждые 2-3 часа при 10 000 активных ТСР соединений, в одном их них… после бесконечных крешдампов, килограмов логов была обнаружена ошибка: в каком-то одном забитом месте вместо int надо было поставить unsigned int )))))
В этом жеж проекте было особенно весело находить баги и дыры в безопасности в самом протоколе, и в тех-жеж проектах которые мы «реверс-инжинирили»)))
А как же прокрастинация у творческих личностей, в случаях когда попадается нудная задача?
Писать код в одно лицо, основываясь на коде огромного старого проекта (из-за нехватки времени 90% кода сохраняется, но в нём ещё нужно разобраться) без документации, при этом написанного на языке, который не знаешь. True story.
Нашел я как-то неуловимый тупой баг в легаси коде, который периодически появлялся у одного пользователя из десяти. Пофиксил, отправил на тест, так тестеры не смогли воспроизвести этот баг и закрыли проблему с комментами, что бага нет.
- Работать с легаси где весь нейминг (переменные, класс, бд) и комментарии на голландском :)
Для меня самое большое мучение — это ежедневное восьмичасовое отсиживание. В обед обязательно пешком иду до столовой, затем гуляю по окрестностям, но всё равно заряда бодрости хватает лишь на на первые шесть часов. Последние два часа рабочего дня превращаются реально в пытку, ноги, спина устают сидеть в одной позе и как ты не пытаешься их поменять — не помогает.
При этом я заметил, что дома на выходном я могу провести за компьютером и 14 часов. Проанализировав свои действия, пришёл к выводу, что дома, не задумываясь об этом, регулярно встаю, могу просто ходить кругами, обдумывая код, могу лечь на пол (какой же это кайф — лежать на твёрдой поверхности) и смотреть в потолок, могу встать и приняться ритмично отбивать ритм барабанными палочками по тренировочному пэду, тоже при этом размышляя.
Это всё такие мелочи, копеечные, но обидно, что они отделяют продуктивную деятельность от непродуктивных мучений. И ни работодатель, никто об этом не знает, я мучаюсь просто зазря и конца этому не видно.
При этом я заметил, что дома на выходном я могу провести за компьютером и 14 часов. Проанализировав свои действия, пришёл к выводу, что дома, не задумываясь об этом, регулярно встаю, могу просто ходить кругами, обдумывая код, могу лечь на пол (какой же это кайф — лежать на твёрдой поверхности) и смотреть в потолок, могу встать и приняться ритмично отбивать ритм барабанными палочками по тренировочному пэду, тоже при этом размышляя.
Это всё такие мелочи, копеечные, но обидно, что они отделяют продуктивную деятельность от непродуктивных мучений. И ни работодатель, никто об этом не знает, я мучаюсь просто зазря и конца этому не видно.
удаленная работа же
Искренне сочувствую вам, у меня начальство к этому вопросу подошло с пониманием.
Помогает регулярное наливание новой чашки чая — дойти до стола с чайником, наклониться, поднять чайник, держа чайник на весу, налить воду в чайник, наклониться, поставить чайник. Наклрниться за пакетиком чая, затем за сахаром. Держа на весу чашку с кипятком, дойти до своего стола и поставить чашку на блюдце, не пролив чай на стол. Если пролил — вернуться к общему столу, поднять рулон бумажных полотенец, оторвать, вернуться к своему столу. А если в чайнике нет воды — то надо сходить с ним до кулера. И так до 4-5 раз за рабочий день.
А на обед можно и в дальнее кафе сходить — 10 минут туда, 10 обратно.
А Вы — неподвижно сидеть! Просто не надо держать пиво в холодильнике у компа. :-)
А что мешает на работе регулярно вставать и ходить кругами?
Прочитал Ваш коммент, как будто в зеркале своё отражение увидел )) Если на работодателя повлиять не получится, нужно менять работу
И ни работодатель, никто об этом не знает, я мучаюсь просто зазря и конца этому не видно.
Так может вы культурно донесёте работодателю свою проблему? Сейчас же уже официально есть в ТК понятие «дистанционная работа», когда сотрудник делает всё то же самое, что и в офисе, только дома. И оформляется это, судя по тому что я читал в обзорах ТК, без особого головняка и для сотрудника и для предприятия.
А как же, когда фича, на которую ушли недели-месяцы внезапно становится ненужной и её нужно переписать или вовсе выкинуть?
Причём порой ощущение, что чем тщательней и ответственней ты подходишь к её разработке, тем больше вероятность, что от неё скоропостижно избавятся, и наоборот — код написанный на коленке для галочки будет жить вечно.
Причём порой ощущение, что чем тщательней и ответственней ты подходишь к её разработке, тем больше вероятность, что от неё скоропостижно избавятся, и наоборот — код написанный на коленке для галочки будет жить вечно.
Я бы добавил сюда низкую ЗП при высоких запросах )))
Был интересный случай, когда бухгалтера попросили заменить лампочку в офисе ответив на мой вопросительный взгляд «Че, тыж программист!»
Нужно изначально нормально писать код, чтобы потом не доходить до белого каления в поисках багов.
еще…
0. Отсутствие четкого ТЗ по задачам
Нужно «чё-то вот такое» сделать
0. Отсутствие четкого ТЗ по задачам
Нужно «чё-то вот такое» сделать
НЛО прилетело и опубликовало эту надпись здесь
По факту только 2 3 и 6 и 9(и то в некоторых офисах эта проблема решена) пункты. Остальные просто нытьё.
Самое тяжёлое — финальная доводка программы под живого пользователя. Всё уже сделано, всё работает, ничего интересного не осталось… а впереди ещё примерно столько же работы, сколько уже проделано. Именно этим работа прикладного программиста страшнее создания какого бы то ни было ядра, хоть чуть отделённого от живых людей. И никакое знание тонкостей организации памяти или методик поиска в небинарном дереве тут не поможет.
Спасибо! Покажу руководству.
1x. Догматические методологии «на все случаи жизни».
Которые выливаются в нечто типа «Мы не должны тратить много времени на брэйнсторм и планирование (Боже упаси, это Waterfall), но дайте нам четкий список того, что будет сделано к следующему релизу (или тоже самое с другого конца: „когда будет завершена эта фича?“).
Которые выливаются в нечто типа «Мы не должны тратить много времени на брэйнсторм и планирование (Боже упаси, это Waterfall), но дайте нам четкий список того, что будет сделано к следующему релизу (или тоже самое с другого конца: „когда будет завершена эта фича?“).
НЛО прилетело и опубликовало эту надпись здесь
Это уже какие-то придирки. Вникание в области, в которых и работает ПО — это обязательное условие нормального понимания задачи. Не представляю как можно написать бухгалтерское ПО не вникая в бухгалтерию…
Другой вопрос, насколько глубоко нужно вникать. А «огорчение» — это когда вникать приходится самостоятельно, а не с помощью специалиста указанной области.
Другой вопрос, насколько глубоко нужно вникать. А «огорчение» — это когда вникать приходится самостоятельно, а не с помощью специалиста указанной области.
Хорошая работа, но как пожар, так хоть увольняйся.
НЛО прилетело и опубликовало эту надпись здесь
Картинка в топике. Показалось что палят по дискете 5,25", а может даже 8"… увы, а ведь было бы символично.
Я бы добавил работу со старым (legacy) кодом на старых технологиях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 главных огорчений программистов