Исправление Iron_Bug, (текущая версия) :
да. но обсуждать надо ДО того, как что-то начнут делать. а не после и не в процессе. потому что если что-то надо обсуждать в процессе - это значит, что изначально всё не было продумано. а заниматься написанием софта наугад (авось, в процессе поймём, что же мы пишем) - занятие заведомо тупое и бесперспективное. а в разработке харда такое вообще не канает. хард всё-таки вещь более серьёзная. там нельзя взять и откатиться по причине тупизма изначальной задумки.
просто я считаю, что разработчик должен понимать, что он делает. а не бегать советоваться с кем-то постоянно. а от постоянных ненужных докладов, кто что сделал, работа быстрее точно не делается. минус время, просранное на доклады. и минус кэш в голове, сбитый этой ненужной бюрократией.
Исправление Iron_Bug, :
да. но обсуждать надо ДО того, как что-то начнут делать. а не после и не в процессе. потому что если что-то надо обсуждать в процессе - это значит, что изначально всё не было продумано. а заниматься написанием софта наугад (авось, в процессе поймём, что же мы пишем) - занятие заведомо тупое и бесперспективное. а в разработке харда такое вообще не канает. хард всё-таки вещь более серьёзная. там нельзя взять и откатиться по причине тупизма изначальной задумки.
просто я считаю, что разработчик должен понимать, что он делает. а не бегать советоваться с кем-то постоянно.
Исходная версия Iron_Bug, :
да. но обсуждать надо ДО того, как что-то начнут делать. а не после и не в процессе. потому что если что-то надо обсуждать в процессе - это значит, что изначально всё не было продумано. а заниматься написанием софта наугад (авось, в процессе поймём, что же мы пишем) - занятие заведомо тупое и бесперспективное. а в разработке харда такое вообще не канает. хард всё-таки вещь более серьёзная. там нельзя взять и откатиться по причине тупизма изначальной задумки.