Dev in the wild — образ мышления разработчика программного обеспечения

Вот мой взгляд на смену карьеры с более чем десятилетним опытом работы, более чем 2 годами обучения и сейчас, когда я работаю в этой области около 6 месяцев. Немного глубокого погружения и взгляда с другой стороны обучения на реальную сделку.

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

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

Все знать

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

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

По сути, чтобы писать простые программы на C#, Java, Python и т. д., вам не нужно разбираться в языке на продвинутом уровне. На мой взгляд, программирование — это последовательность хорошо выполненных простых шагов. Да, программы могут быть очень сложными, но это не ракетостроение.

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

Это может быть так же просто, как использование буфера обмена для заметок, как в любом текстовом редакторе или текстовом процессоре. Или веб-сайт для разработки карт системных процессов, таких как visual-paradigm, MIRO и т. д. Вы будете удивлены тем, что вам как разработчику приходится регулярно гуглить.

Совет. Отслеживайте свои действия по мере продвижения, и вы будете более эффективно искать ответы. Представьте, что вы отправились на поиски пищи и хотите вспомнить обильные области.

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

Алгоритмы или бюст

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

Алгоритмы хороши для более теоретических знаний, но как разработчик приложений я обычно рефакторю вызовы API, пишу операции CRUD или выполняю более простую оптимизацию внешнего интерфейса HTML/CSS.

Примечание. Учебник Intro to Algorithms также отлично помогает при работе с монитором. :-)

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

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

Я провел бесчисленное количество часов в учебниках, пытаясь найти исправление, иногда 8–10 часов. В итоге было всего несколько простых изменений, которые были необходимы на основе обновленных зависимостей.

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

Создание системы для себя, в которой вы будете работать, — лучший инструмент, который вы можете предоставить себе как разработчику.

Какая местность на самом деле…

Можете ли вы пройти несколько миль босиком по лесу?

Да, это можно сделать, но я уж точно не Чендлер Стивенс

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

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

Вы сами принимаете решения, когда речь заходит о том, как пересечь местность.

Стратегии филиалов

… Каждое приложение похоже на дерево.

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

Посмотрите на изображение дерева ниже. Теперь представьте, что узлы — это нервная система дерева. Дерево будет знать, когда и как реагировать на действие, необходимое для его процветания. Эти внутренние мессенджеры похожи на то, как работает ветвление. Порядок операций будет кратким, поскольку каждый узел мессенджера отвечает другому. В конечном итоге ключевым моментом будет коммуникация внутри команды. Итак, думайте как дерево… Это очень абстрактная версия общего процесса. Или, если вы хотите получить техническую информацию, погуглите «стратегия ветвления git»…

ООП

Аналогия в аббревиатурах. В этом случае ООП может означать объектно-ориентированную программу (программы) или может означать ошибку… Линии связи являются ключевыми в разработке.

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

Совет. Поддержание постоянного взаимопонимания особенно ценно в удаленном мире, где видимость всей команды может быть низкой. В целом, мысль о том, что ваше остроумие в использовании сокращений для каждой чертовой вещи в мире разработчиков может стать кошмаром для общения!

Ролевые имена

Что значит быть разработчиком полного стека?

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

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

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

Анализ — это 75 % моей работы, а кодирование и совместная работа — остальные 25 %.

Должностные обязанности и ожидания

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

Вы сами себе лучший защитник

Примечание. Кроме того, идеальным сценарием является подробный список требований к большинству списков вакансий. Это похоже на то, как когда мы смотрим телевизор и видим кого-то с идеальным телом, ему МНОГО платят за то, чтобы он был таким. Давайте не будем обманывать себя и составим этот список как реалистичное ожидание для разработчиков.

Верьте в себя и будьте честны со своими способностями.

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

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

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

Например, если вы занимаетесь дизайном UX/Front-End, вы можете строить с точки зрения графического дизайна или визуального искусства. Если вы любите рисовать и хорошо ориентируетесь в пространстве, эта область может вам подойти.

Или, если вы аналитик, которому нравится выяснять, как все работает (я), вы можете обнаружить, что Back-End или Full-Stack разработка — ваши лучшие варианты. Существует множество ролей, и их значение зависит от проекта, в который вы попадаете, независимо от названия.

Что открывает двери для карьеры в развитии?

Упорство, терпение, трудолюбие и умение разбираться во всем.

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

В конце концов, разве это не то, что мы все отчасти ищем?Если то, что вы делаете по работе, каким-то образом улучшает вашу жизнь, продолжайте это делать. Эта мотивация будет побуждать вас как разработчика на протяжении всего пути в мир разработки программного обеспечения. Ступайте налегке!

Спасибо за чтение и dev-on!

Want to Connect?
Hit me up on LinkedIn