Мысли об извращениях в сфере десктопа

Браузеры то ещё болото. НО прототип написать, да узкие места переписать - это ВРЕМЯ. Время сейчас другое, инЭтик, все дела...

Просто уровень среднего погроммиста не ахти.

там дело не в прототипе. и не в узких местах. например, ошибки уровня возврата указателей на локальные переменные. это уже просто распад мозга. я не уверена, что там можно выловить всё подобное говно. имхо, проще с нуля переписать :)

теперь я понимаю человека, который начал netsurf пилить. сначала мне казалось, что он несколько преувеличивает масштаб проблемы. но нет.

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

Как марксиста то задело

Мечтай. Лишь вызвало удивление и сочувствие.

да всем абсолютно. пистон - тупостью реализации и однопоточностью.

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

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

поэтому иногда надо брать и писать всё с нуля.

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

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

а не надо никого кормить. сами прокормятся. такие вещи писать нужно не по разнарядке, а по собственной инициативе. а по разнарядке наймут кучу говнокодеров (экономия же!) и они понапишут там всякого.

а кто что-то сказал против асма? я до сих пор на нём пишу иногда и использую софт, написанный на нём.

А для чего, если не секрет? Просто я знавал людей, писавших прошивки и прочий системный софт, но нигде не требовался асм (максимум — команда rdtsc для замеров времени выполнения узких мест, и всё).

и да, он не потерял эффективности.

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

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

конечно, не все могут писать на ассемблере. но с говнокодом надо бороться, пока он не укоренился. чем больше песочниц - тем больше говнокодеров и тем больше говнокода.

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

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

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

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

Мне всё-таки кажется, что для тренировки мозгов или в качестве хобби ассемблер вполне подойдёт, но для практических задач — вряд ли (ну разве что, может, за редким исключением, хотя я лично с такими исключениями не сталкивался: даже прошивки пишутся в наши дни на си). И дело тут не только в большой трудоёмкости (хотя это тоже не последний фактор), но и в полной непереносимости ассемблерного кода.

С другой стороны, ассемблер в сравнении с си в большинстве случаев не даёт значительного прироста производительности. Я уже приводил в этом треде пример, когда за счёт оптимизации алгоритма удалось повысить производительность в несколько раз, за счёт прямого обращения к памяти — раза в 1.5 — 2 и за счёт ассемблера — процентов на 10 — 20.

Зато даже для одной и той же архитектуры оптимальное решение в настоящем может оказаться далеко не самым оптимальным в будущем. Классический пример: когда-то на процессорах 8086 авторы разных книжек рекомендовали оптимизировать умножение на 10 сдвигом и 2 сложениями (или 2 сдвигами и 1 сложением). Но сейчас применение этих 3 операций только замедлит код в сравнении с 1 умножением. На си оптимизатор для 8086 мог заменить умножение на 10 этими командами, а при компиляции для 80386 не делать этого. На ассемблере же пришлось бы вручную писать оба варианта либо выбрать какой-то один, оптимальный на одной модели и не оптимальный на другой.

Или взять исходники функции memset из glibc, написанной на ассемблере. Для архитектуры i386 там просто выполняется команда rep stosb. А для архитектуры x86_64 уже идут команды sse и avx. Если всё это поддерживать вручную, то с выходом каждого нового расширения процессора всё придётся переписывать заново. А если этого не делать, то через несколько лет может оказаться, что супер ассемблерный код работает медленнее аналогичного, написанного на си.

Не, смотри шире - сейчас хайп вокруг DOD, соответственно тебе объяснят, что если твой цикл не влез в кешлайн, значит твой код тормозит и вообще говно. Все другие методы считаются не дающими сколько-нибудь осмысленного результата (ну кроме алгоритмических оптимизаций). Так что ассемблер рулит и педалит. Короче код - быстрее префетч - быстрее исполнение. Ну и никакого рандомного доступа к памяти - только последовательно. Так что никаких вам жирных классов и деревьев наследования.

