Ну а про то , какие запросы генерят ORM это отдельная тема
Ну, холивар по поводу ORM это тема отдельной статьи и отдельного треда с комментами.
То, что в экосистемах бэкендовых ЯП присутствуют такие чудища как ORM - это не значит, что надо от бэкенда отказываться и переносить все в БД. Можно же отказаться от ORM, верно?) Ну или на худой конец поменять саму ORM на более вменяемую
Могу предположить, что если выгорание было связано с целью получения какой-то должности на работе, то возможно, этому предшествовало нечто такое:
На Performance review: - Поздравляем тебя, %NAME%! ты очень хороший системный аналитик, мы ради что ты в нашей команде! У тебя очень хороший потенциал дальнейшего роста, и с этого момента ты начинаешь двигаться в сторону СТО!
Спустя 6 месяцев усиленных стараний делать свою работу качественно, с новыми уровнями ответственности и тд: - Отличная работа, %NAME%! Ты продолжаешь двигаться в сторону СТО!
Еще через 6 месяцев: - Вау, мы просто в восторге от тебя, %NAME%! Твоя продуктивность вне всяких похвал, на тебя однозначно можно положиться! Тебе можно доверить всю команду на новые проекты, и ты уже почти на пути к уровню СТО!
То есть, не было ли это какой-то "морковкой", которую подвесили перед ослом, чтобы тот продолжал идти вперед? По факту, это просто способ сделать так, чтобы ценный сотрудник остался в компании подольше.
Возможно, выгорание как раз - это некий сигнал от подсознания, дающего понять, что у этой цели "роста" нет как самого смысла (кроме тщеславия), так и не обозначено конкретных показателей/результатов, достигнув которых, вам гарантировали получение новой должности.
И как только вы перестали играть в эту игру, жизнь сразу наладилась.
Как-то попадалась мне на глаза "IDE для БД", то есть именно с полноценным дебаггером хранимых процедур, брейкпоинтами и остальным. Но она вроде стоила каких-то бешеных денег, и я даже пробовать ее не стал)
Проблема еще в том что например я видел довольно много разрабов, которые почему-то и сами комменты любят на английском писать. Камон, ребят, комменты нужны как раз чтобы недвусмысленно въехать разрабу в то, о чем идет речь, и как можно быстрее (не тратить драгоценные секунды на перевод текста обратно на русский у себя в голове).
Согласен по комментам, но добавлю еще один кейс где комменты полезны. Когда вы имеете дело с древнейшим легаси кодом, который нормально переделывать вот прям щас времени нет, но вы потратили время и хотя бы поняли что этот конкретный говно-кусок делает, вот хотя бы написать коммент про то, что вы только что поняли, это лучше чем ничего))
К тому же во многих городах на операционный стол сложно попасть по ОМС
Тем не менее, говорим по конкретную больницу в конкретном городе :)
При всех ее недостатках, связанных в основном с состоянием самого здания, на операционный стол я попал в тот же день, когда обратился, операция была срочная.
Не, там таки есть крыло с норм ремонтом)) но оно одно, и не на всех этажах (вроде)
Но вообще, когда я там лежал (в крыле без ремонта), очень боялся что-нибудь подцепить нехорошее. Но вроде обошлось.
Но кстати несмотря на плачевное состояние самой больницы, врачи там просто герои, провели сложную операцию и ни копейки не взяли. Где-нибудь в США я бы получил счет на 100к$ думаю))
Не забываем про технические задачи, польза от которых прямо сразу не видна заказчику, потому что функционально они ничего не добавляют. Но задачи эти делать надо, и выделять время на них надо прилично, чтобы потом со временем не начала проседать скорость введения новых фич по причине того, что команда погрязла в техническом долге, запутанном спагетти-коде, лавине багов и т.д. А в особо запущенных случаях на прод может незаметно просочиться то, что я называю "фатальный баг": неприятная поломка, спровоцировавшая цепочку негативных событий и приведшая к банкротству всей компании.
Полагаю автор забил на псевдо-рост (тот который никогда не состоится из-за корпоративных игр) и начал думать о плане реального роста
Ну, холивар по поводу ORM это тема отдельной статьи и отдельного треда с комментами.
То, что в экосистемах бэкендовых ЯП присутствуют такие чудища как ORM - это не значит, что надо от бэкенда отказываться и переносить все в БД. Можно же отказаться от ORM, верно?) Ну или на худой конец поменять саму ORM на более вменяемую
кёрлинг
+, я б не стал это называть "белым зеркалом", скорее то же, родимое, черное
Могу предположить, что если выгорание было связано с целью получения какой-то должности на работе, то возможно, этому предшествовало нечто такое:
На Performance review:
- Поздравляем тебя, %NAME%! ты очень хороший системный аналитик, мы ради что ты в нашей команде! У тебя очень хороший потенциал дальнейшего роста, и с этого момента ты начинаешь двигаться в сторону СТО!
Спустя 6 месяцев усиленных стараний делать свою работу качественно, с новыми уровнями ответственности и тд:
- Отличная работа, %NAME%! Ты продолжаешь двигаться в сторону СТО!
Еще через 6 месяцев:
- Вау, мы просто в восторге от тебя, %NAME%! Твоя продуктивность вне всяких похвал, на тебя однозначно можно положиться! Тебе можно доверить всю команду на новые проекты, и ты уже почти на пути к уровню СТО!
То есть, не было ли это какой-то "морковкой", которую подвесили перед ослом, чтобы тот продолжал идти вперед? По факту, это просто способ сделать так, чтобы ценный сотрудник остался в компании подольше.
Возможно, выгорание как раз - это некий сигнал от подсознания, дающего понять, что у этой цели "роста" нет как самого смысла (кроме тщеславия), так и не обозначено конкретных показателей/результатов, достигнув которых, вам гарантировали получение новой должности.
И как только вы перестали играть в эту игру, жизнь сразу наладилась.
А еще есть супер мега хайлоад известные на всю страну системы с бэкендом на делфи :)
А, это где еще все поувольнялись из-за такой идеи?))
Ну все ж адекватно составленный SQL запрос (с max() вместо выгрузки всего и вся) - это не про хранение логики в БД.
Адекватно составленные оптимальные и быстрые SQL-ники тоже в коде проекта хранятся, просто в БД выполняются :)
Как-то попадалась мне на глаза "IDE для БД", то есть именно с полноценным дебаггером хранимых процедур, брейкпоинтами и остальным. Но она вроде стоила каких-то бешеных денег, и я даже пробовать ее не стал)
Проблема еще в том что например я видел довольно много разрабов, которые почему-то и сами комменты любят на английском писать. Камон, ребят, комменты нужны как раз чтобы недвусмысленно въехать разрабу в то, о чем идет речь, и как можно быстрее (не тратить драгоценные секунды на перевод текста обратно на русский у себя в голове).
Согласен по комментам, но добавлю еще один кейс где комменты полезны. Когда вы имеете дело с древнейшим легаси кодом, который нормально переделывать вот прям щас времени нет, но вы потратили время и хотя бы поняли что этот конкретный говно-кусок делает, вот хотя бы написать коммент про то, что вы только что поняли, это лучше чем ничего))
Какой вариант кода лучше?
или:
Тем не менее, говорим по конкретную больницу в конкретном городе :)
При всех ее недостатках, связанных в основном с состоянием самого здания, на операционный стол я попал в тот же день, когда обратился, операция была срочная.
Не, там таки есть крыло с норм ремонтом)) но оно одно, и не на всех этажах (вроде)
Но вообще, когда я там лежал (в крыле без ремонта), очень боялся что-нибудь подцепить нехорошее. Но вроде обошлось.
Но кстати несмотря на плачевное состояние самой больницы, врачи там просто герои, провели сложную операцию и ни копейки не взяли. Где-нибудь в США я бы получил счет на 100к$ думаю))
Хмм, я всю жизнь думал, что это вроде как работа админов/девопсов
Не забываем про технические задачи, польза от которых прямо сразу не видна заказчику, потому что функционально они ничего не добавляют. Но задачи эти делать надо, и выделять время на них надо прилично, чтобы потом со временем не начала проседать скорость введения новых фич по причине того, что команда погрязла в техническом долге, запутанном спагетти-коде, лавине багов и т.д. А в особо запущенных случаях на прод может незаметно просочиться то, что я называю "фатальный баг": неприятная поломка, спровоцировавшая цепочку негативных событий и приведшая к банкротству всей компании.
Правильно ли я понял, что скрам - это такая штука, при которой в перерывах между митингами программистам разрешается немного поработать?)
GMail проглотил. Конвертнул домен и ругнулся что домена такого нет
ну адрес конвертнется в xxx@xn--d1acufc.xn--p1ai и дойдет
Фактически, Мир - это система карточных платежей, продукт НСПК, через который сейчас в РФ проходят платежи ушедших Визы и МС.
НСПК - это компания, у которой два основных продукта: Мир и СБП. Так что все верно было сказано