Это всё звучит забавно — про споры о IDE для Java. Без которого на языке писать мягко говоря тяжко.
С учётом того что есть языки которые позволяют писать код без IDE и продуктивноться не падет.)
Хорошо бы разработчики одного языка с ними познакомились, бывает если выйти за пределы совего "села" всё привычное уже не кажется каким хорошим. :)
Слабые умы не могут осилить ООП — это основной недостаток ООП
Или же — слабые умы не могут понять что оно не нужно и продолжают верить своим кумирам продвигавшим ООП?) И писать пухлые от лишнего кода проекты.
Java как язык лично для меня умер, и я теперь понимаю что всегда его ненавидел. Уродливый и громоздкий. А вот JVM жива и процветает, под неё огромное кол-во прекрасный языков.
Собственно если уходить от Java то в отрасле должен начаться фундаментальный сдвиг от ужаса называемого ООП, потому что все более менее популярные на сегодня языки не так уж и далеки от Java.
По сути получается google своими же руками создает большие возможности для конкурентов, получить новую аудиторию.
Лично я отказался от chrome потому что дизайн меняется а вот качество работы напрягает, часто вылетает, виснет.
Мне кажется что вы манагер и витаете в облаках.
Почему я должен чему то придерживаться? Если от меня требуют какие то оценки я говорю всегда что могу предположить, но ничего не обещаю и это оценка от балды. Если вам она нужна — пожалуйста. Только ко мне потом не приходите спрашивать почему она не соответствовала действительности.
Не нравиться, ну что ж поищите себе другого сотрудника, у меня благодаря моим навыкам разрабатывать работающий продукт, предложений предостаточно. Где мне не будут всякие не понимающие ничего в разработке личности указывать на то как я должен работать.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Вообще стараюсь компаний где манагеры а не техлиды чем-то рулят, избегать.
Потому что постоянно объяснять человеку о процессе которым он не владеет бесмыссленно и себе же дороже.
Любой адекватный разработчик это понимает. Манагерам удобно так выжимать соки.
Когда я слышу это слово scrum или понимаю что эта бездарная идея где то рядом. Сразу делаю выводы кто передо мной и что нужно валить.
Никто вам манагерам ничего не должен.)
Вы забываете что разработчик это, в основном, квалифицированный специалист. Который обменивает свои знания на деньги компании. А типичный манагер, какой нибудь бывший тестировщик или БА, который 0 в разработке, и трясется за своё место потому что в другой компании он никому не нужен, а в этой получил место просто потому что работает там уже много времени и глубо знаком с проектом, но ни как не потому что он какой то одаренный и с глубоким понимание специалист.
Вот и получается что манагер судит по себе, он жутко зависим от компании и часто ограниченный, в его понимании все такие же как он, а разработчик ресурс. Только вот все не так. Уже не эра заводов и значение квалифицированного специалиста на проекте который может его поддерживать в живом состоянии, решая все проблемы это огромная ценность для бизнеса но не для этого специалиста. С учетом текущей высококонкурентной среды, когда неплохую работу можно найти за неделю.
Разработчик не пахарь, а ценность.
Кол-во манагеров я бы везде тотально сократил, потому что они обычно только мешают. Сколько я проектов уже перевидал, почти все если уже быть честным, где все держится на одном двух, главных разработчиках, и они решают все реальные проблемы, а манагер который только мешает, думает что это результат его 'гениальной' работы и избавится от этого ненужного баласта, постоянно отвлекающего, напрягающего и генерирующего поток бессмысленных идей и предложений по проекту, трудно. Почему то в головах многих людей старой формации, которые сейчас в силу своих возрастных преимуществ владеют большинством бизнесов, прочно заселе восприятие о необходимости манагера.
Но это не беда, сейчас уже много компаний которые стремятся к плоской структуре и они постепенно выигрывают позиции, за счет своей эффективности.
Логичная альтернатива это не использование оценок по времени. Точнее той формы что описана в статье и относится к этим бредовым методологиям.
По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальнику. И корректируются в процессе работы. Смысла в чем то другом не вижу.
Когда вы управляете конвеером где налаженный тех процесс, такие оценки вполне возможны, но даже тут нет страховки от случайных событий — кто-то заболел или отключили электричество.
В IT уже начиная с самого среднего проекта эти оценки бред.
Может когда вся работа это постоянно клепание CRUD или типового УГ на Joomla и аналогах, оценки ещё возможны, при условии что команда слажена. В более менее сложном проекте это уже бред.
Сама идея о том что какие то аналитики, дают оценки времени выполнения задач программистам и делают их декомпозицию, вам это уже само по себе не кажется бредом. Вы программистом работаете? Очень интересно узнать.)
Один раз работал в конторке где были эти сторипоиты, да и вообще нужно было наперёд сказать сколько у меня времени займет та или иная задача.
Имхо бред, я что лопатой копаю? Даже с лопатой можно неверно оценить может под землёй будет куча камней или какая нибудь коммуникация и все оценки сбились.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них, дал слишком много — а почему так много можно же быстрее...)
Ну или очередной тупой манагер который не занимался разработкой никогда, возомнил себя гуру планирования и без понимания сути вещей заставляет всех вокруг страдать точными оценками и отчетами по ним.
Поэтому сейчас когда я слышу о стори поинтах или аналогичной херни, сразу же ставлю крест на предложении.
Может быть если рассматривать коммутацию со старыми телефонными линиями. Но не совсем ясно, зачем что-то поддерживать когда у вас в нутри сети передается голос от одного человека другому, это просто данные.
Мне например поддержка звонков вне сети не особенно нужна.
При современных технологиях брать отдельную плату за передачу виде и аудио (и др.) это просто желание на пустом месте получить побольше денег.
Платишь за канал передачи данных а что передается это уже моё дело.
Пытаются рассказывать какие то сказки о том что это всё на пользу индустрии и даже пользователям!)
Великолепно, я надеюсь это удешевит поездки на автотранспорте. Не нужно будет иметь свою машину и париться с её ремонтом и обслуживаем. Для меня авто это — сел и комфортно доехал. Всё остальное это ненужный геморрой.
А ещё прекрасно что можно будет не видеть товарищей за рулем не нюхать прокуренный салон, не настаивать сделать музыку потише, не требовать чека и не контролироваться показания счетка.
В принципе у меня на даче много работы, подрезать кусты, капать, мыть… Товарищи которые потеряют работу из-за этой технологии без проблем найдут себе место полностью соответствующее их талантам.)
Зачем для данного случая дистанционное управление? Достаточно команды остановить машину в ближайшем доступном месте или в том куда указали. А как это сделать она уже и так знает.
Это всё звучит забавно — про споры о IDE для Java. Без которого на языке писать мягко говоря тяжко.
С учётом того что есть языки которые позволяют писать код без IDE и продуктивноться не падет.)
Хорошо бы разработчики одного языка с ними познакомились, бывает если выйти за пределы совего "села" всё привычное уже не кажется каким хорошим. :)
Тезис прост, объект в 99% задач не нужен — то есть объединение состояния + действия. У вас или данные или действия. Чем проще тем лучше.
Уровень невежества поражает.)
Вот бы увидеть хоть исходный код проект где ООП применили как надо и получилось красиво и понятно.)
Java как язык лично для меня умер, и я теперь понимаю что всегда его ненавидел. Уродливый и громоздкий. А вот JVM жива и процветает, под неё огромное кол-во прекрасный языков.
Собственно если уходить от Java то в отрасле должен начаться фундаментальный сдвиг от ужаса называемого ООП, потому что все более менее популярные на сегодня языки не так уж и далеки от Java.
По сути получается google своими же руками создает большие возможности для конкурентов, получить новую аудиторию.
Лично я отказался от chrome потому что дизайн меняется а вот качество работы напрягает, часто вылетает, виснет.
Мне кажется что вы манагер и витаете в облаках.
Почему я должен чему то придерживаться? Если от меня требуют какие то оценки я говорю всегда что могу предположить, но ничего не обещаю и это оценка от балды. Если вам она нужна — пожалуйста. Только ко мне потом не приходите спрашивать почему она не соответствовала действительности.
Не нравиться, ну что ж поищите себе другого сотрудника, у меня благодаря моим навыкам разрабатывать работающий продукт, предложений предостаточно. Где мне не будут всякие не понимающие ничего в разработке личности указывать на то как я должен работать.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Вообще стараюсь компаний где манагеры а не техлиды чем-то рулят, избегать.
Потому что постоянно объяснять человеку о процессе которым он не владеет бесмыссленно и себе же дороже.
Любой адекватный разработчик это понимает. Манагерам удобно так выжимать соки.
Когда я слышу это слово scrum или понимаю что эта бездарная идея где то рядом. Сразу делаю выводы кто передо мной и что нужно валить.
Никто вам манагерам ничего не должен.)
Вы забываете что разработчик это, в основном, квалифицированный специалист. Который обменивает свои знания на деньги компании. А типичный манагер, какой нибудь бывший тестировщик или БА, который 0 в разработке, и трясется за своё место потому что в другой компании он никому не нужен, а в этой получил место просто потому что работает там уже много времени и глубо знаком с проектом, но ни как не потому что он какой то одаренный и с глубоким понимание специалист.
Вот и получается что манагер судит по себе, он жутко зависим от компании и часто ограниченный, в его понимании все такие же как он, а разработчик ресурс. Только вот все не так. Уже не эра заводов и значение квалифицированного специалиста на проекте который может его поддерживать в живом состоянии, решая все проблемы это огромная ценность для бизнеса но не для этого специалиста. С учетом текущей высококонкурентной среды, когда неплохую работу можно найти за неделю.
Разработчик не пахарь, а ценность.
Кол-во манагеров я бы везде тотально сократил, потому что они обычно только мешают. Сколько я проектов уже перевидал, почти все если уже быть честным, где все держится на одном двух, главных разработчиках, и они решают все реальные проблемы, а манагер который только мешает, думает что это результат его 'гениальной' работы и избавится от этого ненужного баласта, постоянно отвлекающего, напрягающего и генерирующего поток бессмысленных идей и предложений по проекту, трудно. Почему то в головах многих людей старой формации, которые сейчас в силу своих возрастных преимуществ владеют большинством бизнесов, прочно заселе восприятие о необходимости манагера.
Но это не беда, сейчас уже много компаний которые стремятся к плоской структуре и они постепенно выигрывают позиции, за счет своей эффективности.
Логичная альтернатива это не использование оценок по времени. Точнее той формы что описана в статье и относится к этим бредовым методологиям.
По сути оценки времени даются всегда, на глазок, от коллеги к коллеге или начальнику. И корректируются в процессе работы. Смысла в чем то другом не вижу.
Когда вы управляете конвеером где налаженный тех процесс, такие оценки вполне возможны, но даже тут нет страховки от случайных событий — кто-то заболел или отключили электричество.
В IT уже начиная с самого среднего проекта эти оценки бред.
Может когда вся работа это постоянно клепание CRUD или типового УГ на Joomla и аналогах, оценки ещё возможны, при условии что команда слажена. В более менее сложном проекте это уже бред.
Сама идея о том что какие то аналитики, дают оценки времени выполнения задач программистам и делают их декомпозицию, вам это уже само по себе не кажется бредом. Вы программистом работаете? Очень интересно узнать.)
В том и дело что требую где то явно, где то ничего не говорят но на разработчике висит уже груз ответственности в виде поставленой оценки.
Один раз работал в конторке где были эти сторипоиты, да и вообще нужно было наперёд сказать сколько у меня времени займет та или иная задача.
Имхо бред, я что лопатой копаю? Даже с лопатой можно неверно оценить может под землёй будет куча камней или какая нибудь коммуникация и все оценки сбились.
Это такая тупейшая чушь, цель которой только одна заставить разработчика пахать, раздал оценки тогда давай укладывайся в них, дал слишком много — а почему так много можно же быстрее...)
Ну или очередной тупой манагер который не занимался разработкой никогда, возомнил себя гуру планирования и без понимания сути вещей заставляет всех вокруг страдать точными оценками и отчетами по ним.
Поэтому сейчас когда я слышу о стори поинтах или аналогичной херни, сразу же ставлю крест на предложении.
Может быть если рассматривать коммутацию со старыми телефонными линиями. Но не совсем ясно, зачем что-то поддерживать когда у вас в нутри сети передается голос от одного человека другому, это просто данные.
Мне например поддержка звонков вне сети не особенно нужна.
Это решаемо, если смогли сделать автономные автомобили, то сумеют добавить датчики курения.)
При современных технологиях брать отдельную плату за передачу виде и аудио (и др.) это просто желание на пустом месте получить побольше денег.
Платишь за канал передачи данных а что передается это уже моё дело.
Пытаются рассказывать какие то сказки о том что это всё на пользу индустрии и даже пользователям!)
Великолепно, я надеюсь это удешевит поездки на автотранспорте. Не нужно будет иметь свою машину и париться с её ремонтом и обслуживаем. Для меня авто это — сел и комфортно доехал. Всё остальное это ненужный геморрой.
А ещё прекрасно что можно будет не видеть товарищей за рулем не нюхать прокуренный салон, не настаивать сделать музыку потише, не требовать чека и не контролироваться показания счетка.
В принципе у меня на даче много работы, подрезать кусты, капать, мыть… Товарищи которые потеряют работу из-за этой технологии без проблем найдут себе место полностью соответствующее их талантам.)
Зачем для данного случая дистанционное управление? Достаточно команды остановить машину в ближайшем доступном месте или в том куда указали. А как это сделать она уже и так знает.
Попробуйте Clojure. Простой и эффективный.