Очікування випускників проти реальності [закрито]

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

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

1. Технічне обслуговування : В університеті нам всі сказали, що більшість програмних засобів - це обслуговування існуючих систем. Тому я знав очікувати цього абстрактно. Але я ніколи не уявляв, як саме це виявиться непосильним. Можливо, це щось, що я подумки засклив, і сподівався, що буду будувати круті нові речі з нуля набагато більше. Але це справді так, що більшість робочих місць переважно орієнтована на обслуговування, виправлення помилок та підтримку.

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

Хтось ще мав подібний досвід до цього? Які способи ваших очікувань щодо того, якою буде наша професія, відрізнялися від реальності?

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

Те, чого я не очікував:

Шкільний стрес і напруга на роботі не однакові - Напруга працювати над шкільним проектом з друзями або працювати сольно, навіть якщо цей термін закінчується дипломною роботою або захистом спеціального проекту не порівнюється зі стресом, здавалося б, необгрунтованими термінами роботи, проблемами спілкування , (трохи офісної політики) і час кризису.

Відсутність кращих практик - те саме, що і ваш досвід щодо професіоналізму. Перш ніж взяти свою першу роботу і під час навчання, я поспішив переглядати та читати кращі практики як в програмуванні, так і в розробці програмного забезпечення. Їх не дотримуються так само, як це слід з непрактичних і, якщо чесно, практичних причин. І іноді ваші знання дуже мало рахуються з іншими, хто просто боїться невідомого і ставиться до цих практик з презирством.

Те, що вони навчали в школі, було лише вершиною айсберга - Думаючи, що те, що я навчився самостійно вивчати і з класів, було достатньо, щоб пережити мене, я був шокований, щоб сказати щонайменше, коли я дивився ошелешений на перший фрагмент коду, який я був передбачається підтримувати. Багато тих навичок, якими я зараз користуюся, було засвоєно на роботі чи під час роботи, що я продовжую цікавитись, чи не міг би я її взагалі отримати без коледжу. XD

Важливість спілкування - змусив мене зрозуміти, для чого були всі ці уроки англійської мови. Перед реальним світом я не міг побачити актуальності того, щоб у коледжі було три-чотири різні класи англійської мови, коли його викладали, оскільки ми були в першому класі. Ви не використовуєте свою роботу, коли можете спілкуватися з комп'ютером, але не можете спілкуватися з людьми.

Більшість робіт, які ви виконуєте, - це не бездарна

Коли в Uni я працював над AI процедурами для управління футбольними роботами, я створив компілятори і зламав ядра операційної системи.

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

Звичайно, є люди, які можуть сказати "Я працював у Windows" або що завгодно, але я впевнений, що вони насправді нікому не говорять, що, боячись, що наступне питання "Я не можу заставити принтер працювати, ти можеш це виправити для мене? "

^* і 62% усієї статистики складається на місці

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

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

Я не ветеринар галузі; Я навпаки, я нещодавній випускник, але вищий навчальний заклад у США, але моє інстинктивне відчуття полягає в тому, що те, як ми будуємо програмне забезпечення, є неправильним. Замість того, щоб натиснути кнопку паузи та переглядати основи того, як ми програмуємо, ми просто помчали вперед, використовуючи застарілі моделі 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
    .
    .
    .

Я ледь не відмовився намагатися зрозуміти, що відбувається між вухами гострого волосся. "Великий" означає кошмар підтримання, "хороший" означає аварії на легкому вітрі, а "жахливий безлад" означає або це, або добре структуровану кодову базу, інженери якої явно відмовилися дотримуватися нецензурних термінів лише для того, щоб зберегти їх розумність.

Я чув, як вона стверджувала, що вся інженерія програмного забезпечення після першого рядка коду - це обслуговування. І це, звичайно, відповідає моєму досвіду. Єдиний код, який я написав, що не мав більшості його витрат на підтримку, - це настільки невдалий код, що він ніколи не використовувався або використовувався короткочасно.

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

Що я, однак, оцінив у тому, що проблема полягає не завжди в тому, щоб знайти ідеальний алгоритм чи найчистіший варіант вирішення проблеми. Але часто торгуючи всілякими обмеженнями (ресурси, знання, гроші, час, навички, ризик, попереднє навчання користувачів тощо, тощо), щоб досягти максимальної віддачі за доступні інвестиції. Це побудова системи, яка найкраще підходить для всіх цих факторів, а не лише для технічних впливів.

Багато програмного забезпечення просто не досягає того, щоб воно звикло / придбало достатньо. Коли хтось робить це, він, як правило, прилипає і лише "заплутаний" в обслуговуванні.

Очікування користувачів з кожним днем ​​збільшуються щодо функцій, але в багатьох областях вони нижчі в інженерних областях. Припустимо, програмне забезпечення для банківських транзакцій настільки ж надійне і професійно розроблене, як сучасний автомобіль. Поводження з обсягом - це сучасне дивовижне, але чим порушується надійність кожної транзакції? Не так багато. Твій пост про перше лайно твого цуценя на килимі було кинуто, і що. Це більше схоже на маленькі пластикові пакетики в продуктовому магазині. Вони роблять мільярди з них, вони рвуть і рвуть і викидають. Більшість людей не дбають про те, щоб вимагати кращої сумки.

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