а вот несогласен :)
От: Denis Россия http://blogs.gotdotnet.ru/personal/Denis
Дата: 13.10.06 21:31
Оценка:
Валера,
Извини, такому красивому и длинному слогу не обучен (и батарейка у ноута садится )

Мне кажется ты всё смешал в одну кучу. Проекты бывают разные: написание сложного (напр. системного) софта, простая автоматизация (где просто куча формочек), полупрограммирование (индексирование с лёгким скриптингом). Соответственно и разная должна быть квалификация. А ты всё мыслишь близкой тебе первой категорией... Ну зачем в программировании автоматизации куча гуру? да уйдут они скоро и всё. Сложность ситуации в том, что как раз таки эти "автоматизационные" проекты ИМЕЮТ деньги и обычно больше чем в сложных проектах, т.к. ближе к бизнесу (а ещё их банально много).

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

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

в общем всё это всего лишь моё мнение
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Denis Россия http://blogs.gotdotnet.ru/personal/Denis
Дата: 13.10.06 21:46
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS> 8.1. Отсутствие доступной литературы (особенно, предназначенной для самостоятельного изучения темы), закрытость части профессионалов

FDS> 8.9. Отсутствие достаточного и даже необходимого количества литературы, доступной бесплатно и в электронном виде
FDS> 8.2. Неизвестность реальных проблем в реальных задачах: очень редко попадаются книги или статьи, в которых хорошо освещены реальные проблемы, а не их отголоски. Фактически, даже достать условие проблемной задачи в некоторых областях знаний просто почти невозмоно (для этого надо обладать особыми навыками)
FDS> 8.7. Отсутствие документации по новым технологиям (Nemerle, например) и сборников более-менее общепринятых толкований терминов или ссылок на их толкования (например, даже шаблоны проектирования)
FDS> 8.4. Отсутствие литературы по причине занятости и не желания её писать у людей, обладающих достаточной квалификацией
специально собрал всё в кучу, вот чего-го чего, а основная проблема с документацией сейчас это не где достать, а что взять. если мы говорим про "килобаксового" разработчика, то у него вообще сейчас НЕТ НИКАКИХ проблем достать книги. В общем этот стон мне непонятен по поводу документации мне не понятен. приведите хоть один пример


FDS> 8.3. При поднятии престижности профессии может произойти усугубление закрытости части профессионалов, так как они могут попытатся избавиться от конкурентов, что ещё более усугубит пункты 8.1 (особенно) и 8.2

Ага, киллеры разработчики, мне кажетсы вы пересмотрели телевизор.

FDS> 8.6. Отсутствие практики публичного обсуждения исходников: это подтверждается, в частности, отсутсвием такого раздела форума на RSDN

форум sources



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


и вот она квинтэссенция: ВЫ ХОТИТЕ ЧТОБЫ ВСЁ ДЕЛАЛИ ЗА ВАС И ПРОСТО ИЩЕТЕ ПРОБЛЕМУ ТАМ ГДЕ ЁЁ НЕТ, очень показательно это на примере английского (английский можно выучить бесплатно, главное хотеть и приложить усилия)
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: Denis Россия http://blogs.gotdotnet.ru/personal/Denis
Дата: 13.10.06 21:57
Оценка:
Сорри, за тон предыдущего сообщения, только что узнал(пару постов ниже), что Вы пока студент (это просто констатация факта)... наверное, это нормально вам так сейчас размышлять
а вот тоже не согласен :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 01:45
Оценка:
D>Валера,
D>Извини, такому красивому и длинному слогу не обучен (и батарейка у ноута садится )
так, только зашел в эту ветку вновь и сразу попал на твое сообщение — привет, Денис!

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

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

D>Мне кажется ты всё смешал в одну кучу. Проекты бывают разные: написание сложного (напр. системного) софта, простая автоматизация (где просто куча формочек), полупрограммирование (индексирование с лёгким скриптингом). Соответственно и разная должна быть квалификация. А ты всё мыслишь близкой тебе первой категорией...

Денис, а в тебе уже поселился руководитель Обращаю внимание, я этого не говорил и такими категориями не мыслю пока еще Хотя не буду отрицать что меня не устраивает текущее положение вещей и вояж за рубеж на самом деле был попыткой пойти к горе раз она не идет ко мне. Тем более что точка, которую я выделил выше — почти достигнута с нуля теперь и за бугром, что делать дальше — действительно можно задуматься. Что ж — все это действительно дало мне новый опыт и заставило многое начать обдумывать снова, см ниже.

D>Ну зачем в программировании автоматизации куча гуру? да уйдут они скоро и всё. Сложность ситуации в том, что как раз таки эти "автоматизационные" проекты ИМЕЮТ деньги и обычно больше чем в сложных проектах, т.к. ближе к бизнесу (а ещё их банально много).

это уже начинается иное толкование моих слов, предлагаю перечитать — о бесполезности\ненужности "студентов" к примеру там не было НИ СЛОВА.

кстати я сам начинал с автоматизации и именно ПОЭТОМУ рекомендую хотя бы попытаться сменить пример — уж в автоматизации есть где развернуться и найти более эффективное применение ресурсам, тебе ли не знать. А тот подход, что у нас исторически, можно сказать, имеет место и к сожалению весьма широко распространен — уже описан мной выше.

Так что: я вот тоже не согласен

D>посему я не очень понял, мысль то какая была? (все твои выделения подходят под узкий круг проектов, где обычно всё так и есть)

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

Чем проект шире и больше народу использует — тем выше шансы что там половина "попутчиков", хотя прибыль наверняка от проекта есть. Разве я спорил что такие проекты на 50 человек убыточны?

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

