1. Введение

Интенсивное чтение на этой неделе было вдохновлено.

Автор знакомится с фронтендом уже восемь лет, наблюдал за путями развития многих фронтендеров и обнаружил, что у успешных людей похожий опыт:

Большой первоначальный технический энтузиазм -> большое количество культовых технических проектов -> переход к комплексному мышлению -> руководство командой/фокус на методологии

То есть специалистов все меньше стали интересовать технические детали. Следует отметить, что да, упомянутые здесь эксперты больше не заботятся о деталях, что не означает, что они не могут изучать детали, став экспертами, и не означает, что эксперты не понимают деталей.

Было трудно понять это изменение в первые дни. Популярность автора в школе пришла из-за глубокой работы, проделанной над передним концом. Люди, которые изучают технологию с одним ребром, не переносят песок, поэтому я не понял этого, когда я перешли на управление для каких-то старших.Они предают передок.

Однако концепция автора тоже постепенно меняется, и постепенно он развивается в сторону отвращения в начале.Я чувствую, что это не должно быть случайным, поэтому я разобрался со своими инсайтами, надеясь доказать неизбежность такого пути развития. .

2. Интенсивное чтение

Предупреждение: технические эксперты, упомянутые в этой статье, предназначены только для экспертов, изучающих технологии верхнего уровня, не включая технических экспертов нижнего уровня. В самом низу Google очень мало экспертов, и большинству из них приходится идти по пути бизнес-технологий.

Прежде всего, нужно уточнить разницу между техником и учёным: именно техник занимается технической поддержкой бизнеса, поэтому фронтенд — это технология, а не наука.

Кроме того, развитие технологий требует коммерческого продвижения, и странам без сценариев использования сложно продвигать технический прогресс, кроме науки.

Таким образом, бизнес-технологии - это путь устойчивого развития. В конце концов, каждый должен есть, и проекты, имеющие ценность для бизнеса, выживут. Только технология, привязанная к бизнесу, может выжить и распространиться.

В этой статье в трех пунктах будет объяснено, почему эксперты, кажется, уходят от технических деталей.

2.1 Значение технических деталей для отдельных лиц меняется

С увеличением трудового стажа важность технических деталей медленно снижается, а важность технического зрения медленно возрастает.

В первые дни поиска работы технические детали являются важной ступенькой

Во время окончания колледжа технические детали являются важной ступенькой, и только когда вы освоите технологию, компании захотят обратиться к вам.

Вот почему говорят, что выпускники не должны говорить о стратегии, как только они приходят в компанию, потому что время еще не пришло.

Технологии — это не наука, обычные люди могут изучить их, усердно работая.

Изучение технологий не требует очень яркого ума, если вы готовы усердно работать и обладаете хорошими способностями к пониманию, любой может разобраться в технических деталях.

То есть, нет технического порога для изучения технических деталей.С возрастом, если только накапливается содержание, которое может выучить каждый, то, когда старые знания устраняются, скорость изучения новых знаний не так высока. как у молодых людей, и они будут постепенно терять опыт.

Итак, как использовать функцию отсутствия порога, чтобы превратить его в порог? То есть в любом возрасте легко изучить технические детали, копаться в деталях, когда это необходимо, и тратить время на понимание архитектуры макросов, когда вам это не нужно.

Это воспитывать способность к эффективному обучению, чтобы иметь возможность точно судить о том, необходимо ли освоить определенную техническую деталь, при необходимости, как быстро освоить основное содержание, а не привязываться к нему после его освоения, вы можете быстро уйти и продолжайте мыслить глобально. Для такого мышления есть порог, и технические специалисты могут это сделать.

Вам не нужно разбираться в деталях, чтобы добиться цели

На первый взгляд это немного странно: как можно что-то делать, не зная деталей?

В то время как понимание технических деталей может помочь в решении задач, выполнение задач не обязательно требует понимания бизнес-деталей.

Это зависит от того, как понимать взаимосвязь между бизнесом и технологиями, например, построение «федерации данных». Может потребоваться много времени, чтобы понять технические детали различных систем хранения. На самом деле, нет необходимости разбираться во всех технических деталях. Определяется общая спецификация взаимодействия, и каждая система хранения может инкапсулировать набор интерфейсов взаимодействия, соответствующих этой спецификации.

Чтобы что-то сделать, часто требуется макротехническое мышление, и многие технические моменты должны быть связаны друг с другом. Например, действия аналогичны офицеру, руководящему сражением: цель состоит в том, чтобы выиграть войну, придумав стиль игры, а не бросаясь в атаку и измеряя ширину вражеских траншей. Забота о технических деталях — это только часть конкретных элементов реализации каждого человека, а цели технических деталей складываются для того, чтобы все происходило.

2.2 Понять реальные потребности бизнеса в технологиях