А еще если у тебя 4K байт памяти исполнения, а тебе туда надо и USB и Ethernet засунуть - то тебе только ассемблер и светит.

Манагеры с тобой не согласны.

А вот на счёт ассемблера, это ты загибаешь все палки. Т.е. залёт денежных мешков с первыми корпоративными компами, когда каждую пятилетку нужно было переписывать ПО, причём тогда трудились не 5 очкариков в одной комнате, а целый отдел и еще 100*500 тёток операторов ввода с перфокарт.

И как-то денежные мешки очень быстро смекнули, что ИБМу заплати, за аренду шкафов, тёткам заплати, а их много нужно было, так еще и десятку технишенов и погроммистов заплати много...

но для практических задач — вряд ли

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

оптимальное решение в настоящем может оказаться далеко не самым оптимальным в будущем

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

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

не, далеко не всё. разработчики процессоров не враги сами себе. если бы они выпускали несовместимые процессоры, каждый раз пришлось бы переписывать системы, компиляторы и многое другое. и процессоры бы просто не выходили на рынок: кому они нужны без софта? поэтому за последние лет десять изменения в процессорах составляли в основном добавление пары-тройки дополнительных команд, всяких там SSE, AVX, AES и т.д. но общая архитектура никогда не ломается. это было бы и технически сложно, и совершенно невыгодно с точки зрения продаж нового процессора. самым последним коренным переломом было введение 64-битной архитектуры. тогда были провалы с выпуском итаниумов. они провалили продажи как раз из-за неготовности софта. такой опыт был ощутимо неприятен даже для такого гиганта, как Intel. и они не захотят снова всё ломать.

и надо сказать, что софт околосистемного уровня, типа glibc, всегда был и будет оптимизирован под конкретные архитектуры. оптимизация таких глобальных библиотек важна и оправдана. так что как раз в этих случаях вообще даже не возникает вопроса о специализации кода.

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

Ну, это если мозги есть, и если у бизнеса есть возможность эти мозги оплачивать. Бывает проще докупить оборудования, чем искать квалифицированные кадры.

А при отсутствии мозгов бывают и обратные случаи, как недавно на Хабре мелкало: «мы чего-то понаписали на асме, оно тормозило, переписали на Rust, оно тормозить перестало.» В общем, известная поговорка про стеклянный предмет.

Манагеры с тобой не согласны.

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

каждую пятилетку нужно было переписывать ПО

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

тёткам заплати, а их много нужно было

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

Плохие новости в том, что тёток уже заменили, когда перфокарты отменили.
А мешки от манагеров требуют только отчеты о повышении рентабельности расходов на отдел. %-)

Бывает проще

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

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

Кстати, там затык был в том, что люди не осилили нормально сделать переход от кода на Rust к коду на inline-ассемблере. В результате большую часть времени функции тратили не на вычисления, а на выполнение пролога и эпилога у ассемблерных вставок. Когда вставки убрали, стало «быстрее».

А потом после таких «тестов» и появляются истории, что «компилятор оптимизирует лучше человека».

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

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

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

опять же, издержки на работу с нижним уровнем - следствие попыток сделать «умный» компилятор. люди не понимают, что не бывает бесплатной «безопасности». всё равно это вылезет в тормоза, так или иначе.

прихлебатели-гуманитарии только выносят мозг, мешают работе и тормозят прогресс

Они написали тебе оперы, которые ты слушаешь за работой.

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

Ну, это тоже не вредители, без толкового менеджмента тоже грустно. У меня бывало так: http://project.megarulez.ru/forums/showthread.php?t=13867

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

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

чтобы не нарушался регламент, чтобы не было ругани и драк на работе

а что, бывают драки??? да у вас там вообще жуть какая-то прямо!

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

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