Денис, к сожалению писалось с реальных проектов и компаний, которые повидал за 15+ лет. Более того такая ситуация наблюдалась не раз. Но что важно, сейчас мы в SecureWave
Автор: Valery A. Boronin
Дата: 09.05.06
работаем по "идеальной" модели и результаты вообще говоря фантастические — особенно с точки зрения бизнеса. Нас-то как технарей фантастика наоборот совершенно не интересует и мы ее стараемся заменять реальными вещами — чтобы потом с Марса в саппорт не звонили

Боюсь лишь, что скоро модель начнет перетекать в "классическую", но пока вродн держимся. От текущего места работы собственно это наблюдение, наверное, наибольшее впечатление произвело в свое время. И многое заставило и заставляет переосмыслить — можно считать что текстом выше пытался даже в не последнюю очередь для себя мысль зафиксировать... а потом решил поделиться со всеми

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

D>в общем всё это всего лишь моё мнение

есс-но, как и все наши сообщения здесь — лишь наши частные мнения, так что это подразумевается само собой
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 01:53
Оценка:
Здравствуйте, Starlight, Вы писали:

VAB>> Т.к. производить столь масштабный hiring с последующим обучением и иметь такую текучку — вообще говоря могут позволить только гиганты калибра близкого к MSFT. Правда у них текучка почти отсутствует


S>Ну это не совсем так. Текучка здесь сильно выше, чем может показаться со стороны.

признаю, у инсайдеров пробить инфу поленился

но в любом случае, описанная в выше текучка и уровень утекающих\притекающих — все же слишком разные, чтобы сравнивать
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 02:30
Оценка: +1
Здравствуйте, td, Вы писали:

td>Я не менеджер и не работодатель. Я простой работник. И реалист. Поэтому смотрю на вещи с позиции работодателя. А рабодатель (если он не совсем идиот) всегда будет минимизировать риски. Т.е. ну не должно быть — что-бы увольнение исполнителя могло как-то сказаться на сроках. Поэтому работодатель готов нести огромные убытки(затраты на постановку этих самых бизнес-процессов, бюрократический оверхед) ради устранения этого риска.

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

td>А теперь давайте рассмотрим ваш манифест с позиции работодателя

td> — в пользу человека за 4K, вместо 2х за 2К при прочих равных.
td>Ни один работодатель на это не пойдет. Риски в случае 2х за 2К гораздо меньше. А скиллзы которыми обладает чел за 4К просто могут быть не востребованны. Ведь далеко не все проекты сложные.
С подобными тезисами, что не все проекты сложные спорить невозможно не спорил и не собираюсь — в моем тексте противоречий не найдете. впроечм, если хотите — попытайтесь, заодно перечитайте еще раз статью, замените цифры с реальных на абстрактые X, чтобы не сбивали с анталыку стойкие ассоциации с реальной жизнью вокруг 2К. Возможно, это поможет понять суть?

td>- нужна большая смелость и уровень доверия среди руководителей.

td>Туда же. Руководитель не должен увеличивать риски того что проект не будет завершен.
а не увеличение ли риска постановка на серьезный проект трех обезьян вместо реального ушедшего (который равен не пришедшему кстати говоря — почему еще об этом никто не говорит?) специалиста? И навороты потом таких решений что мне например и в жизнь не придумать, хотя есть проверенные решения — только погугли... что, не встречали еще такого? А ведь все это сплошь и рядом происходит в КОММЕРЧЕСКОМ софте! который первым делом вывешивает disclaimer, никем уже и не читаемый, потому что и так все знают — ответственности никакой!! А если все же есть капелька ответственности — то это просто промашка такого же обезьяны-юриста

А если б у вас ТВ или чайник перезагружался постоянно или ломал ф-ть стиральной машины? Достаточно вспомнить как часто все падает и взрывается просто потому что кто-то скопипастил код на хуках из студенческого open-source руткита на GPL в модный раскрученный продукт без особой для того необходимости, не буду показывать пальцем. Почему ж удивляемся потом мол престиж падает? и почему стало престижно все сваливать на MSFT, хотя самим неплохо было бы сначала азам хукостроения подучиться и хотя бы понимать где и когда хуки стоит применять
Автор: Valery A. Boronin
Дата: 16.08.06
, раз уж я их помянул как пример? А кто будет учить — свои шишки и велосипеды? или кастомеры озверевшие на саппорт и остальные производители, чей софт вдруг становится несовместим с такими поделухами — включая саму ОС Вот и думайте где риск меньше и где расходы суммарные меньше и всего геморроя тоже меньше...

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

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

короче не хочу развивать священный флейм — свою позицию я высказал выше, уверен, там можно найти о чем поспорить ибо нет абсолютной истины в нашем неоцифрованном 0 и 1 мире

td>- должны больше различаться и зарплаты сотрудников

td>А вот это — дурь. Привидет к обидам, увольнениям, депрессиям типа "меня не ценят", и как результат, понижению продуктивности труда и т.д.
тоже не согласен. перечитайте еще раз мой текст. обиды увольнения и депрессии будут при любом раскладе и сейчас их не меньше, так что это не резон.

<...excess quoted lines suppressed...>

короче, все понимаю (и замечу понимал до написания текста, но ), но зачем же было столь злостно оверквотить?
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 02:43
Оценка: +2
Здравствуйте, SkyDance, Вы писали:

SD>Написал по сути своей верно. В некоторых деталях есть неточности, но в целом написано верно.

SD>С чем хочется поспорить: почему двое гуру не всегда лучше десяти обезьян: существуют т.н. "одноразовые" проекты, фактически не подразумевающие развитие. Будучи единожды написанными, эти проекты никогда не перерабатываются и усилия гуру на них не нужны.
да да и да. но я не писал что предложенный мной вариант — серебрянная пуля!! Где у меня квантор для всех и всегда?

SD>Также гуру не нужны "формочки клепать".

