На чём нынче кошерно пилить опенсорс кроссплатформу?

да. а что тут не так?

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

или вы думаете, что ведущий программист занимается бумагомаранием?

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

Но занимаются. А иначе в ТЗ, эскизный проект и в программу испытаний попадет такое, что программисты будут сильно не рады тому, что к бумагомаранию отношения не имели.

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

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

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

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

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

Делать юзерский интерфейс без общения с юзерами — это мощно. Но в вашем случае даже никакого удивления не вызывает.

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

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

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

Но ей богу, лучше бы вы своими делились своими домыслами по поводу нежуностей в современном C++.

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

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

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

он вытрясает из юзера подробности и переводит их некоторый непротиворечивый набор требований

Девушка, меня не радует учить вас за бесплатно тому, что рассказывают в нормальных профильных ВУЗах на соответствующих спецкурсах. Но ТЗ фиксирует не только то, что хочет заказчик, но и то, что заказчик должен получить. А это уже определяется тем, что конкретный коллектив разработчиков может сделать. И определить это БА самостоятельно не сможет, тут в любом случае требуется участие программиста/архитектора.

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

Поэтому многие программисты дальше middle или, в лучшем случае, senior-а никогда и не вырастают.

и да, у меня нет причины вам нравиться

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

ТЗ фиксирует не только то, что хочет заказчик, но и то, что заказчик должен получить.

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

Поэтому многие программисты дальше middle или, в лучшем случае, senior-а никогда и не вырастают.

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

Ваша проблема в том

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

и не раз его составляла.

Вы путаетесь в показаниях.

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

Поэтому многие программисты дальше middle или, в лучшем случае, senior-а никогда и не вырастают.

А куда ещё расти-то? Senior — высшая стадия программиста. Тимлиды и дальше — уже не программисты.

в каком таком заповеднике вас содержат

Эмбеддед же.

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

нет.

Да.

я составляла ТЗ. и - внезапно! - для этого не нужно никаких офисов, да.

Может вы его прямо в email-е писали?

А почему, собственно, нет? Я ещё не встречале ТЗ, для которых не хватало бы .txt. Мало того, мыло и HTML-форматирование поддерживает, в приличных почтовиках есть визуальный редактор. Не вижу проблемы.

Эмбеддед же.

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

Ещё UML нужен

NASA, хех?

plantuml.

А почему, собственно, нет?

Ну, если ТЗ не идет приложением к договору, то, действительно, почему бы и нет?

Письма и распечатывать можно, чому нет?

Письма и распечатывать можно, чому нет?

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

соответствующим образом оформлено

Ну вот для этого и есть TeX.

Да, вы еще скажите, что исходит для TeX-а лежит в git-репозитории и через git с ним работают БА, ПМ-ы, юристы, архитекторы, тест-менеджеры, внедренцы, безопасники и пр.

ППЦ, детский сад какой-то.

Как они с ним должны работать-то? Ты не осилиле PDF-формы?

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

То есть ТЗ на управляющий софт контроллера какой нибудь газовой турбины тоже бизнес-аналитики ставят? Нюню.

Короч, для справки, раз уж вы прикидываетесь умным: мир программирования делится на несколько областей в которых «вообще все по разному», с организационной точки зрения. список неполон: Есть например научно-расчетный софт который пишут в науке. Есть софт в области всякой там техники-механики-оборудования (совершенно не обязательно встроенный). Есть веб. Есть корпоративная erp/crm/whatever фигня, которая лет 10-15 назад тоже технологически веб, но организационно - остался корпоративной фигней. Хотя границы часто размываются между веб и корпоративом, да.

Ну и непонятно в каком таком заповеднике вас содержат?

Это очевидно. Крупная контора, низкоуровневый разработчик.

Они там все такие через раз.