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

29

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

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

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

Spong
источник
20
Капот ... ой, подождите ..
ChaosPandion
21
ИМО программист не должен носить один из этих больших мексиканских сомбреро, потому что край будет продолжать биться о монитор.
Мейсон Уилер
1
@Peter Turner: «Самая крутая шляпа программиста» станет одной из тех новинок, на которые установлены две банки с пивом. Только пива нет. Красный Бык.
BlairHippo
4
Черт. Такое многообещающее название ...
Никто
4
@ Мейсон, удерживая сомбреро над монитором, защитите от бликов на глянцевых экранах. Другими словами - техника.

Ответы:

54

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

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

BlairHippo
источник
7
ЭТО. Если серьезно, то, что я работаю на компьютерах, не означает, что я могу исправить инфраструктуру. Вы просто тратите время разработчиков.
Жак Преториус
5
+1 урон, который может нанести системный администратор-любитель, огромен.
Давидтбернал
И если вы получите шляпу сисадмина, они могут также надеть вам шляпу менеджера, которую следует избегать любой ценой.
HLGEM
3
ОТО, я работаю в компании с невероятно некомпетентным и вялым ИТ-отделом. Чего бы я не дал, чтобы иметь возможность вносить изменения в свой собственный брандмауэр ...
Гейб Моутарт
1
Кто-то указал, что мой босс не был одет, но сказал им, что он испачкается с пола, настраивая компьютеры. Они указали на меня, указывая, что я должен делать это. Я чуть не перепрыгнул через их стол и задушил их, но я отпил кофе и сказал, что не занимаюсь железом.
Джеффо
35

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

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

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

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

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

Крис Холмс
источник
5
@Josh: я думаю, что это будет одна из тех ситуаций "найти новую работу".
Адам Лир
21
Просто будь осторожен с этим. Боссы, как правило, используют тех, кто готов на все. Просто убедитесь, что вы получаете компенсацию правильно.
Тони
5
Я не думаю, что Крис говорит «делай что-нибудь» (ну, он немного в конце; я не принесу кофе тем, кто не приносит мне напитки тоже), но говорю: «Я разработчик, я не будет менять картридж принтера "просто издеваться.
Питер Боутон
10
Я не согласен. Легко сказать, что разработчик должен иметь возможность делать все, что ему требуется, но это не значит, что он ДОЛЖЕН. В этих ситуациях возникают серьезные проблемы с конфликтом интересов. Я не хочу , доступ к производственным системам , потому что я буду быть обвинен , когда они идут вниз ( «ой, ну XXX был там в прошлом месяце, так что я уверен , что он испортил что - то , потому что он это DEV, а не администратора»)
MBonig
7
-1; здесь есть доля правды, но у этого мышления есть некоторые серьезные ограничения, которые этот ответ не делает достаточно, чтобы признать. Как насчет того, когда истинная основная проблема заключается в том, что ваш работодатель сосет в управлении персоналом? Однажды я наблюдал, как рухнул офис, потому что руководители настаивали на том, чтобы придумывать умных, способных инженеров на роли, которые они ненавидели и выполняли очень плохо. Иногда говорят "Нет!" это лучшее, что вы можете сделать для себя и своего работодателя.
BlairHippo
29

Тестер!

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

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

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

Питер Тернер
источник
4
Хорошие преданные тестеры определенно недооценены!
Питер Боутон
3
Собачья еда!? Я готовлю только пять звездных лобстеров! ... и поэтому мне нужен тестер, чтобы сказать мне, когда я что-то напортачил. Я сделал вещь и знаю, как она работает. Никто из тех, кто создал пользовательский интерфейс, никогда не может его тщательно протестировать, просто потому, что он знает, как он работает, а не как он работает с тем, кто этого не делает.
Морган Херлокер
15
Нет ничего плохого в том, чтобы быть тестером в целом. Неправильно быть единственным тестером ВАШЕГО СОБСТВЕННОГО кода. Программисты программируют с учетом ряда предположений, и, если тестировщик имеет идентичные предположения, они не будут выполнять неожиданные части и пропустят много ошибок.
ДБКК
5
Тестирование вашего собственного кода - это определенно большое нет-нет. Программист может охватить множество других вещей, но реальное функциональное тестирование (если вы не проводите модульное тестирование, вы все равно не можете быть программистом) вашего собственного кода - очень плохая идея. Собака с этим хорошо, ум.
Гленатрон
3
+1 - программисты думают совершенно иначе, чем непрограммисты с точки зрения того, как использовать программы. Вы когда-нибудь обнаружили ошибку в пункте меню «Файл -> Сохранить»?
26

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

