Откуда мне знать, что я по незнанию не испортил свое обучение программному обеспечению?

Первым признаком того, что вы не являетесь, является тот факт, что вы обеспокоены тем, что вы могли бы быть.

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

Еще одним признаком является то, что вы не получаете обратную связь. Я склонен не давать обратную связь, если что-то работает хорошо. Если вы действительно беспокоитесь, обратитесь к кому-нибудь. Я предполагаю, что они достаточно довольны вашей работой и уровнем компетентности, чтобы оставить вас в покое. Вы знаете, старое «Если это не сломано, не чини это».

Лучший способ приблизиться к этому — попросить старшего сотрудника посидеть с вами некоторое время, объяснить свои чувства и сказать им, что даже если ваша работа на должном уровне, вы хотели бы просмотреть свой код и узнать, что он думает о вас. У вас все хорошо, и где вы могли бы улучшить.

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

Для меня это звучит как классический синдром самозванца, и поверьте мне, каждый разработчик время от времени сталкивается с ним. Да, и я профессионально программирую уже семь лет. И даже сейчас у меня часто бывают дни, когда я думаю, что кто-то собирается похлопать меня по плечу и сказать: «О чем ты думала, солнце?»

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

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

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

НО полезно время от времени оценивать свои способности, так как это может выявить слабые стороны, которые вы затем сможете устранить.

Тот факт, что вы пытаетесь научиться хорошей практике, — это очень хорошо, и я могу порекомендовать вам пару книг с этой целью:

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

Поверьте мне, когда я говорю вам, что многие программисты не отстают и идут вперед, когда ваш код — ерунда. Я не раз принимал участие в проверке кода.

И помните, что вы ученик, поэтому они должны обучать вас. Если вы используете Github или Bitbucket в своей компании, вы можете использовать запросы на вытягивание, например, как способ проверки кода.

Всего несколько мыслей, которые оказались довольно длинными... извините

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

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

Если у вас есть какие-либо личные проекты по программированию (не публикуйте рабочий код), вы можете опубликовать их на https://codereview.stackexchange.com/ , чтобы другие могли их просмотреть. На странице тура этого сайта написано:

Спросите о...

Качество вашего рабочего кода в отношении:

• Лучшие практики и использование шаблонов проектирования
• Проблемы с безопасностью
• Производительность
• Корректность в непредвиденных случаях

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

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

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

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

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

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

Если только ты не работаешь на свою маму, я очень сомневаюсь, что это так.

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

Все, что вы говорите, кажется, наводит меня на подозрение, что с вами все в порядке, что-то действительно не так с компанией. Компания, которая не делает никакого обзора кода или, по крайней мере, некоторого модульного тестирования/покрытия кода (не говоря уже об автоматическом развертывании), не стоит того, чтобы на нее работать. Что-то взорвется очень скоро. Начинайте полировать свое резюме и бегите в более приличную компанию.

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

Что мне помогло:

• Поиск (других) наставников. Приставал к коллегам до тех пор, пока один из них не сжалился и не обсудил со мной мою работу, не предложил улучшения, не показал мне приемы ремесла, а также рассказал мне о реалиях (а не только идеализированной версии) работы.* Старайтесь изо всех сил найти этого полезного человека в вашей компании. Кто знает, если вы спросите, может ваш аусбилдер наконец-то решит заняться своим делом! (Но, очевидно, не спрашивайте такими словами...) Если вы не можете найти такого человека, подумайте о том, чтобы перейти к пункту №4.

• Ходить на семинары и конференции и, как правило, встречаться с другими людьми в такой же ситуации (в вашем случае Berufsschule?), обсуждать с ними работу, налаживать связи и выяснять, что сомнения в своей работе не так уж необычны (а иногда и полезны). Может быть, найти семинар/курс по качеству программного обеспечения и попросить своего руководителя направить вас туда; предложите представить то, что вы узнали, своим коллегам (им это наверняка пригодится!). Также имеет плюс «проявления инициативы».

