Meestal schrijf ik over IT - over verschillende, min of meer zeer gespecialiseerde onderwerpen zoals SAN/opslagsystemen of FreeBSD, maar nu probeer ik over het vakgebied van iemand anders te spreken, dus voor veel lezers zal mijn verdere redenering behoorlijk controversieel of zelfs naief. Dit is echter hoe het is en daarom ben ik niet beledigd. Maar als directe consument van kennis en onderwijsdiensten, met excuses voor deze vreselijke bureaucratie, en ook als enthousiaste amateur die graag urbi et orbi wil delen met zijn twijfelachtige ‘vondsten en ontdekkingen’, kan ik ook nauwelijks zwijgen.
Daarom sla je deze tekst verder over voordat het te laat is, of je vernedert jezelf en volhardt, want, terwijl ik losjes een beroemd liedje citeer, wil ik alleen maar fietsen.
Laten we dus, om alles in perspectief te plaatsen, van veraf beginnen – van school, die in theorie basiszaken zou moeten leren over wetenschap en de wereld om ons heen. In wezen wordt deze bagage gepresenteerd met behulp van traditionele methoden van de scholastiek, zoals het samenstellen van een zorgvuldig ontkracht schoolcurriculum, dat een beperkt aantal conclusies en formules bevat die door leraren zijn voorbereid, evenals herhaalde herhalingen van dezelfde taken en oefeningen. Door deze benadering verliezen de onderwerpen die worden bestudeerd vaak de helderheid van de fysieke of praktische betekenis, wat naar mijn mening ernstige schade toebrengt aan de systematisering van kennis.
Over het algemeen zijn schoolmethoden aan de ene kant goed om op grote schaal een minimaal vereiste hoeveelheid informatie in de hoofden te hameren van degenen die niet echt willen leren. Aan de andere kant kunnen ze de ontwikkeling vertragen van degenen die in staat zijn om meer te bereiken dan alleen het trainen van een reflex.
Ik geef toe dat de situatie in de dertig jaar sinds ik van school ging, ten goede is veranderd, maar ik vermoed dat deze nog steeds niet ver verwijderd is van de middeleeuwen, vooral sinds de religie weer naar school is teruggekeerd en zich daar best goed voelt.
Ik heb nooit een hogeschool of een andere instelling voor beroepsonderwijs bezocht, dus ik kan er niets inhoudelijks over zeggen, maar het risico is groot dat het studeren van een beroep daar uitsluitend neerkomt op het trainen van specifieke toegepaste vaardigheden, terwijl je de theoretische aspecten uit het oog verliest. basis.
Doe Maar. Tegen de achtergrond van school lijkt een onderwijsinstituut of universiteit, vanuit het oogpunt van kennisverwerving, een echte uitlaatklep. De mogelijkheid, en in sommige gevallen zelfs de verplichting, om de stof zelfstandig te bestuderen, en een grotere vrijheid om leermethoden en informatiebronnen te kiezen, openen ruime mogelijkheden voor degenen die kunnen en willen leren. Het hangt allemaal af van de volwassenheid van de student en zijn ambities en doelen. Ondanks het feit dat het hoger onderwijs tot op zekere hoogte de reputatie heeft gekregen dat het stagneert en achterloopt op de ontwikkeling van moderne IT, slagen veel studenten er nog steeds in om cognitiemethoden in de praktijk te brengen, en krijgen ze de kans om de tekortkomingen van de school te compenseren. onderwijs te geven en de wetenschap van het autonoom en onafhankelijk leren opnieuw onder de knie te krijgen om kennis te verwerven.
Wat betreft allerlei cursussen die worden georganiseerd door leveranciers van IT-apparatuur en software, moet je begrijpen dat hun hoofddoel is om consumenten te leren hoe ze hun programma's en apparatuur moeten gebruiken, vaak algoritmen en theoretische grondslagen, evenals de belangrijkste details van wat “onder de motorkap” verborgen is, worden alleen in de lessen besproken voor zover de fabrikant daartoe gedwongen wordt om algemene informatie over de technologie te verstrekken zonder bedrijfsgeheimen prijs te geven en niet te vergeten de voordelen ervan ten opzichte van concurrenten te benadrukken.
Om dezelfde redenen heeft de certificeringsprocedure voor IT-specialisten, vooral op instapniveau, vaak te lijden onder tests van onbeduidende kennis, en tests stellen voor de hand liggende vragen, of erger nog, ze testen de reflexieve kennis van de stof van de aanvrager. Waarom vraagt u de ingenieur bijvoorbeeld tijdens een certificeringsexamen niet “met welke argumenten: -ef of -ax moet u het ps-commando uitvoeren”, verwijzend naar die specifieke variant van UNIX- of Linux-distributie. Een dergelijke aanpak vereist dat de testpersoon deze commando's uit het hoofd leert, evenals vele andere commando's, ook al kunnen deze parameters bij de mens altijd worden verduidelijkt als de beheerder ze op een gegeven moment vergeet.
Gelukkig staat de vooruitgang niet stil, en over een paar jaar zullen sommige argumenten veranderen, andere zullen verouderd raken, en er zullen nieuwe verschijnen die de plaats van de oude zullen innemen. Zoals gebeurde in sommige besturingssystemen, waar ze na verloop van tijd een versie van het ps-hulpprogramma begonnen te gebruiken die de voorkeur geeft aan een syntaxis zonder "minnen": ps ax.
Dus wat dan? Dat klopt, het is noodzakelijk om specialisten opnieuw te certificeren, of beter nog, er een regel van te maken dat eens in de N jaar, of bij de release van nieuwe versies van software en apparatuur, “verouderde diploma’s” worden ingetrokken, waardoor ingenieurs worden aangemoedigd om certificering te ondergaan met behulp van de bijgewerkte versie. En natuurlijk is het noodzakelijk om certificering betaald te maken. En dit ondanks het feit dat het certificaat van de ene leverancier de lokale waarde aanzienlijk zal verliezen als de werkgever van de specialist van leverancier verandert en soortgelijke apparatuur bij een andere leverancier gaat kopen. En oké, als dit alleen zou gebeuren met “gesloten” commerciële producten, waartoe de toegang beperkt is, en daarom heeft certificering daarvoor enige waarde vanwege de relatieve zeldzaamheid ervan, maar sommige bedrijven zijn behoorlijk succesvol in het opleggen van certificering voor “open” producten, bijvoorbeeld zoals bijvoorbeeld gebeurt bij sommige Linux-distributies. Bovendien proberen ingenieurs zelf verslaafd te raken aan Linux-certificering en besteden ze er tijd en geld aan, in de hoop dat deze prestatie hun gewicht op de arbeidsmarkt zal vergroten.
Met certificering kunt u de kennis van specialisten standaardiseren, hen één gemiddeld kennisniveau geven en hun vaardigheden aanscherpen tot het punt van automatisering, wat uiteraard erg handig is voor een managementstijl die werkt met concepten als: manuren, menselijke grondstoffen en productienormen. Deze formele benadering heeft zijn wortels in de gouden eeuw van het industriële tijdperk, in grote fabrieken en industriële fabrieken die rond de lopende band zijn gebouwd, waar van elke arbeider wordt verwacht dat hij specifieke handelingen nauwkeurig en in een zeer beperkte tijd uitvoert, en er simpelweg geen tijd om te denken. Om na te denken en beslissingen te nemen, zijn er echter altijd andere mensen in de fabriek aanwezig. Het is duidelijk dat een persoon in een dergelijk schema verandert in een "radertje in het systeem" - een gemakkelijk vervangbaar element met bekende prestatiekenmerken.
Maar zelfs niet in een industriële onderneming, maar in IT dwingt zo'n verbazingwekkende kwaliteit als luiheid mensen om naar vereenvoudiging te streven. In het Skills, Rules, Knowledge (SRK)-systeem geven velen van ons er vrijwillig de voorkeur aan om vaardigheden te gebruiken die tot op het punt van automatisme zijn ontwikkeld en de regels te volgen die slimme mensen hebben ontwikkeld, in plaats van moeite te doen om problemen diepgaand te onderzoeken en problemen op te lossen. zelf kennis vergaren, omdat dit zoveel lijkt op het uitvinden van weer een betekenisloze fiets. En feitelijk keurt het hele onderwijssysteem, van school tot cursussen/certificering van IT-specialisten, dit goed, door mensen te leren proppen in plaats van onderzoek te doen; trainingsvaardigheden die geschikt zijn voor specifieke gevallen van toepassingen of apparatuur, in plaats van het begrijpen van de grondoorzaken, kennis van algoritmen en technologieën.
Met andere woorden, tijdens de training wordt het leeuwendeel van de inspanning en tijd besteed aan het oefenen van de aanpak "Als gebruik dit of dat hulpmiddel”, in plaats van te zoeken naar een antwoord op de vraag “Waarom Werkt het zo en niet anders?” Om dezelfde redenen gebruikt het IT-veld vaak de “best practices”-methode, die aanbevelingen beschrijft voor de “beste” configuratie en het gebruik van bepaalde componenten of systemen. Nee, ik verwerp het idee van best practices niet, het is heel goed als spiekbriefje of checklist, maar vaak worden dergelijke aanbevelingen gebruikt als een ‘gouden hamer’, het worden onschendbare axioma’s die ingenieurs en management strikt volgen en gedachteloos, zonder de moeite te nemen om het antwoord te vinden op de vraag “waarom” de ene of de andere aanbeveling wordt gedaan. En dit is vreemd, want als een ingenieur bestudeerd и weet materiaal, hoeft hij niet blindelings te vertrouwen op gezaghebbende meningen, die in de meeste situaties geschikt zijn, maar hoogstwaarschijnlijk niet van toepassing zijn op een bepaald geval.
Soms bereikt het in verband met best practices het punt van absurditeit: zelfs in mijn praktijk was er een geval waarin leveranciers die hetzelfde product onder verschillende merken leverden enigszins verschillende opvattingen over het onderwerp hadden, dus toen ze op verzoek van een bedrijf een jaarlijkse beoordeling uitvoerden de klant bevatte één van de rapporten altijd een waarschuwing over schending van best practices, terwijl de andere juist prees voor volledige naleving.
En laat dit nu te academisch klinken en op het eerste gezicht niet toepasbaar op gebieden als: ondersteunen IT-systemen waarbij de toepassing van vaardigheden vereist is, niet de studie van een onderwerp, maar als er een verlangen is om de vicieuze cirkel te doorbreken, ondanks de schaarste aan echt belangrijke informatie en kennis, zullen er altijd manieren en methoden zijn om erachter te komen het eruit. Het lijkt mij tenminste dat ze helpen:
- Kritisch denken, wetenschappelijke benadering en gezond verstand;
- Zoeken naar oorzaken en bestuderen van primaire informatiebronnen, bronteksten, standaarden en formele beschrijvingen van technologieën;
- Onderzoek versus proppen. De afwezigheid van angst voor ‘fietsen’, waarvan de constructie het op zijn minst mogelijk maakt om te begrijpen waarom andere ontwikkelaars, ingenieurs en architecten deze of gene manier hebben gekozen om soortgelijke problemen op te lossen, en, op zijn hoogst, een fiets zelfs beter dan eerst.
Bron: www.habr.com