Джон Онстотт
источник
Скажите преступникам, что им нужно разрешение от вашего босса, и зарегистрируйте все время, использованное для этого.
@Thor Направление работы над аппаратными средствами от моего босса. Это было полезно для офиса, но я не мог сосредоточить свою карьеру на программировании так, как мне бы того хотелось.
Джон Онстотт
@ Джон, если босс говорит, что тебе нужно это сделать, ну ... тебе нужно сделать это. Затем вы можете обсудить с ним, является ли это удовлетворительным или нет, и если вы не можете прийти к соглашению, пришло время уйти.
+1 То же самое случилось со мной. Они хотят, чтобы я не только писал код, но и имел дело с сетевыми проблемами, а также с поставщиками браузеров, и это вызвало большой стресс.
Богатое
16

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

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

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

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

dbkk
источник
10

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

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

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

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

Джош К
источник
7
Что касается пункта 2, то есть, по крайней мере, одна компания, основополагающим принципом которой является то, что человек, пишущий код, должен разговаривать напрямую с клиентом: дезинтермедиация имеет свои преимущества.
Фрэнк Шиарар
10

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

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

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

tcrosley
источник
2
+1 Договорились, что тестирование QA разработчиками, которые его написали, побеждает цель.
Спонг
2
@JoshK Некоторое тестирование QA может быть выполнено разработчиками, но основное тестирование QA должно быть сделано другими. Если вы протестируете свое собственное приложение, которое вы написали, вы подсознательно обойдете любые потенциальные проблемы. Дело в том, чтобы обнаружить проблемы, которые разработчики не могут найти, своего рода свежий взгляд, так сказать.
Спонг
2
@JoshK @ChaosPandion Согласен, предварительное тестирование разработчиками должно быть выполнено, но ему нельзя доверять, таким образом, проводится отдельное тестирование QA теми, кто его не разрабатывал.
Спонг
5
-1: я не согласен с тем, что программисты не должны разрабатывать графический интерфейс. Я проработал 8 лет в небольшой компании и разработал весь пользовательский интерфейс. Я всегда следовал отличным руководствам по дизайну от Microsoft и прочитал пару книг по дизайну HMI. Мы передали сторонним иллюстраторам только графику.
Wizard79 29.09.10
3
Одна вещь, которая меня беспокоит, это то, что графические разработчики лучше подходят для разработки пользовательского интерфейса, чем программист. Возможно, ваш графический художник очень хорош в разработке интерфейсов, но в общем случае он может выродиться в запутанный, непригодный, симпатичный интерфейс в противоположность запутанному, едва используемому, уродливому интерфейсу, который вы получите от стереотипного программиста.
Дэвид Торнли
8

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

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

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

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

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

user281377
источник
5

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

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

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

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

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

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

Дэн Рэй
источник
4

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

HLGEM
источник
Да, да и да. Никогда не предоставляйте разработчикам никакого доступа к производству и очень ограниченному (и желательно никому) этапу. Если ни для чего другого это не уменьшает стресс, которому они подвергаются.
ElGringoGrande
1
Да! Я разработчик, и я не хочу иметь доступ ко всем этим продуктам. И с другими людьми, занимающимися развертыванием программного обеспечения, это еще один тест процесса развертывания. (И, возможно, из-за этого также улучшится восстановление после стихийного бедствия.)
съеживаться
3

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

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

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

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

Джейсон Уильямс
источник
2
«Большинство программистов очень плохо разбираются в artwook», а «многие программисты не очень заинтересованы» - это не то же самое, что «ни один программист не заинтересован» и «все программисты плохие». Я на самом деле знал пару, которая неплохо справляется с этим.
МВД
1
@ Джим Леонардо: Действительно. Вот почему я сказал «большинство» и «много», а не «все». :-)
Джейсон Уильямс
3

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

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

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

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

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

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

rjzii
источник
1

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

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

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

Аудрюс
источник
1

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

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

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

Ingvald
источник
1

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

wildpeaks
источник
0

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

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

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

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

Джонни
источник