Міграція з науки/освіти в ІТ

Отже ти науковець чи просто викладач університету, що пов'язаний з комп'ютерами та програмуванням. Можливо тобі трапляються відчуття, що життя ніби проходить повз тебе. Ти даєш знання і путівку в життя молодим людям - студентам, але твоя власна кар'єра, здається, знаходиться у глибокій стагнації. Ти в кінці робочого дня розумієш, що нічого не зробив, а бігав по кабінетам, підписував папірці, писав нікому непотрібні звіти. Підписував і перепідписував їх кланяючись кожному бюрократу, що заплив салом і створює видимість роботи. Ти пишеш статті, витрачаєш на них купу зусиль, а тоді платиш за кожну опубліковану сторінку твоєї статті. Тоді вона виходить у якому не будь віснику, але ніхто її не читає. Ти шукаєш теми для досліджень, гарячково переглядаючи чужі статті, і не розумієш за що взятися. Що може принести бодай якусь користь тобі і іншим? Наукові дослідження для замовника з фінансуванням та реальними проблемами - недосяжна розкіш. Ти виступаєш на конференціях, де тебе слухає купка студентів і аспірантів, що їх примусово загнали до зали. Міжнародна наука - недосяжна мрія. Ти навчаєш студентів працюючи на півтори ставки. Вони після твоїх занять ідуть працювати на півдня, але заробляють більше від тебе і переважно вважають, що марнують час на твоїх заняттях. Хай йому абищо! Щось тут дуже сильно не так. Що там казати, навіть за кордоном освіта і наука майже повністю відірвана від реальної індустрії програмного забезпечення, а українська, вибачте, взагалі пародія. Є люди, які цього не помічають, або через це не переймаються. Це просто чудово! Хтось же має виписувати корочки і давати бодай якийсь фундамент студентам. Але якщо тобі це не байдуже, можна подумати про міграцію в ІТ. Як людина, що пройшла цей шлях, ось що я гадаю тобі слід знати про нього:

Міграція буде дуже болісною. З двох причин. По-перше, як уже згадував, наука і освіта відірвані від індустрії, тому формально ти без жодного досвіду. Для кадровика, якщо твоя наукова діяльність не збігається з предметкою компанії, ти ніхто. Навіть менше ніж ніхто. Тому що, як недивно, на приймаючій стороні компанії люди ніби "бояться" мігрантів з науки. Адже після власних універів вони добре засвоїли собі, що то люди непрактичні, часто занадто високої про себе думки і забагато знають для тієї роботи, що необхідно виконувати. Тобто по-друге тебе майже скрізь визнаватимуть overqualified. Практично це спричинить ситуацію, коли на майже на всі твої розсилання резюме відповіддю буде гробове мовчання телефону. Тут лише можу порадити почитати на моєму блозі способи/стратегії потрапляння в ІТ (http://alexnechay.blogspot.com/2015/07/blog-post_26.html).

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

Хоча повернення в науку малоймовірне, педагогіка для тебе не буде втраченою. ІТ галузь - це безперервний потік знань і інформації. Навчати когось і вивчати щось самому потрібно увесь час. Тебе це приваблювало в науці, в ІТ цього навіть більше. Тобі потрібно буде писати код так, щоб його міг зрозуміти інший. Компанії завжди дуже тішаться, коли хтось влаштовує knowledge sharing сесії і готові таку людину всіляко підтримувати. Компанії також дуже раді, якщо ти береш участь у зовнішніх форумах, адже це для неї певний ПР. Я роблю усі ці речі. Крім того щороку проводжу кількатижневі курси з APL - мови програмування, що у нас її використовують.

Ти втратиш свободу і спершу почуватимешся немов у в'язниці. Адже ти звик, що прив'язаний лише до розкладу своїх занять, а решту часу ти сам вирішуєш що і як тобі робити, де знаходитись. Ти звик придумувати навчальні програми, спілкуватися з людьми і загалом вести творче життя. В ІТ ти не вирішуватимеш нічого цього, як мінімум в траншеях, в яких ти почнеш свій шлях. У них тобі вкажуть ось тут сиди і пиши ось це і це, ось так і так. І так триватиме 8 годин щодня. Ти і комп'ютер. Майже ніякої свободи творчості. Виття вовком гарантоване. Але ти відкриєш для себе вечори, вихідні і відпустки. Можна спокійно відпочивати, а не думати про наступну статтю чи готуватися до чергової лекції. Ці дні і години належатимуть тобі і твоїй родині, а належно приправлені доларом вони набудуть абсолютно нових кольорів. З часом, якщо навчишся фокусуватися на поставлених завданнях і програмування загалом тобі подобається - звикнеш. Адже звикають в'язні до в'язниць))).

Робота в ІТ часом буває цікавою, і навіть дуже цікавою. Але це не наукові дослідження. Це переважно рутина, особливо в нашій країні, куди на аутсорс дають не самі цікаві проекти. Я багато разів себе ловив на тому, що я з досадою ляскаю долонею по столу і вигукую: "Блін, та це ж робота рівня хлопчиків що 2 роки в ПТУ провчилися, а я ж к.т.н!". Але who cares? The work needs to be done. Тож будь готовий стиснути зуби і уявляти, що ця рутина - найпривабливіша у світі робота. Якщо цю мантру приправити усвідомленням того, що є реальні люди кому це потрібно і вони готові за це платити, то можна досягти успіху.

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

Як потрапити в ІТ?

Перед тим як потрапляти в ІТ, гарно подумайте чи воно вам справді потрібне. Це важка, інтелектуально виснажлива робота, часто нудна, часто стресова, яка знищує ваше здоров'я. У ній ти постійно ідіот, який нічого не знає, ти мусиш постійно вчитися аби хоч якось триматися на плаву. А програмісти за 40 взагалі зникають, є теорія що їх сплавляють по Дніпру :-)). Але якщо вам подобається писати код і вчитися, Господи, вам сюди, тут класно, затишно і грошовито:-). Я потрапляв в ІТ двічі, тому що робив перерву на викладання і наукову роботу. Зараз, напевно, буду потрапляти втретє, бо ІТ вийшло у мене з-під ніг, я трохи забагато провів часу на десктопі, який раптом став не актуальним. Ось способи потрапляння в ІТ, які я виділив із власного досвіду і досвіду моїх знайомих.

Некро-технології. Це, напевно, найпростіший спосіб потрапити до ІТ і доволі дієвий. Майже нічого не треба робити, але треба мати технічну освіту і якийсь мінімальний досвід, типу щось для диплому писав. Суть способу полягає  у пошуку компаній які застрягли у минулому і мають старезний код і технології, часто доморощені, від яких вперто не хочуть відмовлятися. Наприклад, трапляються такі, що сидять на Lisp, COBOL, APL, Gupta, Delphi, PowerBuilder. Я реально на кожну бачив вакансії.  Це можуть бути також компанії, які чомусь вирішили використовувати щось екзотичне, типу Erlang. Цей спосіб, я знаю точно, працює, тому, що я сам ним скоритався щоб потрапити до міжнародного вендора програмного забезпечення SimCorp, який активно використовує екзотичну мову програмування APL і купу жахливих доморощених технологій. Жоден успішний амбіційний девелопер не погодиться на цьому працювати, тому я просто з універу, погодившись працювати з "некро-технологіями" отримав чудову зарплату, закордонні відрядження, мед страховку і тому подібні няшки. Спосіб вкрай небезпечний - можна обрости мохом, почати пахнути нафталіном і на цьому і закінчити кар'єру. Необхідно постійно навчатися паралельно. Я зараз опанував C# і частину робочого часу отримую релевантний досвід виконуючи .NET проекти.

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

Знайомства. Звучить дещо пошло, я знаю, культурно це звучить типу references. Якщо у вас є знайомі, що працюють в ІТ компаніях, а особливо що впливають на прийняття рішень там - бінго! Цей спосіб може бути як дуже дієвий так і зовсім безглуздий. Можна сказати це навіть напівспосіб, тому що якщо у вас немає необхідних навичок вас ніхто не візьме на роботу. Але якщо навички все ж таки є, то серед купи народу з такими ж навичками, візьмуть саме вас. Тому знайомства дуже і дуже важливі. Як на початку кар'єри, так в її середині, а особливо вкінці. Я сам навіть пишу цей блог а потім виступатиму з цим перед аудиторію саме з такою метою: познайомитися і бути знайомим. Маю я і особистий досвід користування цим способом. Перший раз я потрапив до ІТ ще будучи студентом. Мій добрий приятель помітивши як мої очі блищать на заняттях з цифрової техніки і мікропроцесорів (Женя Бабін, привіт!:-)) запропонував зайнятися з ним веб програмування, яким він і багато інших студентів у ті часи (двотисячні ) активно промишляли. Також я маю досвід рекомендування людей. Двох рекомендував і обох не взяли. Не було потрібного скіла, не було потужного прагнення у людей, тому і не спрацювали мої поради їх найняти. До речі, походи на курси у компанії, має цінність саме з точки зору заведення знайомства з компанією, її потребами і працівниками. Ці знайомства можуть спрацювати.

Масове розсилання резюме. Цей спосіб класичний, про нього не потрібно розповідати, його знають і використовують усі. Ефективність цього способу однак, не підсиленого комбінуванням з іншими способами, близька до нуля. Ти шлеш і шлеш резюме, а потім чекаєш і чекаєш і чекаєш... І нічого не відбувається. Починаєш писати в резюме те, чого нема, тоді який не будь відчайдушний HR тебе запрошує на співбесіду, яку провалюєш з лунким тріском. Знайомо? Народ, хоча б резюме подбайте вилизати. Я проводив курси у своїй компанії для зовнішніх і мав насолоду дивитися на резюме що їх присилали щоб на курси потрапити. Господи, що я тільки там не бачив. Інколи живіт тріщав від реготу. Колись цей спосіб з розсиланням резюме був супер швидкий і ефективний. Програмістів було потрібно відчайдушно багато. Брали усе що могло if та for написати і пояснити різницю. Ці часи минули, нажаль. Сьогодні розіславши в купу місць резюме із меседжом "я класний, гарно вчився, і можу робити все на будь якій технології" отримаєте зловісно мовчазний телефон.

Стати відомим. Цікавий спосіб потрапити в ІТ чи не так? Але не такий уже й важкий як це було 10 років тому. Погляньте, скільки можливостей є у наших руках, які майже нічого не коштують: ведення свого блогу, відкриття свого YouTube каналу, написання статей на DOU, запис своїх подкастів, написання і інтернет-публікування своїх книжок. Бери - і роби, лише потрібен час. Звісно, ви для цього маєте бути не безробітнім чоловіком із жінкою та дітьми на голові. Але якщо ви студент або працюєте ще не в ІТ, цей спосіб можна застосувати. Я не можу, однак, сказати що цей спосіб дієвий, я сам його не використовував. Але зараз я дію саме за ним, цей спосіб є моєю кар'єрою стратегією сьогодні. Мені страшенно набридло ходити на співбесіди і відповідати на запитання типу скільки яєць можна кинути з якого поверху, як швидко множаться бактерії, скільки разів треба човном котів перевозити на інший берег, чи якусь іншу дурню. Я хочу щоб мені самі дзвонили і пропонували роботу ті, кому потрібні мої послуги. Для цього потрібно щоб про мене знали і знали як фахівця з чогось, тобто треба спеціалізуватися і колупати цю спеціалізацію роками. Але це уже інша тема.

Власний бізнес. Для таких людей як я ідея створення власного бізнесу негайно напрягає. У мене ж нема підприємницької жилки, я не хочу усіх цих клопотів із податковими, бухгалтерією, пошуком клієнтів. Але чим цікаве ІТ, що можна створити свій бізнес без усіх клопотів. Але по порядку. Суть способу полягає у створенні власного бізнесу, який розроблятиме програмний продукт. І зовсім не обов'язково когось наймати чи отримувати прибуток. Без найму і прибутку немає необхідності офіційно реєструватися, і займатися тяганиною з податковою та бухгалтерією. Обов'язково обрати популярну актуальну технологію і використовуючи її робити продукт, дуже класно якщо хтось ним ще й користувався б безкоштовно. Це могло б зорієнтувати які саме фічі потрібні. Це було б суперово, але не обов'язково. Але що ж це за бізнес такий, який не приносить доходу, або приносить мізер? Який зиск? А зиск у тому що через рік-два можна буде написати в резюме: ASP.NET, C#, Angular, JavaScript - досвід 2 роки, компанія така-то, продукт, що робив ось тут можна подивитися і код, що я пишу і його якість можна зацінити ось у цьому репозиторії GitHub. Та це ж уже звучить солідно, правда? А якщо є бодай один клієнт - то взагалі круть. Множимо це на знайомого, що принесе це резюме в руки керівництва і маємо першого реального клієнта/роботодавця з баблом. І тепер ми по справжньому в ІТ. Гадаю, ні в кого не викликає сумніву той факт, що це дуже дієвий спосіб, але й дуже важкий, вимагає багато праці і самовіддачі. Не підходить безробітній людині без засобів до існування. Мій приятель, Женя Бабін, що я з ним починав свою кар'єру, потрапляв в ІТ саме цим способом. Він типу створив компанію, знаходив в інтернеті клієнтів і спочатку пропонував їм виконати роботу за мізер, можливо були і безкоштовні випадки. Це не важливо. Важливо що на момент випуску з університету у нього було 5 років досвіду і купа виконаних проектів. Навіть досвід управління мною і іншими хто йому допомагав. Якби він захотів, він міг би отримати будь-яку роботу в Києві з веб програмування. Але він не захотів, бо його власний бізнес уже забезпечував усі його потреби.

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

Чи потрібна вища освіта програмісту?

Ця публікація є реакцією на інтерв'ю із Сашею Шевчуком (http://itvdn.com/ru/channel/video/pps-good) про те, навіщо програмеру вища освіта. Саша за своєю манерою такий категоричний у тому, що вища освіта абсолютно необхідна. Я після універу уже майже 4 роки сиджу у реальних траншеях і... от нутром відчуваю, що насправді зовсім ні, не потрібна. Правда, я хотів би сказати що потрібна, і що усім слід сумлінно навчатися в університетах, отримувати гарні оцінки, тішити своїх професорів, і навіть писати круті дисертації. Але не можу, тому що сам озираючись у своє минуле, ніяк не второпаю нащо я добивався усіх своїх золотих медалей, червоних дипломів і наукових ступенів. У траншеях (ні, я не в АТО, це так називають реальну брудну програмерську роботу) ці знання майже не потрібні, а якихось вмінь наша освіта давати не може. 

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

Ну ок, можна заперечити, що мовляв все одно має бути фундамент спочатку. Так, згоден. Але принаймні наші університети дати його не можуть. Думаю закордонні теж. І не тому що погані чи не надто розумні. Ні. Просто наша галузь надто молода і ніхто толком не знає що є фундаментом у ній. А тому, наприклад вчать, основам програмування на С++. Це фундамент? Правда? А студент вийде і муситиме писати на JavaScript і як прототипним наслідуванням чи замиканнями він не вмітиме. Який же це тоді фундамент. Далі ООП на C#, де казатимуть що private - це інкапсуляція і це має якийсь стосунок до ООП. А на роботі - Ruby, і уся освоєна об'єктна модель - коту під хвіст.

На заняттях з проектування вчитимуть UML до запаморочення в усіх деталях. Хоча до проектування він має стільки ж стосунку скільки будь яка інша мова програмування, просто UML - графічна мова от і все. А на робочому місці - студент не знайде UML. А якщо і знайде - то неправильний і усі його знання - коту під хвіст. А ще вчитимуть патерни, більшість з яких просто хакають систему типів статично типізованих мов, а частина їх уже вбудовані в самі мови програмування і платформи (С# events - observer, lambda expressions - strategy).

Інші предмети і згадувати страшно, знання їх взагалі ніяк не допоможе ні в чому (фізика, 90% дискретки і вишки, соціологія, релігія, філософія, археологія...).

Гаразд, є фундаментальні теми, Саша їх згадує. Кінцеві автомати. граматики, графи, дерева. Але ці усі теми потрібні виключно для розробників мов програмування і операційних систем. Багато з нас цим займаються? Ті хто хотять, або відчувають у цьому потребу на проекті - йдемо на Coursera і проходимо курси з компіляторів, структур даних і алгоритмів. Я проходив. Пререквізити - шкільна освіта. Це абсолютно все що потрібно в найекзотичніших проектах.

На мою думку за відсутності фундаментальних знань в сфері інженерії програм (не комп'ютерні науки! це як електроніка і фізика) в університетах майже нічого навчитися не можна крім комп'ютерних наук, які програмному інженеру тільки інколи трохи релевантні. А тому навчання там - марнування часу. Фундамент можна отримати тільки шляхом узагальнення практичних знань після того як побачив десятки мов програмування, парадигм, платформ і фреймворків. Онлайн курси дадуть необхідну стартову базу.

John Sonmez (http://simpleprogrammer.com/) рекомендує починати кожному свій бізнес, робити продукт і отримувати в процесі досвід. Так, студент скоріш за все того продукту не продасть, і доходу не матиме, але так само студент не матиме доходу від вищої освіти. Але від цього маленького софтверного бізнесу буде досвід і запис в резюме, що так необхідні для отримання першої роботи. 

P.S. Дорогий читачу, якщо ти студент, це не означає що слід негайно покинути університет. У кожного свій шлях. Я, наприклад, коли навчався більшість часу займався веб програмування а на навчання так би мовити "підзабивав". Все ця "корочка"... І все ж таки аналоги універських курсів по спеціальності варто пройти на Coursera. Хоча б тому що це страшенно цікаво. ))

Підсвічування синтаксису на Blogger

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

Але годі лірики. Навряд чи колись фахівець із програмного забезпечення зможе вести блог і не зіштовхнутися із необхідністю привести вихідний код на якійсь мові програмування. Blogger такої можливості не підтримує. Розв'язання цієї проблеми виявилося відносно легким. Один гарний хлопець на ймення Олексій Горбачьов розробив чудо програму SyntaxHighlighter. Докладна і елегантна інструкція по інсталяції наведена тут. А тут можна знайти теми в яких вихідний код буде показано.

Після проходження покрокового процесу інсталяції можна насолоджуватися зовнішнім виглядом програмки на C# :

// Comment for HelloModule
public class HelloModule
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

Шкода лише що APL не підтримує, а то я похизувався би своїми пізнаннями у цій незвичайній мові :-)

Куди ж податися, у Java чи у .NET: перегляд

Немало минуло часу з дати мого останнього допису. Мені довелося зіштовхнутися з реальним суворим світом ІТ та випробувати на власній шкурі ідеї, що я їх ретельно у тому дописі викладав. Так сталося, що я вирішив залишити нагріте місце в університеті з метою отримання реального досвіду. Звісно, я, як і раніше був переконаний, що головним є фундаментальні знання, а не конкретна технологія чи інструмент, тому вибирав компанії, і вакансії, керуючись у першу чергу їх принадністю, а не тим, знання яких інструментів вони вимагали. Мушу зазначити, я мав дуже непогані знання із С++, Java, C#, PHP, і тому подібного, але без реального досвіду, тому про мою цілковиту відірваність від реальності не йдеться. В результаті, роботу шукав я дуже довго, і невдалих співбесід пройшов досхочу. Могло б здатися, мої погляди хибні, та попри все я досі їх дотримуюся. Справді, мені багато разів відмовили з двох основних причин: я застарий уже для ІТ (і це у віці 28 років); я недостатньо обізнаний з інструментом. Друга причина, як перша, дуже дивна, оскільки на співбесідах запитували справді тонкощі та особливості використання тієї чи іншої мови. Я переконаний, що працюючи з мовою 1-3 місяці, ці речі можна було б засвоїти дуже швидко.

Врешті-решт, я потрапив у компанію, де мене запитували речі, які, як на мене, важливіші за тонкощі інструмента. Зазначу, що у цій компанії використовують старі, маловідомі технології, і це, можливо, основна причина такої манери співбесіди. Але результатом було моє працевлаштування, і мої заяви на співбесіді про не першу важливість технологій були сприйняти схвально. Пропрацювавши 3 місяці у компанії, можу сказати, що вона просто казкова, і умови праці ліпші за усі ті, що пропонували в інших місцях. Тому зроблю висновок, хоча і дуже суб’єктивний: якщо Вам відмовляють на підставі недостатнього знання технології, не засмучуйтеся, ця компанія не надто варта того, що б у ній працювати. Хочу тут згадати GlobalLogic, де після співбесіди і підчас неї у мене мало не стався серцевий напад, настільки нахраписто, жорстко і принизливо поводилися інтерв'юери. Наразі, я дуже втішений, що там мені відмовили. Якщо ж Вас не запитали нічого такого, що дозволяє оцінити ваш рівень і світогляд, це свідчить про низький рівень як інтерв'юера, так і компанії, що її він репрезентує, і тут треба добряче помізкувати, чи погоджуватися на співпрацю з ними.

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

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

Куди ж податися, у Java чи у .NET?

На днях сталося дві події. Я начитався Парнаса (David Parnas) і знову стикнувся з класичною ситуацією, коли студент стоїть перед вибором куди ж податися? Чи то у Java чи то у .NET, а може у PHP? Цього разу на форумі і студент зовсім не мій. Я знаю скільки на ці пошуки витрачається дорогоцінної молодої енергії, тому вирішив розписати суть проблеми, застосовуючи мої улюблені аналогії. Сподіваюся ця аналогія, хоча трішечки різкувата, але допоможе розібратися.
Для початку декілька загальних слів про те, хто ж такий інженер. Інженер загалом займається тим, що змінює навколишній світ, створюючи і підтримуючи продукти, які до того не існували. Для створення продуктів інженер застосовує наукові знання, математику, практичний досвід (можна ще додати економічні та соціальні аспекти, особливо у програмній інженерії). Саме використанням наукових знань та математики інженер відрізняється від техніка. На відміну від науковця, який добуває знання, інженер творить, проектує і доводить, що те, що він спроектував буде працювати як слід, покращить суспільне життя і буде безпечним у всіх відношеннях. Для роботи інженер може обирати та використовувати різноманітні інструменти.
Приблизно таке міркує собі пересічний студент (це не вигадка, цитата з форуму, що там казати, я зовсім недавно так само розмірковував).

Итак 19 лет, студент 3его курса! По сути дела на данном этапе знаю нормально С\С++ прошло 1.5 года любви с ним с момента написания cout<<"Wake Up, Neo..."; сидеть еще 2 года на учебе понта не вижу... В голове мысль надо работать, делать опыт, делать деньги... на 4ом .NET от А до Я а на 5ом Java и PHP ну это к слову! Итак... Меня терзает мысли о том что быть человеком оркестром не хорошо, и быть про во всем тоже! Так как это не возможно, а лучше выбрать одну ветку это или .NET или Java или PHP или ЯблоДевелопер ! По сути дела больше тянет в .NET так как понравилася C# и испытываю симпатию к продуктам Microsoft (это не сарказм) а также тянет в Яблочную сторону но как бы денег не хватает чтобы купить макбук + девайс на iOS =) Java смотрел по Шилдту тоже неплохо но немного напрягает (я думаю с не привычки) linux-based системы и все такое, я как бы осознаю что Java это чистый Enterprice и ничего более , то есть если бы не было J2EE она бы сдохла давненько или осталась в разделе тупенькие приложение для мобилок на J2ME это сугубо мое мнение оно может быть не верным... PHP тоже неплох, но мну бесит HTML CSS то есть для меня радость занимать себя чисто программированием а не всякими разметками и т.д. Опять же более тянет в .NET или apple ... и если посмотреть на такие сайты как work.ua или trud.ua или rabota.ua (я сам в Днепре) то могу увидеть что больше всего требуется PHP потом Java потом .NET потом Apple ... И когда я на work.ua фильтровал по окладам выше 15к гривасов PHP — 2 Java — 3 .NET — null ! Я подумал странно! Ведь на прошлом опросе зарплат на ДОУ четко было видно рулит .NET и Java и по кол-ву работы и по размеру оклада... Вот я сейчас смотрю на work.uaPHP — 76 вакансий Java — 58 .NET — 16 ! Я как бы в курсе что судить по вакансиям не имеет смысла так как многие вакансии стоят тупо для вида не понятно почему! Но я не знаю откуда мне взять данные о том что же в спросе как говоритЦо! Перечитавшись топиков на форумах я стал выкупать что люди валят с PHP на Java да и многие студенты вроде меня видят свое будущее в Java! Если законы физики никто не отменял можно предположить что Java программистов будет океан а это плохо для джавистов... и тут я все больше плюсую .NET…

А тепер уявімо собі юного радіоінженера, що навчається у супер радіо-академії ШАГ. Подивимося, що ж він собі міркує.

Гаразд, я вже навчився штрикати кнопки на вольтметрі «С++», якого вже 1.5 років кохаю до нестями з того моменту як вперше в нього запхав батарейки. Я не знаю ні теорії електронного обладнання, я не знаю принципів побудови приймачів та передавачів, ні статистичної радіотехніки, ні перетворення Фурьє, ні спектрального аналізу, ні математичного аналізу, ледве можу взяти інтеграл, і щось віддалено чув про закон Ома. Відчуваю себе зле при розмовах про розрахунки електромагнітного поля та рівняння Максвела. Проте ще 2 роки сидіти на навчанні не бачу понту, я ж навчився користуватися цим супер вольтметром! Треба йти заробляти гроші, набувати ще крутішого досвіду штрикання кнопок на вольтметрі, можливо навіть навчусь приєднувати нові детальки до нього! Думаючи про це, я купив собі ще два вольтметра, один «С#» а інший «Java». Трохи навчився й на них штрикати кнопки. Але після цього мене почала доводити до сказу думка, що професійно вміти користуватися усіма цими вольтметрами не є добре та й неможливо, бо вони мають забагато деталей і режимів роботи. Тому треба вивчити один з них у всіх деталях, але який!? Взагалі то мені подобається «С#», він такий ошатний, кнопочки гарно натискаються і напис на ньому аж лисніть: Microsoft! Що за пречудова фірма… Вона ще крім того робить казкові унітази і зубну пасту! Як мені подобається ними користуватись. Тому саме вольтметр «С#» та мотлох, який необхідний щоб він працював я вивчити хотів би від А до Я. І то нічого що читати технічну документацію до нього я не можу англійською, тому купую за скажені гроші привезені з сусідньої держави, як попало перекладені (живу я в колонії, переклад мовою монополії) застарілі книжечки і читаю. Щоправда є ще один вольтметр – «МАК». Тай гарний же! Однак дорогий, купити не можу, тому не вивчатиму. Дивився до «Java». Що сказати – слабенько, слабенько. Не знаю чому, чи нема напису Microsoft, чи кнопок малувато. Ще є непоганий «ПХП», але мене дратують амперметри. Бо мені втішно напругу міряти, а не усілякі там струми! Фі! Знову ж таки тягне до Microsoft чи Яблука, там усе таке гарне та симпатичне, а який професійний маркетинг (ковтає слину і мрійливо посміхається). Полазив по сайтам робіт, а там чомусь більше потрібні такі, що вміють штрикати кнопки на «ПХП»… Дивні речі якійсь кояться. Чорт голову зломить в цих вольтметрах! Їх так багато, там їх використовують, там – ні! От лихо! Аби ж то усі використовували один амперметр! Тоді б я його зубрив би до посиніння, а потім напевно нарубав би грошей величезну купу. А так все це доводить мене до сказу! Та ще й викладачі днями вчать штрикати кнопки на вольтметрах і хоч би хто щось порадив! Вони ж такі досвідчені штрикальники! Полазив по форумах багато студентів типу мене бачать своє майбутнє у вольтметрі «Java». Але згідно з законами фізики, що я їх в школі сумлінно вивчав, якщо багато штрикатимуть кнопки на вольтметрі «Java», то тим, хто їх штрика на «C#» буде краще. От трясця, що ж його робити?!

У чому ж тут мораль? А в тому, що студент-радіоінженер так ніколи не думає, адже це є абсурдним для нього! (я був таким студентом і прекрасно знаю чим їх голови забиті у 19 років). Чому ж інженер-програміст мучиться у таких роздумах? Думаю це окрема тема для палкої дискусії. Тут я лишень хочу дати свої скромні поради, навіяні Парнасом.

Вивчайте англійську мову і читайте оригінальні свіжі статті та книжки з програмної інженерії. Вивчайте наукові основи програмної інженерії, комп’ютерних наук (в меншій мірі, тут без фанатизму, лише речі для побудови програм, типу основи мов програмування, а не завороти штучного інтелекту) та практики, які гарно себе зарекомендували. Вивчайте дискретну математику (заспокойтесь, не усе підряд, а ті розділи, які застосовуються у серйозних програмних проектах, а що саме застосовують і як – це предмет Вашого дослідження). Вчіться якісно будувати програмне забезпечення, аналізувати та тестувати його. Саме БУДУВАТИ, СТВОРЮВАТИ. Оберіть відкритий проект, або почніть самі з друзями. Починайте його робити, застосовуючи те, що чого навчилися! Проблема постане у виборі інструментів (не тільки мови, а й систем командної розробки, збирання, моделювання, тестування, реструктуризації, компілятори та інфраструктурні речі, типу БД чи операційної системи). Спокійно сядьте і напишіть набір критеріїв які важливі з економічної, соціальної, технічної точки зору. Абсолютно чітко і строго. Складіть список кандидатів і на основі критеріїв зробіть висновок. Наприклад, якщо критерій навчитися застосовувати об’єкти – ПХП тут ні до чого. Якщо замикання – Жава ні до чого. Якщо нема наслідуваних систем і однорідна платформа Windows, треба обирати .NET, але якщо потрібна потужнна безкоштовна система реструктуризації коду – VisualStudio не допоможе. Робіть ваші висновки НАУКОВО (не маркетинго, не емоційно, ні товаришозапивно, ні форумно) обґрунтованими.

Конкретний інструмент ви швидко освоюєте, не поспішайте так до них. Наполегливий народ за 3 роки стає лідерами команд. Це не ракетна наука. Зате ті 2 роки навчання, проведені правильно, дадуть вам поштовх і імпульс стати інженерами а не техніками. Це щось типу довгострокових інвестицій. Одразу одні витрати, а далеко пізніше результат. Якщо не інвестуватимете – нічого не отримаєте, і все професійне життя труситиметесь, а що, якщо завтра моя компанія раптом спише той вольтметрик, що я на ньому так звик клацати, що я робитиму?

Канапа і модуляризація

На днях мені привезли нову канапу, однак на тому місці, де її необхідно було поставити, стояла величезна кутова стара канапа. Я був вдома геть один, а місце звільнити треба було. Ось таке собі завдання: винести стару канапу у іншу кімнату. Вона мало того, що важка, що не підняти, так ще й велика, що в одвірок ніяк не протиснеш! Але я із завданням успішно впорався. Стара канапа була МОДУЛЬНОЮ, тому необхідно було лише від'єднати модулі один від одного та винести кожен окремо (навіть по одному підняти і протиснути модуль було неабияк важко, однак можливо). Хоча ця історія банальна, та вона була прекрасним наглядним прикладом застосування принципу "розділяй та володарюй", і його окремого випадку - "модуляризація". Мені дуже подобаються аналогії у процесі пізнання, тому впоравшись із завданням я усвідомив, що це пречудова аналогія модуляризації у програмному забезпеченні та інших продуктах. Хоча інструмент модуляризації не завжди існував, ми часто його сприймаємо як щось невід'ємне, тому неправильно розуміємо його суть, неправильно його застосовуємо. Це особливо стосується студентів. Тож згадаймо канапу наступного разу, коли намагатимемося пояснити студенту/джуніору принцип модульності, або зловимо себе на думці, що завдання під рукою не підйомне та страшенно заплутане (така згадка може привести на канапу і занурити в сон, ну і нехай!).

Чи унікальність компонентів ПЗ є причиною його складності?

Я часто на своїх лекціях розповідаю студентам, що програмне забезпечення є найскладнішим інженерним творінням людини. Я, звісно, досі у цьому переконаний, але після декількох тривалих дискусій зі своїм студентом-дипломником похитнувся мій основний аргумент: у програмного забезпечення усі компоненти унікальні. Я завзято пояснював, що якщо з'являються два однакові шматки коду, то їх виносять у окрему підпрограму, залишаючи тільки виклик на старому місці. У той час електричний ланцюг може складатися з багатьох компонентів, що мають однакову функціональність: транзистори, резистори, конденсатори. Але чи доцільна така аналогія? Мабуть, коли мова заходить про компонент та про екземпляр компонента, це майже у всіх викликає замішання. І тут порівняння підпрограми з транзистором вкрай невдале, тому, що підпрограма є компонентом,  а ось транзистор у мікросхемі є екземпляром компонента. Навряд чи хтось прагнутиме дублювати специфікацію транзистора, яка репрезентує абстрактне поняття компонента-транзистора. В свою чергу підпрограма багато разів ініціюється комп'ютером, який в залежності від виконуваної підпрограми-специфікації "прикидається" різними екземплярами компонентів. Насмілюся  зробити висновок, що самі по собі компоненти унікальні в усіх інженерних галузях. Напевно замість згаданого аргументу слід говорити про те, що компонентів ("класів" компонентів) у програмному забезпеченні набагато більше ніж у інших творіннях людини, плюс до всього, кожен екземпляр компоненту може бути у величезній кількості станів. Можна сказати, що транзистор, у принципі, може знаходитись взагалі у нескінченній кількості станів, проте вони обумовлені законами фізики, а стани програмного забезпечення цілком визначають люди. А це вкрай складно.

Комплекс меншовартості

Цікаво спостерігати за українцями. Переважна більшість із них зневажають/не сприймають/не люблять/байдужі до усього українського: мови, культури, історії, символіки, ба навіть товарів та послуг, що в Україні вироблено. В результаті створювати якісний український продукт нікому. Тай й на виборах народ голосує за антиукраїнські політичні сили. Так і живемо у невизначеності: чи то ми європейська незалежна і успішна країна, чи то російська колонія, частина русского міра, безправна, корумпована, визискувана й злиденна. Просто дивовижно, що люди не усвідомлюють того, що ця країна побудована навколо національної ідеї. Тож зневага до цієї ідеї неминуче веде до краху цієї держави. Більшість щиро дивується, до чого тут мова, аби їсти було що! Та ні, усе складніше, набагато складніше. До прикладу, аби схід гарячкувато не голосував за російську мову, ми б не мали президентом пана Януковича, з усіма наслідками. Схоже, що ця нелюбов та зневага до українського і є проявом того комплексу меншовартості та колоніальної свідомості. Я працюю в університеті, бачу багато молодих людей, навіть юних, і їх уже пронизує цей комплекс. Тож марно сподіватися, що цей комплекс зникне сам собою з часом. Доки є імперіалістична Росія вона буде, спільно з нашими місцевими холуями, перетворювати наш народ і нашу націю у біомасу, її простіше визискувати. Тож, на мою думку, вільну і процвітаючу країну ми зможемо побудувати лише у щоденній боротьбі з комплексом меншовартості.

Чи є майбутнє у керованої моделлю розробки програмного забезпечення

Давненько не писав. Часто виникає бажання щось написати, але потім якось руки не доходять. Аж раптом нещодавно трапилась мені на очі презентація шановного Джона ден Хаана під назвою «Чому у керованої моделлю розробки програмного забезпечення немає майбутнього» (Why there is no future for model driven development).  Оскільки я палкий прихильник розробки програмного забезпечення, керованої моделлю, не можу не відреагувати. Свою думку я йому коротко висловив на сайті, а тепер вирішив трохи детальніше розміркувати.

Почнімо з визначення. Отже розробка програмного забезпечення, керована моделлю (РКМ) – це методологія розробки програмного забезпечення (ПЗ), що спрямована на використання моделей ПЗ як основних продуктів розробки та генерування на їх основі інших робочих продуктів, у тому числі і вихідного коду, наприклад на Java або C++. Як і більшість понять у галузі ПЗ, це поняття запозичене із більш традиційних інженерних дисциплін, хоча там на керованості моделлю так явно не наголошують, оскільки використання моделей є загальноприйнятим. Ніхто навіть і уявити собі не може конструювання такої будівлі як Московський Міст у Києві чи літак «Мрія» без попередньої побудови великої кількості різноманітних спеціалізованих моделей. Моделі допомагають зрозуміти складні завдання та їх потенційні розв’язки через абстракцію. Однак у галузі розробки ПЗ моделювання аж ніяк не набуло широкого впровадження. Не будемо тут намагатися аналізувати причини, це тема окремого посту, а перейдемо відразу до демонстрації того, що РКМ має майбутнє.

Не вдаючись до історії постійного підвищення рівня абстракції мов програмування, відразу перерахуємо фундаментальні принципи програмної інженерії та покажемо як РКМ відповідає цим принципам: строгість та формальність, розділення відповідальності, модульність, абстракція, передбачення змін.   

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

Розділення відповідальності. Один з найголовніших принципів інженерії взагалі та інженерії ПЗ зокрема. Розділення відповідальності - це спрощення єдиного монолітного розв’язання завдання шляхом поділу на взаємодіючі розв’язання під-завдань. Моделювання різних аспектів ПЗ, таких як бізнес-логіка або архітектура, за допомогою різних, предметно-орієнтованих мов програмування (DSLs) є реалізацією цього принципу. Особливу вагу для бізнесу мають предметно-орієнтовані мови, призначені для опису конкретної галузі в якій працюватиме застосування. Наприклад, мови для опису управляння страховими полісами, бізнес процесів, алгоритмів розрахунку статистики успішності студентів і т.д. Програму, написану такою мовою зможе читати бізнес експерт, а програму мовою Java – ні.

Модульність. Цей принцип є окремим випадком попереднього. Суть його полягає у розбитті системи на простіші частини, що називаються модулями, компонентами, сервісами і т.д. Перераховані назви є, безумовно, абстракціями, створеними для реалізації принципу модульності. Однак ми не обмежені лише цими абстракціями у побудові ПЗ! Ми можемо послуговуватися, формально визначивши, такими абстракціями як компонент, процес, замикання, виключення, повідомлення, синхронізація, з’єднувач, двигун, крило літака, контролер, гамбургер, страховий поліс, множина яких обмежена лише нашою фантазією! Усі вони є частинками певного застосування, а моделювання ПЗ з їх використанням є реалізацією принципу модульності.

Абстракція. Принцип не потребує коментування. Відзначимо, що усе ПЗ є абстракцією. Абстракція дозволяє нам створювати складні системи. Абстракція подарувала нам поняття класу, об’єкту, події, функції, бібліотеки, тощо. Розробка ПЗ є складною. ПЗ є найскладнішим продуктом, що створює людина. Якщо задатися запитанням: а скільки інженерів-механіків я знаю? А скільки інженерів програмістів? Думаю, останніх у декілька разів більше. Гадаю, саме робота на надто низькому рівні абстракції змушує компанії наймати усе більше інженерів з ПЗ та виставляти захмарні ціни за розроблення та супроводження ПЗ. РКМ дає можливість підвищувати рівень абстракції та створювати нові абстракції, що краще відповідають потребам зацікавлених у розробці сторін.

Передбачення змін наголошує на тому, що необхідно передбачати та створювати зручні умови для внесення змін у ПЗ. Як правило, реалізацію цього принципу забезпечують модульність та розділення відповідальності. Якщо різні аспекти системи модельовані окремо, то можна легко змінювати окремо від інших аспектів бізнес-логіку, архітектуру, базову абстрактну машину (мови програмування, операційні системи, проміжне ПЗ, бази даних, тощо). Тобто РКМ надає інструменти для ефективної реалізації принципу передбачення змін.

Звісно, РКМ не є срібною кулею, гадаю такої кулі не буде винайдено. Однак, на мою думку, це закономірний рух уперед і дозрівання розробки програмного забезпечення до інженерної дисципліни. Автор коментованої доповіді відзначив, що моделювання має стосуватися не лише конструювання ПЗ, а й інших фаз розробки, особливо збору вимог, та розгортання. З цим важко не погодитися, тому правильніший термін був би не розробка, керована моделлю, а інженерія ПЗ, керована моделлю. Аби така інженерія стала реальністю, необхідно ще дуже багато наукових досліджень та практичної роботи.

Отже, чи є майбутнє у інженерії ПЗ, керованої моделлю? Судячи з усього так, інакше немає майбутнього у ПЗ як такого.

Як стати успішним архітектором програмного забезпечення

Молоді спеціалісти, в тому числі і я, часто захоплюються різними титулами, хочуть ці титули мати. Титул, чи посада "Архітектор ПЗ" є особливо омріяною. Хоча я не думаю, що архітектором буди краще чи престижніше, ніж кодувальником чи тестувальником, все ж архітектура є для мене найцікавішою галуззю знань в програмній інженерії. Однак чи ж інженерією є розроблення програмного забезпечення? Кількість дискусій на дану тему зростає, що змушує задуматися. Погляньте лише на розмах маніфесту програмних ремісників. І якщо інженерія програмного забезпечення не інженерія, то архітектуру освоїти з книжок або в університеті неможливо... З цього приводу хочу навести уривок з інтерв'ю Франка Бушмана (програмного інженера з Siemens) для Software Engineering Radio (епізод 54).

Міхаель: Як людина може стати успішним архітектором?

Франк: Тут я процитую свого наставника: нехай працюють над складними проблемами. Не починайте навчати програмній інженерії, або програмній архітектурі використовуючи маленькі приклади (завдання). Студент або початківець може вирішити їх за допомогою будь-якої технології, а тому не побачить їх переваг та недоліків. Але якщо студент працює над складними проблемами, які важко розв'язати, він в результаті може усвідомити переваги та внесок різних технологій. А ще практика, практика, практика, практика... Я розглядаю інженерію програмного забезпечення не як інженерну дисципліну, і навіть не як мистецтво, а як ремесло. А ремісник потребує практичного досвіду (очевидно, що передається від майстра до учня, який спостерігає за тим, як працює майстер та допомагає йому) та дискусій з іншими ремісниками.

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

Ідея обчислювального процесу

Я сьогодні почав читати книгу "Structure and Interpretation of Computer Programs". Початок першого розділу мені так сподобався, що я вирішив його перекласти. Мені здається, що для студентів-програмістів ці декілька абзаців можуть стати певним просвітленням.

Ми збираємося вивчати ідею обчислювального процесу. Обчислювальні процеси є абстрактними істотами, які населяють комп'ютери. По мірі їх виконання, процеси маніпулюють іншими абстрактними істотами, які називаються даними. Виконання процесу спрямовує система правил, яка називається програмою. Люди створюють програми, для спрямування процесів. По суті, ми заклинаємо духів комп'ютера нашими заклинаннями.
Обчислювальний процес, дійсно, дуже схожий на поняття чаклунського духу. Його не можливо розглянути або торкнутися. Він зовсім не складається з матерії. Однак, він дуже реальний. Він може виконувати інтелектуальну роботу. Він може відповідати на запитання. Він може вплинути на світ виплатою грошей у банку або контролем маніпулятора на заводі. Програми, які ми використовуємо щоб чаклувати процеси - подібні до заклинань чаклуна. Вони ретельно складені з символічних виразів на таємничих і езотеричних мовах програмування та приписують завдання, які ми хочемо, щоб наші процеси виконували.
Обчислювальні процеси в комп'ютері, що правильно працює, виконують програми точно й правильно. Таким чином, подібно до учня чаклуна, програмісти-початківці повинні навчитися розуміти і передбачати наслідки їх чаклунств. Навіть невеликі помилки (які зазвичай називають багами або дефектами) в програмах можуть мати складні та непередбачувані наслідки.
На щастя, навчання програмуванню значно менш небезпечне ніж вивчення магії, тому що духи з якими ми маємо справу, зручно утримуються в безпечному режимі. Проте реальне програмування вимагає ретельності, досвіду і мудрості. Наприклад, невелика помилка в системі автоматизованого проектування може призвести до катастрофи літака, пошкодження або самознищення промислового робота.
Кваліфіковані інженери з програмного забезпечення можуть організувати програми так, що вони можуть бути достатньо впевнені у тому, що процеси, які управляються цими програмами виконають призначені завдання. Кваліфіковані інженери можуть наперед чітко уявляти собі поведінку їх систем. Вони знають як організувати програми так, щоб непередбачені проблеми не призвели до катастрофічних наслідків, а коли проблеми виникають, вони можуть налагоджувати свої програми. Добре розроблені обчислювальні системи, подібно до добре продуманих автомобілів або ядерних реакторів, розроблені на модульній основі таким чином, щоб їх частини могли бути побудовані, замінені і налагоджений окремо.