• Обучение. Если есть люди еще моложе вас (например, новые ученики), попробуйте дать им представление и помощь, которую вы пропустили, когда начинали. Вы улучшите свое понимание предмета, если попытаетесь объяснить его другим. Если младшего больше нет, купите резиновую утку ;-)

• В конечном счете: покинуть эту компанию и найти место, более заинтересованное в развитии своих сотрудников и качестве их продукции. Я не знаю, как много ты можешь изменить в этой компании, будучи ворчуном. Может быть, они приветствовали бы усилия по установлению какого-то процесса обеспечения качества программного обеспечения, это было бы хорошим знаком. Если они этого не сделают, вам, вероятно, будет гораздо легче найти другую компанию, которая вам подходит, чем изменить их культуру. Вам придется решить, произойдет ли это до или после ваших экзаменов (иногда вам просто нужно выдержать это, а иногда быстрое завершение означает меньше боли).

* Относительно вашей ситуации: вы не поверите, какое количество дерьмового программного обеспечения используется по всему миру (некоторые из них мне пришлось развертывать самому ;-)), поэтому, если люди не появляются за вашим столом и кричат, что вас нет среди них самые плохие кодеры.

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

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

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

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

Вместо этого я хочу сосредоточиться на техническом аспекте.

Тестирование

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

Метрики кода

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

Система развертывания и отслеживание ошибок

Поскольку вы всего 5 разработчиков в крупной компании, вам, вероятно, также не хватает инструментов для развертывания и отслеживания ошибок.
Попытка хотя бы стандартизировать (если не полностью автоматизировать) способ развертывания продукта снизит риск передачи кому-либо устаревшего файла или библиотеки, а наличие формальной системы отслеживания ошибок поможет людям сообщать вам, есть ли в вашем продукте проблемы или ошибки.

Автоматическая проверка и отслеживание всего, несомненно, повысит вашу уверенность и поможет вам создать отличный (или, по крайней мере, достаточно хороший) продукт.

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

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

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

Мне кажется, у тебя все хорошо. Автоматизация тестирования уже дает вам преимущество перед конкурентами. Конечно, идеально иметь тесты, которые говорят вам, что вы сделали что-то не так; если это происходит редко, возможно, вам следует приложить больше усилий к тестам. Но опять же, наличие тестов, предотвращающих нарушение существующей функциональности, само по себе является отличным показателем. Если вы уверены, что сможете провести рефакторинг своего кода и ваши тесты выявят большинство (не буду говорить «любых») ошибок, вы, вероятно, уже входите в 10% лучших с точки зрения дисциплины и профессионализма.

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

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

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

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

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

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

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

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

Однако не удивляйтесь, если у вас получится несколько скучная и повторяющаяся работа.

Также может случиться так, что эта стажировка вам не подходит, поэтому стоит сообщить о своих опасениях своему научному руководителю / наставнику.

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

Если ваш Ausbilder (парень, ответственный за учеников) не является подходящим техническим специалистом, обращайтесь с ним как с менеджером по персоналу. Он твой босс, да. Но он может делегировать. Обычно индивидуальные уроки ( Ausbildungseinheiten ), основанные на целях ( Groblernziele ), установленных в документе, описывающем ученичество ( Ausbildungsrahmenplan , Ausbildungsordnung ), проводятся отдельными людьми, а не Ausbilder . В IT это сложно. Тем более, что в небольших компаниях люди заняты.

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

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

Если есть разные Азуби или другие люди вашего возраста, поговорите с ними об этом. Даже если они больше ориентированы на продажи или если они готовятся к работе в Buerokauffrau . Они могут испытать то же самое. Они относятся. Поговорите с ними. Вместе все проще.

В школе поговорите с друзьями. Спросите их об их Ausbilder . Найдите того, у кого с ними очень хорошие отношения. Может быть, их Аусбилдер всего на несколько лет старше. Попробуйте встретиться с ними. Если культура их компании поощряет барбекю, походы за напитками после работы и тому подобное, попросите друга взять с собой. Тогда обсудите свою ситуацию с крутым Аусбилдером . Они будут слушать, они будут сочувствовать. Они, вероятно, дадут совет или предложат взглянуть на ваш код и сказать вам, что они думают. Я бы все равно это предложил.

