Выпускник ожидания против реальности [закрыто]

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

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

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

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

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

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

Вещи, которые я не ожидал:

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

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

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

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

Большая часть работы, которую вы делаете, не новаторская

Когда я работал в Uni, я работал над процедурами ИИ для управления роботами, играющими в футбол, строил компиляторы и взламывал ядра операционной системы.

Но в реальном мире 99% ^* разработки программного обеспечения на самом деле довольно скучно. Я всегда восхищался архитекторами или строителями, которые, когда их спрашивали "чем вы зарабатываете на жизнь?" может указать на здание или что-то еще и сказать «Я сделал это ». Но большинство разработчиков программного обеспечения не могут этого сделать. На вопрос "чем ты зарабатываешь на жизнь?" самое близкое к тому, что я когда-либо смог прийти, это когда я работал в компании, которая создавала программное обеспечение, которое обрабатывало SMS-сообщения для радиостанций и т. п. радиостанция, чтобы проголосовать за песню, я написал программное обеспечение, которое обрабатывает эти голоса и прочее ". До сих пор нет места так здорово, как указывать на здание и говорить: «Я построил это».

Конечно, есть люди, которые могут сказать: «Я работал на Windows» или что- то в этом роде , но я уверен, что они на самом деле никому не говорят, что из-за боязни следующего вопроса: «Я не могу заставить свой принтер работать, Вы можете это исправить для меня? "

^* и 62% всей статистики составляется на месте

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

полное интервью: http://queue.acm.org/detail.cfm?id=1039523

Я не ветеринар индустрии; Наоборот, я недавно закончил школу, но в одной из лучших школ CS в США. Но мое инстинктивное чувство состоит в том, что способ, которым мы создаем программное обеспечение, неправильный. Вместо того, чтобы нажимать кнопку паузы и пересматривать основы того, как мы программируем, мы просто бросились вперед, используя устаревшие модели 50-х, 60-х годов, постоянно добавляя немного сахара сверху. Если мы будем продолжать в том же духе, мы никогда не пройдем мимо того места, где мы находимся. Люди просто не могут управлять сложностью вещей размером с кодовую базу MS Windows. Нам нужен новый способ. Я не знаю что это.

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

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

• Big Iron . Технологии, которые они преподавали, были в основном мейнфреймами и миникомпьютерами. Декан одного колледжа сказал мне, что я не смогу устроиться на работу, потому что я даже не знал, что такое мастер-файл. Я не собирался работать на мэйнфреймах, поскольку не мог себе этого позволить, но я не собирался быть настолько глупым, чтобы не быть слегка подготовленным. VAXen были крутыми, и я с нетерпением ждал, когда мне заплатят за код на моем собственном Micro VAX в моей кабине. Какой позор, что рынок полностью взорвался. (Как оказалось, у меня было две должности по работе с мэйнфреймами… в качестве подрядчика для IBM.)

• Разработка программного обеспечения. На пятом уровне структурного программирования, SASD и других методологий проектирования вы могли подумать, что мы станем настоящими инженерами. Я сделал. Но учителя давали очень мало советов по методам проектирования, которые я читал в библиотеке. Студенты были вынуждены сами постоять за себя, а благодаря микросхемам было слишком легко разбираться в коде, пока они не получили ответ, которым они были довольны. Я не понимал, насколько хуже было на рынке труда. Каким-то образом мне пришлось написать довольно много нового кода, так что это было не так скучно. Но я также многое взял на себя, и они были достаточно плохими, это было похоже на новый проект, потому что мне пришлось исправлять много кода. Это была комбинация исследования существующей функциональности и создания нового кода (его замена); написание инструментов для упрощения процесса и улучшения управления проектами.

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