это дело легко аутсорсится — о чем были слова выше

SD>Также бывает монотонная тупая работа, где гуру просто повесятся от скуки, потому что это они тысячу раз уже делали.

SD>Суть-то вот в чем: интересной работы не так много.
неверный вывод из неправильной посылки

SD>А сложной так и еще меньше.

не спорю

SD>Куда девать всех этих научившихся многому гуру? Их просто не надо в таком количестве.

короче пока с Вами мы ни в чем не расходимся а что 2+2=4 я с Вами полностью согласен

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

сейчас же сплошь и рядом ресурсы непроизводительно используются и я полностью согласен что в таком кол-ве программистов наверное и не нужно. Или не стоит их путать с настоящими программистами. Будет меньше народу — престиж повысится, вот и вся идея. Но чтобы от привычной схемы с тупой пилой отказаться — нужна смелость и доверие, вот о чем я по-моему написал. Вы ж кстати о том же самом пишите чуть ниже
Автор: SkyDance
Дата: 13.10.06
и опять с Вами я согласен
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 02:51
Оценка:
Здравствуйте, mag2005, Вы писали:

VAB>>- имеет смысл всеми силами работать против необоснованного увеличения размера команд\компаний (заметьте, про проекты я этого не говорил!)


M>Интересно, что я как-то интуитивно всегда придерживался такого подхода. Я изменил ему только один раз, когда в R-Style купился на перспективу стать большим начальником и не противился раздуванию команды МОЕГО проекта. В результате из 4-х отличных парней команда выросла до 15, дело абсолютно встало, парни уехали в Штаты, а я оказался у разбитого корыта. А все могло быть иначе...

ИМЕННО! уж будьте уверены, Ваш опыт не самый редко встречающийся

а то что Вы интуитивно или как то иначе сделали вывод — честь и хвала, ведь очень-очень редко почему-то анализируются прошлые-закрытые проекты, хотя все книжки про post-mortem вроде читают... И уж еще реже способны потом что-то изменить в новых, с учетом старых

Вижу, Вы не из таких и поэтому выражаю мое Вам почтение

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

побольше бы таких президентов. покажите ему мое обращение к руководителям
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 02:57
Оценка:
Здравствуйте, AndreiF, Вы писали:

AF>Тут проблема даже не только в том, что руководителей "жаба душит" платить больше.


AF>Каким образом оценить квалификацию программиста? Правильно, провести ему собеседование с другим программистом.


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

AF>Обосновать свое мнение?
не стоит. на этот счет у меня уже есть еще одна опубликованная Re[8]: гипотеза ;-)
Автор: Valery A. Boronin
Дата: 13.06.06


AF>Практически невозможно доказать человеку, что он неправ, если он априори считает себя умнее и чувствует себя хозяином положения.

AF>Указывать проводящему собеседование на его фактические ошибки — вообще бесполезное дело, они все равно будут отметены как "несущественные" и только вызовут озлобление.
AF>И чем больше разница в уровне, тем больше непонимания. Еще кто-то из классиков отмечал, что мало кто способен оценить чужую квалификацию, если она выше собственной.
может быть это был я со своей гипотезой — простите, не удержался

AF>Если добавить к этому обычную привычку программистов недооценивать сложность проектов, в том числе и чужих (в особенности — чужих! ), положение становится еще печальнее.

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

AF>Похоже, что единственный шанс для профи пробиться "на верха" — это открыть свое собственное дело.

или например найти профи от бизнеса, который будет смел и будет доверять, о чем я и написал. voila! (fr.)
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 03:43
Оценка: 19 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Давай над выводами и покумекаем.


VAB>>- как следствие повышения смелости и доверия должны больше различаться и зарплаты сотрудников(чем еще мерять риск и доверие, как не ЗП?), вместо фактически присутствующей своего рода уравниловки на рынке. А уравниловка никогда к престижу не приводила. Сам смысл престижа — это его недоступность для большинства. Т.е. "программистов" должно быть поменьше, а уметь и делать они должны больше, чем мы имеем сейчас. Появится и престиж.


ГВ>А вот это уже напрямую соприкасается со структурой самих артефактов программистской деятельности. Вот смотри, имеем, например, ситуацию, когда проект приведён к состоянию, когда нужно сделать ну... скажем... 150 диалогов (MFC, WinForms... далее по вкусу). Как ни верти, но 150 форм — это, как минимум, 75 дней тупого накидывания контролов, хоть для гуру, хоть для середнячка. Три месяца. Понятно, кого занять такой работой разумнее. Выводов можно сделать два.

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

Приятно вспомнить как один мой хороший знакомый, тогда только-только попавший ко мне на проект, пришел с каким-то диалогом или визардом и хоть мне и было известно что у него регулярно 3-4 пересдачи и в программировании он большого опыта не имеет, собственно весь его опыт был тогда — требующиеся на MFC простейшие GUI штучки. Но по-моему я куда-то торопился и ко всему был раздражжен его затруднениями на ровном месте, решил все ему показать с нуля и как надо — поэтому вероятно руки летали быстрее обычного и все его проблемы были на практике мной решены наглядно — последовательно созданы неск. форм диалогов для визарда, накиданы все контролы, определены карты событий, обработчики, все связалось как требуют правила, подкручел места для появления немодальности где нужно — через буквально 30-40 минут выданный ему недельный объем работ был выполнен и багов на него потом кстати не поступало.

Короче на него это тогда произвело весьма большое впечатление и лишь спустя долгое время он мне в этом признался, а урок "делай как я" ему пошел тогда впрок — он стал заметно ответственнее подходить к работе и реальней к оценке сроков, ведь он искренне считал что тут пару дней минимум даже если все знаешь. Так вот, нынче он уже ПМ в одной Новосибирской конторе.

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

