Здравствуйте, so5team, Вы писали:
P>>Мысли — точно нет, ваши ассоциации — да, вы их сами сюда выливаете.
S>Вы свою интерпретацию моих слов называете "моими ассоциациями". В очередной раз вынужден вам не это указать.
Когда в ответ на мой пример из опыта вы приводите "длина", "достать", "померять", то мне это непонятно, потому я просто делаю вывод, что у вас возникли такие вот ассоциации и вы решили ими поделиться. Опыт — неизмеряемое, качественное, субъективное, длина — измеряемая, количественная, объективная. Вы разницу улавливаете? Мне трудно следить за вашим ассоциативным рядом.
Это ж не я пишу про длину с вашего аккаунта, как считаете?
P>>Именно!
S>Именно что? С первого для и продакшен качества код?
И то и другое. Сеньор наверняка научился писать продакшн качества код на предыдущих проектах.
S>Простите, но не верю.
А я вас и не убеждаю.
S>>>Если так, то я не то, что такого никогда не видел, но даже и не слышал (не читал) о подобном.
P>>А что тут знать — если я знаю продукт, и представляю опыт сотрудника, то нужно сделать еще один шаг — найти область пересечения. Вот приходит джавист с бакенда на проект с TypeScript фронтенд в кроссплатформенном гибридном приложении, ему даем задачку перефиксать все логирование в гибридном кроссплатформенном приложении, которое только есть.
S>Да, для такого рода работ нужно обязательно искать сеньора, не меньше. Меня другое интересует: у вас ваш сеньор сразу же начнет получать задания для своей квалификации или все-таки какое-то время на погружение ему потребуется?
Смотря какой опыт. Вот выпускника ФПМ с близким бекраундом мы сразу посадили за алгоритмы в коре. И очень даже успешно. При этом он был сиплюсник, а у нас уже разгул полного дотнета.
Если сеньор переходит из абсолютно чужой области, то не совсем понятно, как он к нам в команду то попал.
S>Судя по тому, что вы пишете про "перефиксать все логирование", таки потребуется. А раз так, то не вижу противоречий с тем, что я говорил раньше. Вы же лишь цепляетесь за детали того, как будет происходить погружение человека в проект.
К сожалению, я не в курсе, как вы это понимаете и что вы там додумали. Я то в курсе, какая была задача и какая у ней сложность была, а вы — нет.
P>>Что еще надо ? S>Надо, чтобы речь шла о фремворке, который никто не знает за пределами "Рога и Ко".
На мой взгляд, фремворк в любом проекте это минорное знание, изучается по ходу. Требовать на входе знание того или иного фремворка значит сужать круг кандидатов.
Потому от отсутствия знания фремворка издержки тоже минорные. Куда больше издержки, если джун думает, что логирование это просто ctx.trace.
S>Если вам нужно объяснять такое мидлу, то у нас с вами разные понятия об уровне "мидл".
Разумеется, разное. А почему должно быть иначе?
P>>О том я и говорю. Тогда и пишите прямо: "ваши слова для меня ничего не значат". S>Вы просто мастер интерпретировать мои слова по своему. В оценке адекватности ваших высказываний они значат для меня многое.
Это просто логика. Нивелировать = убрать разницу. Посмотрите контекст, где вы пишете про нивелировать. Я вот сомневаюсь, что вы имели ввиду убрать разницу между моим и вашим опытом. А раз так, то выбор невелик.
S>>>Тут вопрос в том, что вы понимаете под опытом.
S>Вот мой опыт говорит, что при переходе с MFC на Qt все знания API MFC и принципов построения приложений на базе MFC можно смело выбрасывать. S>Вы же говорите, что это не так. Хочется понять почему.
Вы дали общие слова, а от меня почему то ждете бОльшей конкретики Фремворк это не про знание API. Это подход к проектированию. И самое ценное, что можно взять у сеньора, это его навыки проектирования. И эти навыки между MFC и QT схожие.
Вот, скажем, современный фронтенд далек что от MFC, что от QT. По крайней мере того, с которым я работал.
P>>В те же времена, когда использовал C/С++/MFC/WinApi/ATL/WTL/COM. Забавно, что вы не в курсе, какой же у меня опыт был, но уже даете оценки.
S>Когда в разговоре про Qt человек пишет QT, то про опыт многое становится понятно.
А если учесть, что и по русски я опечатки делаю, то и вовсе надо точку ставить в разговоре.
P>>Я думал у вас будет аргумент, но вы поделились общими словами
S>Слушайте, я вам кучу названий библиотек и фреймворков привел. Тому, кто знает о чем идет речь, уже достаточно, остальным пофигу. Скажем, в Qt moc, механизм signal-slots, модель владения на основании дерева QObject и QWidget, Layout-ы и spacer-ы в диалогах и т.д., и т.п. Тогда как MFC -- это относительно тонкая обертка вокруг WinAPI. А Dear ImGUI -- это вообще совсем другой принцип работы с UI.
Не поверите, но после MFC эти сигнал-слоты мне были понятны сразу, без объяснений. Проблему они какую решают, по вашему?
Layout, spacer — встроеных вещей в мфц нет, но их обычно добавляли тем или иным образом в виде доп либы. В нашем проекте было. Вы что думаете, в мфц все мастырили наколеночный код, и не знали что такое Layout и декларативное задание поведения?
QWidget семантически похож на Window. QObject ровно тот же CObject, только чуть-чуть иначе сделан.
На счет Layout, spacer — щас вот перешел на Linux, понасмотрелся на результаты применения Qt. Местами такой убогий лайоут, что иногда хочется на выундоус.
Вобщем, это всё минорные знания.
P>>Только, похоже, ваш неуд выглядит вдвойне неадекватным аргументом. S>Вы даже не поняли за что неуд.
Да как ни крути, конструктива в этом я не вижу.
P>>Тем не менее это ассоциации. Я не пытаюсь их интерпретировать, просто указываю на сам факт, который зафиксирован в истории сообщений. S>Когда вы "просто указываете" -- это есть высказывание вашей интерпретации моих слов и озвученных вами "моих ассоциации".
Когда я указаваю, это просто сообщаю что есть такой факт. А интерпретация это совсем другая вещь, которую я нигде не приводил.
Чего вы пугаетесь? У человека всё мышление построено на ассоциациях. Это нормально, если собеседнику понятно о чем речь.
Вы, похоже, не сильно заботитесь быть понятым.
Впрочем, вам это и другие указывали на это.
S>Про длину опыта яркий пример. Вы домыслили за меня и выдали это за "мои ассоциации". И так у вас все. По крайней мере в этом обсуждении.
Читайте сами:
Я не просил вас доставать ваш опыт и демонстрировать его длину.
Как мы видим, мой опыт вызвал у вас ассоциацию с длиной. Заметьте — это вы писали, не я. Опыт — качественное, неизмеримое, субъективное, а длина — количественная, измеримая, объективная. А вот логику такого перехода вы объяснить затрудняетесь. Ну, бывает. Я и не требую, что бы вы объясняли всё сказанное.
P>>Ну так посмотрите на количество сообщений у меня и у вас, на количество нарушений у меня и у вас. S>Э... 1933/3 (644) против 40390/69 (585). О чем должны сказать эти числа?
Да вроде очевидно — переходить со мной на личности дело вобщем бессмысленное. Но если вы таки видите в этом смысл, пожалуйста.
Впрочем, я уже давал разрешение даже хамить мне. Если вам так будет легче, валяйте.
S>Шансов на что? На то, что я донесу до вас смысл? Таких шансов ноль. Абсолютный.
Очевидно, что это вы так думаете. Вероятно, потому и переходите на личности. Только в эту игру можно играть не только вдвоем, но и целым форумом. Тут желающих много.
S>Вы действуете однотипно: как-то по своему воспринимаете мои слова и, вместо того, чтобы уточнить, вываливаете на меня свой спор со своим восприятием. Приписывая попутно мне некие ассоциации.
Очевидно, что я не умею читать ни ваши мысли, ни чьи угодно. А раз так, то воспринимаю написаное в соответствии с тем опытом, что у меня есть.
Ассоциации — это смотрите ваше сообщение про длину опыта.
Длина — измеримая, количественная характеристика. Опыт — неизмеримая, качественная.
Отсюда ясно, что вы где то передёргиваете, раз у вас неизмеримое качественное субъективное стало измеримым количественным объективным.
Здравствуйте, Pauel, Вы писали:
P>Опыт — неизмеряемое
Видимо, ваш опыт никогда не видел вакансий и резюме, в которых опыт измеряется годами. А от ограниченности опыта может проистекать и специфическое восприятие реальности.
P>И то и другое.
Ну, OK. Пусть так.
P>А я вас и не убеждаю.
Проблема в том, что ваши слова доверия не вызывают, т.к. противоречат всему что видел и слышал. Но я уже понял почему так происходит.
P>Смотря какой опыт. Вот выпускника ФПМ с близким бекраундом мы сразу посадили за алгоритмы в коре. И очень даже успешно. При этом он был сиплюсник, а у нас уже разгул полного дотнета.
Т.е. вы просто нашли место под человека. Так бывает.
P>Если сеньор переходит из абсолютно чужой области, то не совсем понятно, как он к нам в команду то попал.
А теперь представьте ситуацию, когда есть проблема, а людей, заточенных под ее решение на рынке нет. И нужно искать из того, что есть.
S>>Судя по тому, что вы пишете про "перефиксать все логирование", таки потребуется. А раз так, то не вижу противоречий с тем, что я говорил раньше. Вы же лишь цепляетесь за детали того, как будет происходить погружение человека в проект.
P>К сожалению, я не в курсе, как вы это понимаете и что вы там додумали. Я то в курсе, какая была задача и какая у ней сложность была, а вы — нет.
Ну так поделитесь деталями. И другие будут в курсе.
P>На мой взгляд, фремворк в любом проекте это минорное знание, изучается по ходу. Требовать на входе знание того или иного фремворка значит сужать круг кандидатов. P>Потому от отсутствия знания фремворка издержки тоже минорные. Куда больше издержки, если джун думает, что логирование это просто ctx.trace.
Может быть потому, что вы не сталкивались с фреймворками, которые заточены под задачу?
S>>Если вам нужно объяснять такое мидлу, то у нас с вами разные понятия об уровне "мидл".
P>Разумеется, разное. А почему должно быть иначе?
Потому что уровни квалификации "джуниор", "мидл" и "сеньор" более-менее устоялись.
P>Это просто логика. Нивелировать = убрать разницу. Посмотрите контекст, где вы пишете про нивелировать. Я вот сомневаюсь, что вы имели ввиду убрать разницу между моим и вашим опытом. А раз так, то выбор невелик.
Вы нивелировали свой уровень до уровня плинтуса. В таком смысле это было употреблено. Простите, если употребил слово неправильно.
P>Вы дали общие слова, а от меня почему то ждете бОльшей конкретики Фремворк это не про знание API. Это подход к проектированию. И самое ценное, что можно взять у сеньора, это его навыки проектирования. И эти навыки между MFC и QT схожие.
Такое я уже слышал и неоднократно. От архитекторов-астронавтов, которые код давным-давно не пишут, а квадратики на вайтбордах рисуют и щеки на совещаниях надувают. А как дойдет дело до кода (того же джуна, который нужно пофиксить и объяснить почему так делать нельзя), так и выясняется, что разница не только в принципах, но и в вызовах конкретных функций.
S>>Слушайте, я вам кучу названий библиотек и фреймворков привел. Тому, кто знает о чем идет речь, уже достаточно, остальным пофигу. Скажем, в Qt moc, механизм signal-slots, модель владения на основании дерева QObject и QWidget, Layout-ы и spacer-ы в диалогах и т.д., и т.п. Тогда как MFC -- это относительно тонкая обертка вокруг WinAPI. А Dear ImGUI -- это вообще совсем другой принцип работы с UI.
P>Не поверите, но после MFC эти сигнал-слоты мне были понятны сразу, без объяснений. Проблему они какую решают, по вашему?
Вы не туда разговор ведете. Речь о том, что знания API MFC вам придется выбросить когда придется работать с API Qt, и наоборот.
P>Вы что думаете, в мфц все мастырили наколеночный код, и не знали что такое Layout и декларативное задание поведения?
Я вообще говорю о других вещах.
P>Вобщем, это всё минорные знания.
См. выше про архитектора-астронавта.
Ну и правильно я понимаю, что раз эти знания минорные, то вы готовы сходу начать писать код на Qt?
P>Когда я указаваю, это просто сообщаю что есть такой факт. А интерпретация это совсем другая вещь, которую я нигде не приводил.
Поздравляю вас соврамши:
"Здесь логическая ошибка и это в вашей голове, предполагая, что это вы писали в тот раз с этого аккаунта.
Если готовых сеньоров нет, то из этого никак не следует, что можно брать сразу джуниоров и мидлов."
Это ваша интерпретация моих слов: "Если компания использует внутренний фреймворк X, специалистов по которому на рынке нет от слова совсем, то бесполезно искать кандидатов уровня senior со знанием X. Их не существует."
P>Чего вы пугаетесь?
Я не пугаюсь, я настойчиво предлагаю говорить о том, что написал я, а не о том, что вы домыслили за меня.
S>>Про длину опыта яркий пример. Вы домыслили за меня и выдали это за "мои ассоциации". И так у вас все. По крайней мере в этом обсуждении.
P>Читайте сами: P>
P>Я не просил вас доставать ваш опыт и демонстрировать его длину.
P>Как мы видим, мой опыт вызвал у вас ассоциацию с длиной. Заметьте — это вы писали, не я. Опыт — качественное
Смотрим выше. Размер/длина опыта -- это давно уже устоявшиеся понятия и в разговорах, и в резюме, и в вакансиях, вполне себе количественные. Как по годам опыта, так и по количеству сделанных проектов, так и по количеству записей в трудовой, так и по другим параметрам.
Так что все ассоциации на вашей совести.
P>Очевидно, что я не умею читать ни ваши мысли, ни чьи угодно. А раз так, то воспринимаю написаное в соответствии с тем опытом, что у меня есть.
А вы попробуйте задать дополнительный вопрос а не домысливать. Я вот вам вопросы задаю, скажем, про то, что подразумевается "сразу в бой". И получаю недостающую информацию. Если вам размер вашего опыта не позволяет так делать, то перестаньте хотя бы приписывать мне свои собственные ассоциации.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Мельком видел как он работает на Линуксе (в основном внутри VM), долго плевался. На Винде я его и не вижу, вообще ни одного приложения на Qt не использовал на постоянной основе. Телеграммом пользуешься?
Здравствуйте, Vermicious Knid, Вы писали: VK>Я к тому, что внутри Qt ничего радикально не поменялось.
Это демонстрация невежества и не более. Механизмы отрисовки менялись. Их сейчас несколько. VK>Это монструозное создание, которое любит жрать ресурсы.
Какие ресурсы оно особо ест?
Пример
3 приложения на Qt:
— Qt Creator
— Novelda HPD Studio (показывает графики на отдельном мониторе)
— Telegram
VK>Это очень грустно (если посмотреть с точки зрения пользователя ПК).
С точки зрения ПК только сейчас массово появляется нормальный интерфейс, а не "миллион тулбоксов и кнопочек" в духе винды 90-х.
Здравствуйте, so5team, Вы писали:
S>Видимо, ваш опыт никогда не видел вакансий и резюме, в которых опыт измеряется годами. А от ограниченности опыта может проистекать и специфическое восприятие реальности.
Помню, вы мне совет давали: "А вы попробуйте задать дополнительный вопрос а не домысливать. "
Возвращаю его вам, тк этим подходом вы не пользуетесь.
У меня в основном долгоиграющие проекты были, отсюда в вакансии давали соответствующие описания, и получали резюме под эти описания.
Вобщем, ваша угадайка подсказывает вам чтото не то.
P>>А я вас и не убеждаю.
S>Проблема в том, что ваши слова доверия не вызывают, т.к. противоречат всему что видел и слышал. Но я уже понял почему так происходит.
Так бывает. При этом почему то именно вы рассказываете, чего я смогу, а чего нет.
P>>Смотря какой опыт. Вот выпускника ФПМ с близким бекраундом мы сразу посадили за алгоритмы в коре. И очень даже успешно. При этом он был сиплюсник, а у нас уже разгул полного дотнета. S>Т.е. вы просто нашли место под человека. Так бывает.
Это не единичный пример. Извините, всех перечислять слишком долго. В целом мы закрывали вакансии довольно быстро. Часто даже upfront — до того, как появится вакансии, уже была пара-тройка потенциальных кандидатов.
P>>Если сеньор переходит из абсолютно чужой области, то не совсем понятно, как он к нам в команду то попал. S>А теперь представьте ситуацию, когда есть проблема, а людей, заточенных под ее решение на рынке нет. И нужно искать из того, что есть.
Тогда нужно отталкиваться от людей с похожим бекграундом — домен, дизайн-архитектура, ресёрч, и если ну никак, то уже тогда скатываться до джунов-мидлов.
Многие скилы даже у мидлов отсутствуют. Каким образом они будут с вашей проблемой взаимодействовать?
Пилить UI и из него не вылазить? Ну сгодится мидл. Ну, джун, если денех нет. А если нужно чтото больше — трудно понять, как вы это хотите достать из мидла.
S>>>Судя по тому, что вы пишете про "перефиксать все логирование", таки потребуется. А раз так, то не вижу противоречий с тем, что я говорил раньше. Вы же лишь цепляетесь за детали того, как будет происходить погружение человека в проект.
S>Ну так поделитесь деталями. И другие будут в курсе.
Логирование это одна из систем контроля качества, нас интересует решение end2end. От момента появления подозрительной ситуации, до момента поступления сведений о ней нашим QA, девелоперам или суппорту. Задача включала в себя не столько фиксы логирования, сколько получение четкой, внятной картины, что где происходит, как настраивает, куда шлется, как вычитывается, итд.
Сбросить такое на джуна — утонет. Бакенду с опытом — вполне, он такое искаропки умеет.
P>>Потому от отсутствия знания фремворка издержки тоже минорные. Куда больше издержки, если джун думает, что логирование это просто ctx.trace. S>Может быть потому, что вы не сталкивались с фреймворками, которые заточены под задачу?
А вы имеете ввиду "заточены под задачу"? Все фремворки это библиотечный способ расширения языка под конкретное семейство задач.
P>>Разумеется, разное. А почему должно быть иначе? S>Потому что уровни квалификации "джуниор", "мидл" и "сеньор" более-менее устоялись.
Не наблюдаю такого. Вот сеньоров начинают местами стругать с года опыта, а у других в этом время только мидл начинается. Что здесь устоялось?
S>Вы нивелировали свой уровень до уровня плинтуса. В таком смысле это было употреблено. Простите, если употребил слово неправильно.
Вы подобное повторяли уже раз пять в разной форме. Что мне должна дать такая информация?
Я и без этого понимаю, что вы не доверяете моим словам.
Это следует из ваших ассоциаций, попыток "измерять", ставить "неуд" и тд и тд.
Вы, проще говоря, в своём классическом репертуаре. Это же ваш аккаунт eao+цифры какието ?
P>>Вы дали общие слова, а от меня почему то ждете бОльшей конкретики Фремворк это не про знание API. Это подход к проектированию. И самое ценное, что можно взять у сеньора, это его навыки проектирования. И эти навыки между MFC и QT схожие.
S>Такое я уже слышал и неоднократно. От архитекторов-астронавтов, которые код давным-давно не пишут, а квадратики на вайтбордах рисуют и щеки на совещаниях надувают.
Точнее — вы тех, кто думает иначе, считаете астронавтами. Говорите честно, это всегда в почете.
P>>Не поверите, но после MFC эти сигнал-слоты мне были понятны сразу, без объяснений. Проблему они какую решают, по вашему? S>Вы не туда разговор ведете. Речь о том, что знания API MFC вам придется выбросить когда придется работать с API Qt, и наоборот.
Это минорные знания, они подымаются с земли за ничтожное количество времени.
S>Ну и правильно я понимаю, что раз эти знания минорные, то вы готовы сходу начать писать код на Qt?
Последние лет 10 у меня задачи, как бы сказать, совсем не UI. И желания погружаться в UI нет.
C/C++/MFC/ATL/WTL/COM/QT — это закончилось где то в 2007м году.
P>>Когда я указаваю, это просто сообщаю что есть такой факт. А интерпретация это совсем другая вещь, которую я нигде не приводил.
S>Поздравляю вас соврамши: S>"Здесь логическая ошибка и это в вашей голове, предполагая, что это вы писали в тот раз с этого аккаунта. S>Если готовых сеньоров нет, то из этого никак не следует, что можно брать сразу джуниоров и мидлов."
Вы и за контекстом перестали следить
P>Это ж для вас это чтото странно, раз у вас здесь появляются странные ассоциации вида "длина", "достаньте", "спрячьте".
Простите, но я все эти слова употреблял в отношении вашего опыта. И не несу ответственности за ваши интерпретации их смысла.
S>Это ваша интерпретация моих слов: "Если компания использует внутренний фреймворк X, специалистов по которому на рынке нет от слова совсем, то бесполезно искать кандидатов уровня senior со знанием X. Их не существует."
— читайте свой ответ на это сообщение. У вас резкий переход к оценкам, и измерениям.
Собственно, вы постоянно даете оценки, то мне, то моему опыту, только признавать это не хотите. Это уже интерпретация ваших ассоциаций, т.к. сведений накопилось вполне достаточнь.
S>Я не пугаюсь, я настойчиво предлагаю говорить о том, что написал я, а не о том, что вы домыслили за меня.
Ну так посмотрите по дереву
P>>Как мы видим, мой опыт вызвал у вас ассоциацию с длиной. Заметьте — это вы писали, не я. Опыт — качественное
S>Смотрим выше. Размер/длина опыта -- это давно уже устоявшиеся понятия и в разговорах, и в резюме, и в вакансиях, вполне себе количественные. Как по годам опыта, так и по количеству сделанных проектов, так и по количеству записей в трудовой, так и по другим параметрам.
Вы постоянно даёте оценку и мне, и моему опыту. Так понятнее? Вы что, видите в этом конструктив?
P>>Очевидно, что я не умею читать ни ваши мысли, ни чьи угодно. А раз так, то воспринимаю написаное в соответствии с тем опытом, что у меня есть.
S>А вы попробуйте задать дополнительный вопрос а не домысливать.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Qt нарушает основной принцип C++ — "не платить за неиспользуемое". Фактически, он создает избыточную "экосистему" вместо предоставления [относительно] независимых возможностей.
Привиди пример, за что "переплачиваешь", что невозможно отключить?
ЕМ>Из-за этого он органично смотрится только в достаточно тяжелом софте, а легкий — сильно утяжеляет сам.
Покожи "легкий" софт который работает на 3-4 платформах и рисует хоть что-то интересное?
Здравствуйте, Skorodum, Вы писали:
ЕМ>>Qt нарушает основной принцип C++ — "не платить за неиспользуемое". Фактически, он создает избыточную "экосистему" вместо предоставления [относительно] независимых возможностей. S>Привиди пример, за что "переплачиваешь", что невозможно отключить?
QT превратился в маленький аналог .Net platform, или JDK. Пудозреваю, это имелось ввиду.
ЕМ>>Из-за этого он органично смотрится только в достаточно тяжелом софте, а легкий — сильно утяжеляет сам. S>Покожи "легкий" софт который работает на 3-4 платформах и рисует хоть что-то интересное?
Здравствуйте, vaa, Вы писали:
vaa>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
Когда-то давно делал на С++ с MFC, но это не интересно.
Из более интересного — делал гуевые приложения на D с использованием DFL (почти клон WinForms) и DlangUI (это ближе к Qt, само рисует, есть декларативная разметка а-ля QML). Тема — обработка фото и видео. Тормозов и проблем с GC не было, кроме одного случая, когда 32-битное приложение (визуализатор дисков) большие графы объектов строило. Сейчас при компиляции в 64 бита GC обычно проблем не создает.
Бинарники получались небольшие, запускались мгновенно, работали гладко.
В D нет строгой дихотомии между "всем управляет GC" и "все вручную", можно выбирать. Например, буферы для кадров видео выделить вручную и потом самому освободить, а всякий мелкий мусор вроде строк и GUI объектов можно отдать на откуп GC, там суммарный объем небольшой и сборка проходит быстро.
Здравствуйте, Pauel, Вы писали:
P>У меня в основном долгоиграющие проекты были, отсюда в вакансии давали соответствующие описания, и получали резюме под эти описания. P>Вобщем, ваша угадайка подсказывает вам чтото не то.
Какое отношение это имеет к тому, что в окружающией меня реальности опыт вполне себе имеет количественное выражение? Для вас опыт не выражается количественно, поэтому вы не можете нормально воспринять разговоры о длине опыта.
S>>Проблема в том, что ваши слова доверия не вызывают, т.к. противоречат всему что видел и слышал. Но я уже понял почему так происходит.
P>Так бывает. При этом почему то именно вы рассказываете, чего я смогу, а чего нет.
Где я говорил, что вы чего-то не сможете?
P>>>Смотря какой опыт. Вот выпускника ФПМ с близким бекраундом мы сразу посадили за алгоритмы в коре. И очень даже успешно. При этом он был сиплюсник, а у нас уже разгул полного дотнета. S>>Т.е. вы просто нашли место под человека. Так бывает.
P>Это не единичный пример. Извините, всех перечислять слишком долго. В целом мы закрывали вакансии довольно быстро. Часто даже upfront — до того, как появится вакансии, уже была пара-тройка потенциальных кандидатов.
Это "много" не имеет отношение к разговору об условном фреймворке X от "Рога и Ко".
P>>>Если сеньор переходит из абсолютно чужой области, то не совсем понятно, как он к нам в команду то попал. S>>А теперь представьте ситуацию, когда есть проблема, а людей, заточенных под ее решение на рынке нет. И нужно искать из того, что есть.
P>Тогда нужно отталкиваться от людей с похожим бекграундом — домен, дизайн-архитектура, ресёрч, и если ну никак, то уже тогда скатываться до джунов-мидлов.
Ну и с чем вы тогда спорите? Рискую предположить, что "в интернетах кто-то не прав" и вам хочется доказать что правы именно вы.
Но это мое предположение. Поэтому уточню у вас: так ли это?
P>Многие скилы даже у мидлов отсутствуют. Каким образом они будут с вашей проблемой взаимодействовать?
Посредством правильного погружения в тему, обучения и воспитания. Ваш КО.
P>Пилить UI и из него не вылазить? Ну сгодится мидл. Ну, джун, если денех нет. А если нужно чтото больше — трудно понять, как вы это хотите достать из мидла.
Вырастить со временем сеньора со знанием X (потому что на рынке таких нет от слова совсем). И да, речь вовсе не только про UI.
P>Логирование это одна из систем контроля качества, нас интересует решение end2end. От момента появления подозрительной ситуации, до момента поступления сведений о ней нашим QA, девелоперам или суппорту. Задача включала в себя не столько фиксы логирования, сколько получение четкой, внятной картины, что где происходит, как настраивает, куда шлется, как вычитывается, итд.
P>Сбросить такое на джуна — утонет. Бакенду с опытом — вполне, он такое искаропки умеет.
Как интересно получается, оказывается не только фиксы, тут еще и куча другой работы.
P>А вы имеете ввиду "заточены под задачу"?
То и имелось в виду. Уж простите за грубость.
P>Все фремворки это библиотечный способ расширения языка под конкретное семейство задач.
Вот, скажем, Qt GUI -- это фреймворк для UI. Но он не заточен под задачу, Qt GUI универсален и делать что-то специфическое на нем (например, рисовать спектрограммы звуковых семплов) с нуля может быть слишком долго и дорого. Под конкретную задачу на Qt GUI можно сделать специфический фреймворк, скажем, позволяющий работать со спектрограммами всего парой-другой строчек кода.
Из конкретного опыта -- внутренний фреймворк для проведения платежных транзакций. Где-то глубоко под капотом там были базовые вещи из J2EE, но сверху это была заточенная под определенные требования и определенные предположения конструкция.
S>>Потому что уровни квалификации "джуниор", "мидл" и "сеньор" более-менее устоялись.
P>Не наблюдаю такого. Вот сеньоров начинают местами стругать с года опыта, а у других в этом время только мидл начинается. Что здесь устоялось?
Критерии. Что-то вроде:
Джуниор -- максимально подробное описание задачи, описание способов решения, помощь в выполнении, обязательный контроль результатов.
Мидл -- четкое описание задачи (не обязательно подробное), возможно, указание на способ решения, не нужна помощь в выполнении, контроль результатов желателен.
Сеньор -- общее описание задачи (подробности выясняет сам исполнитель), нет способов решения (изыскивает сам исполнитель), не нужна помощь в выполнении, не нужен контроль результатов.
И это еще не касаясь ролей наставничества и пр.
Вроде бы уже лет 15 как такая градация устоялась.
P>Вы подобное повторяли уже раз пять в разной форме. Что мне должна дать такая информация?
В том, что апелляция к "из моего опыта" не работает. Конкретика (вроде задачи с фиксингом логов) работает. Общая отсылка к опыту -- нет.
P>Точнее — вы тех, кто думает иначе, считаете астронавтами. Говорите честно, это всегда в почете.
Опять не угадали.
P>>>Не поверите, но после MFC эти сигнал-слоты мне были понятны сразу, без объяснений. Проблему они какую решают, по вашему? S>>Вы не туда разговор ведете. Речь о том, что знания API MFC вам придется выбросить когда придется работать с API Qt, и наоборот.
P>Это минорные знания, они подымаются с земли за ничтожное количество времени.
Вообще-то речь не про подымаются, а про забывание:
"Разница будет только в том, что сеньор может быстрее начать выдавать результат. Да и то не факт, т.к. сеньора будут ставить на более сложные задачи, которые будут требовать более глубокого погружения. Причем сеньору может потребоваться много чего из своих знаний выбросить за ненадобностью. Чего не будет у мидлов с джуниорами."
При переходе с MFC на Qt вам не нужен будет огромный пласт знаний, связанных с MFC API и тонкостями его использования. Этот пласт сеньору нужно будет забыть (а по ходу дела он ему может мешать).
S>>Ну и правильно я понимаю, что раз эти знания минорные, то вы готовы сходу начать писать код на Qt?
P>Последние лет 10 у меня задачи, как бы сказать, совсем не UI. И желания погружаться в UI нет.
А если вдруг, то вы же не сразу начнете выдавать код на Qt уровня сеньора. О том и речь.
P>>>Когда я указаваю, это просто сообщаю что есть такой факт. А интерпретация это совсем другая вещь, которую я нигде не приводил.
S>>Поздравляю вас соврамши: S>>"Здесь логическая ошибка и это в вашей голове, предполагая, что это вы писали в тот раз с этого аккаунта. S>>Если готовых сеньоров нет, то из этого никак не следует, что можно брать сразу джуниоров и мидлов."
P>Вы и за контекстом перестали следить
— читайте свой ответ на это сообщение. У вас резкий переход к оценкам, и измерениям.
Так это же вы в своем сообщении сослались на свой опыт:
Собственно, я бы предложил вам глянуть чуть дальше того "парадокса", т.к. там вполне конкретное описание моего личного опыта, наблюдений, собеседований, итд на таких вот проектах, с 2001 по 2013й
Собственно, я ему и дал оценку в разрезе нашего разговора (вы вели себя как "если я не видел, значит никто не видел").
P>Собственно, вы постоянно даете оценки, то мне, то моему опыту, только признавать это не хотите.
Если не ошибаюсь, уже неоднократно говорил, что оцениваю ваши слова и на основании этих оценок делаю выводы.
P>Это уже интерпретация ваших ассоциаций, т.к. сведений накопилось вполне достаточнь.
Видимо, вы не перестанете приплетать ассоциации сколько бы вам на это не указывали. Ок, будем знать.
Здравствуйте, so5team, Вы писали:
S>Какое отношение это имеет к тому, что в окружающией меня реальности опыт вполне себе имеет количественное выражение?
Вот видите, к чему привела ассоциация — вы говорите про реальность, где качественное выражается количественно Нанимать людей за годы опыта это вобщем тупик. А вот собеседование даёт вполне себе хорошее обоснование почему отказать тому, у кого 10 лет, или взять того, у кого 1 год опыта. Одному интересно, другому — нет. Упс. На кой ляд нам скучающий эксперт?
И это всё качественные признаки. В этом году походил по конторам, почти везде фидбек дают именно в качественных признаках. Ну вот ни разу не видел количественных. Как то так.
Скажите, пожалуйста, какая ваша нынешняя позиция, разработчик, менеджер? Давно ходили по собесам на разработчика?
P>>Так бывает. При этом почему то именно вы рассказываете, чего я смогу, а чего нет. S>Где я говорил, что вы чего-то не сможете?
Вы там что, меняетесь за этим аккаунтом? Вот ваши слова
вы не сможете взять готового сотрудника с нужными знаниями, которого можно сразу бросить в бой.
P>>Это не единичный пример. Извините, всех перечислять слишком долго. В целом мы закрывали вакансии довольно быстро. Часто даже upfront — до того, как появится вакансии, уже была пара-тройка потенциальных кандидатов. S>Это "много" не имеет отношение к разговору об условном фреймворке X от "Рога и Ко".
Разумеется. У нас то был вполне конкретный набор, я уже перечислял, сколько там было всего кастомного, хватит на десяток фремворков.
P>>Тогда нужно отталкиваться от людей с похожим бекграундом — домен, дизайн-архитектура, ресёрч, и если ну никак, то уже тогда скатываться до джунов-мидлов.
S>Ну и с чем вы тогда спорите?
Ну так это с ваших слов джуны и мидлы появились в данном треде. Я то как раз говорю, что это вынуденный вариант, или же кейс с низкой сложностью.
P>>Многие скилы даже у мидлов отсутствуют. Каким образом они будут с вашей проблемой взаимодействовать? S>Посредством правильного погружения в тему, обучения и воспитания. Ваш КО.
На мой взгляд, джунов-мидлов нужно брать. Только не по причине их перформанса, а именно ради возможности вырастить смену нынешним сеньорам, тратимся сейчас — решаем риски найма потом.
Сеньоры всё равно рано или поздно уйдут, а в самопальных решениях как правило бОльшая часть сеньоров не хочет развиваться — это потом нигде не будет востребовано.
То есть, риски найма увеличиваются настолько, что приходится применять специальные стратегии — выращивать своих.
А вы рассказываете про какое то снижение рисков
P>>Сбросить такое на джуна — утонет. Бакенду с опытом — вполне, он такое искаропки умеет. S>Как интересно получается, оказывается не только фиксы, тут еще и куча другой работы.
Ровно как у всех сеньоров. Мы даже время на изучения ЯП не выделяли. Щелкнул пальцами — "ты умеешь TypeScript" и всё.
P>>Все фремворки это библиотечный способ расширения языка под конкретное семейство задач.
S>Вот, скажем, Qt GUI -- это фреймворк для UI. Но он не заточен под задачу
Под задачей вы подразумеваете не задачу, а домен Про доменные знания всё ровно то же. Придет товарищ из этого же домена, но с другим фремворком, вы его что, отправите домой?
По моему доменные знания первичны, фремворк — вторичен. А у вас вроде как наоборот выходит.
S>Из конкретного опыта -- внутренний фреймворк для проведения платежных транзакций. Где-то глубоко под капотом там были базовые вещи из J2EE, но сверху это была заточенная под определенные требования и определенные предположения конструкция.
Ну и придет к вам человек, который писал на другой конторе такое же. Что вы ему скажете? Иди гуляй, мы джуна возьмем и будем растить?
S>Вроде бы уже лет 15 как такая градация устоялась.
Слишком расплывчато. А по этой причине и происходят сеньоры с опытом от года.
P>>Точнее — вы тех, кто думает иначе, считаете астронавтами. Говорите честно, это всегда в почете. S>Опять не угадали.
Это предположение, в котором я сильно уверен. Обычно люди, которые лезут направо-налево оценивать других вобщем так и поступают. Собственно, вы в данном треде понадавали столько оценок меня и моего опыта, что навскидку и не сосчитаю.
P>>Это минорные знания, они подымаются с земли за ничтожное количество времени. S>Вообще-то речь не про подымаются, а про забывание:
А зачем нам учитывать эти минорные знания? Я вот в своих фремворках, которые пишу уже 4й или 5й год, не помню всех вещей, но при этом успешно консультирую команды разработчиков. На кой ляд держаться за фремворковые знания?
S>При переходе с MFC на Qt вам не нужен будет огромный пласт знаний, связанных с MFC API и тонкостями его использования. Этот пласт сеньору нужно будет забыть (а по ходу дела он ему может мешать).
Я вам про опыт, а вы мне про знания Ну жизнь такая, что бОльшая часть знаний устаревает мгновенно. Зачем держаться за то, что протухает прямо в руках?
Это всех технологий касается. Вот доменные знания, фундаментальные — такие стоит качать.
P>>Последние лет 10 у меня задачи, как бы сказать, совсем не UI. И желания погружаться в UI нет. S>А если вдруг, то вы же не сразу начнете выдавать код на Qt уровня сеньора. О том и речь.
Начнем с того, что на вашу вакансию Qt я и подаваться не буду. Когда писал на С и С++ — Qt зашло само, без особых усилий.
Я менял стек технологий и платформы много раз. Ну трудно первое время, но это не такой ужос-ужос, который вы здесь демонстрируете.
S>вы вели себя как "если я не видел, значит никто не видел".
А можно точную цитату? Что именно вас сподвигло так думать?
P>>Собственно, вы постоянно даете оценки, то мне, то моему опыту, только признавать это не хотите. S>Если не ошибаюсь, уже неоднократно говорил, что оцениваю ваши слова и на основании этих оценок делаю выводы.
Вы оцениваете гораздо больше чем только слова. При чем регулярно, и в разговорах не только со мной. Это факты.
S>Видимо, вы не перестанете приплетать ассоциации сколько бы вам на это не указывали. Ок, будем знать.
Разумеется. Вот у вас вылезла еще одна ассоциация "если я не видел, значит никто не видел"
За одной мы уже выяснили, что именно стоит. Теперь и за этой посмотрим
Здравствуйте, Pauel, Вы писали:
S>>Какое отношение это имеет к тому, что в окружающией меня реальности опыт вполне себе имеет количественное выражение?
P>Вот видите
Ответа на вопрос не вижу. Очередное додумывание вижу.
P>Нанимать людей за годы опыта это вобщем тупик.
Я не говорил про найм. Я не давал оценок тому, насколько хорошо считать опыт в годах или еще в чем-то. Лишь указал, что такое имеет место быть.
И то, что вы не принимаете этот фактор в расчет, приводит вас к неверным выводам.
Хотя к оценке опыта в годах вы сами же и прибегаете.
P>Скажите, пожалуйста, какая ваша нынешняя позиция, разработчик, менеджер?
Все сразу.
P>Давно ходили по собесам на разработчика?
Летом прошлого года.
P>>>Так бывает. При этом почему то именно вы рассказываете, чего я смогу, а чего нет. S>>Где я говорил, что вы чего-то не сможете?
P>Вы там что, меняетесь за этим аккаунтом? Вот ваши слова P>
P> вы не сможете взять готового сотрудника с нужными знаниями, которого можно сразу бросить в бой.
А вы это и сами признаете, как выясняется в озвученных вами подробностях. У вас таки не получается, "нешмогли". Посадили человека за изучение фреймворка, мелкие фиксы там как следствие.
P>Разумеется. У нас то был вполне конкретный набор, я уже перечислял, сколько там было всего кастомного, хватит на десяток фремворков.
А вот не уверен в свете того, что вы не понимаете про заточенный под задачу фремворк.
P>>>Тогда нужно отталкиваться от людей с похожим бекграундом — домен, дизайн-архитектура, ресёрч, и если ну никак, то уже тогда скатываться до джунов-мидлов.
S>>Ну и с чем вы тогда спорите?
P>Ну так это с ваших слов джуны и мидлы появились в данном треде. Я то как раз говорю, что это вынуденный вариант, или же кейс с низкой сложностью.
А где-то говорилось, что это лучший вариант?
Где-то мной делалось сравнение этих вариантов?
Где-то мной озвучивалась стоимость хотя бы одно из них (краткосрочная, долгосрочная)?
Было сказано, что такой вариант имеет место быть. И все. И в нем требования к квалификации соискателей ниже.
Так с чем вы спорите?
P>То есть, риски найма увеличиваются настолько, что приходится применять специальные стратегии — выращивать своих. P>А вы рассказываете про какое то снижение рисков
Про какое снижение рисков я рассказываю? Давайте цитату, а то с вашим домысливанием веры вам уже нет.
P>Ровно как у всех сеньоров. Мы даже время на изучения ЯП не выделяли. Щелкнул пальцами — "ты умеешь TypeScript" и всё.
Ётить, колотить, такие упоротые не в единственном числе!
P>По моему доменные знания первичны, фремворк — вторичен. А у вас вроде как наоборот выходит.
Так мы же про программистов говорим, не про архитекторов. Программисту знание фреймворка жизненно необходимо.
S>>Из конкретного опыта -- внутренний фреймворк для проведения платежных транзакций. Где-то глубоко под капотом там были базовые вещи из J2EE, но сверху это была заточенная под определенные требования и определенные предположения конструкция.
P>Ну и придет к вам человек, который писал на другой конторе такое же. Что вы ему скажете?
Сказали бы "Родной, как долго мы тебя ждали! Сколько денех хочешь?"
И это как бы не красное словцо, довелось собеседовать человека на роль тим-лида с хорошим бэкграундом в похожей области. Готовы были брать на любых условиях, но ему пришлось уехать в другой город, не сложилось
P>Иди гуляй, мы джуна возьмем и будем растить?
Вы все еще не поняли: речь идет о ситуациях, когда людей, которые в "домене", нет вообще. От слова совсем. Пусть даже под "доменом" понимается фреймворк, вроде Яндексового userver.
S>>Вроде бы уже лет 15 как такая градация устоялась.
P>Слишком расплывчато.
Опять сошлюсь на свой опыт и скажу, что только такая градация и уместна, только она и работает.
P>А по этой причине и происходят сеньоры с опытом от года.
Нет. Способность самостоятельно решать задачи с общей формулировкой за год не приобретают.
В моем мире, по крайней мере.
И да, что за оно: "с опытом от года"? Кто здесь начал опыт мерять количественно?
P>А зачем нам учитывать эти минорные знания? Я вот в своих фремворках, которые пишу уже 4й или 5й год, не помню всех вещей, но при этом успешно консультирую команды разработчиков. На кой ляд держаться за фремворковые знания?
Чтобы младшим товарищам помогать и не лезь за каждой мелочью на stackoverflow.
P>Начнем с того, что на вашу вакансию Qt я и подаваться не буду.
Это отношения к делу не имеет.
S>>вы вели себя как "если я не видел, значит никто не видел".
P>А можно точную цитату? Что именно вас сподвигло так думать?
Здравствуйте, Pauel, Вы писали:
P>QT превратился в маленький аналог .Net platform, или JDK. Пудозреваю, это имелось ввиду.
По удобству разработки — да, при этом на Qt можно отключить все не нужное и сделать маленькое приложение. Быстродействие от размера не зависит.
ЕМ>>>Из-за этого он органично смотрится только в достаточно тяжелом софте, а легкий — сильно утяжеляет сам. S>>Покожи "легкий" софт который работает на 3-4 платформах и рисует хоть что-то интересное? P>Жээс Легкость смотря в чем.
И в чем там легкость?
Здравствуйте, Skorodum, Вы писали:
ЕМ>>>>Из-за этого он органично смотрится только в достаточно тяжелом софте, а легкий — сильно утяжеляет сам. S>>>Покожи "легкий" софт который работает на 3-4 платформах и рисует хоть что-то интересное? P>>Жээс Легкость смотря в чем. S>И в чем там легкость?
Здравствуйте, so5team, Вы писали:
S>>>Какое отношение это имеет к тому, что в окружающией меня реальности опыт вполне себе имеет количественное выражение?
P>>Вот видите
S>Ответа на вопрос не вижу. Очередное додумывание вижу.
На самом деле мы просто выяснили, откуда растут ваши ассоциации про длину.
S>Я не говорил про найм. Я не давал оценок тому, насколько хорошо считать опыт в годах или еще в чем-то. Лишь указал, что такое имеет место быть. S> И то, что вы не принимаете этот фактор в расчет, приводит вас к неверным выводам.
Основной вывод который я сделал, это про происхожденией вашей ассоциации длина-опыт.
S>Хотя к оценке опыта в годах вы сами же и прибегаете.
Вы углядели в моих словах хвастовство — очередная ваша ассоциация. На самом я описывал факт из своей трудовой биографии, что бы было понятно, что пишу про свои наблюдения, а не пересказываю очередную статью "как сделать всех счястливыми".
P>>Скажите, пожалуйста, какая ваша нынешняя позиция, разработчик, менеджер? S>Все сразу.
Как долго вы работаете у нынешнего работодателя? Лет 20 наверное?
P>>Вы там что, меняетесь за этим аккаунтом? Вот ваши слова P>>
P>> вы не сможете взять готового сотрудника с нужными знаниями, которого можно сразу бросить в бой.
S>А вы это и сами признаете, как выясняется в озвученных вами подробностях. У вас таки не получается, "нешмогли". Посадили человека за изучение фреймворка, мелкие фиксы там как следствие.
Вы сейчас переиначиваете сказаное мной. Приложение порядка на два больше чем фремворк. Фремворком на этом фоне можно спокойно пренебречь. Как я сказал, такие знания берутся с земли за короткий срок.
Собственно, чуть ниже вы сами утверждаете, что фремворк не важен.
P>>Разумеется. У нас то был вполне конкретный набор, я уже перечислял, сколько там было всего кастомного, хватит на десяток фремворков. S>А вот не уверен в свете того, что вы не понимаете про заточенный под задачу фремворк.
Мы выяснили, что под задачей вы подразумеваете не задачу,а домен. Подбирайте слова тщательнее, а то у меня нет уверенности, что я вас понимаю.
Любой фремворк заточен под семейство задач, по определению. А то что вы подразумеваете, это доменный фремворк, привязаный к конкретной предметной области. Т.е. не общего назначения, а специализированый.
S>Так с чем вы спорите?
Я пока что выясняю, что имеет стоит за вашими ассоциациями. Мы же не вживую беседуем.
P>>То есть, риски найма увеличиваются настолько, что приходится применять специальные стратегии — выращивать своих. P>>А вы рассказываете про какое то снижение рисков
S>Про какое снижение рисков я рассказываю? Давайте цитату, а то с вашим домысливанием веры вам уже нет.
Мое утверждение — чем больше самописного кода, тем больше риски найма, задирает планку требуемой квалификации
Вы вбрасываете альтернативу вида "а бывает так, что чем больше самописного кода, тем ниже риски найма"
Вы сами то понимаете что написали?
P>>Ровно как у всех сеньоров. Мы даже время на изучения ЯП не выделяли. Щелкнул пальцами — "ты умеешь TypeScript" и всё. S>Ётить, колотить, такие упоротые не в единственном числе!
Здесь вы снова даёте оценку мне Чего это вас тянет оценки давать?
Я вам больше скажу — студентов ФПМ я точно так же учил, щелкнул пальцами "вы знаете JavaScript", и дальше на лекции-практике решаем конкретные задачи не останавливаясь ни на синтаксисе, ни на каких то минорных вещах.
S>Так мы же про программистов говорим, не про архитекторов. Программисту знание фреймворка жизненно необходимо.
Я с этим не согласен. Мы с вами вроде в одной стране живем, если вы не уехали. Сколько ни ходил по собеседованиям, вот в прошлом году было ажно 15шт, ни разу про фремворк глубоко не спрашивали.
Алгоритмы, дизайн, платформа, gc, сеть, протоколы, архитектура, домен. Фремворк — или ничего, или один-два вопроса.
P>>Ну и придет к вам человек, который писал на другой конторе такое же. Что вы ему скажете? S>Сказали бы "Родной, как долго мы тебя ждали! Сколько денех хочешь?"
Поздравляю, вы сейчас сказали, что фремворк не важен на старте.
На этом можно и завершать беседу.
S>Вы все еще не поняли: речь идет о ситуациях, когда людей, которые в "домене", нет вообще. От слова совсем. Пусть даже под "доменом" понимается фреймворк, вроде Яндексового userver.
Ну нету, и что? Придет другой человек который умеет асинхронщину кроме userver, и всё будет путём.
Здесь главное не фремворк, а фундальные знания — та самая асинхронщина.
S>Опять сошлюсь на свой опыт и скажу, что только такая градация и уместна, только она и работает.
Уместна, конечно. Только в данный момент глядя на рынок труда совсем не очевидно, что она работает. Если полно "сеньор от года", этого говорит о том, что слишком много контор такой градацией не пользуются.
А раз так, то можно говорить только о том, что такая градация работает в конкретных конторая, которые позаботились о внутренней структуре и проработали все уровни.
И даже там это работает не просто так, а за счет того, что ассессмент ведут интервьюеры с большим опытом, которые вобщем пользуются своим внутренним видением.
P>>А по этой причине и происходят сеньоры с опытом от года. S>Нет. Способность самостоятельно решать задачи с общей формулировкой за год не приобретают.
В том то и дело. Скилов еще нет, а погоны уже выдадены. Что говорит о том, что ваша устоявшаяся градация устоялась только в некоторых конторах.
S>И да, что за оно: "с опытом от года"? Кто здесь начал опыт мерять количественно?
В данном случае это скорее стаж. Количественная характеристика, вполне объективная — можно с точностью до дня посчитать по трудовой книжке.
На опыт это конечно же никак не ложится.
P>>Начнем с того, что на вашу вакансию Qt я и подаваться не буду. S>Это отношения к делу не имеет.
Я могу сказать только за свой опыт — когда писал на C/C++/MFC/Atl/Wtl/COM/, QT зашел сам собой.
Как это будет сейчас — трудно даже представить, я с С++ закончил ажно в 2007м году.
P>>А можно точную цитату? Что именно вас сподвигло так думать?
S>Да вот здесь целое сообщение ваше: http://rsdn.org/forum/flame.comp/8444837.1
S>Особенно последний абзац. Вы исходите только из того, что видели. И ведете себя так, как будто другого не бывает. Это и сподвигло.
Вы пишете "Благие пожелания...". А я вам говорю, что у меня не только пожелания, но и успешный опыт их реализации.
То есть, именно вы утверждаете, что чего то нет и быть не может, а я вам говорю — что может, и даже работает.
S>Или вот здесь: http://rsdn.org/forum/flame.comp/8444876.1
S>В том разделе где вы перечисляете варианты с сеньорами, которые...
Вы пишете, общий смысл ваших слов — сеньоров нет, и быть не может, вы их найти не сможете.
А я вам накидываю варианты, откуда могут взяться сеньоры, которых, именно по вашей версии, гарантировано нет.
То есть, именно вы говорите, что сеньоров нет и быть не может, а вот по моему — они таки есть.
Более того — в моей версии находится место и мидлам и джунам.
То есть, вы в очередной раз приписали мне ваш собственный взгляд. Это уже не ассоциация, а проекция.
P>>Вы оцениваете гораздо больше чем только слова. S>А вот это очередное домысливание.
Здравствуйте, Skorodum, Вы писали:
S>В целом хороший GUI который работает везде это по прежнему сложно, но теперь это возможно с более-менее единой кодовой базой.
Qt вроде как с начала времён. Но вот шота UI пошел по другому пути, QT снова на обочине.
На счет более-менее единой кодовой базой, в жээс это есть почти что искаропки.
Я вот как то не вижу, что гуи на системном ЯП имеет какое то светлое будущее. Нет столько разработчиков на таком языке, чтобы еще и гуи писать.
Да вобщем глядя на самый распрекрасный лялих, можно разишо ужаснуться. Я сейчас прихожу в ужас до трёх раз на день или даже чаще. Хорошо, что я крепок, а то бы давно сбежал обратно на Винду
Глянул вот софтину одну, GitKraken, ищу замену Git Extension. И вот порадовался за QT, годный продукт сю-сю, ля-ля. А потом вижу, что GitKraken судя по логам на жэсточайшем жээсе сделан
Фремворк это не про знание API. Это подход к проектированию. И самое ценное, что можно взять у сеньора, это его навыки проектирования. И эти навыки между MFC и QT схожие.
Легкость смотря в чем.
Чего это вас тянет оценки давать?