Бизнес рассчитывает реализовать функции с помощью технологий, поэтому техническим специалистам нужно сделать так, чтобы лучше реализовать бизнес-требования, а это означает, что понимание бизнес-требований является наиболее важной способностью. Представьте себе человека, который не может понять, что собирается делать бизнес, даже если он понимает больше технических деталей, это не представляет ценности для бизнеса.

Бизнес-мышление — это решение проблем, техническое мышление — это создание проблем.

Люди с техническим складом ума, как правило, увлекаются решением нереалистичных задач или задач, которые решили другие. Такое мышление очень полезно для технического обучения, но если такое мышление нельзя изменить в течение длительного времени, оно не создаст никакой ценности для компании.

Люди с деловым мышлением должны сначала понять бизнес. Только путем понимания бизнеса и после правильного бизнеса они могут иметь уверенность в будущем и знать, что их усилия могут быть обменены на возврат.

После того, как вы поймете бизнес, вы будете знать, как использовать технологии, чтобы помочь бизнесу добиться успеха.

Например, в начинающей компании видение босса очень точное, время для входа — раннее, а рынок — голубой океан. После анализа вы обнаружите, что, если вы используете зрелую технологическую структуру для быстрой итерации, чтобы помочь бизнесу занять рынок, вы можете помочь бизнесу завоевать рынок в краткосрочной перспективе. Однако возможности настройки этого фреймворка невелики, и если появятся новые требования, может потребоваться время для его рефакторинга. В это время люди с техническим мышлением будут рассматривать только ремонтопригодность кода и предлагать набор самостоятельно разработанных фреймворков, в то время как технические эксперты с бизнес-мышлением решат использовать зрелые технологии для быстрого создания прототипов, а затем реконструировать их после того, как бизнес станет стабильным.

Конечно, конкуренция на интернет-рынке сейчас очень жесткая, и голубой океан с низким техническим порогом в основном превратился в красный океан.Упомянутые выше сценарии могут быть относительно редкими.Что нам нужно принять больше решений, так это то, будет ли доход бизнес в ближайшие несколько лет стоит ресурсов R&D, вложенных сейчас.

Два человека, которые могут писать фреймворки, не так хороши, как один человек, который может принимать решения.

Еще один простой пример: если технические специалисты сосредоточатся только на технических деталях и хорошо разберутся в реализации различных интерфейсных фреймворков, каждый сможет создавать элегантные, простые в использовании и сопровождении продукты, а также у них есть свои «фичи». или колесами, то команда может легко ввязаться в техническую схватку, в которой стычки двух экспертов решают, что делать головой. В этом случае выработка двух технических специалистов даже не так велика, как у стажера, ведь стажер напрямую использует open source фреймворк для начала работы, в 99% случаев надежность хуже, чем построенное колесо специалистом по фронтенду.

С другой стороны, на данном этапе слишком много людей могут писать фреймворки React и Vue во внешнем мире, и слишком много фреймворков, подобных React и Vue, уже написано. Подавляющее большинство проектов, которые сделаны для практики, удаляются, и подавляющее большинство из них действительно хотят продвигать его для использования другими Это типичная проблема в мире открытого исходного кода: повторяющееся низкоуровневое создание колеса не требует причине, и он не должен нести ответственность за его продвижение для вашего использования. Поскольку фреймворк является виртуальным активом Интернета, граничная стоимость равна нулю, что определяет, что рынок фреймворков должен быть большим олигополистическим рынком, и аналогичные проекты не могут разделить кусок пирога через какие-то безобидные функции. Так что даже если в группу структуры компании набрать 10 человек, умеющих писать фреймворки, в итоге остается только две возможности: либо структура раздувается, и каждый добавляет свои кредиты, либо выбирают худшее решение, которое не будет Ущерб выгоден любому архитектору.

Так что теперь компании более склонны взращивать таланты внутри компании, потому что внутренние люди понимают, что нужно бизнесу, и создаваемая ценность часто выше, чем у архитекторов, находящихся в воздухе.

Широкое техническое видение облегчает использование

Теперь, когда технических моментов становится все больше и больше, если вам нужно подробно разбираться в технических деталях, в конце концов у вас не должно быть хорошего общего видения. Лучшее состояние — найти несколько ключевых моментов для глубокого понимания, а другие технические моменты будут рассмотрены более подробно после освоения общего технического видения.

В первые дни существования Интернета, когда многие технические основы были несовершенны, заимствование технологий не имело большого значения, в конце концов, было не так много доступных вещей.

Но сейчас передние и задние технологии и колеса уже завораживают, и люди, которые могут освоить эти существующие технологии, постепенно становятся более ценными, чем те, кто может до конца разобраться в некоторых технических деталях. Отличный эксперт должен быть в состоянии быстро определить, существует ли зрелое техническое решение для решаемой бизнес-проблемы, и как его достичь с наименьшим соотношением затрат и результатов, сохраняя при этом хорошую ремонтопригодность и адаптируясь к обслуживанию бизнеса.