хотя признаю — просто в клепании GUI разных MFC приложений мне тоже пришлось достигнуть некоторых высот параллельно с освоением внутренностей ОС. Если бы было действительно что-то неизвестное для меня — тут бы ничем уже помочь не смог и неделя была бы честно на задачу угрохана. Но это как раз и наталкивает на мысль — что нужно было в проект не знакомого было брать, а опытного клепальщка, у которого руки летают по заученным траекториям без лишних простоев, хоть и стоит не Х а 2Х

ГВ>Вывод первый, идиотский. Индустрии нужны обезьяны как раз для такой работы. Т.е., обезьяны — нужны.

этого я не отрицал, прошу записать в протокол

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

именно, надо брать не двух по 2К, а одного поопытнее

ГВ>Почему возможен второй вывод? Потому что среди этих 150 форм почти наверняка можно выловить закономерности и тупую работу исключить, автоматизировать. Почему это мало кто делает? Сложный вопрос с массой неочевидных ответов. Но кое-что, кажется, я могу озвучить.


ГВ>Во-первых, такая ситуация может быть продиктована нестабильностью требований на начальном этапе развития и особенностями взаимодействия с заказчиком. Устаканивание занимает так много времени, что на разработку средств автоматизации просто нет времени. Логично, что если заказчику ещё не ясно, что из себя должен представлять конечный продукт, то ему нужны короткие промежуточные этапы и быстрый обмен макетных версий. Но казалось бы, это должно быть временным явлением. Казалось бы... Но есть и "во-вторых".

нет ничего более постоянного, чем временное (с)

ах как хорошо это становится понятным именно опытным... которые стараются не допустить этого на корню, так чтобы будущие писатели форм на MFC даже и не понадобились — об этом еще Михаил Чащин в своей отличнейшей статье Framework design
Автор(ы): Михаил Чащин
Дата: 12.06.2004
Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.
писал — там как раз борьба с формами была осуществлена

ГВ>Во-вторых, то же самое может возникнуть, когда архитекторы просто "ориентируются на всех", на "устоявшиеся индустр-р-риальные р-р-решения" и... не обладают нужными знаниями или не могут их применить. Да и желания такого не испытывают. Плюс к тому нужно учесть прессинг, который оказывает на них постоянное зудение: "середняки этого не поймут". Это как... как злокачественная опухоль. "Все", "середняки", "ты что, самый умный?", "все делают не так", "они все глупые и не поумнеют". Лекарство — радикальное оперативное вмешательство на ранней стадии: по шеям тому, кто начинает апеллировать к потребностям средних умов. Всё, что мы видим вокруг — это уже следствия. Следствия этой неоправданной "демократии" и воплей о том, что идиоты имеют такое же право голоса, что и гуру, от чего в конечном итоге, хуже стало всем. (Плюс к тому, совершенно в пар размытые критерии. Кто такой, вообще, этот самый гуру? Тот, кто помнит 150 разных API или тот, кто умеет оперировать чем-то фундаментальным?)

есть такая буква

ГВ>Ремарка на полях. Вот объясните, зачем вообще нужно поддерживать и поощрять глупость и скудоумие в коллегах? По идее, единственный разумный довод, это опасение конкуренции со стороны глупцов и "сбивания тарифов". Но! Если они глупы, то конкурентами никогда не станут и бояться нечего. Если же умны, то тогда апелляция к их глупости — самоё глупость. Прочие же химеры разбиваются об один-единственный довод: девять баб не родят ребёнка за месяц.

браво! и спасибо, Геннадий. Честно говоря, это дело не попало в мой текст только по причине и так большого объема — выделенная жирным фраза как раз соседствует в Бруксе с цитатой, что я оттуда дернул....

ГВ>И опять таки, сей подход (я про "по шее") приведёт к тому, что интегральная производительность на сложных проектах вырастет благодаря иному структурированию проблемы. Следовательно, те же самые руководители смогут не менять свою систему приоритетов: таки да, именно в силу высокой производительности можно будет поднимать зарплату сотрудникам. Но платить "гуру" только за то, что он "гуру", хоть и "лабает формы" как третьекурсник, — глупо с любой точки зрения.

конечно глупо. я этого и не предлагал ни разу — тоже для протокола

ГВ>Как это ни парадоксально прозвучит в моих устах, но лозунги вроде: "Програмирование — не интеллектуальная работа", "Нам достаточно 10 обезьян", "После 30 ты уже не программист" имеют, б...ь, под собой реальные основания. Действительно, можно (и нужно) обойтись обезьянами, потому что те, кто не обезьяны, либо создают фронт работ для обезьян, либо сами заняты обезьяньей работой... А есть ещё и такое явление, как демотивация...

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

VAB>>Если же серьезно, то я бы обратился к руководителям: смелее доверяйте и продвигайте достойных, опирайтесь на них, ставьте в пример и поощряйте (материально и не только!) готовых учиться и развиваться, готовых помогать и обучать остальных!


ГВ>Руководителю, как и любому администратору нужен сценарий действий, а не голый призыв. Кто будет выделять тех самых? По каким критериям? В какое время? Например, Вася Пупкин хочет получить сертификат фирмы "Рога и Копыта Inc.". Хорошо это или плохо? Он учиться желает или просто получить бумагу, которой будет потом шантажировать руководство? Так что, сдаётся мне, руководители (я имею ввиду менеджеров типа "передай другому", те, кто повыше, обычно тупостью не отличаются) тут на самом деле на вторых номерах. Их дело — заказчиков подыскивать и народ скрепками обеспечивать.