Вклад в Open Source был упомянут, и вы делаете это здесь. Но ваш стек технологий не идеален для OSS. Это затрудняет это сделать. Но все же могут быть встречи по некоторым технологиям, с которыми вы имеете дело на работе. Если вы находитесь в Берлине, Гамбурге, Франкфурте или Мюнхене, они будут. Иди туда. Не бойтесь разговаривать с незнакомцами. Люди, которые ходят на эти мероприятия, интересуются технологиями, но также и общением с людьми. Они увидят в вас любознательного человека, который хочет учиться, а не ребенка, который еще ничего не знает.

Я посмотрел на ваш профиль SO. Ты пробыл там чуть больше года. Вы собрали более 5000 интернет точек. У вас есть значок тега на C. Вы вносите свой вклад в автоматизированную систему, которая помогает защитить всю платформу от спама. Ваши сообщения лаконичны, четко структурированы, технически обоснованы (насколько я могу судить) и обычно хорошо принимаются. Ваше владение письменным английским языком впечатляет среднего азуби. Из более чем 250 вопросов только два имеют отрицательный балл, и у вас достаточно честности, чтобы не удалять их. И держу пари, вы, вероятно, один из тех, кто помогает слабым ученикам в школе, и, возможно, вы либо Klassensprecher , если таковой существует, либо вы являетесь частью Schülervertretung.в школе. Хотел бы я, чтобы у меня было больше азуби, таких любопытных, мотивированных и занудных. Продолжайте хорошую работу. :)

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

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

Есть много вещей, которые вы можете сделать для развития профессионализма:

• Изучите профессиональные взгляды и привычки.
  • Поймите, что критика работы — это не личная критика. Я научился этому на своей первой работе. Хотя это, конечно, не универсальное отношение, очень полезно, когда вы можете критиковать реализацию, не критикуя человека, который ее сделал.
  • Всегда имейте веские причины для того, чтобы сделать конкретный выбор, и сообщайте об этих причинах. Поймите, что в каждом выборе есть компромиссы, и попытайтесь понять конкретные компромиссы в каждом случае.
  • Поймите, что есть вещи, которых вы не знаете, которых вы не знаете. Вот почему хорошо задавать вопросы, если вы не понимаете, почему был сделан конкретный выбор.
  • Оцените каждое решение, чтобы увидеть, решает ли оно реальную проблему.
  • Научитесь решать проблемы, а не писать код.
• Присоединяйтесь к профессиональным организациям, таким как Association of Computing Machinery , и стремитесь следовать как их Кодексу этики разработки программного обеспечения , так и общему Кодексу этики и профессионального поведения ACM .
• Изучите книги по программированию, такие как «Прагматичный программист » , « Полный код» , « Чистый код », « Эффективная работа с устаревшим кодом» , « Рефакторинг » и « Обслуживание персонала » .
  • Прагматичный программист особенно показывает вам некоторые основные вещи, которые должен делать хороший разработчик, и почему. Если у вас нет наставника, то эта книга — очень хорошее начало для самостоятельного наставничества. Это эпизодически, и вы можете сразу перейти к книге.
  • Code Complete — более серьезный трактат, но он более глубоко охватывает ту же тему, проводя исследования, подкрепляющие выводы.
  • Peopleware — лучшая книга по управлению программистами, которую я когда-либо читал. Он показывает, что ваша рабочая среда имеет большое значение, и подкрепляет свои выводы эмпирическими данными. Он показывает вам, как вы можете структурировать свое рабочее пространство и рабочие привычки, чтобы быть более эффективными.
  • « Эффективная работа с устаревшим кодом» и « Рефакторинг » — две самые важные книги, которые вы можете прочитать, потому что, по оценкам, 80% времени жизни кодовой базы проходит в режиме обслуживания. Также распространен афоризм о том, что программисты тратят больше времени на чтение кода, чем на его написание. Вот почему важен чистый код , потому что легко читаемый код легко модифицировать.
