Портрет разработчика

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

??

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

Выдержка из исследования:

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

Это не всегда так, и бывают весёлые и общительные программисты, но в среднем по больнице портрет близок к реальности.

Связанные с разработкой проблемы и забавные ситуации:

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

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

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

4. пришел один разработчик / тимлид, написал / спроектировал проект — полностью или частично. По каким-либо причинам на его место позже пришел другой, и тут же озвучил страшный вердикт: всё херня, надо переделывать. И всё бы ничего, но оба они — уважаемые опытные сеньоры =)