Обновить
61

Architect | Lead | Senior Developer

0,7
Рейтинг
13
Подписчики
Отправить сообщение

Таки правило «умножить первичную оценку на пи и на e» нашло подтверждение в графиках и собранной статистике 😅?

Так, в кратце-то - что вы сделали? Переложили написание части тестов на программистов?

Как решили вопрос с программистами, кто был против тестирования? Уволили/уволились?

Так, там ниже уже ответили, но я уже собрал пример

https://livesql.oracle.com/next

Если ключевые поля, по которому идет джоин, содержат дубликаты значений - то будет перемножение. Я на практике пару раз попал на это за все время работы программистом, когда джоин был не по PK/FK

Давайте комментом, что помните 🙂

😅 а, ну и ирония в том, автор статьи выступает на конференциях и как раз является тем сениором «которого все знают»

Жаль не могу найти - однажды давно попалось видео типа реального собеса на ютубе в тинькоф. Там был какой-то тип (со стороны тинькова), стриженный под машинку, который матерился в эфире. Оставило неизгладимое впечатление.

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

В смысле на джуна? Можно пояснительную бригаду в студию?

Когда говорят о нехватке - это имеется ввиду нехватка дешевых работников. Если волшебным образом появится миллион толковых программистов и других айтишников - зп станут как у учителей. Чего собственно и добивается бизнес и государство.

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

Короче ясно понятно - жефорс 6090 будет стоить не 5к, а 10к $

С наступлением эпохи рынка работодателя такое станет еще популярнее. См ATS системы.

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

В некоторых случаях лучше ее обманывать - я встречал ошибки в вакансии. Например postgre или postgres вместо postgresql. Но в моем-то резюме правильно написано.

ЗП в резюме выше как минимум на 30%, чем в вакансии

А в самой вакансии точно зп указана? А то судя по статистике таких вакансий меньшинство.

Объёмный опыт, малый возраст

И интересно стало - а какой кандидат идеальный то? Что там надо писать в сопроводительном письме и так далее?

Я тоже пишу limit 10 000 в sql запросах, как защита от дурака.

Прогнозы дело такое, но вот мои

  1. АГИ и робототехника в здравоохранении - люди станут меньше болеть, меньше умирать, и как результат - людей станет еще больше

  2. АГИ и робототехника в производстве

    1. Для капиталистов сначала настанут кайфовые времена - уволят медленных людей, которые жрут, срут и спят 16 часов из 24. Заменят их АГИ роботами, повысят производство и свои прибыли. Уволенные люди - будут искать работу и часть из них не найдет и станет нищими/сопьются/повесятся.

    2. Но когда так сделает критическая масса капиталистов - окажется, что некому покупать их товары (люди же не работают, денег у них нет). Экономика пойдет на спад. Я не думаю что человечество быстро разработает какие-то новые экономические теории, сначала будут костылить (по типу безусловного базового дохода). Другими словами капиталисты должны будут делится своими благами, чтобы у них продолжали покупать их товары, произведенные АГИ роботами

    3. Из плюсов - есть шанс, что людей заменят на вредных производствах

    4. Разумеется все это будет неравномерно (как страны первого/третьего мира), но в случае если АГИ робот станет дешевле, чем условный китаец на фабрике с людьми - то это будут плохие новости для дешевого ручного труда

  3. АГИ и робототехника в потреблении

    1. Тут не только роботы-уборщики и доставщики, но роботы в условном амазоне на складах - работников ждет примерно тоже самое, что и работников на производстве

    2. Аналогично для всех монополизированных сфер или около того - например такси с появлениям всяких уберов

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

Спасибо, в статье написано еще что spike может быть назначен на разработчика.

И если задача не оценивается в SP - то как потом вы управляете capacity команды? Получается некая "неучтенная" задача в понятиях скрама. То есть по хорошему надо выделить меньше SP на команду/человека. Что вы делаете в этом случае?

Вот, это уже лучше. Вопрос - кто и когда успевает делать spike? Это отдельная задача в рамках спринта? Кто и как ее оценивает в sp?

Хорошо что все собранно в одной статье - я и сам местами стал приходить к тем же выводам.

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

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

Я тоже самое написал. Но решения я так и не вижу / не знаю.

Раскройте пжл в следующих статья вопрос автоматического масштабирования - там насколько я помню нельзя было просто добавить еще один сервер-consumer и нужна переконфигурация партиций (см https://stackoverflow.com/questions/36203764/how-can-i-scale-kafka-consumers). Отсюда собственно непонятно - каким образом в этом LinkedIn вообще это пытались масштабировать.

Информация

В рейтинге
2 335-й
Откуда
Россия
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Архитектор программного обеспечения
Старший
C#
.NET Core
SQL