Comments 12
Не соглашусь. Во-первых, описаны обе стороны медали — возможно, вы не дочитали до конца. Во-вторых, на моём опыте, описанная проблема абсолютно реальна и приводит к застою в компаниях.
Я напасал модуль в проекте. Это долг?
Нет, "долг знаний" не зависит от того, написали вы модуль или не написали. Он возникает, согласно автору, когда доступные технологии/знания расширились, но вы о них не в курсе.
Я использовал библиотеку. Уже могу нанимать людей со знанием либы?
Конечно, можете. Автор указывает, что, при прочих равных, вам будет выгодней взять человека, который владеет еще и другими либами, или сможет освоить вашу библиотеку достаточно быстро, как и любую другую, а не человека, знающего хорошо только её.
Но описания проблемы нет.
Я вас не очень понимаю. В статье описана проблема, и описаны способы её решения.
превратится в что-то наподобие компаний, использующих Enterprise Java в наши дни.
А что не так с Enterprise Java?
> Компания должна нанимать людей, умеющих решать проблемы, программировать и которые впишутся в коллектив, а не обладающих специфическим набором знаний
суперправильно, настоящий профессионал освоит любую технологию и будет выдавать хороший результат
суперправильно, настоящий профессионал освоит любую технологию и будет выдавать хороший результат
Но у такого подхода есть фундаментальный недостаток. Компания должна нанимать людей, умеющих решать проблемы, программировать и которые впишутся в коллектив, а не обладающих специфическим набором знаний.
Вы в самом же начале сказали самую правильную вещь, хотя и противоречащую заявленной теме абсолютно. И обществу и разработчикам наплевать (по крайней мере, должно быть), насколько модные технологии используются в каком-либо продукте, пока этот продукт решает проблему. Нет никакого долга знаний, если вы используя удобную для себя технологию решаете нужные вопросы.
Ну, для начала — это перевод. :) (тут не сильно явно видно где перевод, а где авторская статья, да).
И, хотя, вы говорите, в принципе, верную вещь, но тут подводит само определение того, что значит «продукт решает проблему». Печатная машинка решает «проблему» журналиста, но ультрабук решает её гораздо лучше. Но если журналист привык к печатной машинке, равно как и его компания, и они не знают про ноутбуки, то их долг знания и будет велик, и они будут уверены в том, что используют удобную для себя технологию, решающую нужные вопросы. (пример намеренно утрирован, для демонстративности)
И, хотя, вы говорите, в принципе, верную вещь, но тут подводит само определение того, что значит «продукт решает проблему». Печатная машинка решает «проблему» журналиста, но ультрабук решает её гораздо лучше. Но если журналист привык к печатной машинке, равно как и его компания, и они не знают про ноутбуки, то их долг знания и будет велик, и они будут уверены в том, что используют удобную для себя технологию, решающую нужные вопросы. (пример намеренно утрирован, для демонстративности)
О, про перевод и не заметил, точно. Тогда вопрос перенаправляется автору оригинала:)
Пример действительно утрирован, потому что зависит от того, какую проблему решают этой печатной машинкой:) Если «быстро напечатать немного текста для себя» — вполне. А если «издавать еженедельник с тиражом в 100тыс копий», то это совсем другое. И для каждой задачи свой инструмент.
А если мы три года делаем готовый продукт на LAMP, а тут к нам приходит хипстер и говорит «вы чо такие унылые консервы, всё переписываем на Rust!», то его закономерно пошлют по известному адресу в абсолютном большинстве живых примеров:)
Пример действительно утрирован, потому что зависит от того, какую проблему решают этой печатной машинкой:) Если «быстро напечатать немного текста для себя» — вполне. А если «издавать еженедельник с тиражом в 100тыс копий», то это совсем другое. И для каждой задачи свой инструмент.
А если мы три года делаем готовый продукт на LAMP, а тут к нам приходит хипстер и говорит «вы чо такие унылые консервы, всё переписываем на Rust!», то его закономерно пошлют по известному адресу в абсолютном большинстве живых примеров:)
Естественно, что хипстеры, которые тянут незрелый и неоправданный инструментарий в прод — это тема для отдельной статьи. Но если команде внезапно понадобится шустрый микросервис-числомолотилка, а команда вся набрана под LAMP, то они и будут делать его на PHP, теряя в продуктивности и ещё больше подвязывая себя на именно этот стек.
Ээ… что за компания (какой бизнесс, что в нем делает IT), зачем ей инвестировать в кучу технологий, в чем преимущество широкого профиля? Все эти вопросы в статье никак не поднимаются.
В итоге получается какой-то сферический конь в вакууме, который зачем-то кому-то нужен.
В итоге получается какой-то сферический конь в вакууме, который зачем-то кому-то нужен.
Даже не знаю как вам ответить. Именно эти вопросы в статье и поднимаются.
Технологии — это инструменты, которыми компания решает свои бизнес-задачи. Если компания владеет только одним инструментом, всё сильнее на него подвязывается и не прилагает усилия, чтобы осваивать другие инструменты, которые потенциально могут сделать её продуктивнее, то она и не будет продуктивнее, а будет отставать, проигрывать на рынке и терять хороших людей.
Технологии — это инструменты, которыми компания решает свои бизнес-задачи. Если компания владеет только одним инструментом, всё сильнее на него подвязывается и не прилагает усилия, чтобы осваивать другие инструменты, которые потенциально могут сделать её продуктивнее, то она и не будет продуктивнее, а будет отставать, проигрывать на рынке и терять хороших людей.
Sign up to leave a comment.
У вашей компании есть долг знаний