Ако некогаш сте се занимавале со сметководство, веројатно знаете дека не е многу забавна професија. Ако не, еве краток преглед. Постојат многу правила што треба да се следат, впишани во локални, национални и меѓународни стандарди, и многу модерни ERP системи ги имаат барем делумно имплементирано и автоматизирано. Нема вистинска креативност во работата - освен ако не сакате да работите во организиран криминал, а професијата е високо регулирана. Постои многу контрола околу тоа кој може да ја работи работата, или кој може да работи некој дел од работата и каков вид сертификати треба да има, иако суштината на сметководствениот процес е во голема мера непроменета откако била кодифицирана некаде за време на ренесансата или отприлика во тоа време.
Никој нема хоби во сметководство. Не постои интересен проект во сметководството што можете да го споделите со вашите пријатели, а нема ниту интересни или провокативни конференции или средби каде што темата е сметководството. Дали некогаш имало сметководител/ка што зборувал/а на TED? Не проверив, но ако имало, тој/таа веројатно зборувал/а за нешто друго.
Каква врска има ова со софтверското инженерство? Да го искористиме смешниот дијаграм на Дон Мекмилан, сега гледаме поместување од решавањето проблеми во софтверското инженерство. Наместо да решаваме проблеми, ние пишуваме документи што им кажуваат на агентите да решат некој проблем. Дури и во овие рани денови гледаме проекти што се појавуваат со стандардни .md датотеки за да извршат одредени задачи или да пишуваат на одреден јазик. Мислам дека наскоро да видиме стандардна .md датотека со вештини за креирање на R пакет или за креирање на FastAPI или нешто друго, при што сложеноста на проблемот што се решава ќе се зголемува со текот на времето.
Постои траекторија во која вештините на агентите ќе станат нешто слично на Меѓународните стандарди за финансиско известување. Мислам дека не сме далеку од тоа големите компании да произведуваат „проверени“ вештини (кога отидов на LinkedIn за да го објавам овој текст, ме пречека објава од Антон Абизов која зборува за алатка за проверени вештини :) за да прават одредени работи во нивниот екосистем. Замислете на пример „AWS проверени вештини за инфраструктура“. И можеби ваквите вештини ќе почнат да се продаваат за определена цена во зависно од сервисите или регионот во светот каде што ќе се користат.
Понатаму, ако сте компанија што работи со ревизија на софтвер, веројатно ќе имате вештина што ќе му наложи на вашиот агент да ја ревидира работата на друг агент. Не би ме изненадило ако т.н. Big 4 ревизорски куќи веќе размислуваат за ова.
Што останува за софтверските инженери? Помалку на решавањето проблеми, повеќе OCD? Мислам дека не е тешко да се замисли дека идната работа ќе биде претежно читање на .md датотеки и обид за фаќање недоследности што се провлекуваат низ проверката на правопис или слични алатки. Замислете дека некој напуишал cat наместо car во некоја .md датотека, а некој друг да се обидува да открие од каде доаѓа грешката. Тоа ми звучи многу поблиску до ловење на несовпаѓањето на салдото на билансот на состојба, отколку до подобрување на лошо имплементирана функција што понекогаш го блокира компјутерот на корисникот.
Дали е ова добро или лошо? Претпоставувам дека зависи од тоа за кого или што е добро или лошо. Мислам дека дури и ако излезе дека сме на оваа траекторија, веројатно тоа нема да влијае на сегашната генерација софтверски инженери.
Сепак, не размислувајќи за другите прашања што се покренуваат (како што се општата грижа за животната средина, изгледите за вработување и меурот на берзата), мислам дека со текот на времето е многу веројатно да бидеме сведоци на трагедијата на заедничките добра во светот на слободниот софтвер.
Потоа можеби голем дел од софтверот ќе стане како евтините чадори што ги купувате на улица од ад-хок продавачи кога одеднаш ќе почне да врне, а кои се кршат по втората употреба и ги фрлате. И можеби голем дел од софтверот ќе се претвори во проблем сличен на пластиката во океаните и некои инженери ќе се преквалификуваат за да се справат со тоа.
За сегашната генерација мислам дека ова ќе изврши притисок врз градењето заедници околу софтвер, хоби проекти и настани. Размислете: зошто би сакал да дојдам на настан на кој ќе разговараме за вашата најнова .md датотека? Таа ионака не е наменета за луѓе. Или зошто би се мачел со пријавување грешка или pull request на проект кој во голема мера е изграден од агент за кодирање? Внатрешната мотивација да помагамe и да бидeмe вклучени со луѓе едноставно ја снемува. Дури би рекол дека нема мотивација да ја испратам мојата претплата на агент да направи pull request на твојот проект управуван од агент. Која би била мојота презентација на lightning talks на следнта конференција: како да ја форматирате вашата .md датотека во 10 лесни чекори? Постои вештина и за тоа. На крајот на краиштата, дали некогаш сте слушнале за заедница за сметководство?