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

CAF>Ага, конечно.

Можно пример не профессионала которого перевезли из России в штаты ?

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

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

O>>Для продуктивной работы надо хорошо отдыхать, хорошо ли вы отдыхаете на работе ?
K>Меня этим поразили парни высокой квалификации в штатах. Приходят в офис в 7-8, садятся за комп и фигачат до 4-5 вечера с перерывом на ланч. Никаких отдыхов, никаких кофе, всё в работу.


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

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

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

CAF>>Ага, конечно.

O>Можно пример не профессионала которого перевезли из России в штаты ?

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

Хуже всего, когда и там ничего путного не найти, во тогда все — звиздец. Сиди и сам выдумавай

CAF>Ну я например по такми меркам Что не задача — так сижу и разбираюсь как делать. Ну не знаю как делать или знаю, но хочу сравнить с другими подходами. И приходится статьи, книги и интернет шерстить.

CAF>Хуже всего, когда и там ничего путного не найти, во тогда все — звиздец. Сиди и сам выдумавай

А можно пример такой задачи что 1. "не знаю как делать" 2. "ничего путного не найти"

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

CAF>>Ну я например по такми меркам Что не задача — так сижу и разбираюсь как делать. Ну не знаю как делать или знаю, но хочу сравнить с другими подходами. И приходится статьи, книги и интернет шерстить.

CAF>>Хуже всего, когда и там ничего путного не найти, во тогда все — звиздец. Сиди и сам выдумавай

O>А можно пример такой задачи что 1. "не знаю как делать" 2. "ничего путного не найти"

Да пожалуйста. Как хорошо оттестировать сложное многопоточное нативную библиотеку? И главное как это померять.

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

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

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

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

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

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

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

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

O>Здравствуйте, 0xCAFEDEAD, Вы писали:

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

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

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

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

O>Но когда тебе делали оффер наверное подразумевалось что ты другую задачу будешь решать и врятли ты по той задаче/области не был специалистом.

Мы, навреное, в несколько разных мирах крутимся. Когда меня нанимали, проверили что я умел программировать в общем. Ну типа могу список развернуть или удалить из него элемент вроде. Ну и еще пару подобных задач спросили, ну и поговорили немного о программировании в целом. Язык и технологии их мало волновали. Предполагается, что все остальное выучишь по дороге в необходимом объеме. Включая языки, библиотеки и технологии.

А у тебя как?

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

CAF>Конечно не предупредил, я вообще думаю, что это никто не умеет хорошо делать А задачи у меня разные, и специалиста на каждую нанимать?

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

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

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

O>>Но когда тебе делали оффер наверное подразумевалось что ты другую задачу будешь решать и врятли ты по той задаче/области не был специалистом.

CAF>Мы, навреное, в несколько разных мирах крутимся. Когда меня нанимали, проверили что я умел программировать в общем. Ну типа могу список развернуть или удалить из него элемент вроде. Ну и еще пару подобных задач спросили, ну и поговорили немного о программировании в целом. Язык и технологии их мало волновали. Предполагается, что все остальное выучишь по дороге в необходимом объеме. Включая языки, библиотеки и технологии.

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

Возможно ты что-то важное не упомянул.


CAF>А у тебя как?

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

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


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

CAF>>Конечно не предупредил, я вообще думаю, что это никто не умеет хорошо делать А задачи у меня разные, и специалиста на каждую нанимать?

O>Конечно, вот если завтра компьютер сломается, чего им админа чтоли нанимать который в железе разбирается, как говорят "тыж программист"

O>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.

Примеры в студию?

O>Но не важно наши субъективные представления — есть специалисты такие или нет — плохо то что не предупредил, т.к. тем самым ты не даешь руководству полной информации о ситуации. Они не знают знаешь ты или нет, дав им информацию они как раз смогут оценить стоит ли поискать и нанять "админа" как в ситуации выше, т.е. человека который хорошо разбирается в этой области и решить задачу качественно и быстро, либо потратить деньги на то чтобы обучить тебя и первый блин скорее всего будет комом, тут не в твой личный огород — я о ситуации в среднем.
Да прекрасно это мое руководство все это знает. Но в первую очередь нужен человек разбирающийся в нашем продукте. Я вот собираюсь сделать некоторую визуализацию и анализ перформанс характеристик, вот изучаю походы и тулы. Опять нового человека нанимать? А как быстро он поймет задачу в целом? И что с ним делать когда она будет решена?

O>>>Но когда тебе делали оффер наверное подразумевалось что ты другую задачу будешь решать и врятли ты по той задаче/области не был специалистом.