ГВ>И потом, каких, к чёрту, "остальных" нужно обучать? Добро бы ещё просто подсказать, куда идти. Но обучать... Книжек, что-ли, нет? Зачем плодить паразитов? Хай сами учатся. Не хотят? В сад. Другие всегда разыщутся. Заодно, может, на курсах "повышения квалификации" начнут читать что-то более дельное, чем глупости очередного API.

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

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

а что курсов нормальных нет — так нет спроса на нормальных лекторов\тренеров. так бы глядишь — и подался в эту область развиваться.

VAB>>Всем же нам закругляясь лишь хочу пожелать:

VAB>>давайте все вместе максимально избегать застоя и постоянно повышать свой собственный уровень.
VAB>>А вместе с ним престиж нашей профессии — все в этой жизни взаимосвязано!


ГВ>Очень скользкий это призыв, надо сказать. Беззубый и неконкретный. Изучить Java после C++ это поднять свой уровень или нет? А освоить функциональное программирование в совокупности с Lisp с теми же начальными условиями — да или нет? А переквалифицироваться в "Web-программиста" — это поднять свой уровень или нет? Или скажем так, что лучше: изучить T-SQL в дополнение к PL/SQL или заняться теорией множеств?

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

Спасибо Геннадий за на мой взгляд очень интересный пост! несмотря на выводы мне кажется что у нас есть что-то общее
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 03:57
Оценка:
Здравствуйте, S-SH, Вы писали:

SS>С всем согласен, анализ ситуации верен.

спасибо

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


SS>У Паркинсона есть замечательный пример (излагаю по памяти), когда одному сержанту поручили расшифровывать аэрофотоснимки. На следующий день он пришел к начальству с просьбой выделить ему помощника. Через шесть месяцев он был в звании подполковника и командовал, тут я забыл чем именно, пусть ротой.

вот! и я о том же — очень часто штат раздувается не потому что дело требует, а потому что политика.

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

SS>Это ведь профессионалам-программистам нужно, что бы руководители изменились. А самим руководителям надобности меняться не испытывают, поскольку руководитель айтишников — это наемный работник. А раз наемный, значит, уровень его авторитета и з/п впрямую зависят от количества ему подчиненных сотрудников (Так исторически сложилось, как любит повторять уже бывший мой начальник, когда не знает, что происходит). А раз зависит — то, сами понимаете, стимул у него — выбить побольше штат, а не уменьшить. И аргументы для вышестоящего начальства у него соответствующие — нет ресурсов, мы заняты, на это нужен специальный отдельный разработчик, которого у нас нет, и никто из моих людей этого не умеет.

я сам ровно об этом писал, может быть и не раз, в этом же форуме — лень искать... согласен!

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

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

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

спасибо за дополнение!
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Поднимаем престиж профессии. Размышления на тему :)
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 14.10.06 04:22
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Вот уж действительно: барьер для флейма, так как не каждый прочитает всё, что написано.

прошу пардону — не дал бог таланта укладывать все в пару строк. искренне об этом сожалею иногда

FDS>Возникает вопрос с тем, что делать, если эти 50 программистов сидят каждый в своём отделе своей фирмы и делают однотипные, но всё же разные операции. Ведь вы эти программисты, которые получают меньше одного "килобакса" , сидят, прежде всего, в непрофильных маленьких отделах. Получается, что ... ой, раскрываю коммерческую тайну (щутка) ...<...excess quoted lines suppressed...>


обащаю внимание, квантор для всех у меня в тектсе практически не встретите — никоим образом не обощал на ВСЕ возможные типы проектов и ВСЕ возможные варианты компаний т.п.

поэтому не буду поддерживать флейм в это ветке, у Вас слишком много фактов из серии что земля круглая — спорить не буду, согласен со всем

FDS>1. Нужна фирма, которая возьмёт все ИТ дела нескольких непрофильных фирм на себя

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

FDS>2. Затраты на организацию беспорядка из 50 человек не существуют, так как работают маленькими коллективами человек по 5-7.

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

FDS>3. Одним хорошим программистом в каждую фирму не отделаешься: иногда нужна не квалификация, а объём. Конечно, объём можно заменить квалификацией, при большом желаниии (см. след пункт)

да

FDS>4. Рутина, с автоматизацией которой может справиться только заинтересованная в этом группа программистов: см. пункт 1, который невозможен без понимания непрофильных ИТ-фирм

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

FDS>5. Как быть с "командой быстрого реагирования": нужно сделать то-то для такого-то отдела — сделаешь за 3 часа? Если человек сидит в другой фирме, это может быть уже более сложно сделать

да хоть на другом конце земли, при чем тут это

FDS>6. Сильная неравномерность загрузки "профи" — ему нужно делать и "рутину", и некоторые сложные вещи

а вы думаете профи только сложными вещами занимаются? к сожалению, это далеко не всегда так — впрочем все в тексте написал

FDS>7. Негде получать опыт, если все будут брать только "профи" да "гуру"

этого в моем тексте Вы также не найдет — там нет призыва всех не-гуру ликвидировать как класс

FDS>8. Сложность самообразования:

а это во все времена почти константа

FDS> 8.1. Отсутствие доступной литературы (особенно, предназначенной для самостоятельного изучения темы), закрытость части профессионалов

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

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

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

FDS> 8.3. При поднятии престижности профессии может произойти усугубление закрытости части профессионалов, так как они могут попытатся избавиться от конкурентов, что ещё более усугубит пункты 8.1 (особенно) и 8.2

баланс все равно установится — тут в теорию самоорганизующихся систем надо двигать наверное, но меня об этом не спрашивайте

FDS> 8.4. Отсутствие литературы по причине занятости и не желания её писать у людей, обладающих достаточной квалификацией

если мне нахамят или спросят на слабо — может и не отвечу, а если по человечески и противопоказаний нет вроде NDA, время найдется — почему не помочь? Меня ж тоже не всегда с распростертыми бъятиями встречали — совсем наоборот скорее, да и ресурсов раньше просо не было — а сейчас их немерянно, попробуй найди что надо. Везде свои плюсы и минусы. Как всегда.