С менеджерами всё просто. Крупная IT-контора-интегратор не в самом плохом состоянии. Собирается совет директоров. Прибыль IT-отдела - отридцательная. Прибыль отдела продаж - офигенная. Чтобы повысить доходы акционеров, ликвидируем отдел продаж с layoff'ом всех. Контора сдохла после полугода работы. И мне в течение этих полугода объясняли почему это решение экономически было абсолютно правильным. И таких много. Очень много. Просто выпиливание основной деятельности никого не останавливает, потому как менеджер не должен интересоваться никакой деятельностью, его только цифры прибылей должны интересовать. Организовать формально продажу продукта IT-отделом отделу продаж никто не стал - все же свои.

А манагеру не с руки разбираться - ведь всем известно, что продавать выгодно, а производство - одни расходы. Так и живём.

Если есть не настоящий менеджер, который понимает и хочет понимать что в конторе происходит - живём хорошо. Как приходит MBA-щик - всё, хана. Сектанты всё сразу переводят на графики и макроэкономические показатели и сразу выпиливают производство. Если им удается на одних продажах взлететь - повезло. Но как правило как-то не очень...

Да и вообще IT-шный бизнес сложная штука, разбираться некогда а менеджеру не надо разбираться, ему надо бабло зарабатывать - иначе какой он менеджер?

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

В некоторых конторах драки обычное дело. Некоторым чего-то такого не хватает. Поставили бы боксёрский ринг в подвале и решали там все вопросы...

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

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

я думаю, что если в компании сотрудники дерутся меж собой, то это уже что-то совсем нездоровое. и непонятно вообще, как там можно работать.

Я подозреваю что словл «тимбилдинг» что-то значит для тех контор где драк нет, и непонятная штука там, где они есть. Драки я видел обычно там, где никто не хотел брать на себя ответственность и потом разгребали результаты, а руководство было не при делах.

Да, работать в таких местах нет никакого желания. Ни руководство методом быкования, ни коллеги, разбирающиеся кто виноват, не способствуют поднятию морального духа.

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

обычно при разработке проекта утрясаются интерфейсы

А что, это бывает на этапе разработки ТЗ? Рекомендую прочитать дискуссию по ссылке, которую давал чуть выше. У нас была особенность бизнес-процесса, связанная с госзаказами. Отсюда было расплывчатое ТЗ, позволявшее легче выиграть тендер, а потом уже детальные требования прописывались в отчётах о совещаниях, которые проводились по необходимости.

но я себе даже представить не могла, чтобы кто-то на работе серьёзно ругался или дрался

Ну, до рукоприкладства доходило только два раза. А вот ругань была регулярно. Самый эпичный случай выглядел так. Пообещали заказчику что сделает к завтра то, что маловероятно отладить. В результате часть разработчиков пошла орать на главного программиста и в итоге орали друг на друга весь рабочий день, так и не приступив к тому, что обещали заказчику завтра.

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

Но вообще, в итоге у меня остался негативный осадок не от главного программиста, который учился в ЛЭТИ, а от матмеховцев, которые любили шумно протестовать против его методов работы и понимать всех на подковёрную борьбу. Матмех - это такое место, где учат гордиться, что ты с матмеха, а не работать. Впоследствии я старался избегать связываться с выпускниками матмеха.

В конторах в 100+ рыл доступ к телу уже редкость. А если директор просто назначен хеджфондом, то вообще никогда.

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

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

А что, это бывает на этапе разработки ТЗ?

ну, разработчики обычно знают, как они планируют решить поставленные задачи. а заказчик обычно говорит что-то типа «мне тут завод надо автоматизировать...» :)

В результате часть разработчиков пошла орать на главного программиста и в итоге орали друг на друга весь рабочий день, так и не приступив к тому, что обещали заказчику завтра.

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

у нас было 500 человек (помню, потому что у карточек для входа в компанию было ограничение в 512 карточек, из-за битности, и их начало не хватать на всех). но всё было нормально без всяких тимбилдингов. всё зависит от уровня развития людей.

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

Всё-таки какой-то процесс на сглаживание углов должен был быть.

Я ж не говорю что раз в полгода должна быть общая пьянка (хотя это в общем тоже полезно) но ежедневно вся работа должна быть поставлена так, что морды бить не хочется.