CAF>>Мы, навреное, в несколько разных мирах крутимся. Когда меня нанимали, проверили что я умел программировать в общем. Ну типа могу список развернуть или удалить из него элемент вроде. Ну и еще пару подобных задач спросили, ну и поговорили немного о программировании в целом. Язык и технологии их мало волновали. Предполагается, что все остальное выучишь по дороге в необходимом объеме. Включая языки, библиотеки и технологии.

O>Наверное да в разных мирах, если все как ты говоришь таких претендентов со знанием как развернуть список и удалить элемент — каждый второй выпускник знает. И этим заморского работодателя не удивишь , таких много и на местном рынке. Ради этого он не станет тратить время и ресурсы, брать риски чтобы перевозить, делать визы.

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


CAF>>А у тебя как?

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

А что за навыка и проекты в общих чертах? Просто интересна степень совпадения и области.

O>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.

CAF>Примеры в студию?
Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

O>>Но не важно наши субъективные представления — есть специалисты такие или нет — плохо то что не предупредил, т.к. тем самым ты CAF>Да прекрасно это мое руководство все это знает. Но в первую очередь нужен человек разбирающийся в нашем продукте. Я вот собираюсь сделать некоторую визуализацию и анализ перформанс характеристик, вот изучаю походы и тулы. Опять нового человека нанимать? А как быстро он поймет задачу в целом? И что с ним делать когда она будет решена?

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


O>>Возможно ты что-то важное не упомянул.
CAF>Ну я нанимался к забугорному работодателю, но без переезда. Потащили они меня из-за своих личных тараканов. Да, каких-то особенных способностей у меня не нет. Вполне обычный, типичный инженер.

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


CAF>А что за навыка и проекты в общих чертах? Просто интересна степень совпадения и области.


В основном компьютерная графика от математики до визуализации.

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

O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.

CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

Хмм, если бы было все так просто. Обычно там самым верным является первое предложение типа
Testing multithreaded code is a tough challenge.
Testing multithreaded code is difficult to do.
Multithreaded code is hard to write and even harder to test.

Простая на вид задача не имеет хорошего решения.

O>>>Но не важно наши субъективные представления — есть специалисты такие или нет — плохо то что не предупредил, т.к. тем самым ты CAF>Да прекрасно это мое руководство все это знает. Но в первую очередь нужен человек разбирающийся в нашем продукте. Я вот собираюсь сделать некоторую визуализацию и анализ перформанс характеристик, вот изучаю походы и тулы. Опять нового человека нанимать? А как быстро он поймет задачу в целом? И что с ним делать когда она будет решена?

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

O>>>Возможно ты что-то важное не упомянул.
CAF>>Ну я нанимался к забугорному работодателю, но без переезда. Потащили они меня из-за своих личных тараканов. Да, каких-то особенных способностей у меня не нет. Вполне обычный, типичный инженер.

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

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

CAF>>А что за навыка и проекты в общих чертах? Просто интересна степень совпадения и области.


O>В основном компьютерная графика от математики до визуализации.

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

CAF>>>Примеры в студию?
O>>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

CAF>Хмм, если бы было все так просто. Обычно там самым верным является первое предложение типа
CAF>Testing multithreaded code is a tough challenge.
CAF>Testing multithreaded code is difficult to do.
CAF>Multithreaded code is hard to write and even harder to test.

CAF>Простая на вид задача не имеет хорошего решения.

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


O>>Знает или нет — это предположение, если оно об этом само не сказало или ты сам явно не сказал.
CAF>Давай будем считать, что мой менеджер отлично знает круг моих способностей/навыков.
Не может он знать этого иначе бы он был разработчиком, он не знает что в твоей голове, ты не знаешь что в его.
Надеятся что по глазам он все прочитает — не всегда, лучше все лишний раз уточнять.
CAF>А нанимать консультантов для каждого такого случая замучаешься. Особенно учитывая, что им еще в нашу специфику как-то надо будет влезть. Вот у мне сейчас надо будет дописать кое-какую вещь на питоне.
CAF>Ну не нанимать же питониста для этого. Ну и в том же духе.
Вот пусть это и решает менеджмент, задача разработчика предупредить что — не знаю как решать, но могу разбираться.
Задача менеджмента оценить риски связанные со временем и качеством решения и на основании этого уже решать стоит нанимать контрктника/штатника или нет.

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

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

CAF>>>>Примеры в студию?
O>>>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

CAF>>Хмм, если бы было все так просто. Обычно там самым верным является первое предложение типа
CAF>>Testing multithreaded code is a tough challenge.
CAF>>Testing multithreaded code is difficult to do.
CAF>>Multithreaded code is hard to write and even harder to test.

CAF>>Простая на вид задача не имеет хорошего решения.

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

Можешь хоть один приличный пример привести, или это твои домыслы?

O>>>Знает или нет — это предположение, если оно об этом само не сказало или ты сам явно не сказал.
CAF>>Давай будем считать, что мой менеджер отлично знает круг моих способностей/навыков.
O>Не может он знать этого иначе бы он был разработчиком, он не знает что в твоей голове, ты не знаешь что в его.
O>Надеятся что по глазам он все прочитает — не всегда, лучше все лишний раз уточнять.
CAF>>А нанимать консультантов для каждого такого случая замучаешься. Особенно учитывая, что им еще в нашу специфику как-то надо будет влезть. Вот у мне сейчас надо будет дописать кое-какую вещь на питоне.
CAF>>Ну не нанимать же питониста для этого. Ну и в том же духе.
O>Вот пусть это и решает менеджмент, задача разработчика предупредить что — не знаю как решать, но могу разбираться.
O>Задача менеджмента оценить риски связанные со временем и качеством решения и на основании этого уже решать стоит нанимать контрктника/штатника или нет.

CAF>>Больших познаний не требуется но книжки почитать иногда приходится.
CAF>>Возможно где-то и по-другому, но у нас именно так.
O>Это в большинстве случаев так к сожалению, разработчики стесняются говорить "незнаю" , менеджеры тоже со своей стороны ленятся это учитывать риски, т.к. им меньше думать = пихать все задачи на одного человека, не особо мотивируют подобную открытость.
O>Эта порочная практика в итоге приводит к нехорошим последствиям, к перегоранию людей и к снижению качества продукта в целом.

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

CAF>Можешь хоть один приличный пример привести, или это твои домыслы?
https://jodah.net/testing-multi-threaded-code

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


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

К сожалению нам дается усдовно 40 лет для работы( с 20 до пенсии ) за которые я уже не смогу собрать много личной статистики.
Но я делаю выводы не из столько из своего опыта, а то что рассказывают окружающие, вот ты рассказал свою историю, она совпадает с большинством историй которые я слышал и также большая часть из них привела к тому что люди несчастливы, сгоревшие, не особо любят работу, ходят потому что платят нормально. Может в твоем случае все не так, но это исключение.

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

CAF>>Можешь хоть один приличный пример привести, или это твои домыслы?
O>https://jodah.net/testing-multi-threaded-code

O>Начни например с этой статьи , там общие выводы, попробуй спросить у автора что он порекомендует в твоем случае.
O>Не любишь такую работу искать людей, коммуникации о чем и говорю делегируй это к менеджеру.

Ну вот ты мне что-то типа "Hello World" посоветовал, начать так сказать


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

O>К сожалению нам дается усдовно 40 лет для работы( с 20 до пенсии ) за которые я уже не смогу собрать много личной статистики.
O>Но я делаю выводы не из столько из своего опыта, а то что рассказывают окружающие, вот ты рассказал свою историю, она совпадает с большинством историй которые я слышал и также большая часть из них привела к тому что люди несчастливы, сгоревшие, не особо любят работу, ходят потому что платят нормально. Может в твоем случае все не так, но это исключение.

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

Внеси, что меня все устраивает. И очень нравится иногда отвлечься от основного курса и в посвятить рабочее время изучению новых разных технологий. Расширить кругозор, так сказать, развеяться. Я бы и так читал, но по выходным ми ночами. А так время есть. Эффективность компании меня волнует мало, да и не влияю я на нее. Для этого есть менеджер, директор, VP, Senior VP, CTO, Board of Directors, а я как-то ну совсем не карьерист.
Если кто-то считает, что не стоит распыляться, а надо полностью посвятить себя одной теме. Но как по мне — то где 80/20 или 70/30 основной курс и остальное. А если кто-то считает, что надо кровь из носу, хоть убейся ради большей зп — ну тоже его дело.

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

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

CAF>>>Можешь хоть один приличный пример привести, или это твои домыслы?
O>>https://jodah.net/testing-multi-threaded-code

O>>Начни например с этой статьи , там общие выводы, попробуй спросить у автора что он порекомендует в твоем случае.
O>>Не любишь такую работу искать людей, коммуникации о чем и говорю делегируй это к менеджеру.

