Комментарии 84
Нам приходилось оставаться после работы по крайней мере четыре из шести рабочих дней в неделю, но компания не платила нам за переработки, даже не говорила «спасибо». Руководство считало переработки чем-то обычным. Это красный флаг для разработчиков.
Нам мой взгляд "шесть рабочих дней" это уже огромадный краснющий флажище :)
Видимо в другие компании не брали. И автор пришел куда смог. Там у автора есть еще статья про сексизм в IT.
переработки до 10 часов по крайне мере 4 из шести дней в неделю дают 56 часов в пике, в статье упоминается 60 часов в неделю. эмоции?
Вы забываете что одно никак не исключает другого. То есть наличие шестидневной недели не исключает переработок.
И если в наше время и фирма предлагает айтишнику шестидневку, то это достаточно странно само по себе. И вряд ли означает что-то хорошее.
Напишите мне 6 цифр (часов работы в день)
Удовлетворяющих трём указанным в статье условиям.
Сумма 60
Каждое не более 10
Число больше 8 должно появляться не более 4 раз
Продолжаю быть занудой :)
Почему сумма должна быть 60? Ну давайте я напишу что "больше 40 часов в неделю это уже огромадный краснющий флажище". Речь о том что если от айтишника ожидают что он будет работать больше 40 часов и прямо ему об этом говорят, то это уже должно насторожить. Ну или зарплата при этом должна быть раза в 2-3-4 выше средней по рынку.
"по крайней мере 4 из шести" — это "минимум 4 из 6", не так ли? Так что в пике как раз 60 и получается. А вот минимум — таки 56 часов, да.
Если хотите занудствовать — делайте это правильно ;-)
давайте тогда разберем противоречие между утверждениями
а) крайней меры 4 дня из 6 и б) минимум по девять-десять часов в день.
Т.е. два дня были меньше 9 часов в день или таких дней не было?
Душно стало.
*открыл окно пошире.*
Ну чисто с точки зрения формальной логики — тут нет никаких противоречий. Шесть всяко больше чем четыре. Она могла бы сказать "по крайней мере один" и это тоже было бы правильно.
Но вообще, сформулировано конечно корявенько. Наверное имелось в виду что в какие-то недели приходилось перерабатывать по 4 дня, в какие-то — все шесть.
В период стажировки мне платили всего 100 долларов в месяц, но я не сожалела об этом, потому что мне нужен был опыт работы.
У нас не было сениор-программистов. Все мы были джуниорами.
Вот это называется "противоречащие параграфы". Работать "забесплатно" и "заради получения опыта", который не у кого перенимать...
Ну и в целом картинка - молодой и неопытный разработчик идет куда-то, куда идти не стоит...
Начальный опыт можно получить и без более опытных коллег. Всякими стековерфлоу и кодом из гитхаба. Да и каждому надо сначала обжечься чтобы в следующий раз уже знать в как каким работодателям лучше не ходить. Повезет если это будет фриланс, хуже, конечно, когда постоянное место работы
Начальный опыт можно получить и без более опытных коллег. Всякими стековерфлоу и кодом из гитхаба
Можно, да.
Но, в большинстве компаний первичный отсев кандидатов делается ХРюшами, для которых это «не опыт».
Начальный опыт можно получить и без более опытных коллег.
А можно и не получить. Команда, в которой я работал на первом проекте, состояла из доучивающихся студентов непрограммистских специальностей, при этом мы делали достаточно серьёзную систему управления. Так вот, например, про систему контроля версий мы узнали где-то на второй год разработки, когда в команду занесло человека, который успел поработать в конторе, где они применялись. Правда, это было в районе 2000-го года, интернет был по карточкам :)
Насчёт обжечься, согласен.
"Знать программирование" и "уметь работать в компании" - это совсем разные вещи. Например, если бы герои этого повествования имели опыт - они бы сделали так, чтобы демо работало даже без Интернета, не говоря уже о буквах-цифрах.
Так сейчас джунами без опыта работы не берут. Вот она за копейки и работала, получила запись в трудовую. Опыт есть. Заодно получила жизненный опыт, будет знать с кем работать не стоит.
Заодно получила жизненный опытПри том, достаточно разносторонний. Практически, полный набор граблей, на которые наступать не стоит. Подобный опыт (при условии, что человек учится на ошибках) позволяет избежать следующих 2-3 подобных мест.
А ещё это очередное подтверждение того, что чем хуже работа, тем сложнее её бросить.
К сожалению, это довольно частая картинка. Сейчас моя знакомая работает на такой работе. И это очень сильно действует на нее отрицательным образом. Я ее давно убеждаю начать искать новое место работы и она этим занимается. Так что есть надежда, что у нее, в конечном итоге, все будет хорошо.
У меня был опыт когда меня увольняли. Хотя, формально, я написал "по собственному". Но психологически это, все-равно, был очень тяжелый опыт.
В России программеров увольняют нечасто, а в сев америке - как два пальца. Приходишь на работу с утра и через час выходишь свободным человеком с вещами, но без ноута и пропуска. Первые пару раз это напрягает, а потом уже похер. Просто нужна хорошая подушка месяцев на 6-10, чтобы не торопясь искать следующую.
У меня был опыт когда меня увольняли. Хотя, формально, я написал «по собственному». Но психологически это, все-равно, был очень тяжелый опыт.Ну, первый раз неприятно. В следующий раз приходишь в контору с намерением объявить об увольнении (нашёл другое место, получше), а тебя приглашают на финальную беседу. Приходишь — ну ок, мне до лампочки, но приятно, что получу на выходе ещё немного денег :)
А чего бы не озвучить ФИО этих самых CEO и CTO, дабы индустрия знала кто есть ху, а иначе это всё выглядит каким-то странным нереалистичным графоманством, да ещё и прикрытом блогом ITSOFT.
Привыкайте к новой реальности где вместо авторов посты пишут нанятые девочки-переводчицы, не имеющие никакого отношения к теме
Ага. Любой почти резонансный пост разбивается о фактчекинг.
Тут другое, мне кажется. Люди, даже когда жалуются на Хабре на работодателей изо всех сил стараются не называть имен по причине того, чтобы их следующий работодатель не отказал при приеме на работу. Поскольку, работодатель увидит статью на Хабре и подумает "ну нафиг, чтобы мое имя в следующий раз полоскали на Хабре".
Я думаю эти CEO и CTO уже трудятся рядовыми сотрудниками, причем не лучшими, совсем в других местах.
Думаю не стоит делать такие выводы основываясь исключтиельно на слова уволенного и пожалуй и обиженного сотрудника. То есть скорее всего стартап действительно был не то чтобы идеальным. Но не факт что всё было прямо так как описывает автор оригинальной статьи.
Я думаю эти CEO и CTO уже трудятся рядовыми сотрудниками, причем не лучшими, совсем в других местах.А я думаю, что они делают успешную карьеру в других факапах. Каждый поднимается до уровня своей некомпетенции…
Это ж перевод. В оригинале тоже без имён. И есть у меня подозрение, что не указали их из опасения исков.
Это переводная статья. Возможно будет продолжение и автор раскроет лица "супостатов".
Когда у фирмы из-за вас большие проблемы и при этом вы не совершали никакой откровенно вредоносной деятельности (от простого обмана коллег и начальства, чтобы меньше работать, до явного криминала типа слива данных конкурентам), то стыдно должно быть исключительно вашему руководству, которое не смогло нормально выстроить процессы.
Собственно, неоплачиваемые переработки являются явным красным флагом, что на каждом шагу будет мина замедленного действия и только вопрос времени, какая из них, когда и при каких обстоятельствах сработает. Потому что запаса прочности нет и вся работа организации держится исключительно на случайности (потому что интеллектуальный труд не имеет детерменированного времени решения задачи - только интервал оценки и вероятности).
Вас нанимают, чтобы вы 8 часов 5 дней в неделю (или сколько предусмотрено вашим трудовым договором и ТК вашей страны) делали то, что вам скажет начальство и то, что может сделать средний человек способный пройти такое же собеседование как вы и получающий такой же оклад. Приведёт ли эта деятельность фирму у успеху или банкротству - вопрос исключительно к руководящим позициям. Подобно тому как бездарный полководец может угробить самую крутую армию и в истории было немало примеров.
По тому что я вижу описывают начинающий стартап, причём можно сказать в "альфа" фазе. Если идёшь туда работать, то надо просто понимать специфику. То есть вкалывать надо не по детски и из единственных плюсов теоретическая возможность хорошо разбогатеть на опционах и/или попасть "в начальство" если стартап "выстрелит" и будет расти. Правда шансы на это...
Туда надо наверно идти когда сам уже состоявшийся специалист, знаешь как организованы процессы, имеешь подушку безопасности, легко найдешь себе новое место работы и просто хочется немного рискнуть и разнообразить себе жизнь. В таком случае если что можно наорать на СЕО/СТО, и в крайне случае просто хлопнуть дверью и потом с добродушной улыбкой смотреть издалека как стартап тонет, а бывшее начальство пропадает из медиапространства подальше от инвесторов.
В случае же совсем молодого специалиста это конечно полезный опыт, однако всякий опыт полезен, но не всякий необходим.
Когда в начинающем стартапе "четверо партнеров", а работу работают "пять нанятых программистов" - добром это не кончится.
Я работал в стартапе, который начинался с "трёх партнёров и двух программистов". Правда пришёл уже в момент когда инвестор был найден и там было около 40 сотрудников. А ушёл когда в нём было что-то около 300 сотрудников и его продали за пол миллиарда или что-то в этом роде.
То есть не знаю можно ли это назвать "кончилось добром", но я бы сказал что те самые "первые пятеро" по идее себя обеспечили до конца жизни.
Чем занимались "три партнера"? Я тоже работал в чем-то подобном - но у нас CEO искал деньги и партнеров/клиентов, CPO - говорил что и как делать, а СТО был заодно и hands-on тим-лидом. Таким образом, два из трех основателей были довольно плотно задействованы в процессе разработки.
Разработкой они не занимались, так как были далёкими от ИТ людьми. Но да, без дела они тоже не сидели. То есть те же самые поиски денег/партнёров/клиентов и обьяснение "предметной области" программистами, которые в ней в общем-то ничего не понимали.
Но это было самое начало 2000-х и в принципе надо было тратить кучу усилий чтобы убедить людей что будущее за ИТ/интернетом. То есть партнёры-клиенты по началу просто не верили что сама идея имеет смысл :)
если бы получили контракт, подняли бы зарплату…
а так у фирмы проблемы
У CEO поднял бы зарплату. Он бы ходил и рассказывал, какой он замечатльный, как своим умом и трудом он всех их, убогих и тупых, обеспечил работой, и ему все должны быть благодарны.
если бизнес процветает, то хозяин доволен и в чем здесь сарказм?
если бизнес процветает, то есть смысл говорить о повышении ЗП.
и то что он дал работу это факт и то что рано или поздно закроется контора без инвестиций не факт, но аксиома.
думаю ошибочно считать, что поддерживать стартап и искать инвесторов это не труд инвесторы не стоят в очереди на бирже инвесторов (приходи и выбирай хороших :)
Сталкивался с похожими вещами. Берём с потолка сроки, обещаем их заказчику, и ставим перед фактом команду разработки :)
Из такой шараги уволили без двух недель отработки + зп два месяца, по моему это больше вин, чем луз
Выскажу непопулярное мнение, однако валидация ввода - это один из столпов разработки ПО, в университете на каждой лабораторной работе это проверялось. Искренне соболезную негативному опыту автора, конечно же процессы должны были быть выстроены так, что приложение с такой ошибкой не должно было попасть на демонстрацию.
Набив шишек, разработчик добавит валидацию. Потом, когда поймет, что валидация тоже не всегда спасает, добавит fuzzy/smoke testing.
Это был прототип. На этапе прототипирования корректность вводимых данных не главное. Даже тестирование не главное. Это лишняя трата времени и, соответственно, денег.
И самое главное что инвесторы такое обычно тоже понимают. И им интересно увидеть POC, а не работающий идеально UI. То есть скорее всего проблема была не во вводе текста.
Вообще, вся история очень похожа на плохую беллетристику, если бы я сам однажды не был на подобной встрече в Билайне, где наша сторона была на столько феерически позорно не готова, хотя я много раз спрашивал и уточнял, что именно надо показывать, меня уверяли и готовили к одному сценарию, а был совсем другой. И именно на меня всё свалили. Но шли бы они в жопу.
Не подготовиться к встрече, не потыкать в своё приложение, не тыкать в него по заранее проверенному сценарию — ну такоэ. Так что да, я верю в подобную историю.
С другой стороны, допилить приложение, что бы оно хотя бы не падало, а просто сообщало об ошибке, уже было бы хорошо. Но в любом случае, это проблема руководства, а не разработки. Хотя всех деталей мы не знаем.
Это не прототип - а демо. А демо опытные люди делают так, чтобы оно работало всегда. У меня был случай, когда показывали Очень Важным Дядькам - сидящим на верхних этажах свежепостроенной башни. И когда мы, проверив все за время ожидания в лобби, поднялись на лифте - нам сказали что GPRS до них не добивает, т.к. антенны банально на 10 этажей ниже. А мы такие хоп - "у нас сервер на лэптопе, и раутер в рюкзаке!".
Это как раз один из самых пропускаемых "столпов" для прототипов.
Потому что можно сэкономить на коде защиты от дурака, просто надо, чтоб демонстрирующий был, собственно, не дурак.
Что ж, вам виднее, не хочу спорить на эту тему. Хотелось бы ответить сразу всем комментаторам (т. к. мысль у вас по сути одна), но что-то я не понимаю как призывать других пользователей в комменты :)
В общем мой поинт такой:
Даже в случае прототипа, написание кода не занимает всё рабочее время (обычно это меньше 50%)
Добавить валидацию "только цифры" в текстовое поле зачастую даже не одна строка, а один атрибут (типа "allowed characters"). Если это не так, всегда можно подписаться на PreviewKeyDown/Up и отфильтровать, т. е. кода нужно ну совсем немного, и это не rocket science чтобы ещё и думать над этим.
Исходя из предыдущих пунктов, я совершенно не понимаю, как можно не уделить 5 минут, чтобы потом не о***раться.
Может быть, конечно, я чего-то не знаю про прототипы, но у нас они так не делаются (как описано в статье).
В общем мой поинт такой
В случае выкатываемого в кратчайшие сроки прототипа — написание кода обычно занимает гораздо более 100% рабочего времени. Скажем, я однажды в своей жизни сидел кодил почти непрерывно 24 часа, чтоб успеть к демонстрации. Качество этого кода — соответствующее, обычно это пишется 90-100% на выброс. Медленно разрабатываемые прототипы за разумные промежутки времени — это совсем другая история и это не про статью выше.
Когда вы пишете ровно чтоб успеть доделать основное наполнение для демо — "просто добавить один атрибут" может быть последним, что вас в это время интересует.
Любая скоростная разработка — она и так вся про то, чтоб выкатить годный для какого-то показа результат, самые разнообразные "5 минут" там уделяются совсем другим вещам. В основном тому, чтоб результат вообще был.
Я вот обратил внимание на некоторую нестыковку - если инвестор не дурак, он понимает что MVP может содержать ошибки, костыли и отсутствие валидации. Поэтому, возможно, это была попытка со стороны CEO продать не MVP, а "уже почти готовый продукт". В этом случае можно порадоваться за программистов - если бы продать удалось, им бы пришлось в еще более жестоком темпе вкалывать еще полгода, допиливая все косяки и недоработки - в то время как заказчик оплатил деньги за продукт и ожидает, что он уже готов к эксплуатации.
Напомнило старый анекдот
----
Однажды русская и немецкая компании договорились провести совместные соревнования по гребле на восьмиместных байдарках.
Обе команды долго и упорно тренировались и когда обе были на пике формы устроили соревнования, но...
Немцы победили с преимуществом в 1 км.
После поражения русская команда была деморализована.
Топ-менеджмент решил выяснить причину провала.
Была создана рабочая группа для подготовки предложений по изменению и реструктуризации в команде.
После многих недель изысканий было установлено, что в немецкой команде гребли семеро и один рулевой…
а в русской – один на веслах и семеро рулевых!
Топ-менеджментом русской компании была привлечена консалтинговая компания для подготовки и проведения реструктуризации команды.
Получив солидный гонорар и внедрив показатели KPI, ССП и ISO 9001 и проведя маркетинговые исследования, консалтинговая фирма пришла к выводу:
Слишком много сотрудников в русской команде подает команды и слишком мало гребет….
После реструктуризации русская команда выглядела так:
– четыре рулевых…
– два старших рулевых,
– один рулевой директор,
– и один гребец.
Кроме того для гребца была введена персональная система оценки показателей эффективности и расширен круг обязанностей, чтобы повысить его ответственность.
На следующий год немецкая команда опять убедительно победила с отрывом в 2 км.
В результате очередного поражения, топ менеджментом русской компании была нанята консалтинговая компания по аудиту и оценке эффективности команды. Было принято решение расформировать гребную команду…
Гребец, как основной виновник неэффективности команды был уволен, все плановые инвестиции на 2014-2015 годы в новую лодку и весла были отменены.
Рулевым была объявлена благодарность, а сэкономленные деньги были выплачены топ-менеджменту в качестве премии.
Не вижу смысла растраиваться и переживать, потому как всё прошло максимально оптимально для автора.
Хотела получить опыт и повысить квалификацию - выполнено!
Искала другую работу - вот тебе два оплаченных месяца и работа найдена - выполнено!
Уйти от плохого работодателя - выполнено!
Работодатель наказан за свои косяки провалом проекта, а неправильным "разбором полетов" - решили автору проблему №2 и №3!
Просто "картина маслом"! :)
А "web platform for building a customized delivery platform" (ориг.) - это точно "веб-платформа для сборки специализированной платформы эксплуатации и сопровождения программ"?
Никакого позора в таком увольнении нет - то что начальство хапнуло больше, чем смогло проглотить - никакой вины разработчиков нет
У меня в начале карьеры была похожая ситуация, только компания была не стартап, а методы руководства очень похожие.
Продержался я почти год.
Минусы - ЗП была маленькая, потому что "не справлялся" и постоянно ругали и унижали, из лучших побуждений - чтобы я больше и качественнее выполнял объем работ, правда работало это строго наоборот).
Из плюсов - опыта работы и жизненного получил как за три года) И больше в такие компании ни ногой)
У меня первое место работы было похожее. Я был джуном и процессы в компании были поставлены очень странно. Например у нас не было команды на проекте, мы просто отдавали задачи в отдел тестирования, и не знали кто там из будет тестировать. У них стояла задача найти как можно больше багов, и завести как можно больше баг тикетов. А к нас всех было подписано соглашение, что мы обязуемся не совершать больше одного бага в месяц. Все что больше, фиксим в нерабочее время. Ну и много других интересностей. Как-то собралась у нас инициативная группа и написало письмо с предложениями того как можно улучшить процессы. В результаты мы получили в ответ письмо от руководства(которое на тот момент было а отъезде) чтобы к из возвращению в город, мы все уже написали по собственному желанию, а иначе голый оклад, который по классике в договоре был много меньше зарплаты.
Собственно я получил интересный опыт и сейчас увидит бы подобное, сразу бы развернулся. А вот переживаний почему-то небыло, наверное потому что на тот момент я уже проработал три года и не о каком повышении не шло даже речи с джуна, а через неделю я уже устроился на x2.5 зарплату. А компания тоже получила своё, город у нас относительно не большой и потом компания испытывала трудности с подбором персонала, и сейчас она раза в 2-3 меньше чем была в те времена.
СЕО молодец, конечно. Когда мы делали демо на сырых системах (а это, увы, реальность) - там каждая буква сценария была прогнана по десять раз, чтобы мимо доски не наступить и не улететь в пропасть :)
Удивительно, что оплатили два месяца. Бывали конторы, которые джуниоров нанимали с заделом им вообще не платить (систематически). Держали только на "испытательный срок", чтобы потом выгнать. Качество того, что выходило - естественно было ниже плинтуса, но зато бесплатно.
В общем с такой работы лучше бежать. Научиться там все равно можно только тому, как делать не надо, а вот здоровье и энергию потом не вернуть.
Как трёх программистов уволили из-за единственного сбоя в приложении