Я лично считаю что первый язык программирования должен быть C
Точно! А на географии рассказывать, что земля покоится на трех слонах, стоящих на черепахе. И на физике рассказывать, что Земля - центр мира, а Солнце, планеты и звезды вращаются вокруг нее. Вряд ли C зайдет абсолютному новичку. Он просто не поймет ценности и значения этого языка. Для него - это набор заумных идей, которые невесть откуда взялись и не пойми как их использовать. Исключения случаются, наверное. Но для большинства - это путь в тупик
Работодатели (не буду указывать пальцем кто именно, но таких немало) в курсе, что многие высококлассные разработчики просто психологически не способны лайвкодить? Вот не могут и все - ступор у людей. Из недавнего: приятель, отменно знающий ядро линукса в части многопоточки и планирования на уровне исходников, сам правивший и контрибьютивший в него, не смог пройти элементарного собеседования по C. При том, что знает язык до деталей стандарта. Ну не тот у него характер, не тот психотип. Результат? Конечно, отказали. Хотя на той стороне сидели люди, чьи скиллы в совокупности вряд ли больше, чем у него. И знаете, мне таких работодателей ни капельки не жаль. Действуя по шаблону, они упустили главное - нужного человека. Приятель мой нашел работу, если что. Работодатели, вы кого ищете? Джуна - да, надо в меру погонять. А сеньора+ для чего? Вы поговорите с ним по-душам. Скорее всего, его опыт совершенно адекватен и возможно даже более чем адекватен для той позиции на которую ищут человека. Какого (извиняюсь) хрена вы требуете написать реализацию B-дерева, когда вся работа, которую вы готовы предложить - элементарный Rest API и перекладывание json-ов?
Приведите реальный пример, что у вас в офисе решается за полчаса, а месяц в зуме. Какая у вас там такая волшебная доска с кружочками?
Не доска с кружочками, а люди сели в кружок :) О доске я вообще ничего не говорил. Обычно, хватает несколько листиков бумаги А4 из ближайшего принтера. Вот Вам и пример неудобства переписки и удаленных совещаний: я написал одно, Вы прочли другое и полетело недопонимание. А ведь случай - простейший. На все про все ушло 2 суток (с момента моего предыдущего комментария). Еще нужны доказательства?
P.S. "Единственная известная мне роскошь - это роскошь человеческого общения" (Антуан де Сент-Экзюпери) - трудно не согласиться, или нет?
Плоховато с данными у автора: на картинке все мужчины либо с бородой, либо дурно выбриты. Вы не в курсе, что существуют такие мужчины (и их много), что чисто бреются? Кроме того, все 7 персонажей - в очках. Вывод: будешь работать дата-инженером, непременно испортишь себе зрение. Так себе представление о роде человеческом.
Все мужчины - темноволосые и среди них нет ни одного лысого или коротко стриженного. Ошибочка, однако: есть и светловолосые и стриженные.
Вот так, без всяких инструментов, я получил ряд бесспорных "выводов", которые непосредственно следуют из предложенной автором картинки.
Готовя статью о данных и их обработке, неплохо бы озаботиться представлением этих самых данных. Их репрезентативностью. Рисунки должны способствовать пониманию и иллюстрировать важные идеи. Ваша картинка - профанация для привлечения внимания.
Мне кажется, здесь нет однозначного ответа, пригодного на все случаи жизни. В принципе - я за гибрид (а в отдельных случаях и за полную удаленку), если бы не одно "но": порой это реально препятствует достижению конечного результата. То, что при очном контакте в офисе можно решить за 15-30 минут, при удаленке легко может превратиться в недели и месяцы обсуждений в телеге/зуме/... и в переписке. В офисе как? Сели в кружок и начали рисовать. Тут же вносятся правки и проигрываются новые идеи. Результат получается многократно быстрее, аккуратнее и согласованнее. Потом перешли к следующей задаче, повторили и так далее. Тут же набрасываются таски, заготовки, дополняется аналитика и ТЗ. Дорабатываются архитектурные огрехи. Согласовываются зависимости, сроки и последовательность выполнения. Проколы случаются, но не в пример реже, чем на чистой удаленке. Как правило, даже с большими объемами удается справиться за полдня и остается время на закрепление успеха пивной вечеринкой. Что, кстати, дополнительно укрепляет команду и связи внутри команды. И вообще, это реально препятствует одичанию :)
То есть, когда за перекладывание джейсонов хорошо платят, но это скучно - опять плохо?
Почему сразу плохо? Каждый выбирает по себе. Лично мне - скучно. И это плохо. Но за это неплохо платят. И это хорошо. Не надо все делить на белое/черное или правильное/неправильное. Мир богаче любых схем
Не все, конечно. Просто большинство. Есть по-настоящему интересные задачи и проекты, но, как правило, в таких конторах, где платят ровно столько, чтобы штанишки на попе держались
К перечисленным выше 3 случаям ошибок при проектировании я бы добавил слабую проработку бизнес-процессов. Это - боль. Бизнес-аналитики часто не утруждают себя прямым контактом с пользователями. Не все, конечно, но многие. Отсюда - дичайшая дичь. Они могут увидеть поверхностные явления (а потом - извратить и их), но чем эти явления обусловлены - им невдомек.
Часто приложения проектируются без учета потенциального роста бизнес-логики и количества пользователей. Как говорится "сейчас справляется - и ладно; о лучшем подумаем после". Тут нужен талант, своего рода чуйка. Этому не научишься на курсах. Этому учатся в процессе. Но результатов добиваются единицы.
Часто бизнес говорит "сделайте по минимуму, лишь бы работало". Его понять можно. Но также часто бизнес не пытается заглядывать чуть дальше. Задача архитектуры и аналитики быть прозорливее пользователей. Для этого нужна погруженность в те процессы, что выполняют пользователи. Если пользователи привыкли, что отчет формируется ночь, то при росте нагрузки в 2 раза этот же отчет будет наверняка формироваться дольше, но не в 2 раза, а, скорее, в 4 или даже в 10 раз.
Решения - как это предусмотреть и избежать, у меня, увы, нет. С унаследованными системами все очень больно - придется влезать в старую кодовую базу, менять фреймворки, базы данных, архитектуру - такое себе решение, но обычно на это приходится идти. А иногда и этого нельзя делать - только править существующее.
Но хоть новые-то проекты можно делать сразу по-людски, с перспективой роста?
Приблуда отличная. На хабре даже была парочка статей лет этак 5 назад (пишу со смартфона, а на нем искать неудобно, так что сами поищите). Настраивал когда-то ABAC на несколько сотен пользователей. Не скажу, что с первого раза получилось, но получилось и в итоге остался доволен. Рекомендую
Точно! А на географии рассказывать, что земля покоится на трех слонах, стоящих на черепахе. И на физике рассказывать, что Земля - центр мира, а Солнце, планеты и звезды вращаются вокруг нее.
Вряд ли C зайдет абсолютному новичку. Он просто не поймет ценности и значения этого языка. Для него - это набор заумных идей, которые невесть откуда взялись и не пойми как их использовать. Исключения случаются, наверное. Но для большинства - это путь в тупик
Какая обида, помилуйте. Просто мы себя не на помойке нашли и играть в непонятные игры не готовы. Кто хочет - welcome. Кто не хочет - его право
Понятия не имею. Я там не работаю. И приятель мой. Что и правильно
Работодатели (не буду указывать пальцем кто именно, но таких немало) в курсе, что многие высококлассные разработчики просто психологически не способны лайвкодить? Вот не могут и все - ступор у людей. Из недавнего: приятель, отменно знающий ядро линукса в части многопоточки и планирования на уровне исходников, сам правивший и контрибьютивший в него, не смог пройти элементарного собеседования по C. При том, что знает язык до деталей стандарта. Ну не тот у него характер, не тот психотип. Результат? Конечно, отказали. Хотя на той стороне сидели люди, чьи скиллы в совокупности вряд ли больше, чем у него.
И знаете, мне таких работодателей ни капельки не жаль. Действуя по шаблону, они упустили главное - нужного человека. Приятель мой нашел работу, если что.
Работодатели, вы кого ищете? Джуна - да, надо в меру погонять. А сеньора+ для чего? Вы поговорите с ним по-душам. Скорее всего, его опыт совершенно адекватен и возможно даже более чем адекватен для той позиции на которую ищут человека. Какого (извиняюсь) хрена вы требуете написать реализацию B-дерева, когда вся работа, которую вы готовы предложить - элементарный Rest API и перекладывание json-ов?
За меня зачем решать-то, что мне интересно, а что нет? По мере возможности и не без любопытства - мониторю. Не грех послушать другое мнение
Не доска с кружочками, а люди сели в кружок :) О доске я вообще ничего не говорил. Обычно, хватает несколько листиков бумаги А4 из ближайшего принтера.
Вот Вам и пример неудобства переписки и удаленных совещаний: я написал одно, Вы прочли другое и полетело недопонимание. А ведь случай - простейший. На все про все ушло 2 суток (с момента моего предыдущего комментария). Еще нужны доказательства?
P.S. "Единственная известная мне роскошь - это роскошь человеческого общения" (Антуан де Сент-Экзюпери) - трудно не согласиться, или нет?
Плоховато с данными у автора: на картинке все мужчины либо с бородой, либо дурно выбриты. Вы не в курсе, что существуют такие мужчины (и их много), что чисто бреются?
Кроме того, все 7 персонажей - в очках. Вывод: будешь работать дата-инженером, непременно испортишь себе зрение. Так себе представление о роде человеческом.
Все мужчины - темноволосые и среди них нет ни одного лысого или коротко стриженного. Ошибочка, однако: есть и светловолосые и стриженные.
Вот так, без всяких инструментов, я получил ряд бесспорных "выводов", которые непосредственно следуют из предложенной автором картинки.
Готовя статью о данных и их обработке, неплохо бы озаботиться представлением этих самых данных. Их репрезентативностью. Рисунки должны способствовать пониманию и иллюстрировать важные идеи. Ваша картинка - профанация для привлечения внимания.
Ну, Вы поняли - минус. Ничего личного )))
Неплохо, но есть получше: https://dmkpress.com/catalog/computer/programming/python/978-5-93700-166-5/
:)
Мне кажется, здесь нет однозначного ответа, пригодного на все случаи жизни. В принципе - я за гибрид (а в отдельных случаях и за полную удаленку), если бы не одно "но": порой это реально препятствует достижению конечного результата.
То, что при очном контакте в офисе можно решить за 15-30 минут, при удаленке легко может превратиться в недели и месяцы обсуждений в телеге/зуме/... и в переписке. В офисе как? Сели в кружок и начали рисовать. Тут же вносятся правки и проигрываются новые идеи. Результат получается многократно быстрее, аккуратнее и согласованнее.
Потом перешли к следующей задаче, повторили и так далее. Тут же набрасываются таски, заготовки, дополняется аналитика и ТЗ. Дорабатываются архитектурные огрехи. Согласовываются зависимости, сроки и последовательность выполнения. Проколы случаются, но не в пример реже, чем на чистой удаленке.
Как правило, даже с большими объемами удается справиться за полдня и остается время на закрепление успеха пивной вечеринкой. Что, кстати, дополнительно укрепляет команду и связи внутри команды.
И вообще, это реально препятствует одичанию :)
Да ладно на год ) Пусть скажут для начала, когда на юге температура с 39-42 упадет хотя бы до 30
А вычитать текст перед публикацией - не судьба? Извините, но это минус
Забыли (пока?) о налоге на бездетность. В СССР был такой. Чтобы активнее размножались, лодыри)))
Прикольно, конечно, но какое отношение это имеет к хабру? :)))
Почему сразу плохо? Каждый выбирает по себе. Лично мне - скучно. И это плохо. Но за это неплохо платят. И это хорошо.
Не надо все делить на белое/черное или правильное/неправильное. Мир богаче любых схем
Не все, конечно. Просто большинство. Есть по-настоящему интересные задачи и проекты, но, как правило, в таких конторах, где платят ровно столько, чтобы штанишки на попе держались
Книга интересная. Гейтс справедливо ее отметил в своем обзоре пару лет назад )
Но первая книга "Об интеллекте" гораздо содержательнее imho. Так что тем, кто ее не читал - рекомендую
К перечисленным выше 3 случаям ошибок при проектировании я бы добавил слабую проработку бизнес-процессов. Это - боль. Бизнес-аналитики часто не утруждают себя прямым контактом с пользователями. Не все, конечно, но многие. Отсюда - дичайшая дичь. Они могут увидеть поверхностные явления (а потом - извратить и их), но чем эти явления обусловлены - им невдомек.
Часто приложения проектируются без учета потенциального роста бизнес-логики и количества пользователей. Как говорится "сейчас справляется - и ладно; о лучшем подумаем после". Тут нужен талант, своего рода чуйка. Этому не научишься на курсах. Этому учатся в процессе. Но результатов добиваются единицы.
Часто бизнес говорит "сделайте по минимуму, лишь бы работало". Его понять можно. Но также часто бизнес не пытается заглядывать чуть дальше. Задача архитектуры и аналитики быть прозорливее пользователей. Для этого нужна погруженность в те процессы, что выполняют пользователи. Если пользователи привыкли, что отчет формируется ночь, то при росте нагрузки в 2 раза этот же отчет будет наверняка формироваться дольше, но не в 2 раза, а, скорее, в 4 или даже в 10 раз.
Решения - как это предусмотреть и избежать, у меня, увы, нет. С унаследованными системами все очень больно - придется влезать в старую кодовую базу, менять фреймворки, базы данных, архитектуру - такое себе решение, но обычно на это приходится идти. А иногда и этого нельзя делать - только править существующее.
Но хоть новые-то проекты можно делать сразу по-людски, с перспективой роста?
Поддерживаю - отличная книга. Автор в предисловии пишет, что книга может быть полезна не только питонистам и это действительно так
Продолжаете набрасывать на вентилятор? Было же уже: https://habr.com/ru/companies/testograf/articles/816291/
Приблуда отличная. На хабре даже была парочка статей лет этак 5 назад (пишу со смартфона, а на нем искать неудобно, так что сами поищите). Настраивал когда-то ABAC на несколько сотен пользователей. Не скажу, что с первого раза получилось, но получилось и в итоге остался доволен. Рекомендую