• Мотивация сотрудников: правила офисной дипломатии
    –2
    Весьма «водный» текст. Бросился в глаза абзац «ненависти к теоретикам», по меньшей мере странная реакция на людей с хорошим теоретическим базисом.
  • О том, что убивает продуктивность разработчиков
    –1
    На сцене появилась история и гражданские генералы? Это уже было, директора колхозов, рулящие дивизиями и не знавшие с какой стороны пуля из ствола вылетает. Правда потом супостат купался в Крыму, стоял на Волге и катался в Сокольниках на мотоциклах.
    Ладно, я не любитель пустых споров, творческих успехов вам.
  • О том, что убивает продуктивность разработчиков
    0
    В армии отлично бы смотрелось — «офицеры не должны быть военными, пусть будут одни доверенные солдаты, которые не дадут другим недоверенным солдатам обмануть балбесов-командиров». Просто блеск
  • Особенности национального менеджмента
    +1
    феерический бред и собрание комплексов и обид автора
    — это я просто без комментариев оставлю. Увы. Далее, по сути
    Где нормальные типы менеджеров? Которые изначально готовились как менеджеры, а не ломали карьеру, переходя из исполнителей в руководители?

    А действительно, где? Где, как, кем осуществляется подготовка кадров на позиции менеджеров программных проектов? Было бы замечательно с ссылкой на учебный план и учебное заведение. Может я слона то не приметил, и все здорово в датском королевстве.
  • Три дня, которые потрясли нас в 2013
    –8
    Разработчик, создававший и тестировавший шаблон

    Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла

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

    Понятно почему у вас бажные скрипты выполняются в бажном кастомном интерпретаторе, а потом все валиться.

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

    Вы считаете это хорошей архитектурой?

    В извлечении уроков я не увидел ничего, касающегося пересмотра архитектурных подходов.

    P.S. Избавьте от этих вопросов для самопроверки, в данной ситуации на двоешников похожи больше вы.
  • Как я стал программистом. Путь от питерского бездомного до Senior Developer-а за 6 лет
    0
    Мне к сожалению реально лень в тысячу первый раз устраивать дебаты на эту тему, если считаете что полноценный инженер возможен без профильного высшего образования — всякое мнение имеет право быть. Наверное имеет.
  • Как я стал программистом. Путь от питерского бездомного до Senior Developer-а за 6 лет
    0
    Автор, импонирует Ваша история. Надеюсь не произошло «головокружение от успехов» и в Ваших планах есть получение высшего профильного образования, то бишь переход из состояния талантливого самоучки в состояние дипломированного специалиста.
  • История одного факапа или почему итеративность — это необходимое, но не достаточное условие для Agile
    +1
    Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;


    Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
  • Data Access Object (DAO). Уровень класса
    +1
    getPrepareStatement и closePrepareStatement как protected смотрелись бы лучше
  • Куда пойти учиться на программиста
    0
    Вы понимаете разницу между «помимо» и «затачивает»?
  • Куда пойти учиться на программиста
    +2
    Программная инженерия

    Относительно новая специальность, готовящая по сути менеджеров программного продукта. Этот специалист смотрит поверх задач разработки, управляет требованиями, функционалом, версиями, командами разработки. На первых курсах вы изучите технологии программирования и, возможно, пару языков, но дальше в учебном плане будет всё больше про управление разработкой ПО. Начинать карьеру можно как Junior Developer, но вместо дальнейшего апгрейда до Middle вы станете менеджером проекта.


    Автор, ну не надо писать ахинею и вводить детей и прочих абитуриентов в заблуждение.
  • Что нам готовит C# 7 (Часть 1. Кортежи)
    +1
    Не будет, но теперь +1 способ сломать первую буковку из SOLID, при чем довольно удобный. Опять оговариваюсь — в кривых ручках.
  • Программисты не понимают
    +19
    Тут идет жонглирование двумя понятиями — стратегией продаж и качеством продукта. Покупая авто даже в самой убогой комплектации, покупатель никогда не получит машину с разной компрессией в цилиндрах, отваливающимся глушителем и дырявым бензобаком. Маркетинговая стратегия в компании автора видимо такая — срубим заказ, выставя зараннее зауженные сроки реализации, загоним разработчиков в перегорание и хронический стресс, поставим клиенту говно, потом под соусом «доработки под заказчика» будем допиливать то, что валится слишком явно. А потом еще, на десерт, подпишем клиента на поддержку продукта, потом что багов в таком говнософте предостаточно, и они будут периодически всплывать.

    Браво, бис!
  • Что нам готовит C# 7 (Часть 1. Кортежи)
    +1
    А что заминусовали js605451?

    Он прав, это будет провоцировать сode smells в неумелых ручках.
  • Твой код никого не интересует
    0
    Нет, мой манифест — манифест человека, который много часов и нервных клеток потратил на разгребание «макарон», оставшихся после таких «творцов».
  • Твой код никого не интересует
    +2
    Написание кода не является работой программиста. А является ей создание приложения для решения определенных задач.

    А код и приложение — это какие- то ортогональные вещи? После этой фразы читал уже по инерции. Не статья, а манифест говнокодера.
  • Post Hawk. Перезагрузка
    0
    Во-первых — удачи Вам в этом начинании, идея мне понравилась.

    Во-вторых, по сайту, в качестве контруктивной критики — очень не понравился шрифт в навбаре, раскалывает все впечатление от дизайна страницы, ИМХО.
  • Бизнес vs программная инженерия
    0
    У меня нет конкретных мыслей как все правильно делать, если нет конкретной вводной.

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

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

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

    Возможно ошибка, что Вы сделали ставку на людей из академической среды, плюс не имевших опыта конкретно в этом виде деятельности. Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом. Самые лучшие практики, использованные не по назначению, разумеется могут дать противоположенный эффект, тут нет ничего удивительного.
  • Бизнес vs программная инженерия
    0
    Для этого не обязательно учиться в вузе вообще.
    ?

    -Участвовать в проведении научных исследований (экспериментов, наблюдений и количественных измерений) программных продуктов, проектов, процессов, методов и инструментов программной инженерии
    -Заниматься построением моделей программных проектов и программных продуктов с использованием инструментальных средств компьютерного моделирования
    -Составлять описания проводимых исследований, готовить данные для составления обзоров и отчетов
    -Заниматься сбором и анализом требований заказчика к программному продукту
    -Помогать заказчику в оценке и выборе вариантов программного обеспечения
    -Участвовать в составлении коммерческого предложения заказчику, готовить презентации и согласовывать пакет договорных документов
    -Проектировать компоненты программного продукта в объеме, необходимом для их конструирования в рамках поставленного задания
    -Создавать компоненты программного обеспечения (кодирование, отладка, модульное и интеграционное тестирование)
    -Выполнять измерения и рефакторинг кода в соответствии с планом
    -Заниматься разработкой тестового окружения и созданием тестовых сценариев
    -Разрабатывать и оформлять эскизную, техническую и рабочую проектную документацию
    -Осваивать и применять средства автоматизированного проектирования, разработки, тестирования и сопровождения программного обеспечения
    -Осваивать и применять методы и инструментальные средства управления инженерной деятельностью и процессами жизненного цикла программного обеспечения
    -Осуществлять контроль, оценку и обеспечение качества программной продукции
    -Обеспечивать соответствие разрабатываемого программного обеспечения и технической документации российским и международным стандартам, техническим условиям, нормативным документам и стандартам предприятия
    -Участвовать в процессах разработки программного обеспечения
    -Участвовать в создании технической документации по результатам выполнения работ
    -Проводить обучение и аттестацию пользователей программных систем
    -Участвовать в разработке методик обучения технического персонала и пособий по применению программных систем
    -Участвовать в составлении технической документации (графиков работ, инструкций, планов, смет, заявок на материалы, оборудование, программное обеспечение)
    -Планировать и координировать работу по настройке и сопровождению программного продукта
    -Организовывать работу малых коллективов исполнителей программного проекта
    -Вводить в эксплуатацию программное обеспечение (осуществлять инсталляцию, настраивать параметры, адаптировать, администрировать)
    -Осуществлять профилактическое и корректирующее сопровождение программного продукта в процессе эксплуатации
    -Обучать и консультировать пользователей по работе с программной системой

    Чем быдлокодер, получившийся в результате неких «курсов», отличается от инженера по разработке ПО, можно попытаться понять например тут.
  • Бизнес vs программная инженерия
    +1
    Возможно тут дело просто в монополизации сегмента рынка ПО и, как следствие, зашкаливающем «борзометре» у монополиста.
  • Бизнес vs программная инженерия
    +1
    Код метода в 342 строки — это очевидное нарушение одного из базовых принципов проектирования ПО, single responsibility principle. И это не «техническая деталь», с которой «знакомиться там и место», а то, что превратит код проекта в «большой ком грязи», ну или «спагетти-код», кому как нравится.

    Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
  • Бизнес vs программная инженерия
    +1
    Красота кода — это не главный критерий, код не картина и не женщина, главный критерий — эффективность. Красота это производная эффективности скорее…

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

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

    Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.

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

  • Бизнес vs программная инженерия
    +1
    Уважаемый krasko, в последних двух абзацах я не написал ничего, что относится к этой замечательной цитате.

    Музыкант не должен играть без нот, а инженер работать
    «with little or no idea of the mathematical underpinnings of what they are doing»
    Но! Математика для инженерии и инженерия для математики — это две большие разницы. Я видел senior'ов с «solid mathematical background», но не знающих, что код метода не должен быть длиной 342 строки.

    Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
  • Как улучшить свой стиль программирования?
    0
    Подписываюсь тут под каждым словом.

    Плюс — дело не только в грамотно нормализованной модели, знании SOLID и О-нотации, дело вообще в таком замечательном понятии как «обеспечение качества ПО». Вот с пониманием что это такое, у бизнеса реально большие проблемы. Что наплевательское отношение к такой на первый взгляд хрени, как проектирование классов и интерфейсов, как рефакторинг и код ревью, в общем к тому, на чем бабки не отбить, в дальнейшем выливается в бесконечные багфиксы и кастомер инциденты.

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

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

  • Еще одна книга о паттернах? Дайте две!
    +1
    Считайте меня волонтером в таком случае, будет интересно принять участие.
  • Еще одна книга о паттернах? Дайте две!
    +1
    Мушкетеры Паттерны 20 лет спустя. Нет планов привлечь хабросообщество к написанию сего труда?
  • Путь к непрерывной интеграции. Selenium + TeamCity
    0
    Из-за «тести» сложно было на смысле текста сконцентрироваться.

    Если по сути — думаю не лучшая практика гонять автотесты на каждый чекин, там хватит и обычных юнит-тестов.
  • Эксперимент в Яндексе. Как идентифицировать взломщика с помощью машинного обучения
    –1
    Изучение поведенческих алгоритмов, психологический портрет… На приеме у психолога чтоли? Было бы разумно отдать на откуп решение таких вещей тем, кого яндекс собирается защищать — хочет человек, юзает вариант, описанный в статье, хочет — «простая» аутентификация без наворотов.
  • Началось создание «100-процентно российской программной платформы»
    +2
    Еще как клеили… Почитайте «Записки авиаконструтора» Яковлева, как начинался совдеповский автопром — брали чемодан денег и галопам по европам, скупать все лучшее, привозили, разбирали, снимали размеры и копировали. И кто-то даже на полном серьезе даже верит, что АК-47 сделал сержантик с 8 классами образования, и Хьюго Шмайссер тут не при чем:) Так что «заимствование лучших западных образцов» не вчера и не позавчера началось.
  • Началось создание «100-процентно российской программной платформы»
    +1
    Разумеется на десятилетия, но вполне возможно тут дело просто в уровне развития людей принимающих решения. «Старшие пацаны» привыкли другими делами заниматься, уж точно не реальным производством, этого по факту в РФ нет. А тут «грядка» совершенно незнакомая, но рефлексы то все те же — дадим бабок и все разрулят, и невдомек же что база, как кадровая, так и технологическая, тут даже не годами — десятилетиями нарабатывается.
    На банальный попил это уже не похоже — прилетел санкционный петушок к «старшим пацанам» и больно клюнул в зад.
  • «Не навреди», или Как не стать корпорацией
    0
    Созерцательность, выстраданность, глубина… хороший текст. Единственная по мне так «невкусная» метафора — это жизнь против течения.
  • Размышления о блюзе — еще раз про exception handling
    0
    В первом случае я имел ввиду поведение, контролируемое тем, что в нашем доморощенном переводе называется операционный уровень приложения, а в оригинале application layer. Сюда же с огромной натяжкой можно отнести контроллер из того же MVC-паттерна, к примеру. Это самый «высокоуровневый» код, который контролирует всякого рода мэнэджеры, хэлперы, контроллеры, и ту бизнесс-логику которую они отрабатывают, если речь идет про anemic domain model, или data driven design, если смотреть с точки зрения методологии проектирования, и контролирует фабрики, репозитории и агрегаты, если речь идет про domain driven design. То есть ближе всего use case соотносятся с методами именно application layer-а, и соответственно ответственность за некорректную отработку прецендентов было бы логично возложить именно на методы application layer-а. Это я имел ввиду, говоря про «код, наиболее близкий к клиенту» и «знающий больше всего про ожидаемое поведение».

    Далее по второму случаю, и тому, что будет делать обработчик — здесь банальное поддержание согласованности данных, когда это представляется возможным. Когда нет — падение с фиксацией описания ошибки для скорейшей локализации и расследования причин, ничего нового тут не сказал.
    habrahabr.ru/post/126374/ исходя из этой градации, думаю то, что я имею ввиду, относиться к строгой гарантии.
  • Размышления о блюзе — еще раз про exception handling
    0
    Про «литье воды» замечание принимаю, надо работать над стилем изложения, но все же надеюсь здравые зерна во всех этих рассуждениях есть.