Хотя это не исчерпывающий список, это также не список требований.
Многие черты противоречивы. На самом деле, наиболее привлекательным является их баланс.
Вы редко встретите их в одном человеке, что и делает создание команд таким интересным.
Одному человеку сложно описать следующие черты в идеальном равновесии, но легче нанять или сформировать команду, которая проявляет их в совокупности.
Это часто лучше, поскольку отдельные крайности часто могут сотрудничать, чтобы произвести продукт, который лучше, чем группа, существующая на медиане.
Тем не менее, весь этот пост следует воспринимать с недоверием.
Как и все в программном обеспечении, это мнение одного человека, основанное на его опыте, который, вероятно, отличается от вашего собственного.
Непоколебимая уверенность в себе
Давайте будем откровенны, как разработчики программного обеспечения мы создаем новые миры из собственного воображения.
Чтобы просто предпринять эти усилия, не убегая от страха, нужна хоть капля уверенности в себе.
Чтобы сделать это для большей части системы, на которую полагаются другие люди, требуются значительные усилия.
Для этой небольшой части вселенной вы являетесь богом, властелином всего, что вы исследуете, и вас будут постоянно спрашивать, почему все обстоит именно так.
Если вы доброжелательный бог, почему пользователи не могут хранить свой любимый вкус пончика? Неужто мудрый и справедливый бог допустит такое ?!
Такую уверенность обычно можно заработать с трудом, пройдя путь от младшего разработчика до ведущего разработчика (или любого другого названия, которое может использовать ваша компания).
На каждом этапе пути кто-то более старшего возраста должен оспаривать каждое ваше решение, не обязательно потому, что они думают, что оно неверно, но чтобы помочь вам понять, почему вы считаете его правильным.
Ваша уверенность в себе станет непоколебимой только благодаря тому, что вы с трудом выиграете свои знания и пройдете испытания в битвах.
Непоколебимая неуверенность в себе
В той же мере, в какой вам нужна уверенность, чтобы заявить, что вода - это вино, вам необходимо иметь определенное сомнение в том, что вы правильно реализовали алгоритм преобразования воды в вино.
Уверенность - очень мощная вещь, но, необузданная сомнениями, она может быть введена в заблуждение и причинить больше вреда, чем того стоит.
Без сомнения, зачем вам писать тесты? Наверняка вам не понадобится проверка, что ваш код работает с полной уверенностью?
Сокрушительное смирение
Смирение - это клей, который объединяет уверенность в себе и неуверенность в себе.
Это то, что позволяет вам подходить к коллегам с позиции: «Я на 99% уверен, что это лучший путь вперед, но мне действительно нужны ваши мысли по этому поводу».
Начать разговор с фразы «Я не совсем уверен, что делать» - это рецепт долгого разговора.
Уверенность в себе, позволяющая начать разговор с определенной точки зрения, помогает сократить его.
Неуверенность в себе и смирение, чтобы попросить о разговоре, помогают улучшить ваше мышление.
Смирение и готовность признать свою неправоту во время разговора помогает достичь наилучшего результата.
Чрезмерно полезно
Будь то младший разработчик, который изучает основы, клиент, у которого проблемы с использованием системы, за которую вы отвечаете, или коллега, который задается вопросом, как что-то работает, по умолчанию вы должны сделать чей-то день лучше.
Очень часто все люди, не входящие в команду разработчиков, слышат «нет».
Стоит использовать любую возможность сказать «да» и облегчить или улучшить ситуацию. Это также придает больший вес вашему «нет», поскольку вы будете единственным человеком, который обычно говорит «да»!
Если вы принимаете решение между тем, чтобы быть слишком полезным, и отказом в просьбе, всегда ошибайтесь в том, чтобы быть слишком полезным. Никогда не знаешь, когда тебе понадобится одолжение, чтобы отплатить им натурой.
Сильно чуткий
Это в некоторой степени относится к тому, чтобы быть полезным, но если бы была одна черта, которую я бы выделил выше всех остальных, это была бы она.
Лучшие разработчики, которых я знал, всегда были более осведомлены о системе, над которой они работают.
Иногда им будет предоставлен контекст, в котором они нуждаются, иначе они спросят: «Почему это важно?» снова и снова и снова, пока они не поймут основную мотивацию.
Это не потому, что они не согласны с изменением, а потому, что они хотят глубоко понять, почему это изменение было сделано. Они понимают, что являются катализатором для компании, в которой работают, и хотят быть максимально эффективными.
Как разработчик вы часто занимаетесь уникальным пониманием того, на что способна система.
Часто к вам обращаются с предложениями по реализации не сформулированной проблемы.
Только сочувствие поможет вам выявить решаемую проблему, что может привести к гораздо лучшему решению.
Здоровый уровень паранойи
Эффективные разработчики знают, что кто-то всегда готов помочь вам.
Даже если вы глубоко понимаете проблему, сотрудничали со своими коллегами, чтобы реализовать оптимальное решение, и реализовали его безупречно, кто-то пытается найти способ какать на вашем параде.
Вот почему мы защищаемся от SQL-инъекций, межсайтовых сценариев, блокируем все возможное и т. Д.
Это не в первую очередь потому, что мы не доверяем другим людям, а потому, что мы никому не доверяем, даже себе.
Хуже всего то, что парадом, скорее всего, будешь ты сам.
Через шесть месяцев у вас может появиться сильная мотивация изменить то, как что-то реализуется, из самых лучших побуждений.
Однако без достаточных мер безопасности, установленных вами в прошлом (тесты, документация и т. Д.), Вы можете нечаянно испортить свой собственный парад, нарушив существующие функциональные возможности.
Очень любознательный
Лучшие разработчики не просто знают, как работает их собственный код, они понимают, как работают библиотеки и среды выполнения, лежащие в его основе.
Обычно это происходит из-за необходимости понять, «как делается колбаса». Хорошее понимание пары уровней абстракции ниже уровня, на котором вы работаете, часто помогает вам писать лучший код на уровне абстракции, над которым вы работаете.
Наиболее частые случаи этого - понимание того, какие вызовы будут и не будут приводить к внешним вызовам, понимание того, какие закономерности приводят к чрезмерному выделению памяти или объектов, что, в свою очередь, приводит к раздуванию или сборке мусора.
Мне нравится термин, который я впервые услышал от Мартина Томпсона для этого: механическая симпатия. Многие подходы могут работать, многие из них могут быть простыми в обслуживании, но часто будет один, который особенно благосклонен к используемой вами библиотеке, среде выполнения, в которой вы выполняете, или оборудованию, на котором вы развертываете.
Только понимая более широкую картину, вы можете выбрать подход, который будет более благожелательным, чем другие, и пожинать плоды.
Упорство
Разработка программного обеспечения - это интеллектуальная задача, которая может стать настоящим испытанием для вас.
Есть максимум возможностей поставки столь необходимой функции, минимум поиска ошибок, минимум функций, которые оказываются невыполнимыми с учетом бюджета, минимум часов на поиск ошибок, минимум определения того, почему что-то работает только на вашем компьютере. , минимумы отставания растут быстрее, чем вы можете его реализовать, минимумы обыденных изменений копий и другую такую тривиальную работу, которая становится только тривиальной после многих лет измельчения, минимумы ...
Вообще-то, это довольно дерьмовые американские горки.
Вот почему настойчивость является ключевым моментом.
Вам часто приходится пробираться сквозь ямы отчаяния или печали.
Но иногда будет что-то, какие-то изменения, которые вам нужно будет сделать, какая-то функция, которую вам нужно будет реализовать, будет настолько легко, основываясь на предыдущих 6 месяцах упорной работы и дисциплины, что вы будете в восторге.
Настолько, что вы сможете встретить следующие 6 месяцев убийства крипов до следующего раза.
Беззаботность
Разработка программного обеспечения может быть очень серьезной.
Это двоичный мир, нули и единицы, черное и белое, правильное и неправильное.
Но многое из этого субъективно: кто-то прав может быть неправым, а напряженность может возрасти.
Простые ошибки могут разрушить мир, стабильные системы могут спонтанно загореться, атаки ниндзя могут произойти в любое время, и эти ниндзя тоже могут загореться.
К разработке программного обеспечения следует отнестись серьезно, но с ней нужно противопоставить немного юмора; немного подшучивания.
В противном случае все становится слишком серьезным, люди испытывают стресс, они перестают получать удовольствие, и тогда они не смогут сосредоточиться на текущей задаче.
Чтобы снять напряжение, не нужно много времени - хорошо подобранный GIF-файл, идеальный смайлик или обмен забавной ссылкой.
Это может быть все, что нужно, чтобы все не перекипело.
Это просто набор нулей и единиц в конце дня.
Хорошая память для предыдущих ошибок
Эффективные разработчики стараются не повторять одну и ту же ошибку дважды.
Вы часто обнаруживаете, что в их личных делах есть практики, которые помогают им избегать их.
Например, написание тестов, документирование аргументов в пользу определенных вещей, использование инструментов кода и так далее.
Небольшие ошибки легко сделать, но все же потребуется время, чтобы их исправить.
Если вы можете создать процесс или использовать инструмент, который поможет вам избежать мелких ошибок, больше вашего внимания будет свободно, чтобы избежать более крупных и дорогостоящих.
TL;DR
Эффективный разработчик часто имеет следующие черты личности:
- Непоколебимая уверенность в себе
- Непоколебимая неуверенность в себе
- Сокрушительное смирение
- Чрезмерно полезно
- Сильно чуткий
- Здоровый уровень паранойи
- Очень любознательный
- Упорство
- Беззаботность
- Хорошая память для предыдущих ошибок
Какие черты характера попали бы в ваш список? "Дайте нам знать".
Изначально этот пост был размещен в блоге Cronofy. Загляните туда, чтобы узнать больше о разработке программного обеспечения, жизни стартапов и API календаря.
И, если вы поклонник Trello, не забудьте проверить наше новое Включение коннектора календаря Trello.
