Senior PHP Programmer
  • Новий скандал у Better: компанія вимагає від працівників повернути гроші за бонусні вихідні

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

  • «Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало

    Так — справа у вартості години роботи ))
    Крім того не завжди програмісти можуть взагалі написати зрозуміло документацію.
    На проекті було 2 тестувальники — як я бачу у статті, наврядче там є техрайтер.

    Чи не забагато відповідальность напрограміста?
    — знати всю систему (щоб розуміти впливи при розробці своєї фічі)
    — знати свою МП
    — знати як працює рушій БД на проекті
    — враховувати безпекові ризики при написанні коду
    — часто — бути фуллстеком
    — красномовно і швидко писати документацію
    — знати (часто додаткову) МП для написання автотестів
    — при цьому встигати писати якісний код у стиснуті терміни!
    — я так розумію реліз менеджмент теж на хлопцях
    — може ще скарги їм почати приймати від людей і відповідати, щоб менше часу минало від виявлення бага до його фіксу?

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

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

  • «Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало

    «После релиза обычно всплывало много багов, клиенты жаловались.»
    — Это вообще как? Зачем вы вообще релизились с багами?
    Если их не находили на этапе тестировани — надо просто менять тестировщиков.
    Если фича была плохо документирована и вылазило то, чего не тестировали — писать доки и, верочтно, все равноменять тестировщиков.

    «Обычно на этапе тестирования вылезало большое количество ошибок и мы не успевали их фиксить вовремя.»
    — Значит надо менять инженеров. Почему они так плохо проектировали фичи?
    На проекте вообще была дока?
    Вы понимаете что программист 90%времени думает и проектируе, 9% читает код и только 1% кодит?

    «При этом бывало, что у Олега Рогинского, нашего фаундера, через несколько дней после планирования релиза уже был назначен customer call, на котором он должен был презентовать новую фичу.»
    — Вот вам лайфхак. Один раз задержите выпуск одной фичи и после этого показываете ее уже готовую чрезе неделю в то время делаете фичи Б, В, Г ...
    — Кроме того это опять же проблема или отсутствия документации (зхнания инженерами системы) или отсутствие платирования при выполнении задач.

    Ребята — вы просто запретили инженерам косячить! «Типа я вроде сделал, а тестировщики пусть проверяют».

    Есть такое понятие в Scrum как Definition of Done. Можно ввечти такое правило что, задача отдается в тестирование только если разработчик видит, что она рабоатет по документации на тестовом окружении.
    Можно не давать премию, если любая задача вернулась к разработчику более 3х раз (для начала) в джите это отлично видно. И потом снижать порог.

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

    «Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA»
    — Значит это плохой QA, не зря есть анекдот

    Заходит однажды тестировщик в бар.
    Забегает в бар.
    Пролезает в бар.
    Танцуя, проникает в бар.
    Крадется в бар.
    Врывается в бар.
    Прыгает в бар
    и заказывает:
    кружку пива,
    2 кружки пива,
    0 кружек пива,
    999999999 кружек пива,
    ящерицу в стакане,
    —1 кружку пива,
    qwertyuip кружек пива.
    ’ or 1 == 1 кружек пива.

  • «Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало

    Ну та а регрессия?
    Хотя бы в связанных модулях.
    Рефакторинг как раз требует регрессии.

    Внутренние программы тоже можно тестировать.
    Как правило всегда есть долг по приведению документации в соответствие проекту.
    Если тестировщики толковые они могут писать или оптимизировать автотесты.

  • Колишній депутат Єгор Соболєв — про шлях в програмування: «В IT, на відміну від політики, захоплює комфортність оточення»

    Штирлиц никогда не был так близок к провалу как в этом комментарии)))

    Підтримав: Yuriy Sultanov
  • Почему продуктовым компаниям нужно уходить из-под крыла аутсорсинга, или Как пережить кризис

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

  • Team Performance Dashboard, или Как измерить реальную продуктивность сотрудников

    Почитав дискуссію у коментарях.

    Думаю, що автору трохи не вистачило висновків і вступу.
    Інструтент складний, бо орієнтований на багато внутрішніх замовників.

    1. Керівництво хоче знати чи переплачують вони співробітникам і наскільки.
    2. Співробітники хочуть розуміть чи буде у них премія та річна надбавка і як їх отримати.
    3. Рекрутери хочуть бачити чи схильний співробітних піти з продуктової компанії.

    Наприклад ось швидкі відповіді («у звичайномупроекті роблять так ...»):
    1. Замовити чи купити дослідження ринку праці по місту / країні. (навіть на ДОУ є просте опитування, щоб зорієнтуватись)
    2. Сформулвати 1-3 пріорітети (фічі, інтергаціх) на рік для кожного співробітника. І мініум поточних задач розв’язаних на місяць.
    3. Спостерігати на мітінгах чи за обідом, що людина не подає ідей, критикіє чужі, веде себе деструктивно.

    Тепер можемо порівняти ці дві системи і приймати рішення про впровадження:
    а) наскільки більш точна інформация від запроповованої системи?
    б) наскільки ця точність критична — я якісне покращення знанні про ринок і колектив, а також задоволенності співробітників прозорісстю КПІ?
    в) скільки часу (грошей) треба для підтримання цієї системи у рамках організації?

    На якому періоді часу проведено експеримент? (Хоча б рік минув)
    Скільки часу зайняло впровадження? (Інталяція, тюнінг параметрів, навчання користувачів)

    Ну і класичні проблема будь яких КПІ:
    — що міряємо — те люди і нарощують, причому дуже творчо :) з мініумом зусиль
    — якщо показників стає забагато, то люди припиняють паритися взагали. Занадто складно цілеспрямовано впливати на премію/підвищення

  • Microsoft купила GitHub за $7,5 млрд

    Вони навіть Minecraft зіпсували )

  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    По факту стаття вийшла про проблеми найму сіньорів.

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

    Але кори приходить ПМ/HR і питає які технології використовуютсья на проекті (навіть окремо у бекенді чи фронтенді) — він отримує свій фантастичний список :)

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

  • Анонс lang-uk: створюємо умови для повноцінної обробки україномовних текстів

    Я розраховував на публічну відповідь. За контакт дякую.

  • Анонс lang-uk: створюємо умови для повноцінної обробки україномовних текстів

    У статті ви пишите, що британці мали клопіт з тим, що корпус не можна використовувати у коменційних цілях. У вас, на гіті, теж ліцензія, яка передбачає тільки некоменрійне використання. Що мені робити, якщо мені потрібні тексти для створення ігри зі словами? Чи можу я використовувати github.com/brown-uk/corpus

    Підтримав: Андрій
  • Всего два выхода для честных ребят

    Как быть честным гражданам, которые не хотят гражданской войны?
    — сиди и работай, нет гражданской войны. Есть столкновения недовольных людей с коррупционной милицией и такимиже «мирными» бойцами оплота, с гранатами и пистолетами.

    А как насчёт регулярного безкаказанного превышения полномочий сотрудниками милиции? Эту ситуацию исправят перевыборы?
    Ведь именно это и бесит людей. С этого всё началось в декабре, это закреплено было в законах от 16 января.

  • Всего два выхода для честных ребят

    И случайно ВР рассмотрена свой вариант закона об амнистии первым (сначала все должны разойтись) первы и тут же приняла его.

    Підтримали: Sergey Shevchenko, Anton Karpenko
  • Всего два выхода для честных ребят

    :) «как бы старая, для Вашего, не подняла»
    А вообще — кто будет колоть дойную корову? Чтоб иммигрировали?
    Хоть кто-то платит налоги, наши 5% сравнимы с 46% от многих белых ЗП.
    + Эти день тратятся в Украине: на машины, квартиры, электронику, чуть более дорогую еду, одежду в том числе ребёнку, ты можешь себе позволить ездить в IMAX и ходить вечером в ресторан с девушкой/женой, покупать новые игрушки ребёнку (а не просить у соседей).
    Ок — мы можем тратить 2-3 тысячи долларов в месяц не в Украине. Читал вроде программистов тысяч 40.

    Підтримав: Сергей Черепанов