так что этот пункт ни при чем — люди разные и обобщать не стоит, а также кому легко (с)

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

классификацией ученые давно и постоянно занимаются.

FDS> 8.6. Отсутствие практики публичного обсуждения исходников: это подтверждается, в частности, отсутсвием такого раздела форума на RSDN

был вроде — см ниже по ветке ответ

FDS> 8.7. Отсутствие документации по новым технологиям (Nemerle, например) и сборников более-менее общепринятых толкований терминов или ссылок на их толкования (например, даже шаблоны проектирования)

Москва не сразу строилась

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

хм, ну или учите язык или меняйте профессию. Это из реальных советов. а нереальные наверное и не нужны?

FDS> 8.9. Отсутствие достаточного и даже необходимого количества литературы, доступной бесплатно и в электронном виде

да полно ее полно. 30Гб может и нет но уж 3 то у меня давно накопилось — при том что отбираю не все подряд

то что у кого то доступ ожет быть затруднен в Сеть — так когда я начинал и этого не было, ни отладчиков ни MSDN/DDK ни второго компа ни виртуальных машин — ничего короче не было. А зато какой был вызов в каждой задаче! Эх, приятно вспомнить — кстати те навыки анализа кода в черном ящике очень мне пригодились и нужны сейчас не меньше... так что выше нос, все в порядке — кому нужно — тот пробьется! уж это точно не та проблема из-за которой останавливаться можно.

FDS>Выводы о том, что надо делать, делайте сами, потому что всё равно вряд ли кто-то влиятельный эти выводы примет к сведению

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

спасибо за дискуссию!
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: AndreiF  
Дата: 14.10.06 05:11
Оценка: :)
Здравствуйте, WhiteDev, Вы писали:

WD>Вопрос "как?" пока для меня остается открытым ...


пока что я не придумал ничего лучше простого плана — продумать свои идеи, накопить денег, уйти с работы и начать работать на себя
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: AndreiF  
Дата: 14.10.06 05:23
Оценка:
Здравствуйте, S-SH, Вы писали:

SS>Для чего нанимают программиста? Правильно, программировать. А не собеседовать(-ся) и не теоретизировать. Следовательно, наиболее адекватным способом оценки квалификации программиста является выполнение теста — написать ПО по слабо сформулированному ТЗ за конечное время.


А за какое "конечное" время? Тестового задания на пару дней хватит только чтобы оценить знание азов, а более длительные проекты практически никто не станет делать. Нужно очень сильно хотеть работать именно в данной фирме, чтобы потратить кучу своего времени без всякой гарантии получить с этого какую-то отдачу.
Самое неприятное в работе программиста — это такие решения. которые выглядят привлекательно в кратковременной перспективе, но приведут к большим проблемам в будущем. Умение заглянуть на несколько месяцев вперед — это именно та вещь, которая отличает гуру от просто крепкого середнячка, и ее наличие таким тестовым заданием ты точно не проверишь.

SS>Важна уверенность человека в ответах. Причем не тупая убежденность, а уверенность, что этот вариант подходит. Почему? Пусть расскажет. А другой вариант здесь можно? Тогда какие побочные эффекты возможны?


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

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


Да, с большой вероятностью вы выберете человека "чуть хуже", чем те, что уже есть. Ну может быть,"чуть лучше", если очень повезет.
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: AndreiF  
Дата: 14.10.06 05:26
Оценка: +1
Здравствуйте, Valery A. Boronin, Вы писали:

VAB>может быть это был я со своей гипотезой — простите, не удержался



не помню точно, кто про это писал. Но смутно кажется, что это был Ларри Константайн.

VAB>или например найти профи от бизнеса, который будет смел и будет доверять, о чем я и написал. voila! (fr.)


Увы, найти такого профи от бизнеса — дьявольски сложная задача. По настоящему хороший менеджер — еще более редкое явление, чем хороший программист.
Re[5]: Уровень программиста от зарплаты не зависит
От: alcotras  
Дата: 14.10.06 09:13
Оценка: +1
Здравствуйте, w00zle, Вы писали:

W>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Это как поглядеть. Если на этом рабочем месте ещё какое-то оборудование помимо компьютера должно стоять... Кстати, если много выездных работ, то и требование лаптопа тоже вполне разумно.


W>И оно выполняется. Сейчас у нас каждый сотрудник, который хотя бы теоретически может когда-нибудь куда-нибудь поехать и там ему понадобится комп — имеет лаптоп. Многие остановились на варианте — мощный лаптоп + монитор,клава,мышь,етс. По предоставлению оборудования рабочего вообще грех жаловаться — получаем всё по малейшему писку, если это требуется.


W>И рабочие места у нас в общем очень даже да. Могу фотки запостить, если интересно


ГВ>>Тут могу только посочувствовать. Хотя опять таки, а воспитать пробовали?


W>Пробуем, но это долго и пока неэффективно.


ГВ>>Не пори муру. (c) Из-за того, что кто-то всегда готов подхватить упавшее знамя (вариант: паяльник) расслабляются те, кто обязаны это делать по долгу службы.


W>Почему "расслабляются"? У них планы свои есть.

W>Последняя ситуация в тему.
W>Объект в 100км. от Москвы. Рельсы. На рельсе стоит датчик. Крепится к рельсу гайками.
W>Приезжает embedded девелопер на объект и видит — датчик валяется рядом с рельсом. Причину выяснили — путейцы меняли рельс, датчик сняли, а обратно не прикрутили.
W>По-твоему embedded девелопер позвонить мне и сказать — такая херня, отлаживаться не могу. Я должен был позвонить монтажникам и сказать — ребят, такая херня, надо делать. Они ответили бы — да, в конце следующей недели может будет окно в планах, съездим прикрутим. Embedded девелопер собирает вещи и едет домой. Потери времени полторы-две недели.
W>Вариант 2. Девелопер находит гаечный ключ и прикручивает датчик.