2.3 Невозможно стать экспертом только с хорошей техникой

Технические эксперты от имени технических барьеров действительно сильный человек? Да, но только технических возможностей недостаточно.

Почему проекты с открытым исходным кодом ищут соавторов позже?

В первые дни моего проекта с открытым исходным кодом все фреймворки и исходный код были практическими, и я чувствовал, что у меня есть лучшие идеи, чем у других фреймворков. На начальном этапе участвовало несколько контрибьюторов, и я, конечно, не хотел, чтобы другие контрибьюторы участвовали, ведь они не понимали концепции дизайна, и меня могли удовлетворить только мои собственные модификации.

Кто лучше автора знает свои проекты с открытым исходным кодом? Тогда почему крупномасштабный проект с открытым исходным кодом работает на более позднем этапе, и его в основном поддерживают сотрудники?

Поскольку открытый исходный код — это систематическая вещь, если вы хотите поддерживать его в течение длительного времени, вы должны создать хорошую систему документации, чтобы ваши идеи можно было копировать и другие могли участвовать. Если вы единственный, кто разбирается в проектах с открытым исходным кодом, то когда вы будете поддерживать два, четыре или шесть одновременно, вы обязательно обнаружите, что не в состоянии это сделать.

Что касается некоторых богов с открытым исходным кодом, которые поддерживают сотни или даже тысячи репозиториев, за ними должно быть больше участников. исходные проекты одновременно. Вы должны быть непредубежденными, чтобы позволить большему количеству людей присоединиться к вам и дать участникам чувство выполненного долга и чести, чтобы они продолжали вносить свой вклад в проект.

Способность вызывать ресурсы, чтобы стать экспертом

Мир с открытым исходным кодом — это игра, в которой проекты привлекают внимание. Предполагая, что общее количество людей в сообществе с открытым исходным кодом составляет 100 человек, ваш проект может привлечь 10 человек для просмотра, 5 человек для использования, 2 человека для внесения вклада, и он в основном выживет. Сообщество с открытым исходным кодом насчитывает не менее 100 проектов, а общего количества людей в сообществе недостаточно для поддержки каждого проекта, и только проекты, получившие достаточно внимания, могут оставаться вечнозелеными.

То же самое верно и в компании: должности выше уровня эксперта потребуют навыков совместной работы, и люди, которые могут мобилизовать ресурсы вокруг себя или даже других отделов, могут играть большую роль в компании.

Генеральный директор мобилизовал ресурсы всей компании с помощью дизайна верхнего уровня, в то время как президент бизнес-направления мобилизовал людей всего бизнес-направления путем демонтажа задач, путем демонтажа целей на каждом уровне и обеспечения полной мобилизации каждого уровня. все ресурсы следующего слоя, компания может эффективно работать.

Если вы всегда заботитесь о технических деталях, вы всегда будете изолированным узлом, самым низким уровнем в любом измерении организации, даже если вы не будете спать 24 часа, вы будете считаться максимум двумя человеческими ресурсами. Если вы хотите преодолеть ограничение в 24 часа в сутки, вам нужно потратить время на то, чтобы другие согласились с вашим замыслом, и усердно работать в одном направлении. как поручать другим. Если задача запутана и оказывает негативное влияние на компанию, то ответственное лицо возьмет на себя вину.

3. Резюме

Подводя итог, смысл этой статьи таков:

1. Технические детали несложно изучить, и лучше узнать больше, когда вам нужно углубиться.
2. Хотите сделать вещи, вам нужно более широкое техническое мышление, поэтому эксперты становятся все более и более широкому зрением, отличным рисунком.
3. У экспертов есть возможность быстро изучать технические детали, но это не является их основной конкурентоспособностью, поэтому более ценно писать статьи о технических деталях, таких как написание методологического мышления.
4. Указывать направления важнее, чем ходить пешком, и эксперты должны постепенно становиться проводниками.
5. Технологии в конечном счете служат бизнесу, и понимание технических деталей не обязательно связано с тем, чтобы позволить бизнесу победить первым.Поэтому, прежде чем углубляться в технические детали, необходимо понять бизнес, уловить направление и предотвратить проблемы маршрутизации в технической сфере. подробности.

Адрес обсуждения:Интенсивное чтение «Почему эксперты не заботятся о технических деталях» · Выпуск №153 · dt-fe/weekly

Если вы хотите принять участие в обсуждении, пожалуйста,кликните сюда, с новыми темами каждую неделю, выходящими по выходным или понедельникам. Интерфейс интенсивного чтения — поможет вам отфильтровать надежный контент.

Сфокусируйся наАккаунт WeChat для интенсивного чтения в интерфейсе

special Sponsors

• Платформа полного процесса DevOps

Заявление об авторских правах: Бесплатная перепечатка - некоммерческая - не производная - сохранить авторство (Лицензия Creative Commons 3.0)