Чи програмування як професія перемагає донизу? [зачинено]

Мені здається, індустрія програмування перемагає донизу. Якщо ми скористаємося практикою:

1. Не потребує часу для впровадження кращих практик
2. Використовуйте код інших людей якомога більше (спеціальний код як відповідальність)
3. Використання мов все більш високого рівня для підвищення продуктивності
4. "Інструменти" для розробки на основі GUI, які значно спрощують "програмування" і не вимагають від людей розуміння сантехніки за кодом

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

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

Я думаю, ви задали дуже питне питання.

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

Змінюється технологія отримання завдання, але завдання все-таки потрібно виконати: Автомобілі все ще повинні бути виготовлені / зібрані, перш ніж їх можна буде загнати; код / ​​бізнес-логіку все-таки потрібно скласти, щоб програма працювала.

Зміни в технології представляють вибір для програмістів: вивчіть програмування на основі GUI або інструменти графічного інтерфейсу програми ... або ... щось інше цілком.

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

Найкращі побажання,

КМ

До трендів, які ви згадуєте, я додав би ще один, який ІМХО пояснює їх:

Існує набагато більше програмістів (як і раніше).

Кількість завдань, які потребують або включають програмування, постійно зростає, і навіть швидше, ніж кількість програмістів. Нині в середньому автомобілі є кілька мікрочіпів. Через 5 років у вашому холодильнику та тостері може з’явитися мікросхема. Через 10 років твоя нижня білизна? ... А комусь потрібно виготовити все те програмне забезпечення, щоб ці роботи були. Таким чином, докладаються всі можливі зусилля для автоматизації того, що є автоматизованим, та для підвищення «продуктивності» (проте це визначено). І набирається все більше свіжих мізків.

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

Дозвольте мені зіграти захисника диявола проти ваших точок вище:

Не потребує часу для впровадження кращих практик

Дуже багато людей, багато людей. Ще десять років тому, коли я вперше виявив тестування приладів та спритний підхід, ніхто з моїх колег не мав найменшого уявлення, що це таке. Нині це майже стандартний матеріал у вузах, тому багато нових випускників це вже розуміють.

Використовуйте код інших людей якомога більше (спеціальний код як відповідальність)

На відміну від чого? Винаходити колесо? Або використовувати код інших людей, щоб уникнути цього?

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

Використання мов все більш високого рівня для підвищення продуктивності

На відміну від кодування всього в зборі? ;-)

"Інструменти" для розробки на основі GUI, які значно спрощують "програмування" і не вимагають від людей розуміння сантехніки за кодом

ІМХО будь-яким інструментом можна неправильно використовувати. Що не означає, що будівельники GUI були обов'язково ідеальними або навіть хорошими - більшість (або принаймні деякі) з них є корисними у своїх межах. Але якщо хтось не знає цих меж, це проблема інструменту чи його користувача?

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

• загальну кількість коду та
• шанси сторонніх людей коли-небудь побачити такий код

було набагато набагато менше.

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

Ви правильно узагальнюєте ситуацію, але повністю неправильно трактуєте значення.

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

Дозвольте сказати так, через 100 років відтепер створити систему настільки складну, як Фейсбук чи Google. Я не кажу про їх веб-сторінки, я маю на увазі їх центри обробки даних. Будь-хто зможе це зробити. Він буде вбудований у телефони, припускаючи, що ми ще їх ще використовуємо. Але НЕ, все ще будуть програмісти, і хоча вони не працюватимуть над такими «тривіальними» системами через 100 років, вони будуть працювати над системами настільки складнішими і складнішими, що ніхто тут навіть не може почати розуміти їх сферу і масштаб. І такі системи, як зараз, будуть далеко недосяжні для звичайного офісного працівника, оскільки деякі люди, які називаються програмістами, вирішать спеціалізуватися на просуванні технології тієї епохи до її крайніх меж.

Я читав таку річ вже сорок років, і я не був на початку прогнозів. Це ще не сталося.

COBOL був оригінальним інструментом розробки, призначеним для усунення потреби бізнес-програмістів, і був набагато вищою мовою, ніж асемблер. Бібліотеки коду (щоб уникнути необхідності писати власний код) мають подібну давнину.

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

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

Проблема від COBOL до сучасних інструментів розробки полягає в тому, що вони не замінюють здатність приймати неточні специфікації та перетворювати їх на щось точне та корисне. У цьому полягає основна здатність програмістів, і тому ми довго не їдемо.

Програмісти асамблеї та FORTRAN, ймовірно, говорили те саме, коли на світ виходили структуроване програмування та широкі перекладачі.

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

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

Коли перетягування або інші методології програмування є загальноприйнятими, світ вимагатиме вирішення ще складніших і складних проблем, і для їх вирішення знадобляться програмісти, які використовують нові нові інструменти. Пост мети буде переміщено.

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

Так, це і повинно бути

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

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

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

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

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

Незалежно від того, що ви можете автоматизувати або зняти з полиці, більшість пакується програмного забезпечення поділяється на дві категорії:

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

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

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

Я не беру ваших аргументів:

1. Не потребує часу для впровадження кращих практик

крім того.

1. Використовуйте код інших людей якомога більше (спеціальний код як відповідальність)

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

1. Використання мов все більш високого рівня для підвищення продуктивності

Продуктивність сама по собі погана - чи не так?

1. "Інструменти" для розробки на основі GUI, які значно спрощують "програмування" і не вимагають від людей розуміння сантехніки за кодом

Якщо інструмент виконує завдання: Використовуйте його. Якщо ні: відмовтеся. Якщо обіцянка виконується, а людям дійсно не потрібно розуміти код - молодець! Ви, здається, говорите, що це обіцянка, яка не виконується?

(Номери тут автоматично передаються неправильно. :))

Візуальне програмування не менш достовірне або заслуговує приниження, ніж текстове програмування.

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

Якщо у вас є можливість спробувати Labview, ви можете побачити потенціал (або навіть спеціалізований варіант у середовищі Lego NXT). Хоча не без недоліків чи недоліків, є спадкові переваги. Бачити - вірити.

Практики програмування не тільки підвищують продуктивність та зменшують витрати на певні типи розробок (ваша гонка до низу), але збільшують можливості застосування та очікування клієнтів (таким чином заохочуючи гонку до вершини). Свідчіть бонуси, які Гул і Facebook виплачують, щоб отримати топ-технологі.

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

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

Якщо ми скористаємося практикою:

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

Якщо ми скористаємося практикою: