55+ в ИТ

[Flash-04]

Он похоже сейчас на годичном минимуме.

[rorp]

Happy Genesis Day!

[АццкоМото]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

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

Как такое проверить на интервью? Я пока не знаю.

Я опоздал на вечеринку, но сам способ/алгоритм вполне нормален.
return false; опустить чуть ниже, но я так понимаю, что это просто опечатка.
Проверки на null и прочее опускаем.
Просто интересно, что не устраивает?

Ну кагбэ есть структуры данных, специально заточенные под подобные задачи. HashMap/HashSet, например. Делать линейный перебор - давно уже моветон. В 20018 (тогда еще) году должно быть что-то вокруг или set,contains(item) или map.get(id)!=null ну или еще что-то. а так - долбаный стыд

[Сказочник]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

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

Как такое проверить на интервью? Я пока не знаю.

Я опоздал на вечеринку, но сам способ/алгоритм вполне нормален.
return false; опустить чуть ниже, но я так понимаю, что это просто опечатка.
Проверки на null и прочее опускаем.
Просто интересно, что не устраивает?

Ну кагбэ есть структуры данных, специально заточенные под подобные задачи. HashMap/HashSet, например. Делать линейный перебор - давно уже моветон. В 20018 (тогда еще) году должно быть что-то вокруг или set,contains(item) или map.get(id)!=null ну или еще что-то. а так - долбаный стыд

Сколько айтемов могут быть в корзине? Не сотни же тысяч? Ну переберёт 2-3 элемента линейкой - на производительности не скажется. А вот тащить тяжелую артиллерию туда, где бъют по мухам - это плохо

[Вячеслав Викторович]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

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

Как такое проверить на интервью? Я пока не знаю.

Я опоздал на вечеринку, но сам способ/алгоритм вполне нормален.
return false; опустить чуть ниже, но я так понимаю, что это просто опечатка.
Проверки на null и прочее опускаем.
Просто интересно, что не устраивает?

Ну кагбэ есть структуры данных, специально заточенные под подобные задачи. HashMap/HashSet, например. Делать линейный перебор - давно уже моветон. В 20018 (тогда еще) году должно быть что-то вокруг или set,contains(item) или map.get(id)!=null ну или еще что-то. а так - долбаный стыд

Сколько айтемов могут быть в корзине? Не сотни же тысяч? Ну переберёт 2-3 элемента линейкой - на производительности не скажется. А вот тащить тяжелую артиллерию туда, где бъют по мухам - это плохо

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

[АццкоМото]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

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

Как такое проверить на интервью? Я пока не знаю.

Я опоздал на вечеринку, но сам способ/алгоритм вполне нормален.
return false; опустить чуть ниже, но я так понимаю, что это просто опечатка.
Проверки на null и прочее опускаем.
Просто интересно, что не устраивает?

Ну кагбэ есть структуры данных, специально заточенные под подобные задачи. HashMap/HashSet, например. Делать линейный перебор - давно уже моветон. В 20018 (тогда еще) году должно быть что-то вокруг или set,contains(item) или map.get(id)!=null ну или еще что-то. а так - долбаный стыд

Сколько айтемов могут быть в корзине? Не сотни же тысяч? Ну переберёт 2-3 элемента линейкой - на производительности не скажется. А вот тащить тяжелую артиллерию туда, где бъют по мухам - это плохо

ну это как когда кошка пьет из унитаза. ничего противозаконного, но все равно противно.

[Kirpidonych]

Насколько сложно найти работу в ИТ (или сохранить имеющуюся) в США людям старшего возраста? В России айтишников списывают чуть ли не в 40 лет.

DevOps

[ptun]

DevOps? Спорно. Чаще всего это работа очень сильно приближенная именно к разработке, а средний возраст разработчика в США - 29 лет. Седой старпёр - not a cultural fit.

https://insights.stackoverflow.com/surv ... mographics

[Kirpidonych]

в девопсе можно занять спокойную нишу и коптить

[zVlad]

