Командный прагматизм и инженерия
Когда дело доходит до любого типа разработки — мне все равно, для Интернета, для мобильных устройств или для какой-либо другой платформы — существует множество книг, онлайн-курсов и т. д., которые невероятно упрощают изучение чего бы то ни было. это вы хотите учиться.
Чтобы было ясно, я также не отказываюсь ни от одного из доступных способов обучения. Ведь все мы учимся по-разному, верно? И кто я такой, чтобы говорить, какой способ лучше любого другого, особенно учитывая тот факт, что я ежедневно пишу на темы здесь и на других сайтах?
Но я могу определенно сказать за себя — человека, которому нравилось учиться в рамках формального образования, учебных пособий, курсов и т. д. — лучший способ получить опыт в этой отрасли — это два пути:
- работа с другими людьми,
- ломать вещи и учиться их чинить.
Я имею в виду делать это в этом конкретном порядке? Неа. Означает ли это, что я на дрожжах впереди других? Это смехотворно.
Но поскольку я имел удовольствие работать с другими над несколькими проектами, общаться с другими через Twitter, на конференциях и так далее и испытал как хорошее, так и плохое, я думаю, что каждый должен иметь возможность сделать это в какой-то момент.
Если бы мне нужно было обобщить это, я бы сказал, что речь идет о поиске баланса командного прагматизма и инженерии. Но почему, если ничего из вышеперечисленного не ново (учитывая, что софтверные компании существуют уже несколько десятков лет), я потрудился написать об этом сейчас?
Командный прагматизм и инженерия
Вероятно, я мог бы составить длинный список причин, почему я считаю эту конкретную тему важной, но есть три конкретных вещи, которые я хотел бы упомянуть в этом посте. И ради длины (читай: времени) я сделаю все, что в моих силах, чтобы они были короткими.
Фактически, TL;DR того, о чем я собираюсь рассказать, имеет отношение к прагматизму и инженерным навыкам. Первоначально я также собирался включить точку зрения на бизнес в целом, но это немного отвлекло общий пост от темы.
1 Прагматизм
Я уже писал о балансе инженерии и прагматизма . Так что, возможно, мне нечего предложить в плане чего-то нового, но я начинаю немного менять свою точку зрения.
То есть в какой-то момент речь шла строго о поиске баланса между поиском решения, которое работает для клиента, хорошо построено и решает их проблему. И я до сих пор подписываюсь под этим.
И, конечно же, есть что сказать о том, как организован код, чтобы его можно было поддерживать с течением времени. Это ключ. Но то, как строится код, пишется и строится решение, может стать немного более размытым с точки зрения прагматизма.
То есть легко написать базовый объектно-ориентированный код, задокументировать его, заставить несколько классов или функций вызывать друг друга, подключиться к WordPress, а затем положить этому конец.
Но является ли этот уровень баланса между поставкой решения и архитектурой решения — это тонкая грань, которую нужно пройти. Я считаю, однако, что в попытках быть слишком прагматичным есть опасность: если вы стремитесь все время оставаться как можно более прагматичным и оставлять свои инженерные навыки на определенном уровне, вы можете не продвинуться как разработчик.
Хотя я предпочитаю использовать объектно-ориентированное программирование в своей работе, я не из тех, кто ввязывается в религиозную войну или выбирает версию какого языка, какой технологии, функционального, процедурного или объектно-ориентированного программирования. программировать лучше.
Проще говоря: речь идет об общем уровне мастерства, которого вы можете достичь на протяжении всей своей карьеры.
И когда я работаю с разработчиками, которые работали над проектами с разными навыками, получили разное образование и решали разные типы проблем, я обнаружил, что постоянно узнаю что-то новое.
Это не означает, что нельзя обсуждать вещи, которые мы можем реализовать как команда или партнерство, но это означает, что это может предотвратить тупиковый потенциал роста как программиста.
Я мог бы продолжать об этом, но вкратце так: если вы собираетесь работать с другими, убедитесь, что они опытны, любят использовать те же парадигмы, что и вы, открыты для вдумчивого разговора и привносят разнообразный опыт к столу.
В конечном счете, это может помочь улучшить как ваши способности, так и качество того, что вы и ваша команда приносите на стол.
Всегда есть больше
Как я уже говорил ранее в посте, всегда есть больше. Я, вероятно, расскажу больше о бизнес-аспекте этого в будущих постах.
Однако сейчас я оставлю то, что я написал, где оно находится, и пойду оттуда позже.