Вы когда-нибудь беспокоились о том, что вас больше волнует, как что-то строится, а не что вы на самом деле строите?

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

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

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

• Интерактивный дизайн
• Пользовательский опыт
• маркетинг

У меня есть кое-что из того, что я узнал от людей, с которыми работал, и от замечательных проектов, над которыми я работал, но я не чувствую, что «владею» этими навыками.

Я прав? Должен ли я пытаться развивать эти навыки дальше, или они должны быть оставлены людям, которые делают это для карьеры?

Как убедиться, что вы не слишком привязаны к тому, как вы делаете что-то, и убедитесь, что вы «делаете своих пользователей крутыми»?

Кто-нибудь знает хорошие ресурсы для изучения этих навыков с точки зрения программирования?

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

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

Я работаю в небольшой компании (~ 50 человек), и мне нравится, когда я могу подойти к любому кубу и поболтать о последних вещах, которые я для них сделал / исправил. Абсолютно лучшее чувство, которое я когда-либо получал от своей работы, - это когда я слышу, как они говорят о своей работе и предлагают что-то, что решит проблему, для которой они даже не осознали, что техническое решение может существовать. Это было бы невозможно, если бы я не понимал их дела и не мог вести с ними непринужденную беседу.

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

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

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

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

Для каждой строки кода, которую вы пишете, вы вводите вероятность ошибки.

Таким образом, лучшие дизайны сводят к минимуму количество введенного кода - возможно, по принципу СУХОЙ (не повторяй себя). Однако стартапы предпочитают подход YAGNI (он вам не нужен), который намного быстрее приводит к MVP (минимально жизнеспособному продукту).

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

Некоторые материалы для чтения

Вы можете прочитать « Не заставляй меня думать », это отличная книга по дизайну пользовательского интерфейса. Кроме того, любая из книг серии Gitomer (в частности, The Little Green Book ) поможет вам приобрести навыки продаж, работы в сети и маркетинга.

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

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

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

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

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

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

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

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