Вариант 3: Девелопер "сигналит" Вам о проблеме. Просит санкции взять гаечный ключ, получает ее, прикручивает. После чего подписывает акт о том, что обнаруженная неисправность ликвидирована, но гарантий на ее дальнейшую работу нет. Гарантии появятся когда приедут официальные монтажники и привинтят датчик заново.
Re[6]: Уровень программиста от зарплаты не зависит
От: w00zle  
Дата: 14.10.06 09:23
Оценка: +2 -1 :)
Здравствуйте, alcotras, Вы писали:

A>Вариант 3: Девелопер "сигналит" Вам о проблеме. Просит санкции взять гаечный ключ, получает ее, прикручивает. После чего подписывает акт о том, что обнаруженная неисправность ликвидирована, но гарантий на ее дальнейшую работу нет. Гарантии появятся когда приедут официальные монтажники и привинтят датчик заново.


Какой акт? О чем вы?
Вы рассуждаете об этом так, как будто работники одной компании — не люди, которые вместе делают одну работу и нацелены на положительный результат, а просто безликие "разработчики C#", "инженеры-схемотехники" и "монтажники ЛВС", которые выполняют строго свою работу и никуда в сторону не смотрят и смотреть не хотят.
По вашей логике когда девелопер выдает скомпиленный проект для внедрения — он должен получить от внедренцев бумажку, что "Такой-то тогда-то для таких-то целей получил компакт-диск с тем-то и тем-то, имярек". А когда на объекте что-то не заработало из ПО, прислать официальное письмо руководителю проекта, что "Выданное Ивановым А.А. программное обеспечение не удалось запустить на клиентском ПК по причине неверных настроек доступа к БД" например. Так что ли? И разработчик получит ***** за то, что не стал утруждать себя нормальной подготовкой. А внедренцы не получат ничего, т.к. "санкции получили, исправить попытались, но гарантий никаких".
Мне всегда казалось, что отдел программеров — это команда единомышленников, которые занимаются интересной работой и получают за это деньги. Если Вы считаете, что это не так и отдел девелоперов — это "абизяны", заточенные на создание кода по написанному для них ТЗ в указанные для них сроки с выдачей указанного им результата, то мы просто в совершенно разных компаниях работаем.
---
Woozle
---
w00zle.
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: FDSC Россия consp11.github.io блог
Дата: 14.10.06 10:09
Оценка:
Здравствуйте, Denis, Вы писали:

D>специально собрал всё в кучу, вот чего-го чего, а основная проблема с документацией сейчас это не где достать, а что взять. если мы говорим про "килобаксового" разработчика, то у него вообще сейчас НЕТ НИКАКИХ проблем достать книги. В общем этот стон мне непонятен по поводу документации мне не понятен. приведите хоть один пример


Вы смотрели мой пост про Белоцерковского. Никаких проблем нет, если книги по программированию, если же по смежным специальностям, то, в лучшем случае, нет в продаже, но мы обязательно сообщим...
Я же говорю про реальные проблемы. И что, что он килобаксовый? Что, у него своя типография из-за этого уже есть?
Если вы знаете магазин, который продаёт все его книги, да ещё и без "отсутствует на складе", укажите мне его. Даже просто все его книги, которые отсутствуют на складе.

FDS>> 8.3. При поднятии престижности профессии может произойти усугубление закрытости части профессионалов, так как они могут попытатся избавиться от конкурентов, что ещё более усугубит пункты 8.1 (особенно) и 8.2

D>Ага, киллеры разработчики, мне кажетсы вы пересмотрели телевизор.

Вообще телевизор не смотрю. Смотрю то, что происходит, например, у меня на кафедре: коммерческий продукт существует и
1. Даже в бинарниках отказываются давать аспирантам части продукта, хотя работают они по теме, связанной с этим продуктом
2. Есть документация по этому продукту, в т.ч. документация в виде книги, где подробно излагаются методы расчётов, используемые в продукте. Некоторые моменты изложены так (книга, между прочим, с тиражём 20 000 экз.), что не просто невозможно реализовать по этому описанию, а описание само запутывает и содержит преднамеренные ошибки, опечатки, просто исключенные из листинга или переписанные участки кода.

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

FDS>> 8.6. Отсутствие практики публичного обсуждения исходников: это подтверждается, в частности, отсутсвием такого раздела форума на RSDN

D>форум sources

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

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


D>и вот она квинтэссенция: ВЫ ХОТИТЕ ЧТОБЫ ВСЁ ДЕЛАЛИ ЗА ВАС И ПРОСТО ИЩЕТЕ ПРОБЛЕМУ ТАМ ГДЕ ЁЁ НЕТ, очень показательно это на примере английского (английский можно выучить бесплатно, главное хотеть и приложить усилия)

Поделитесь секретом — как? Я просто не знаю.

Я сам смог выучить англ. только до уровня относительно безболезненного и довольно медленного чтения литературы по ИТ и кое-чему смежному. На это я угрохал очень много сил и времени.
Ремарка: если вы способны самостоятельно выучить англ., это не значит, что это могут все.
развиваем мысль
От: Denis Россия http://blogs.gotdotnet.ru/personal/Denis
Дата: 14.10.06 10:29
Оценка:
VAB>вижу вечер не пропал незамеченным, удивительно много сообщений нападало, это хорошо.
Привет, Валера, действительно приятно поучавствовать в вечерней дискуссии.

VAB>Денис, а в тебе уже поселился руководитель