• Развитие в основном командная работа. Это означает, что общение (разговор и чтение), чтение чужого кода и повторное использование предыдущих модулей (как внутренних, так и внешних) - это то, с чем приходится сталкиваться почти каждый день. В моем колледже, по крайней мере, мне приходилось кодировать с большим количеством людей в очень редких случаях, поэтому я думал, что основная часть работы заключалась в том, чтобы писать в одиночестве, в пустыне. Это не так.
• Объяснять вещи не-разработчикам сложно (также рассматривается для первого пункта), и вы несете ответственность за то, чтобы высказывать свое мнение (не в других 99% мира).
• Хороший тест - это тест, который не проходит. (по крайней мере, в первый раз) И, конечно же, не существует такого понятия, как код без ошибок. Вы не плохой программист, если у вас есть ошибки. Ошибки - это просто (очень важная и трудоемкая) часть вашей работы.
• Там нет серебряных пуль. У каждой технологии есть свои преимущества и недостатки.
• Колледж не учит вас современным технологиям. Но также 90% работ использует довольно старые технологии. Что, кстати, иногда это то, что нужно.
• Нетехнические люди принимают решения о технических решениях , в основном по таким эзотерическим причинам, как обслуживание, партнерство, доступность работника ...
• Ты только начинаешь , молодой падаван .

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

Оглядываясь назад, для меня одна из лучших частей - это учить и учить других .

• Компьютерное программирование является нефизическим и неинтуитивным.
  • Когда домостроитель заканчивает свою работу, он / она может ходить и сразу же видеть / чувствовать, если что-то не так. Ошибка компьютерного программирования не может быть обнаружена таким же образом, и может скрываться в системе в течение нескольких месяцев или даже десятилетий.
  • Несмотря на то, что программист может просмотреть / почувствовать фрагмент исходного кода при просмотре кода, он не гарантирует обнаружение каждой ошибки, содержащейся в коде. Компьютер, однако, сможет точно воспроизводить ошибку каждый раз, выполняя программу с определенным вводом. Таким образом, человеческое понимание части исходного кода всегда является несовершенной моделью, суть которой состоит в том, чтобы давать инструкции компьютеру.
• Кодировать программу, которая обрабатывает наиболее распространенные случаи, очень легко, но совершенно не удается обработать крайние случаи.
  • В других дисциплинах относительно легко применить корректирующее действие после факта. Может даже существовать совокупность знаний, специально предназначенных для корректирующих действий. Нет такой вещи в разработке программного обеспечения.
  • К счастью, разработка через тестирование помогает систематизировать крайние случаи, которые должен обрабатывать код.
  • Добавлено С другой стороны, некоторые методологии разработки программного обеспечения , кажется, предполагают , что мы можем извлечь ценность для бизнеса (более быстрое время выхода на рынок и т.д.), сознательно выбирая не ручки крайних случаев, и сообщать об этих решениях для клиентов.
• Клиенты могут найти бизнес-ценности в программном обеспечении, которое обрабатывает только самые распространенные случаи, поэтому поставщики программного обеспечения не слишком заботятся об обработке редких случаев.
  • Клиенты просто учатся избегать неровностей.

добавленной

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

добавленной

Мои два цента: просто привыкнуть к этому.

Изображения процессов ISO, множество технической документации, каждая функция и ошибка строго документированы, и в целом профессиональная среда достаточно хорошо описывает мою компанию. Мы производим критически важные программные и аппаратные продукты для инфраструктуры, поэтому, конечно, давление на качество постоянно (мы сертифицированы по ISO 9001, например).

После окончания университета я подумал, что ответственные люди смогут отличить хорошую работу от плохой. После вручения миллионной копии «действительно отличного кода, составленного нашим лучшим программистом», и выглядит так:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

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

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

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

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

Многие программы просто не доходят до того момента, когда их достаточно привыкают / покупают. Когда кто-то делает это, он стремится остаться и только «запутывается» в обслуживании.

Ожидания пользователей увеличиваются с каждым днем ​​для функций, но во многих областях они ниже в областях разработки. Давайте предположим, что программное обеспечение для банковских транзакций так же надежно и профессионально разработано, как и современный автомобиль. Обработка объема - современное чудо, но как насчет надежности каждой транзакции? Не так много. Ваш пост о первом дерьме вашего щенка на ковре был удален, ну и что. Это больше похоже на маленькие пластиковые пакеты в продуктовом магазине. Они делают миллиарды из них, они рвут, рвут и выбрасывают. Большинство людей не заботятся о том, чтобы требовать лучшую сумку.

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