CAF>Ну вот ты мне что-то типа "Hello World" посоветовал, начать так сказать

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

CAF>Внеси, что меня все устраивает. И очень нравится иногда отвлечься от основного курса и в посвятить рабочее время изучению новых разных технологий. Расширить кругозор, так сказать, развеяться. Я бы и так читал, но по выходным ми ночами. А так время есть. Эффективность компании меня волнует мало, да и не влияю я на нее.

Вот это и плохо, не про тебя конкретно а в целом, такое отношение достаточно часто.

CAF>Для этого есть менеджер, директор, VP, Senior VP, CTO, Board of Directors, а я как-то ну совсем не карьерист.

CAF>Если кто-то считает, что не стоит распыляться, а надо полностью посвятить себя одной теме. Но как по мне — то где 80/20 или 70/30 основной курс и остальное. А если кто-то считает, что надо кровь из носу, хоть убейся ради большей зп — ну тоже его дело.

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

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

O>Здравствуйте, 0xCAFEDEAD, Вы писали:

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

CAF>>>>Можешь хоть один приличный пример привести, или это твои домыслы?
O>>>https://jodah.net/testing-multi-threaded-code

O>>>Начни например с этой статьи , там общие выводы, попробуй спросить у автора что он порекомендует в твоем случае.
O>>>Не любишь такую работу искать людей, коммуникации о чем и говорю делегируй это к менеджеру.

CAF>>Ну вот ты мне что-то типа "Hello World" посоветовал, начать так сказать

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

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

А у тебя не бывало задач, которые еще не решены сотни раз?

CAF>>Внеси, что меня все устраивает. И очень нравится иногда отвлечься от основного курса и в посвятить рабочее время изучению новых разных технологий. Расширить кругозор, так сказать, развеяться. Я бы и так читал, но по выходным ми ночами. А так время есть. Эффективность компании меня волнует мало, да и не влияю я на нее.

O>Вот это и плохо, не про тебя конкретно а в целом, такое отношение достаточно часто.

CAF>>Для этого есть менеджер, директор, VP, Senior VP, CTO, Board of Directors, а я как-то ну совсем не карьерист.

CAF>>Если кто-то считает, что не стоит распыляться, а надо полностью посвятить себя одной теме. Но как по мне — то где 80/20 или 70/30 основной курс и остальное. А если кто-то считает, что надо кровь из носу, хоть убейся ради большей зп — ну тоже его дело.

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

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

Ты уж лучше напиши, как ты работаешь. Видимо это контр-пример будет.

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

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

Но ты не написал чем плохи существующие решения, критерий хорошести.

CAF>Я кстати, могу и еще примеры привести из моей прошлой жизни.

Было бы интересно.

CAF>А у тебя не бывало задач, которые еще не решены сотни раз?

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


CAF>Я работаю достаточно прозрачно, добавляю задачи в трекере, планы предоставляю, стараюсь не от них не отклоняться или всех информировать. Что еще? Если руководство что-то еще захочет — оно попросит, для того оно и нужно.

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

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

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

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

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

O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.

CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

Очевидно, что это совсем нетривиальная область.
Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.

Варианта, собственно, два:
— Или обвешиваем всё мьютексами и прощаемся с производительностью
— Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.

А иногда бывает что нету ни того, ни другого
Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).

А вот пример особо эпичной гонки. Конец 2016 года, около 10 лет багу, много лет эксплуатировался хакерами In-the-wild (собственно был пойман после атаки, благодаря логгированию всего сетевого трафика)
Окно — буквально две соседние инструкции. Но мощь при этом невероятная — получаем доступ на запись во все места, к которым имеем доступ на чтение. Причём в буханках /proc/mem это тоже файл, а значит мы можем локально изменить libc, и изменения моментально окажутся ВО ВСЕХ работающих процессах. Включая работающие под root. Баг не требует адаптации под конкретную версию-архитектуру-смещения в коде, работал абсолютно на всех буханках, даже из скриптовых языков — у современных компьютеров достаточно мощности.
Дополнительную пикантность багу придаёт то, что его внёс лично глав-петух Торвальдс. Не осилив починить другой баг.

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

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

O>>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.

CAF>>>Примеры в студию?
O>>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.

IID>Очевидно, что это совсем нетривиальная область.

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


IID>Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
IID>Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.


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

IID>Варианта, собственно, два:
IID>- Или обвешиваем всё мьютексами и прощаемся с производительностью
IID>- Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.

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

IID>А иногда бывает что нету ни того, ни другого
IID>Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).