Thread: IT: gebakken lucht ?
-
15-04-2019, 22:41 #46Banned
- Registered
- 11/09/16
- Location
- Paaseiland
- Posts
- 2,790
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/336
Zeg, ik ga u echt nie in detail een hele codestructuur uitleggen he. Ge snapt het toch niet en dat is gewoon niet mogelijk om dat hier uit te typen. Lees u wat boeken over talen of methodologieen. Of kijk op stackoverflow.
Daarbuiten moet ge ook maar eens kijken naar Agile en Scrum principes. Of deployment strategieen. Of continuous integration. Of source control. Code reviews, commits en pullrequests? Of ...
Ja er worden vaak veel en complexe termen gehanteerd. Maar dat is toch normaal vakjargon?
Een chirurg gebruikt ook woorden die ik niet ken en heel specifiek in zijn wereld wel gekend zijn.
Heck, als ik werkwoorden hoor die een chefkok gebruikt, duizelt het ook al.
Vraag eens wat die 2 mensen heel de dag doen?
Een antwoord als 'patienten opensnijden' of 'eten koken', zult ge terugkrijgen, maar weet ge dan iets van hoe die hun dag doen?
Exact hetzelfde met iedere specialisatie in de IT.
Sommigen zeggen hier dat het hautain is, maar ik vind het dan weer denigrerend hoe de vraag gesteld wordt. Alsof alles te minimaliseren valt in 3 regels tekst.
Kan een geoloog dat wel beantwoorden dan? Of reageert die ook hautain?
Ik werk met studenten en stagairs die mij wel begrijpen als ik vaktermen gebruik. Wij spreken dezelfde jargon.
Als ge het in zo enkele posts ineens allemaal zou begrijpen waart ofwel gij een genie ofwel ik mn job kwijt.Last edited by Tailball; 15-04-2019 at 22:51.
1 members found this post helpful.
Reply With Quote
-
-
15-04-2019, 22:50 #47no votes
Reply With Quote
-
15-04-2019, 23:06 #48Member
- Registered
- 29/11/06
- Location
- Zuid-Limburg
- Posts
- 6,704
- iTrader
- 5 (100%)
- Mentioned
- 11 Post(s)
- Reputation
- 43/1549
Het probleem met politici is niet dat ze géén enkel nut hebben. Dat beweren zou inderdaad onzinnig zijn. Het probleem met politici in België is dat we er véél te véél van hebben.
Een bedrijf die meer werknemers heeft dan het nodig heeft, zonder dat die extra werknemers extra meerwaarde creëren, loopt het risico verlies te gaan maken en failliet te gaan...
Bij de overheid, die in dit land uit 6 regeringen/parlementen bestaat, geldt die logica natuurlijk niet, maar onze staatsschuld is natuurlijk wél navenant.
Ik kan me overigens ook gerust inbeelden dat in sommige bedrijven de IT-dienst niet altijd even nuttig is. Soms is dat maar goed ook, als de netwerkbeheerder(s) van een groot bedrijf weinig werk hebben buiten wat minor issues die er altijd wel zijn, omdat alles goed draait, zal het bedrijf net wél blij zijn. Het houdt die netwerkbeheerders dan uiteindelijk in dienst voor wanneer het toch moest mislopen, om problemen zo snel mogelijk opgelost te hebben.
Dat gezegd zijnde, hoewel ik de schijnbare vooroordelen van de threadstarter niet deel, zou ik op professioneel vlak wel graag eens van iemand horen die actief is in de sector hoe de gemiddelde werkdag/werkweek van een back-end developer eruit ziet (Java/.NET/etc.), mag eventueel ook in PM.no votes
Reply With Quote
-
15-04-2019, 23:07 #49Member
- Registered
- 11/11/03
- Location
- Brussel
- Posts
- 4,195
- iTrader
- 0
- Mentioned
- 9 Post(s)
- Reputation
- 44/629
Aan de andere kant, een kok of een chirurg kunnen dat ook wel concreet uitleggen als ze met een leek bezig praten. Vakjargon is handig omdat het vaak communicatie tussen mensen die de woorden snappen vereenvoudigt, maar er is toch niet echt een reden waarom je geen uitleg zonder vakjargon zou kunnen geven?
Om het met een quote van Einstein te zeggen: "If you can't explain it simply, you don't understand it well enough."1 members found this post helpful.
Reply With Quote
-
15-04-2019, 23:26 #50
Concreet voorbeeld van iets zeer simpel.
Een klant heeft een aantal printers staan met een weegbrug, en wil dat wanneer een vrachtwagen gewogen wordt, automatisch het gewicht afgeprint wordt en de leverancier deze weegbonnen op een website kan zien. Een lijst van alle IT-ers die nodig zijn, en dit zijn vaak verschillende mensen:
De IT-er van de weegbrug leverancier, die meestal een kaske aan de balie zetten waarop je het gewicht kan aflezen op de LED display.
De IT-er die een communicatie-design opstelt, waarbij hij een bepaalde convertor kiest van serieel signaal (seriele kabel) naar ethernet (netwerkkabel).
De IT-er die deze convertor correct kan verbinden met het bedrijfsnetwerk, welk IP adres, welke switch, welke soort kabel, welke afstand...
De IT-er die in dit netwerk een nieuwe server installeert, type Windows OS, met alle beveiligingsupdates, licenties, enzovoort.
De IT-er die een applicatie schrijft (NET of whatever) die op deze server kan draaien, en die in staat is via ethernet protocol met die weegbrug display te communiceren om data uit te lezen.
De IT-er die onderzoekt via welk protocol die printers dienen aangestuurd te worden, en deze code verwerkt in het NET programma
De IT-er die een Cloud-gebasseerde databank aanmaakt dewelke toegankelijk is door dit NET programma
De IT-er die de zaken geprint door dit NET programma kan opslaan in een deze databank in de cloud
De IT-er die de databank in de cloud toegankelijk maakt via een rapporterings website die draait in de cloud
En die mensen moeten allemaal gecoordineerd worden, deze coordinators noemen zichzelf vaak ook IT-er terwijl ze er eigenlijk technisch niet veel van kennen.Last edited by Five-seveN; 15-04-2019 at 23:31.
no votes
Reply With Quote
-
15-04-2019, 23:35 #51Approved 9liver
- Registered
- 05/11/02
- Location
- Kempen
- Posts
- 5,569
- iTrader
- 6 (100%)
- Mentioned
- 1 Post(s)
- Reputation
- 4/96
Als UC / Skype For Business engineer:
- Deze shit analyseren om routing/manipulatie/packetheader errors uit te zoeken:

- RFC's lezen en leren om protocols door en door te kennen (https://www.ietf.org/rfc/rfc3261.txt \o/)
- Front end & back end infrastructuur opzetten voor Skype For Business + AD en DNS prep (Zie https://guybachar.net/2015/04/14/sky...kloads-poster/ voor de workloads)
- Session Border Controllers configureren en interop met telefooncentrales verzorgen. In de praktijk? Neem even volgende documenten door:
https://www.audiocodes.com/media/132...ual-ver-72.pdf
https://www.audiocodes.com/media/132...ide-ver-72.pdf
- Call routing / manupulaties voor klantensites in het buitenland aanmaken
- Contactcenters opbouwen en callflows ontwerpen
- End to end QoS configs doen
- Call quality issues troubleshooten (dit kan gaan van codec mismatches tussen backend en SBC, SBC en provider, tot netwerktraces en wifi analyses)
- Bikkeren met de klant dat de call drops toch echt het gevolg zijn van het netwerk
- Exchange configs voor unified messaging (voicemail, conv./call history, missed calls) opzetten
- Hybride oplossingen tussen on-prem Skype for Business infra en O365/azure AD opzetten
- Bugs uitzoeken in 3rd party oplossingen ism met de klant en de leverancier
- In het verlengde daarvan: eindeloze test opstellingen maken om alles mogelijke scenario's af te gaan.
- Nieuwe producten van leveranciers valideren
- Veel avondwerk, want telefonie en zeker contaccenters zijn altijd kritisch.
- etc..
- etc..
Waarschijnlijk, maar tis een excuus om eens te venten :-DLast edited by Pana; 16-04-2019 at 00:10.
9lives stopt er mee, maar het feestje gaat door op beyondgaming.be!no votes
Reply With Quote
-
15-04-2019, 23:45 #52Approved 9liver
- Registered
- 23/11/08
- Location
- Tessenderlo
- Posts
- 22,572
- iTrader
- 71 (100%)
- Mentioned
- 26 Post(s)
- Reputation
- 87/2948
:unsure : is gewoon elke IT'er van het forum tegelijk aan het trollen
9lives stopt op 31/01 -> BeyondGaming neemt de fakkel over
https://www.9lives.be/forum/algemene...12-2020-a.htmlno votes
Reply With Quote
-
15-04-2019, 23:51 #53
Toch even on-topic reageren:
Zelf ben ik functioneel analist.
Wablieft?
Kort door de bocht: als er een software-oplossing komt voor een probleem dat business heeft, dan is het mijn verantwoordelijkheid om ervoor te zorgen dat 1) alle eisen en wensen van de klant gekend zijn, 2) dat dit vertaald wordt naar een haalbaar technisch ontwerp.
Nee, het is niet zo simpel als de klant vragen "wat wil je?" en dat opschrijven.
Een aantal zaken die leken vaak onderschatten:
Veel mensen begrijpen IT niet. Veel zaken zijn moeilijk uit te leggen aan iemand die er weinig verstand van heeft, en dus moet je vooral vertrouwen opbouwen bij de klant/business zodat ze niet bij elke stap alles in vraag stellen en zo alles nog trager maken.
Software is een enorm complex gegeven. Verander 1 iets, en dit heeft impact op 127 andere plaatsen. De computer doet gewoon letterlijk wat je van hem vraagt. Die heeft geen 'gezond boerenverstand' of context. Dus je moet alles letterlijk stap voor stap uitwerken, en zorgen dat je aan alle mogelijk situaties en toestanden gedacht hebt. Continu de vraag stellen "hoe kan dit verkeerd gaan?" En gegarandeerd dat je programmeur een aantal gevallen vergeet. Gebruikers zijn HEEL goed in manieren vinden om alles te doen fout lopen.
Stel je voor dat je iemand moet uitleggen hoe hij wortelen in schijfjes moet snijden. Je zegt "houdt de wortel vast met je linkerhand, neem het mes met het scherpe deel naar beneden in je rechter, hak met het mes naar beneden, verschuif het dan 0.5cm naar links en blijf dit doen tot er geen wortel meer onder het mes is". De persoon doet niets, je was vergeten uit te leggen hoe hij het mes uit het messenblok moet halen. Ok, je voegt instructies toe en probeert opnieuw. Nu kan hij niet snijden want hij hield het mes in de verkeerde richting vast. Je past weer aan. Nu hakt die zijn vingers af, je was vergeten te zeggen dat hij z'n andere vingers OOK moest opschuiven. Enzoverder. Maar dan 100x gedetailleerder.
Komt daarbij dat een computer miljarden instructies per seconde verwerkt dus er zijn altijd mogelijkheden en toestanden waar zelfs een expert niet direct aan kan denken. Om den duur is het zo complex dat niemand in het team de applicatie volledig begrijpt. Onze developers moeten veel tijd steken in het begrijpen van code die jaren geleden geschreven werd (en die niet gedocumenteerd werd, want ja, dat kost geld he). Die problemen kunnen aangepakt worden met: 1) een robuuste architectuur die zorgt dat de software onderhoudbaar is, uitbreidbaar is, en die veel voorkomende problemen vermijdt,... en 2) uitgebreid testen ( regressietesten = testen dat, na een aanpassing, alle vorige functionaliteit nog werkt zoals het moet).
En dan hebben we het nog maar over 1 systeem. Meestal moet je gaan communiceren met andere systemen, die wellicht op andere manieren werken en door andere mensen onderhouden worden. Die andere systemen zijn vaak een 'black box' -- je weet niet hoe ze vanbinnen werken. Je ziet dat de complexiteit exponentieel toeneemt.
De klant wil vaak aan zo laag mogelijke kost en/of zo snel mogelijk zijn software hebben. Zie ook bovenstaande punten: de klant wil lagere kosten, zegt dan maar "doe die architectuur, dat testen en dat documenteren maar minder uitgebreid dan". Hij begrijpt immers niet wat het nut er van is. Gevolg? Onderhoud en uitbreiding worden een pak duurder. Komt de klant achteraf natuurlijk zagen en klagen en de kosten op ons verhalen. "Tja, je wilde het goedkoper en we hebben gewaarschuwd voor de gevolgen." Dat wil die natuurlijk niet horen...
Mensen zijn enorm slecht in weten wat ze willen. De klant zit vaak zo diep in zijn probleem, dat hij de grondoorzaak niet meer ziet. Bovendien gaat de mens vaak al een oplossing zoeken voor zijn probleem, en jou dan vragen die oplossing te realiseren. Hij staat er niet bij stil dat zijn echte probleem misschien een betere oplossing heeft.
Mensen zijn enorm slecht in communiceren wat ze willen. Ze hebben een rode cirkel in hun hoofd, ze beschrijven het als een blauwe icosaëder uit katoen, en na een lange workshop blijkt dat ze een strandbal in de kleuren van de regenboog willen. Als analist moet ik de business van mijn klant heel goed kennen, alsook de personen in kwestie, om te kunnen anticiperen op hun noden en om te weten hoe ik alles scherp kan krijgen. En dan nog is het vaak een hele klus om bepaalde zaken duidelijk te krijgen.
De klant is zich vaak niet bewust van alle gevolgen van hun keuzes en/of alle speciale situaties die enorm veel complexiteit introduceren. Had ik maar een euro voor elke keer ik dit gesprek had - klant: "ik wil x en y. dat moet toch vlug klaar zijn?", ik: "heb je al gedacht aan speciale situaties a, b en c? wat doen we met [afhankelijk systeem] y? vergeet niet dat je dan ook q en r gaat moeten voorzien. Oh, en weet je nog dat je wilde dat functionaliteit z goedkoop en snel moest gemaakt worden? dat gaan we moeten herschrijven", klant: "... eum... ja, daar had ik niet aan gedacht... moet dat echt allemaal?"
Als functioneel analist ben je de haas als er iets mis loopt. Sommige programmeurs doen gewoon letterlijk wat er in je analyse staat (vooral Indiërs), dus werkelijk elk dwaas dom gevalletje moet je in je analyse zetten. "Amai, moet ik die 150 pagina's lezen voor een paar domme veranderingen?" "Tja, vorige keer was de klant kwaad dat wachtwoorden niet verborgen werden in het inlogscherm... Je schoof het in mijn schoenen omdat dit niet letterlijk in de analyse stond dat wachtwoorden als ***** moeten weergegeven worden."
De klant zal ook op jou schieten als er iets niet is zoals het er in zijn hoofd uitzag. Ook al heeft hij nooit uitgelegd hoe het er in zijn hoofd uitzag. Daarom hebben we dus documenten van 500 pagina's waarin elke scheet in detail beschreven wordt zodat je achteraf geen peperdure veranderingen kan komen eisen.
Ik kan zo even doorgaan... TL;DR: computers zijn de autisten der autisten, complexe structuren worden exponentieel complexer, en mensen zijn heel slecht in communiceren. Als ik m'n job niet goed doe, dan kan het miljoenen euro's kosten omdat software/systemen mogelijk volledig herwerkt moeten worden als ik de requirements niet correct capteer.Last edited by Diatonico; 15-04-2019 at 23:59.
6 members found this post helpful.
Reply With Quote
-
16-04-2019, 07:36 #54Member
- Registered
- 05/11/03
- Location
- City of London
- Posts
- 7,263
- iTrader
- 9 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/62
Waarom reageert iemand daar serieus op? Het is niet aan unsure om te begrijpen wat een IT'er doet. Als de business de benefits ziet en de ROI klopt, meer moet je niet hebben.
Hij blijkt dan ook nog eens gat achterlijk te zijn ook.
Sent from my LYA-L09 using Tapatalk1 members found this post helpful.
Reply With Quote
-
16-04-2019, 09:08 #55Member
- Registered
- 18/05/09
- Location
- Rarara
- Posts
- 12,945
- iTrader
- 4 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 5/63
no votes
Reply With Quote
-
16-04-2019, 09:15 #56Platinum Member
- Registered
- 05/11/14
- Location
- Leuven
- Posts
- 3,402
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 19/68
Dit dus
Ik probeer gewoon wat bij te leren over andere functies
Merci, meest begrijpbare voorbeeld in deze thread
no votes
Reply With Quote
-
16-04-2019, 09:17 #57Member
- Registered
- 25/11/11
- Location
- Heist-op-den-Berg
- Posts
- 20,821
- iTrader
- 4 (100%)
- Mentioned
- 48 Post(s)
- Reputation
- 58/814
Mijn job bestaat erin om een platform op te bouwen zodat de managers van de luchthaven analyses kunnen doen op de verkopen in de winkels en hier op bijsturen om de winst te optimaliseren. Andere collega's houden zich dan weer bezig met het beschikbaar maken van de operationele data van de luchthaven om de efficiëntie omhoog te krijgen.
no votes
Reply With Quote
-
16-04-2019, 09:22 #58Approved 9liver
- Registered
- 13/03/06
- Location
- Lommel
- Posts
- 14,620
- iTrader
- 4 (100%)
- Mentioned
- 1 Post(s)
- Reputation
- 12/169
1 members found this post helpful.
Reply With Quote
-
16-04-2019, 10:05 #59Approved 9liver
- Registered
- 26/01/09
- Location
- Limburg
- Posts
- 19,124
- iTrader
- 37 (100%)
- Mentioned
- 38 Post(s)
- Reputation
- 5/1689
Sorry he maar ne job die ge in 2 letters kunt omschrijven kunt ge niet serieus nemen.
#red9lives
Niet opgeven mannen
no votes
Reply With Quote
-
16-04-2019, 10:09 #60Approved 9liver
- Registered
- 05/11/02
- Location
- Kempen
- Posts
- 5,569
- iTrader
- 6 (100%)
- Mentioned
- 1 Post(s)
- Reputation
- 4/96
no votes
Reply With Quote


.