Бики Ченг, веб-разработчик, основатель Professor Beekums опубликовал на dev.to статью о самом ценном опыте, которые он получил в своей карьере. Редакция techrocks.ru приводит адаптированный перевод материала.
Я проработал разработчиком более десяти лет. На протяжении этого времени я набирался опыта для того, чтобы делать свою работу лучше, чем я делал ее раньше. Я хочу рассказать об опыте, который стал ключевым в улучшении моего мышления и понимания разработки программного обеспечения.
Однажды я устроился на работу в небольшую компанию, в которой я был единственным бэкенд разработчиком, не считая технического директора. Как и во многих небольших компаниях, на мне также были обязанности системного администратора, несмотря на то, что у меня был минимальный опыт в этой области.
В какой-то момент, еще в мои самые первые месяцы работы в этой компании основной сервер MySQL накрылся. То, что технический директор был на деловом совещании, означало, что я был единственным человеком, который мог это исправить.
Да, больше никого не было.
Я знал, что каждую минуту, когда сервер не работал, мы теряем клиентов, и, соответственно, деньги — мы были продуктом для широкой аудитории.
Несмотря все то «веселье», когда я бешено гуглил «мой MySQL накрылся, что делать», чтобы исправить эту проблему, этот момент стал одним из самых переломных в моей карьере. Никто не собирался прийти и спасти меня. Мне нужно было все наладить, и у меня было право делать все, что потребуется. Не имело значения, что я никогда не сталкивался с подобной проблемой раньше и что я не обладал всеми знаниями настоящего системного администратора. В тот момент я был самым способным человеком, который был там и мог все спасти.
Я рассказываю эту историю, потому что до этого момента у меня всегда был выход. Всегда был кто-то еще, на кого я мог imitation rolex sky dweller положиться, тот, кто мог мне помочь решить сложную проблему. Я просто должен был подождать, чтобы мне помогли. Или я мог просто игнорировать проблему, пока не случилось бы что-нибудь другое, и у меня был бы предлог избежать этого. Это был первый случай, когда все те уловки были невозможны. Это был первый раз, когда у меня не было выбора, кроме как решить проблему. Это был тест на уверенность в себе.
Я встречал многих разработчиков, для которых важно обсудить с кем-то проблему. Да, они по-прежнему крутые разработчики, и мне нравилось работать с ними, но когда они сталкиваются с чем-то, что за пределами их зоны комфорта, они ждут, когда кто-то еще вступит в дело и поможет.
Хотя разработка программного обеспечения — это коллективный труд, такое особое отношение к делу снижает эффективность всей команды. Давайте рассмотрим ситуацию, когда у команды из 5 разработчиков есть 3 действительно высокоприоритетных задачи и 10 менее приоритетных задач. Похоже, все три задачи, которые extrax palm springs действительно важны, могут быть решены, правильно? Но что, если только 2 из 5-ти разработчиков на самом деле чувствуют, что могут способны сделать эти задачи?
Одна высокоприоритетная задача остается нетронутой, потому что 3 из 5-ти разработчиков решили предпочтут над менее важной, но более легкой задачей. Есть множество причин, которые оправдают их выбор. Тем не менее, ни одна из этих причин не изменит тот факт, что команда не работает таким образом, который приносил бы наибольшую пользу.
К сожалению, многие компании сегодня не могут дать разработчикам тот опыт, который мне был предоставлен случайным образом — для многих компаний это может быть слишком дорого и опасно. Я раздумывал о возможных решениях этой проблемы, например, о том, что менее опытные разработчики должны на все 100% отвечать за исполнение задач с низким приоритетом. Идея заключалась в том, что задача может и не быть исполнена, но вся компания не пострадает, а стимул работать для всех этих разработчиков по-прежнему будет высок.