Какую шляпу не должен носить программист? [закрыто]

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

Если основная роль заключается в написании программного обеспечения / кода, какие роли не должен выполнять разработчик? Есть ли?

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

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

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

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

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

Решение проблем никогда не выходит из моды.

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

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

Тестер!

Пожалуйста, присылайте нам тестеров прямо из школы тестеров, если это будет необходимо!

Без тестеров люди ожидают, что все сработает, потому что программист - это тестер, и они очень умны, поэтому он должен работать.

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

Вы должны быть осторожны, чтобы стать любителем проблем с офисным оборудованием . Это может включать устранение неполадок с ПК, администрирование сервера, резервное копирование и даже работу телефонной системы. Я допустил ошибку, упомянув свой предыдущий опыт работы с аппаратным обеспечением, и в конечном итоге мои обязанности по аппаратному обеспечению / устранению неполадок сильно противоречили моим программным обязанностям.

Программист не должен быть единственным тестером для своего собственного кода .

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

Более того, чтобы двигаться вперед, разработчики не очень мотивированы, чтобы пытаться что-то сломать, в то время как тестеры (возможно, на подсознательном уровне).

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

Два я могу придумать сразу.

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

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

Написание запросов - это хорошо, тестирование Q / A - это хорошо (и ИМО должна быть задачей программиста, если внешний отдел делает это, но сначала вы должны его протестировать). Администрирование сервера немного серое. В зависимости от того, насколько велик проект или если у вас есть выделенный администратор сервера, он может или не может быть необходим.

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

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

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

Техническая поддержка

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

Некоторые популярные из них:

• «Моя учетная запись заблокирована» или «Я забыл свой пароль»
• «Мой [телефон | клавиатура | мышь | компьютер] не работает»
• "Мой компьютер работает медленно, вы можете проверить его на что-нибудь необычное?"
• «Почему X происходит, когда я нажимаю эту кнопку? Она должна делать Y»
• «Я продолжаю получать эти всплывающие окна ....» или «Я думаю, что у меня есть вирус»
• "Этого человека больше нет здесь, ты можешь отключить все его вещи?"
• «У нас есть новый сотрудник, можете ли вы настроить его с помощью логина, карты безопасности, телефона, электронной почты и т. Д.?»

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

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

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

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

Менеджер по продажам .

Это должен делать какой-то бедняга, но это не должны быть разработчики.

Когда я стал старше, я понял, что лучше всего, если разработчики не выполняют свои собственные развертывания (я боролся с этим одним зубом). Они не должны иметь никаких прав на производственную базу данных, кроме прав выбора. Наш код стал намного менее глючным (и то же самое не возникало несколько раз, потому что изменение было внесено только в prod, и более поздняя установка dev перезаписала его снова, а затем исправила только на prod в спешке, промыть и повторить), когда мы пришлось начать давать его другим людям для развертывания, и им не позволили быстро вносить исправления в производственные изменения, потому что развертывание было не совсем правильным. Кроме того, мы прекратили эти случайные «обновления без выделенного предложения where, которое изменило каждую запись в таблице».

Художник и дизайнер интерфейса пользователя .

Большинство программистов очень плохо разбираются в художественных работах, но компании не удосуживаются платить художнику за то, чтобы он рисовал изображения и значки для своих продуктов, а просто используют «искусство программиста» - с отвратительными результатами. (До Windows Vista это был наиболее очевидный фактор различия между компьютерами Mac и ПК - компьютеры Mac выглядели красиво и дружелюбно, компьютеры - это бровь)

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

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

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

Никогда не надевайте больше «шляп», чем вы можете разумно освоить и с которыми вам удобно работать. Попытка заставить разработчиков забыть о том, что они не должны делать A или B, означает, что хороший дизайнер UI может остаться незамеченным, потому что кто-то считает, что программисты должны держаться подальше пользовательский интерфейс.

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

Кроме того, если на вас надето слишком много шляп (например, программист, дизайнер пользовательского интерфейса, тестировщик, бизнес-аналитик и т. Д.), То вы либо плохо справитесь с некоторыми из них, либо вы обожжетесь. Убедитесь, что вы знаете, сколько шляп вы можете выдержать, и постарайтесь сохранить нагрузку на этом уровне.

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

Я склонен устраиваться на любую работу, которую мне бросают, если и только если:

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

Таким образом, я в основном застрахован от своего босса, и если кто-то пойдет не так, это как минимум исправимо.

Разработчики являются заинтересованными сторонами в данной ситуации (например, клиенты, владельцы и т. Д.), Поэтому они имеют право рассчитывать на значимую работу. На мой взгляд, это означает возможность работать со своими сильными сторонами .

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

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

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

та шляпа с банками пива на стороне с соломой. плохая идея, если тебя поймают.

редактировать:

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

Виновная шляпа.