Разработка
Случайные мысли о 15 годах в программной инженерии
Без особого порядка, просто делюсь некоторыми вещами, которые я узнал, и которые могут быть полезны другим.
Я работал в разных компаниях, начиная от неизвестных стартапов и заканчивая крупными компаниями из Кремниевой долины, похожими на FAANG, а также в разных других компаниях размером между ними. Без особого порядка, просто делюсь некоторыми вещами, которые я узнал, и которые могут быть полезны другим.
Отладка очень недооценена. Когда вы пишете код, вы должны думать о том, как он будет выполняться. Вы также должны думать о том, как он НЕ будет выполняться и как вы будете отлаживать его в продакшене. Оставьте себе следы для аудита, храните данные в человекочитаемых форматах и инвестируйте в средства администрирования.
Проекты опаздывают, причем очень часто. Это не уникальное явление для программного обеспечения. Реальность такова, что время постоянно работает против нас, и когда происходят неожиданные вещи, они могут занимать на порядок больше времени, чем мы планировали. А в программном обеспечении есть множество функций или систем. Приложите максимум усилий и постоянно информируйте заинтересованные стороны о ходе работы и препятствиях.
Агрессивно управляйте областью работы. В связи с вышесказанным следует защищать границы проекта. Защищайте, поскольку в ходе проекта люди будут часто пытаться что-то добавить. Вы не обязаны сопротивляться, если не хотите, но ясно давайте понять то, как это повлияет на реализацию проекта, и широко информируйте об этом. Наступательно ищите то, что можно сократить, или, что мне больше всего нравится, ищите то, что можно поставить на ПОСЛЕ запуска, и настаивайте на перенос этих работ в конец. Я люблю хорошее «fast follow«.
Стейджинг практически всегда сломан. Я вижу, как многие молодые разработчики разводят руками по поводу тестовых сред. Не поймите меня неправильно, тестовые среды — это здорово, и вы должны их использовать. Но чем крупнее становятся ваши системы, тем сложнее и сложнее поддерживать параллельную среду, которая действительно в значительной степени отражает прод. Приложите максимум усилий — но в остальном не парьтесь и не бойтесь тестировать вещи в продакшене (безопасно, фиче флаги — ваши друзья).
Действия вознаграждаются. Указывать на проблемы или жаловаться — нет.
Возьмите на себя ответственность за свои системы. Не только за свой код. Ведите себя так, как будто вы лично отвечаете за успех систем, над которыми работаете, от края и до края, end-to-end (потому что так оно и есть!).
Вы являетесь частью более крупной организации. Программное обеспечение, которое вы создаете, может быть тем продуктом, который она продает, чтобы заработать деньги, но это не значит, что ваша работа — центр вселенной. Найдите время, чтобы познакомиться с людьми из других отделов (продаж, маркетинга, финансов и т.д.) и узнать, как они мыслят и работают. Вы будете иметь гораздо более целостное представление обо всем бизнесе, и решения, принимаемые вокруг вас, будут иметь гораздо больший смысл. Это справедливо даже для самых маленьких стартапов.
Задавайте глупые вопросы. Если вы находитесь в группе людей и у вас есть вопрос по поводу того, что обсуждается, велика вероятность того, что у кого-то еще в группе есть такой же вопрос. Высказывайтесь! Задайте этот вопрос для блага команды. Никто не вспомнит, что вы задали вопрос, но вы и все остальные навсегда запомнят информацию, содержащуюся в ответе.
У вас не будет времени возвращаться назад и исправлять технический долг. Не обманывайте себя. Сделайте все возможное, чтобы свести его к минимуму заранее, и определите приоритеты, исходя из того, с чем вы готовы жить в обозримом будущем. В 99/100 случаев вы не сможете вернуться и исправить это, пока данная часть системы не потребует капитального ремонта, а вы не знаете, когда это произойдет.
Наслаждайтесь этим! Если вы похожи на меня, то работа с кодом — это весело. Иногда я до сих пор смеюсь над тем, что кто-то готов платить мне значительную зарплату за то, что я делаю то, что мне и так нравится.
На этом пока все!
