Здравствуйте, Sharowarsheg, Вы писали:

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

Книжек просто не читали и все. Так бы знали.

Здравствуйте, Ikemefula, Вы писали:

I>8 лет вполне нормально для КМС, здесь нет ничего необычного. Вот если бы он до уровня гроссов дошел в этом возрасте — вот что странно.

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

I>Собтсвенно уровень гроссов менее чем за 10 лет достигают уникумы.

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

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

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

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

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

Т.е. проблемой проверки конкретного понимания на собеседовании является то, что невозможно понять почему человек не понимает какой-то принцип: 1) из-за того, что у него способностей 2) из-за того, что у вас просто разная терминология 3) из-за того, что человек с такими задачами не сталкивался

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

Здравствуйте, Tanker, Вы писали:

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

А ты бы предпочел термины из википедии обсудить? И что интересно нового и полезного из такой дискуссии можно было бы вынести?

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Tanker, Вы писали:

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

U>А ты бы предпочел термины из википедии обсудить? И что интересно нового и полезного из такой дискуссии можно было бы вынести?

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

Здравствуйте, gandjustas, Вы писали:


T>>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны.
G>Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование?
G>С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.

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

Здравствуйте, Undying, Вы писали:

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

Я говорю о том, что если хочешь полностью заменить человека, т.е. решать все его задачи так же хорошо как и он, тебе придется потратить столко же времени. По другому не бывает.
Хочешь опровергнуть — покажи как можно стать уровня гроссов менее чем за 10 лет. Не надо носить рояль, покажи эту серебряную пульку. Ну хотя бы е гроссов, но по ЭЛО что бы было близко.

U>А почему надо понимать именно производную?

Ты лучше читать научись. Я на примере производной показал тот же принцип — понимаешь базу, можешь применить её сколь угодно широков.
Знаешь ты критерий Вилкоксона — значит тебе не надо запоминать случаи его применения.
Сумел прочесть одну книгу — сумешь прочесть и другую.

U>Если у человека есть способности, то он сможет понять принцип "разделять и властвуй", даже если ранее его не знал и соответственно не понимал.

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

U>Т.е. проблемой проверки конкретного понимания на собеседовании является то, что невозможно понять почему человек не понимает какой-то принцип: 1) из-за того, что у него способностей 2) из-за того, что у вас просто разная терминология 3) из-за того, что человек с такими задачами не сталкивался

Во, чую, скоро ты выдаешь еще одну новую хронологию терминологию

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

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

1. циклы
2. списки
3. ссылки-указатели

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

Как правило, причины простые, я это обязательно проверяю. Это может быть "летун", т.е. любитель менять работы или просто постоянно ходит по собеседованиям, ище ЗП на 100$ больше. Или человек с хорошей памятью, которй, скажем, прочитал за неделю всего Рихтера и знанием деталей может ужаснуть. Это может быть новичек который еле-еле освоил ровно одну область небольшую и в ней еще ничего не успел забыть. Есть люди которые искаропки говорят очень гладко и стройно, аж заслушаться можно.

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

Есть подтверждение — хорошо. Нет — до свидания. И я даю обычно больше одной задачи, просто одна большая по времени, строчек на 10-15 от силы, остальные можно и устно или просто картинкой изобразить и тд.

Здравствуйте, Tanker, Вы писали:

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

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

Здравствуйте, gandjustas, Вы писали:

I>>Затем, что такой код и дает больше всего ошибок.
G>Я же тебе писал что ты неправ. В среднем плотность ошибок одинаковая. Типовой код пишется чще, следовательно ошибок в нем больше.
G>Кроме того нетиповой код скорее всего пройдет формальное review и ошибки будут устранены. А весь типовой код не проходит.

Ты сначала говорил про какую то статистику, а теперь оказывается, что статистики у тебя нет

I>>Дай уже эту статистику.
I>>Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить
I>>Парадокс какой то.
G>Ты не подменяй понятия "готовое" и "типовое". Если ты 100500 раз писал обходы графов, то любой обход для тебя будет типовой. Даже если ты его с нуля пишешь.

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

G>Так вот ты пишешь таким образом 80% типового кода. Пишешь его быстро и обычно у тебя 20-50 ошибок на 1000 строк. Просто из-за невнимательности.
G>20% кода не типовые, ты тратишь на них большую часть времени, проверяешь несколько раз, и получаешь те же 20-50 ошибок на 1000 строк.
G>Вот только ты написал типового кода 200 строк, а не типового — 40. И где суммарно будет больше ошибок?

" а теперь оказывается, что статистики у тебя нет"


I>>Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок.
G>Я вот консалтингом подрабатываю, в том числе занимаюсь внедрением процессов контроля качества кода. Так вот почти у всех в только что написаном коде примерно один дефект на 6-10 строк.
G>Это я наблюдал в дсятке мест.

"а теперь оказывается, что статистики у тебя нет"

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

I>>Кто ж вам доктор теперь ?
G>Ну вот перестали давать, как-то лучше стало.

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

I>>>>Если задача сводится к типовой, это просто типовая задача.
G>>>Нет. Иногда можно условия поменять.
I>>Покажи такое изменение условия.
G>Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком.

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

"а теперь оказывается, что статистики у тебя нет"

I>>Покажи уже эту статистику.
G>МакКонелла читай.

Пудозреваю, ты как то прочел его особым образом.

G>Увы ссылку на оригинальное исследование не могу найти.

"а теперь оказывается, что статистики у тебя нет"

I>>>>Разлагается на другие и типовая задача это две большие разницы.
G>>>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой.
I>>Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые.
G>Нет, не все.

"Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком."

