Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Intelligence is the ability to avoid doing work, yet getting the work done, как говорил Торвальдс.
Большинство людей готово безмерно трудиться, лишь бы избавиться от необходимости немножко подумать. (Т. Эдисон)
Он, по-моему, так и делал, когда подбирал материал для спирали :)
И в итоге купил патент на лампочку у русского изобретателя)
У кого и на что?
ru.wikipedia.org/wiki/General_Electric
«Компания основана в 1878 году изобретателем Томасом Эдисоном и первоначально называлась «Эдисон электрик лайт», после объединения в 1892 году с компанией «Томсон-Хьюстон электрик» получила своё современное название.
1910 год — компания начинает серийное производство лампочек с вольфрамовой нитью (патент на использование в лампах накаливания нитей из тугоплавких металлов компания купила у русского изобретателя А. Н. Лодыгина в 1906 году)».
«Компания основана в 1878 году изобретателем Томасом Эдисоном и первоначально называлась «Эдисон электрик лайт», после объединения в 1892 году с компанией «Томсон-Хьюстон электрик» получила своё современное название.
1910 год — компания начинает серийное производство лампочек с вольфрамовой нитью (патент на использование в лампах накаливания нитей из тугоплавких металлов компания купила у русского изобретателя А. Н. Лодыгина в 1906 году)».
Александр Лодыгин, родившийся 18 октября 1847 года, занимался строительством летательного аппарата, для освещения кабины пилота в котором нужна была лампа. Лодыгин догадался выкачать из стеклянной колбы воздух и поместить внутрь угольный стержень, который под действием тока накалялся.
Так «побочное» изобретение — лампа накаливания — сделало Лодыгина всемирно известным. Вдохновленный своим успехом, в 1872 году Лодыгин вместе с другом Василием Дидрихсоном основывает компанию «Русское товарищество электрического освещения Лодыгин и К°», которая в мае 1873 года залила электрическим светом восьми фонарей Одесскую улицу Санкт-Петербурга.
В том же 1873 году Лодыгин получил патент на свое изобретение в Великобритании, Франции, Италии, Швеции и других странах. Но Лодыгину так и не удалось заработать на изобретенных им лампах накаливания: в 1906 году после многолетних тяжб с Томасом Эдисоном, который изобрел лампу одновременно с россиянином, Лодыгин продал патент компании General Electric, возвращаясь после 23 лет жизни за границей в Россию.
На родине он преподавал в Электротехническом институте и работал в строительном управлении Санкт-Петербургской железной дороги. После Февральской революции 1917 года Лодыгин уехал в США, где так и не смог найти себе достойное место и умер в своей бруклинской квартире в 1923 году.
Forbes.ru: 18 октября. Этот день в истории бизнеса
Если интересно, вот тут полная история изобретения. ru.wikipedia.org/wiki/%CB%E0%EC%EF%E0_%ED%E0%EA%E0%EB%E8%E2%E0%ED%E8%FF
Этот афоризм не о том что не надо трудиться, а о том что надо думать чаще.
Оригинал взял из блога Proper Fixation за авторством израильского программиста Yossef Kreinin.
Очень интересный блог, рекомендую всем интересующимся С++ и программированием вообще.
Очень интересный блог, рекомендую всем интересующимся С++ и программированием вообще.
К сожалению не всегда удаеться убедить всех что идея полное Г. Еще большое сожаление в том что даже после того как все увидили что она таки Г, люди не делают выводов на будущее.
Программирование это последнее что должен делать программист)
Программирование это последнее что должен делать программист)
Я понимаю, что идеи «мой начальник неумен» и «надо пореже испытывать неудачу» звучат подкупающе. Однако, в конечном счете, минимизация рисков не является способом получить наибольшую отдачу ни в какой деятельности, в том числе и в разработке. Неудачи необходимы для успеха, просто нужны дешевые неудачи. И контролируемые. Ваша неудача была дешевой?
Это еще более неблагодарное занятие, чем писать библиотеку «на выброс» — компенсировать недостатки в орг.структуре личными усилиями рядового разработчика. Кто-то должен был оценить расходы на такую конструкцию до того, как вы вляпались в поддержку двух ветвей кода — с FP и без, или хотя бы в момент, когда эта конструкция начала создавать проблему. Либо кто-то этого не сделал (и тогда проблема совсем не в ПО), либо кто-то это сделал и решил, что написание boilerplate-кода вашими силами — наиболее дешевый путь (и низкорисковый, кстати). Вы, как человеческий ресурс, для этих людей значите не более, чем для вас значит загрузка конвейера GPU. Похоже, что Вас такой подход не устраивает — и это, пожалуй, проблема.
Статья хорошая. Но содержательная часть этой статьи — об отношениях на фирме, а не о программировании. Ну и небольшая «история неудачи» в добавок.
Это еще более неблагодарное занятие, чем писать библиотеку «на выброс» — компенсировать недостатки в орг.структуре личными усилиями рядового разработчика. Кто-то должен был оценить расходы на такую конструкцию до того, как вы вляпались в поддержку двух ветвей кода — с FP и без, или хотя бы в момент, когда эта конструкция начала создавать проблему. Либо кто-то этого не сделал (и тогда проблема совсем не в ПО), либо кто-то это сделал и решил, что написание boilerplate-кода вашими силами — наиболее дешевый путь (и низкорисковый, кстати). Вы, как человеческий ресурс, для этих людей значите не более, чем для вас значит загрузка конвейера GPU. Похоже, что Вас такой подход не устраивает — и это, пожалуй, проблема.
Статья хорошая. Но содержательная часть этой статьи — об отношениях на фирме, а не о программировании. Ну и небольшая «история неудачи» в добавок.
Человеческий ресурс, это, надо сказать, очень обидное выражение. При таком подходе и команда будет думать про три гвоздя (из комментария выше), а не дело делать. Тема организации сплоченной и продуктивной команды — это тема отдельного длинного разговора. Де Марко даже книжку написал о том почему к подчиненным надо относиться как к людям, а не как человеческому ресурсу.
Кстати говоря, доработка компилятора, чтобы он выполнял операции с плавающей точкой программным путем, обошлась бы в десятки раз дешевле, чем все те ужасы, которые вы написали. Далее система тестов просто выполняется на обоих режимах компиляции (симуляция float и честный fixed) и все случаи, когда для перехода от FP к фиксед требуются специальные полиномы и нетривиальная математика, возвращаются упомянутым «белым алгоритмописателям» обратно. Так что «путь умника», — я хочу сказать, техническое решение, не затрагивающее оргвопросов, — из той ситуации, наверное, тоже был.
:) Не всегда такой подход работает. Бывает что ты сам себе начальник, работаешь над исследованием чего-то нового и пока не попробуешь — не поймешь подходит один метод или другой. И какой лучше и какой быстрее. А уж начальник тем более может быть не в теме, когда у него 10 подчиненных, все работают по плану над своими достаточно общими задачами. Правильность и путь решения на плечах подопечных и пусть крутятся.
А как хотелось бы в 10 раз больше делать. :)
А как хотелось бы в 10 раз больше делать. :)
На самом деле, производительные люди, как отмечают в отзывах разные люди, имеют ещё некоторые другие свойства. Например, способность или привычка быть постоянно погруженным в задачу или круг задач. Тогда, какой бы трудной для понимания других ни была бы тема, они — в теме. Они могут написать дополнение кода с учётом ряда особенностей среды, о которых другие уже успели забыть.
Второе — так как они и в теме языка, они легче других читают чужой код и восстанавливают знания по своему коду.
Третье, есть вообще природная способность быстрее мыслить и связанный с ним показатель IQ. Но без первого (умения надолго держать тему) третье тоже мало полезно.
Ну а разборчивость и собственное мнение о ценности проекта — да, это тоже важный фактор. Хорошо, что Вы его подробно разобрали в статье.
Второе — так как они и в теме языка, они легче других читают чужой код и восстанавливают знания по своему коду.
Третье, есть вообще природная способность быстрее мыслить и связанный с ним показатель IQ. Но без первого (умения надолго держать тему) третье тоже мало полезно.
Ну а разборчивость и собственное мнение о ценности проекта — да, это тоже важный фактор. Хорошо, что Вы его подробно разобрали в статье.
Вы знаете Линуса Торвальдса, хотя Линукс — это клон Юникса, а Гит — клон Биткипера — собственно, потому что это клоны успешных продуктов, которые имели прекрасные шансы преуспеть, если бы появились вовремя.
Долго втыкал в этот кривой перевод криво построенного оригинального изречения:
You remember Linus Torvalds even though Linux is a Unix clone and git is a BitKeeper clone — in fact because they're clones of successful products which therefore had great chances to succeed due to good timing.
Последняя часть, конечно, должна звучать как ", поскольку появились вовремя", а все придаточное предложение со слова «которые» относится к слову «клоны», а не «продуктов», как можно прочитать.
статья — прекрасное руководство к действию, спасибо за перевод!
однако, когда говорят о разнице в производительности между худшими и лучшими в профессии, исходят все-таки из других предпосылок. Автор все же берет в расчет только тех, кто одинаково продуктивно может писать один и тот же код, но в общем случае это не верно.
На самом деле разница просто огромна и она не только в возможности или желании не писать «унитазный» код — всегда есть рутинные задачи, выполнять которые надо и никуда от них не денешься.
Простой пример из жизни, первое что приходит в голову: сотня картинок для проекта, надо изменить размер, или сотня текстовых файлов от заказчика — надо заметить фамилию директора и дальше уже чего-то с ними делать. Ваш джуниор кинется открывать все в редакторе и работать с каждым файлом вручную, другой отправит все назад дизайнеру или заказчику. Кто-то загонит все тексты в базу данных и поменяет все что нужно через sql-запрос. Еще один напишет программу для обработки всего этого добра. А лучший сделает все одной командой в консоли и даже никто не заметит сколько работы мог сделать кто-нибудь менее опытный. Вот и вся производительность — больше, чем в 10 раз на самом деле. А зарплата все-же в 10 раз не отличается :).
однако, когда говорят о разнице в производительности между худшими и лучшими в профессии, исходят все-таки из других предпосылок. Автор все же берет в расчет только тех, кто одинаково продуктивно может писать один и тот же код, но в общем случае это не верно.
На самом деле разница просто огромна и она не только в возможности или желании не писать «унитазный» код — всегда есть рутинные задачи, выполнять которые надо и никуда от них не денешься.
Простой пример из жизни, первое что приходит в голову: сотня картинок для проекта, надо изменить размер, или сотня текстовых файлов от заказчика — надо заметить фамилию директора и дальше уже чего-то с ними делать. Ваш джуниор кинется открывать все в редакторе и работать с каждым файлом вручную, другой отправит все назад дизайнеру или заказчику. Кто-то загонит все тексты в базу данных и поменяет все что нужно через sql-запрос. Еще один напишет программу для обработки всего этого добра. А лучший сделает все одной командой в консоли и даже никто не заметит сколько работы мог сделать кто-нибудь менее опытный. Вот и вся производительность — больше, чем в 10 раз на самом деле. А зарплата все-же в 10 раз не отличается :).
Плохая идея — говорить начальству, какую идею надо реализовывать, а какую нет. Начальник должен задачи ставить, а исполнитель (программист) — выполнять. Это основополагающий принцип предприятия, и его нарушать нельзя. Если не устраивает компетенция начальства — обычно меняют работу.
зависит от стиля управления, принятого в конторе. Часто можно попробовать переубедить. Вообще авторитарный стиль руководства в IT не часто встречается — здесь он просто не эффективен: тут не работают «от забора и до обеда».
То же самое, кстати, с заказчиком: можно пробовать показать, подтолкнуть к мысли о том, что идея плохая.
Хотя бывает, что делаешь, пишешь и проектируешь наперед зная, что все придется в конце-концов выбросить и сделать сначала и по-другому. За свои деньги заказчик может и даже вправе потребовать реализации собственных нелепых идей. Он тоже учится на своих ошибках и, кстати, за свои же деньги их и исправляет. Зато потом становится сговорчивей, больше прислушивается. А отправив подальше с первой нелепой идеей можно его просто потерять.
То же самое, кстати, с заказчиком: можно пробовать показать, подтолкнуть к мысли о том, что идея плохая.
Хотя бывает, что делаешь, пишешь и проектируешь наперед зная, что все придется в конце-концов выбросить и сделать сначала и по-другому. За свои деньги заказчик может и даже вправе потребовать реализации собственных нелепых идей. Он тоже учится на своих ошибках и, кстати, за свои же деньги их и исправляет. Зато потом становится сговорчивей, больше прислушивается. А отправив подальше с первой нелепой идеей можно его просто потерять.
вот, кстати, интересно в контексте сказанного вами.
В книге-сборнике интервью с известными программистами автор каждому задает вопрос о том, является программирование искусством или ремеслом ( Питер Сейбел, «Кодеры за работой. Размышления о ремесле программиста»).
Когда программирование считать искусством, такой подход (в смысле «Начальник должен задачи ставить, а исполнитель (программист) — выполнять») вообще скатывается чуть ли не в область неприемлемого: художнику нельзя приказать создать шедевр :).
В книге-сборнике интервью с известными программистами автор каждому задает вопрос о том, является программирование искусством или ремеслом ( Питер Сейбел, «Кодеры за работой. Размышления о ремесле программиста»).
Когда программирование считать искусством, такой подход (в смысле «Начальник должен задачи ставить, а исполнитель (программист) — выполнять») вообще скатывается чуть ли не в область неприемлемого: художнику нельзя приказать создать шедевр :).
за что минусуете? мы же не о науке или творчестве. мы о промышленном программировании, о бизнесе. об эффективности, об иерархии. Этим начальником в мое случае, например, был инженер колоссального уровня, бывший разработчик JVM из SUN. Это тот случай, когда художник говорит своему подмастерью, что нужно делать.
Я открыл библию от Макконнелла и вот что он пишет по поводу производительности в 28 главе:
Далее он подробно эту тему не раскрывает, но указывает источники где такие исследования есть
Заголовок
Далее он подробно эту тему не раскрывает, но указывает источники где такие исследования есть
В статье есть и здравый посыл и чушь.
Если бы заранее было известно, какой код отправится в мусорку, а какой нет — тут бы и сказочке конец.
Я сам был в ситуации, когда разработчик подвергались сомнению мои задачи из категории «data science» со словами «зачем писать бесполезный код?» А я и сейчас на 100% уверен, что эти задачи оказались полезны.
PS. А вот доходчиво обосновать тупиковость задачи — это полезное качество. Только не надо жаловаться про «тупых начальников». Видал я таких «умных» программистов.
Если бы заранее было известно, какой код отправится в мусорку, а какой нет — тут бы и сказочке конец.
Я сам был в ситуации, когда разработчик подвергались сомнению мои задачи из категории «data science» со словами «зачем писать бесполезный код?» А я и сейчас на 100% уверен, что эти задачи оказались полезны.
PS. А вот доходчиво обосновать тупиковость задачи — это полезное качество. Только не надо жаловаться про «тупых начальников». Видал я таких «умных» программистов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десятикратная разборчивость