А можно об этом подробнее в аську , правда интересно, не думал что мои слова так будут сразу с "душком", надо исправлять
VAB>Обращаю внимание, я этого не говорил и такими категориями не мыслю пока еще Хотя не буду отрицать что меня не устраивает текущее положение вещей и вояж за рубеж на самом деле был попыткой пойти к горе раз она не идет ко мне. Тем более что точка, которую я выделил выше — почти достигнута с нуля теперь и за бугром, что делать дальше — действительно можно задуматься. Что ж — все это действительно дало мне новый опыт и заставило многое начать обдумывать снова, см ниже.

Валера, мне кажется, есть два пути: успокоиться и получать удовольствие от жизни(дети, путешествия) и начать своё

D>>Ну зачем в программировании автоматизации куча гуру? да уйдут они скоро и всё. Сложность ситуации в том, что как раз таки эти "автоматизационные" проекты ИМЕЮТ деньги и обычно больше чем в сложных проектах, т.к. ближе к бизнесу (а ещё их банально много).

VAB>это уже начинается иное толкование моих слов, предлагаю перечитать — о бесполезности\ненужности "студентов" к примеру там не было НИ СЛОВА.
Так, я что-то пропустил где я так толкую твои слова?

VAB>кстати я сам начинал с автоматизации и именно ПОЭТОМУ рекомендую хотя бы попытаться сменить пример — уж в автоматизации есть где развернуться и найти более эффективное применение ресурсам, тебе ли не знать. А тот подход, что у нас исторически, можно сказать, имеет место и к сожалению весьма широко распространен — уже описан мной выше.

VAB>Так что: я вот тоже не согласен
Я тоже начинал с автоматизации и с трудом могу понять КАК можно там держать гуру кроме как на архитекторской должности. Давай определим понятие автоматизации: создание VB(ныне (Web)WinForm, хотя все эти языки тут просто для примера) приложения с кучей довольно однообразных формочек (склад, касса, ресторан).


D>>посему я не очень понял, мысль то какая была? (все твои выделения подходят под узкий круг проектов, где обычно всё так и есть)

VAB>я так не думаю. допускаю, что кому-то по многим причинам в т.ч. уже описаным выше, не буду повторять, бывает удобнее модель с непрестижным хоз-вом. Но это никак не уменьшает проблему повсеместного неэффективного использования ресурсов и сопутствующего падения престижа такой деятельности — вот о чем был текст выше.
Валера, а можно _реальный_ пример неэффективного использования. Просто в связи со спецификой работы отвык что-то решать без usecase


всё остальное пока опустил чтобы не перегружать сообщение. Буду с нетерпением ждать ответов
Re[3]: Поднимаем престиж профессии. Размышления на тему :)
От: FDSC Россия consp11.github.io блог
Дата: 14.10.06 10:37
Оценка:
Здравствуйте, Valery A. Boronin, Вы писали:

VAB>поэтому не буду поддерживать флейм в это ветке, у Вас слишком много фактов из серии что земля круглая — спорить не буду, согласен со всем


Спасибо, мне можно считать себя великим?

Тогда и я почти во всём соглашусь

FDS>> 8.1. Отсутствие доступной литературы (особенно, предназначенной для самостоятельного изучения темы), закрытость части профессионалов

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

А, дак вы и об этом писали — а я не понял!

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

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

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

FDS>> 8.3. При поднятии престижности профессии может произойти усугубление закрытости части профессионалов, так как они могут попытатся избавиться от конкурентов, что ещё более усугубит пункты 8.1 (особенно) и 8.2

VAB>баланс все равно установится — тут в теорию самоорганизующихся систем надо двигать наверное, но меня об этом не спрашивайте

Синергетика Может и не установиться — сначала может "лавина" сойти, т.е. ситуацию можно до кризиса довести.

FDS>> 8.4. Отсутствие литературы по причине занятости и не желания её писать у людей, обладающих достаточной квалификацией

VAB>если мне нахамят или спросят на слабо — может и не отвечу, а если по человечески и противопоказаний нет вроде NDA, время найдется — почему не помочь? Меня ж тоже не всегда с распростертыми бъятиями встречали — совсем наоборот скорее, да и ресурсов раньше просо не было — а сейчас их немерянно, попробуй найди что надо. Везде свои плюсы и минусы. Как всегда.

VAB>так что этот пункт ни при чем — люди разные и обобщать не стоит, а также кому легко (с)


Люди разные, но тех, кто пишет не хватает. Даже по тому же Nemerle мне, лично мне, а не Владу , документации не хватает (хотя я читал её на их сайте на англ.). Владу хватает, мне — нет. Естественно, это конкурентное преимущество Влада, но это же и недостаток сподвижников языка Nemerle. Реальный пример привёл. Конечно, если они так и хотят его оставить "для избарнных", но это уже другой пункт.

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

VAB>классификацией ученые давно и постоянно занимаются.

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

FDS>> 8.6. Отсутствие практики публичного обсуждения исходников: это подтверждается, в частности, отсутсвием такого раздела форума на RSDN

VAB>был вроде — см ниже по ветке ответ
см. ниже по ветке ответ.

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

VAB>хм, ну или учите язык или меняйте профессию. Это из реальных советов. а нереальные наверное и не нужны?

Учу, приходится.

FDS>> 8.9. Отсутствие достаточного и даже необходимого количества литературы, доступной бесплатно и в электронном виде

VAB>да полно ее полно. 30Гб может и нет но уж 3 то у меня давно накопилось — при том что отбираю не все подряд

Я же говорил, по одной тематике может и 30, по другой — нефига.


FDS>>Выводы о том, что надо делать, делайте сами, потому что всё равно вряд ли кто-то влиятельный эти выводы примет к сведению

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

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