А то разведут кумовство, настроят опенспейсов и разбирают потом ЧП кто кого за что...

Вообще четкое понимание, что из-за работы морды не бьют и работа это работа у наших очень часто отсутствует в возрасте до 30, молодые горячие менеджеры могут прессануть за то, что не стал работать больше 60 часов в неделю и за это получить пендаля в первые пару недель работы. Ну или свирли, по дружески. Просто при кумовстве другие механизмы не работают. Ну или уходить в другое место конечно (по любому лучше уходить, да, но часто жалко потраченного времени и сразу не уходишь или не отпускают, например повышая зп в 2 раза).

У нас тмибилдингом назывались корпоративные выезды на природу с подвижными играми. Я так понимаю, тут о чём-то другом речь))). Потому что корпоративные пьянки на все дни рождения и государственные праздники - это святое, на них все забывали про ругань и драки, и всегда был мир и веселье.

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

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

молодые горячие менеджеры...

... не нужны. ни горячие, ни холодные, никакие не нужны.

или не отпускают, например повышая зп в 2 раза

и что, это останавливает того, кто решил уйти? слабаки какие-то.

нет. люди, которые готовы прогнуться ради денег, которые хотят бить друг другу морды, кого-то «прессовать» и т.д. в разработке работать не должны.

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

Да не, в моём случае было два фактора:

1. Я пристроил на работе разработки, которые начал делать, в принципе, для души, из интереса, и там их развивал в боевых условиях. 2. Работа через дорогу от дома, удобно.

С зартплатой там было неплохо, но не более. Так протянулось до защиты диссертации, после этого я понял, что не могу заставить себя дальше там работать (хотя все конфликты уж несколько лет как закончились с уходом молодых выпускников матмеха), и ушёл. Просто потому что уже был не в состоянии решать такие сложные задачи, как прежде, когда это было одним из инструментов междуусобицы. Впоследствии стало понятно, что заниматься чем-то другим, кроме развития своего детища я худо-бедно могу. До увольнения я боялся, что после того, как я несколько лет занимался, по сути, своим собственным продуктом, я не смогу делать что-то другое, но оказалось, что этой проблемы нет. Правда, Веб, например, так и остался мне не по зубам, но это было понятно и на момент устройства в конфликтную контору.

Каждой команде свои тимбилдинги.

Кто-то просто бухает. Кто-то конкурсы выпечки устраивает. Кто-то устраивает внутренние выставки достижений народного хозяйства (часто бывают интересные проекты, в которых бы все хотели поучаствовать но никак), кто-то всякие чемпионаты по (шахматы, боулинг, бридж) кто-то конкурсы красоты, кто-то всякие неприличия/пошлости, кто-то свадьбы манекенов или 3D-персонажей. Возможности огромны.

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

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

Ну даже в мыслях не было? Когда эта индусская скотина к нам приезжает и жрет водяру бесплатно, а потом патчи не принимает больше 20 строк типа регламент, пост-релизный патч длинный нельзя? Или просто режет срок в 2 раза и радостно рассказывает что у нас теперь не больше месяца, а всего неделя до релиза? Не верю...

А как же работа из дома, не только приятная но и круглосуточная? И конфликтов никаких, если белочку не ловить, всегда всех можно послать.

А как же работа из дома

Спасибо, не надо, проходили.

а не надо никого кормить. сами прокормятся.

хм... они ж не гаишники ))) Типа дали пистолет и палку и кормись как хочешь.

такие вещи писать нужно не по разнарядке, а по собственной инициативе.

Сколько самопальных лисапедов уже было на ниве браузеров... Как-то не выжил никто. Такой софт можно писать только командой - слишком огромные значения человеко-часов, не сопоставимые с длиной человеческой жизни и количеством часов в сутках.

иерархия была двухуровневая: разработчики и директор компании.

Крайне неустойчивая конфигурация - директор заболел/попал под машину/еще что-то и ппц всей работе.