"а теперь оказывается, что статистики у тебя нет"


G>>>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал.
I>>Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые.
G>Я говорю что два случая бывает. Но мозг тебя часто обманывает, выдавая второй за первый.


I>>Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем.
G>Это только кажется. Потому что твой мозг напрягается при решении гораздо больше. А за время проведения codereview я разницы не заметил, да и наш TFS говорит о том, что разницы в принципе нет.

Чудеса да и только. Отработаные решения не надо даже дебажить. А вот новые задачи съеают вагон времени на отладку. Похоже, в Шарепоинте как то все наоборот — отработаные решения так же сложные, как и новые

"а теперь оказывается, что статистики у тебя нет"

G>>>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление
I>>Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы.
G>Еще раз. Это все неосознано. От квалификации программистов не зависит.

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

G>Не может один и тот же программист все время решать уникальные задачи. Они просто кончатся. Поэтому достоверную статистику собрать непонятно как.
G>Обычно распределение решаемых задач — 80\20. Как только программист натренируется решать определенные задачи — они становятся типовым для него, он их решет быстрее и у него появляется время решать другие задачи, которые для него нетиповые.

Если свести все задачи к вбиванию символа, то 100% задач станут типовыми, прикинь, все что надо — гнать код.

I>>Велосипедостроителей примерно одинаково и там и там, причины я описал.
G>Я так и не понял как ты их поделил.

Если читать, то помогает.

I>>Данные всегда в памяти.
G>
G>Откуда они берутся? Они зашиты в исполняемый модуль?

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

Здравствуйте, gandjustas, Вы писали:

I>>Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?

G>Ссылку на вакансию кинь? Проверим.

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

Здравствуйте, gandjustas, Вы писали:

I>>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
G>Ну ок. Человек понимает что такое value и ref типы. ИМХО без этого нельзя писать на .NET.
G>Что ему ее нужно? Разворачивать список на месте на бумажке? Я так и не понял зачем это умение.

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

G>Понимание identity? Что это вообще такое? Как выражается?

Похоже, с тобой все ясно.

G>Ты ведь так и не сказал зачем нужен разворот списка. Вроде свелось к пониманию value и ref, но это не головоломка (см определение выше).

Уже раз пять, и один раз выше прямо по тексту.

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

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

G>Есть исследование, которое показывает что инженеры обычно генерируют кучи решений и отсекают неподходящие. Причем критерий "подходящести" обычно меняется при рассмотрении новых вариантов.
G>Увы ссылку не найду быстро, можешь погуглить если интересно.
G>Вообще читай Design of Design Брукса.

Вот в нем как раз все ответы на твои вопросы.

Здравствуйте, gandjustas, Вы писали:

Объясни, пожалуйста, где тут ревес списка

G>

G>static string Reverse1(string s)
G>{
G>    var result = new StringBuilder(s.Length);
G>    for(int i = s.Length-1; i>=0; i--)
G>    {
G>        result.Append(s[i]);
G>    }
G>    return result.ToString();
G>}

G>Можешь у себя запустить.

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

Здравствуйте, gandjustas, Вы писали:


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

Оно и заметно — такие комбинаторы и выдают вместо реверса списка реверс строки через стрингбилдер.

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

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, gandjustas, Вы писали:


T>>>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны.
G>>Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование?
G>>С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.

T>Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает
По сути оно так и есть.

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?

G>>Ссылку на вакансию кинь? Проверим.

I>Ты собеседование что ли хочеш пройти или как ? Ты его не пройдешь, ибо предлагаешь решения нисколько не интересуясь контекстом.

Нет, мы у себя впишем требования и посмотрим кто придет

Здравствуйте, Ikemefula, Вы писали:

I> "а теперь оказывается, что статистики у тебя нет"
А ты всетаки МакКонелла прочитай.
И гугли по defects per loc. Я ссылки не сохраняю, гуглить за тебя мне тоже влом.

I>>>Данные всегда в памяти.
G>>
G>>Откуда они берутся? Они зашиты в исполняемый модуль?

I>Ты лучше спроси что за приложение, тогда дурацкие вопросы отпадут сами собой.
Зачем?

I>Данные берутся
I>1. с диска
I>2. из сети
I>3. от пользователя
I>4. создаются самой программой
В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


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

I>Оно и заметно — такие комбинаторы и выдают вместо реверса списка реверс строки через стрингбилдер.
Ты быть хоть контекст почитал. Смешно выглядишь.

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

Здравствуйте, gandjustas, Вы писали:

I>> "а теперь оказывается, что статистики у тебя нет"
G>А ты всетаки МакКонелла прочитай.
G>И гугли по defects per loc. Я ссылки не сохраняю, гуглить за тебя мне тоже влом.

Время разработки учитывать не надо ?

I>>Ты лучше спроси что за приложение, тогда дурацкие вопросы отпадут сами собой.
G>Зачем?

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

I>>Данные берутся
I>>1. с диска
I>>2. из сети
I>>3. от пользователя
I>>4. создаются самой программой
G>В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?

Ни в одном.

Здравствуйте, gandjustas, Вы писали:

I>>Ты собеседование что ли хочеш пройти или как ? Ты его не пройдешь, ибо предлагаешь решения нисколько не интересуясь контекстом.

G>Нет, мы у себя впишем требования и посмотрим кто придет

Тогда надо и бренд сменить на наш, и зп поднять и тд и тд и тд.

Здравствуйте, Undying, Вы писали:

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

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

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

Здравствуйте, gandjustas, Вы писали:

T>>Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает
G>По сути оно так и есть.

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

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

Это какие то не те админы еще есть безопасники, билд-инженеры....