• Проходите бесплатные онлайн-курсы.
  • Learning How To Learn научит вас учиться, а также решать проблемы и мыслить творчески.
  • Agile Software Development — это лучший обзор, обсуждение и оценка Agile как методологии, с которыми я когда-либо сталкивался.
• Участвую в онлайн-конкурсах по коду, таких как HackerRank , CodeChef и Project Euler , и, когда я решаю задачи, я смотрю на решения других людей, чтобы сравнивать методы и учиться на их коде.
• Составляйте планы обучения и развивайте свои навыки.
• Включите все предупреждения кода и обработайте их как ошибки.
• Используйте линтеры , которые предупреждают о неверных методах написания кода.

Вы упомянули, что в вашей команде всего пять человек. Я тоже работаю в команде с пятью разработчиками, но после обсуждения нашего процесса в команде мы решили принять методологию контроля версий GitFlow. Это означает, что каждое изменение должно быть проверено кем-то еще, прежде чем оно будет объединено обратно в ветку разработки.

Трудно выразить, как много я узнал и получил от проверки кода, а также от проверки моего кода другими людьми:

• У каждого человека есть когнитивные слепые зоны, которые обнаруживаются только тогда, когда кто-то другой смотрит на тот же код и задает вопросы о нем.
• Чужая точка зрения многому меня научила в моем коде.
• Необходимость объяснять свой код кому-то еще во время обзора активирует отладку Rubber Duck .
• Критический взгляд на чужой код учит вас также критически смотреть на свой собственный код.
• Хороший контрольный список вещей, о которых следует помнить во время проверки кода, также очень полезен при создании собственного кода.
• Я просматриваю свой собственный код, когда включаю систему управления версиями, просматривая каждое изменение и объясняя себе его необходимость и цель.

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

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

Есть такой подход к борьбе с неуверенностью в себе — компьютерщики устраивают небольшие меритократические соревнования на первенство — чтобы установить более или менее объективные достоинства в разных категориях.

Давайте возьмем небольшую задачу, и куча людей попробует ее решить (и я не имею в виду шумиху, я имею в виду что-то реальное). Суть в сборе дискретных отзывов о вашем решении. Это быстрый и грязный, но умный взлом? Тогда ты умный хакер. Код быстрый, но едва читаемый? Тогда вы гений, возможно, с багажом в других областях. Результат некачественный, но вы делаете это очень быстро? Тогда ты скоростная кодовая обезьяна. Таких атрибутов гораздо больше.

«Хороший» или «плохой» кодер — это совокупная мера того, насколько вы полезны в общем сценарии. Но в контексте вашей компании это не черное и белое, несмотря на то, что люди постоянно пытаются получить общий ответ (на SO, голосование, от вашего руководителя «да/нет»). Вам нужно спросить о конкретной поломке ваших сильных и слабых сторон, и где это может вызвать проблемы, а где это не имеет значения.

Поскольку в конечном счете ответ зависит от того, что ищет компания, их не волнуют атрибуты, которые им не нужны. Чтобы привести примеры, им нужна скоростная обезьяна? Им вообще нужен QA? Или они согласны на гибкие хаки, связанные с конкретными случаями, а не с систематическими? Нужен ли им быстрый код, потому что критерием является аппаратное обеспечение/отзывчивость? Список можно продолжить...

Хотя ответ RichardU меня устраивает (т. е. с вами все в порядке ), я бы все же посоветовал вам попытаться что-то изменить.

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

Так что в вашей ситуации я бы потихоньку пытался что-то изменить, шаг за шагом. Попробуйте ввести некоторое подобие более профессионального процесса разработки (по крайней мере, минимальное количество рецензий — подумайте о «факторе грузовика»). Если вы просто не можете этого добиться, то ищите другую работу. Я не предлагаю вам подвергать себя давлению; просто имейте открытый разум.

Я бы точно не советовал откинуться назад, похлопать себя по плечу, сказать себе, что у тебя "синдром самозванца" и продолжать так халтурить вечно!