Так рассуждать, то и у сапожника ничего не понятно — кто-то в его ботинках пойдет на работу, а кто-то в луже уснет.
Пожалуйста, не могли бы вы сформулировать свою мысль прямо и недвусмысленно? Я абсолютно серьезно, пытаюсь и не могу понять, к чему вы клоните. Программист должен отвечать за все аспекты создания программы? Хорошие программисты никому не нужны, потому что для успеха программы качество кода не важно? Или что?
Не, я думал речь о том, чтобы на ассемблере именно писать. Если программу просто дизассемблировать, непонятно, откуда у нее возьмется выигрыш в производительности?
Если человек программист, то результатом его труда является код. И на этом фронте он должен сделать все, что может. Хороший код, как минимум, гарантирует гибкость и сопровождаемость. Ну, как от сапожника, вы же не ждете, что он вас жизни научит, а ждете, что он ботинок починит. Женитесь вы в этом ботинке или нет — гораздо более важный вопрос, конечно, но сапожник-то тут причем?
Предсказуемость результата есть признак профессионализма. Программа, действительно, может не выстрелить. Ее успех, действительно, не зависит от качества кода внутри. Но это не означает, что не надо уметь и писать, насколько умеешь, хороший код.
Штука еще в том, что JIT может менять набор инструкций в зависимости от конкретной ситуации, а код на ассемблере всегда статичный. Так что даже тут не все однозначно.
Нет, у него все правильно написано — дизайнер о юзабилити должен знать куда больше, чем программист. В реальности, как вы и говорите, это к сожалению не так.
Мой пока не заполнен, и я бы не назвал описанные знания бесполезными. То есть, если бы Ватсон рассказал Холмсу, как именно он может использовать эти знания в своей работе (о чем моя статья), так просто откреститься от них не получилось бы.
Это те самые эмпирические знания, накопленные программистской культурой, да. Но не все, необходимые для хорошего кода, и под ними нет системы, нельзя проследить, почему это работает, а это нет, можно только запомнить.
Да, это один из самых очевидных плюсов — делать работу проектировщика.
Зачем серверному программисту знать юзабилити? Чтобы потом бэкэнд сшился с фронтэндом без проблем. Бэкэнд определяет достаточно много потребительских качеств (скорость реакции системы, устройство бизнес-процессов, надежность), поэтому даже серверсайд программисту неплохо бы представлять, как то, что он делает, повлияет на использование системы конечными пользователями. Если он не знает точно, что и зачем он делает, успех продукта — только вопрос случая.
Еще раз, я, равно как и любой другой пользователь, готов понять и принять ограничения, накладываемые возможностями железа, программ, человеческого организма.
Я лишь указываю (в силу знания внутреннего устройства софта), что есть места, где часть ограничений можно снять, и это будет иметь практический смысл.
А вы все приводите примеры из серии «я смогу это сломать» и «я знаю, кому это не нужно». Но продукт определяется не этим.
Пожалуйста, не могли бы вы сформулировать свою мысль прямо и недвусмысленно? Я абсолютно серьезно, пытаюсь и не могу понять, к чему вы клоните. Программист должен отвечать за все аспекты создания программы? Хорошие программисты никому не нужны, потому что для успеха программы качество кода не важно? Или что?
Зачем серверному программисту знать юзабилити? Чтобы потом бэкэнд сшился с фронтэндом без проблем. Бэкэнд определяет достаточно много потребительских качеств (скорость реакции системы, устройство бизнес-процессов, надежность), поэтому даже серверсайд программисту неплохо бы представлять, как то, что он делает, повлияет на использование системы конечными пользователями. Если он не знает точно, что и зачем он делает, успех продукта — только вопрос случая.
Я лишь указываю (в силу знания внутреннего устройства софта), что есть места, где часть ограничений можно снять, и это будет иметь практический смысл.
А вы все приводите примеры из серии «я смогу это сломать» и «я знаю, кому это не нужно». Но продукт определяется не этим.