Наверно и мне надо че нибудь написать в теме про тех кого я уже почти на 10 лет старше, и в ИТ.
Писать код, кмк, нужно заканчивать после 40 (с потолка взято) лет. Ну т.е. должен быть некий предел возраста после которого писать код уже неприлично становится.
Конечно, для иммигрантов (вроде нас) это не так уж и неприлично учитывая отсутствие связей и т.п.. И все же.
Нормальным должен быть рост пусть не в начальники, но в те кто учит, контролирует, подправляет борзописцев, т.е. направляет мОлодеж и наставляет.
На худой конец можно зависнуть в администраторах разных там баз данных, систем, сетей. Т.е. сидеть тихонько и ждать когда понадобишься. Я вот в этих последних окопался и доволен вполне. С одной стороны нет давления делать в срок кем то высосаный из пальца, с другой можно придумать какой-нибудь апгрейд, ну или блеснуть знаниями, если они конечно есть, когда какой-нибудь молодой прог попал в сети системы или базы данных, или манагер довел дело до ручки.
Писать программы дело скучное и монотонное. Программирование уже давным давно не наука, а ремесло. Все интересное давно пройдено. Последним было объектно-ориентированное програмирование и это было едва ли не 30 лет назад.

[Sergunka]

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

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

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

[zVlad]

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

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

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

Может быть. Я практически не писал код по чьим то заданиям. Только для себя, по своим заданиям.
Сейчас читаю ветку про прохождение интервью. Смешно. Детский сад, ну или лотерея.
Тем не менее согласился бы поучаствовать в серьезном проекте и даже с кодированием, но только по собственному дизайну.
Недавно на меня вывались написанные Data Glance (наверное вот эти: https://www.dataglance.com) решения для нашего клиента. Пришел в ужас, говорил прожэкт манагеру нашему что это дилетантизм махровый. За это в детском саду в угол ставили. Конечно все осталось как есть. Реально дубовые решения и подходы от распальцованной фирмы. Я бы намного лучше сделал даже при том что не писал прог уже давно. Да дело то и не в прогах вовсе, а в дремучем понимании современных компьютеров. Все по шаблону распределенной обработки сделано без понимания что и где надо бы на самом деле делать.
Например, чтобы связать два места обработки данных в одном поставили триггер и пишут им в таблицу. В другом месте поставили зацикленный удаленный скан той таблицы на предмет не случилось ли что. Это более-менее ладно, но обработанные события (строки) в таблице связи не удаляются, она растет, производительность падает и т.д. и т.п.. Девелопер из DataGlance предлагает уникальный индекс на таблицу, я тут же, в conf-call пишу group by ... having count(*) > 1 и докладываю что это не уникально.
Вообщем гнать бы поганой метлой этот Data Glance, но они уже больше трех лет доят нашего клиента. В продакшн на моем мэйнфрэйм уже умудрились имплиментировать такое что охереть можно. Показываешь, отвечают но ведь работает. Руки бы поотрывал. А ведь поди интервью проходили по всем наукам и традициям.

P.S. Посмотрел на их (Data Glance) клиентуру. Точно, наш в их списке. Уроды.

[zVlad]

Еще про DataGlance чтобы посмеяться. Создали они webservices с доступом в DB2 на мэйнфрэйм. Этот (или эти) webservices инициируют threads pool. Это понятно и не возбраняется - пусть будут на готове. Более того наш DB2 специально сконфигурирован чтобы неактивные threads не выпинывались, а жили. Но это возможно только если в thread нет замков. А у них есть, они (Data Glance) наверное думают что база данных это Оракл. DB2 выпинывает неактивные threads с замками. Всего то делов после инициирования thread выдать commit. Но добиться этого от DataGlance не удается. В итоге каждые 3 минуты - параметр DB2 - threads ихние гасятся, обнаруживается что они погашены и запускаются снова. Онанизм какой-то а не програмирование.
Вот такие эксперты из Кали нас, канадцев, веселят. А репутация у них высокая судя по отношению к ним неспециалистов наших. Как они ее добились, одному богу ведомо, да и то не нашему.

[vdfs]

Я бы намного лучше сделал даже при том что не писал прог уже давно.

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

[nyekimov]

Я бы намного лучше сделал даже при том что не писал прог уже давно.

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

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