Tomcat og hvad jeg lærte af den arrogante softwareudvikler

Ud fra din "udviklers" svar, så lyder det mere som om han er af den type der heller ikke forstår ret meget. Han har fundet en tutorial, og selv bøvlet med at sætte det op, og husker ikke hvordan han gjorde.

Det er ikke alle udviklere, programmører etc der ved ret meget om webserver, styresystem, netværk etc. Mange af dem er faktisk ret snævertsynede både i deres tankegang og viden.

Hjælp til Tomcat, som bare er noget nødvendigt infrastruktur set fra udvikleren (der findes også andre produkter der kan det samme), skal komme fra dine driftsfolk / sysadmins. Dem der passer og plejer invrastrukturen på daglig basis.

Lyder som om, du er blevet efterladt lidt på herrens mark af din organisation. Jeg vil ikke mene, at det nogen sinde er en testers opgave at sætte en java application server op. Endnu mindre at have en sådan kørende på sin lokale maskine (hvis man ikke er udvikler). Det virker lidt som at bede værkstedets kontordame montere nye skivebremser - altså i bedste fald spild af alles tid. Du bør naturligvis bekymre dig om det, du er god til: at teste bemeldte webapp.

Hej Bolette

Tak for et godt indlæg. Det var ret sjovt skrevet. Jeg kan særlig godt lide den del med de særlig vigtige OutOfMemory situationer. Jeg håber dog ikke at denne erfaring har fået dig til at tænke, at det ikke nogle gange er lettere at spørge sine medarbejdere om hjælp. Jeg synes ofte at ting som tager én selv en hel dag at finde ud af, kan forklares på halve timer af en person, man er på bølgelængde med, særligt hvis vedkommende forstår ens behov.

Det er nok bølgelængderne, det kommer an på.

Anekdoten er interessant men jeg tror du er kommet frem til de forkerte konklusioner.

Det er ikke en udviklers opgave at undervise ikke-tekniske kollegaer i tekniske emner som han/hende selv har investeret meget tid i at sætte sig ind i. Det er udviklerens opgave at (drum roll) udvikle. Altså især dette eksempel med Tomcat hvilket er generisk infrastruktur. Det er ikke engang noget teknisk som han/hun selv har skrevet og skal dermed stå for at dokumentere eller forklare videre.

Udvikleren bliver sandsynligvis performancevurderet ud fra hvad han udvikler, ikke ud fra hvor meget af din tid du har sparet.

Martin Kofoed har ret, udvikleren er uskyldig og skal takkes for tålmodighed. Hvis du skal deploye Tomcat og intet aner til det så er der enten et problem med roller i din organisation eller et problem med kompetence mismatch i din testing rolle.

Det er ikke udviklerens skyld at en humanist er sat til at installere noget teknisk infrastruktur.

Men som altid så er det de tekniske ressourcer der får skylden når resten af organisationen ikke kan finde ud af at matche kompetencer med opgaver.

Helt enig, godt indlæg.

Til information så har vi andre det på præcis samme måde når vi kaster os over et nyt emne. Typisk når man læser om noget nyt, som din Tomcat, så følger der en stormflod af begreber med, som dine: servlet, applet, JSP Container, JSP-sider. Så for at forstå helheden skal man forstå de enkelte komponenter, og dem forstår man ikke - så det ligner en catch 22.

Løsningen for mig er typisk at: hente værktøjet, lede efter nogle tutorials, og google det jeg mangler efterfølgende. Specielt en tutorial kan give meget overblik over produktet, eksempelvis Tomcat.

En MEGET tålmodig hjælper er iøvrigt Youtube, hvor det er min erfaring at der altid, næsten ihvertfald, er en video med anvisning på hvordan man laver X på Y. Jeg søgte på youtube med: "enable logging tomcat" og fandt en del som både beskriver hvordan man installerer Tomcat (også som service) og hvordan man debugger servlets og slår logging til.

Fordelen ved youtube er at man blot kan skifte til en anden lærer hvis lyden er dårlig eller man kan skippe frem og tilbage.

Nu er jeg nok også i denne kategori, derfor ...

At spørge en udvikler hvordan man opsætter Tomcat svarer ca. til at spørge selvsamme hvordan man kan filtrere en pivot tabel i Excel.

Vedkommende ved formentlig hvordan man gør (hvis du er heldig), men det er ikke vedkommendes primære arbejdsområde og typisk vil vedkommende være lidt rusten i emnet så denne vil også skulle bruge tid på at sætte sig ind i detaljerne hvis denne virkelig skal kunne hjælpe dig.

Det resulterer i at du typisk vil få et lidt overfladisk svar for at ryste dig af, så udvikleren kan komme tilbage til sit arbejde (eller drikke cola og snakke med de andre nørder, som det åbenbart lyder til udviklere primært foretager sig på jeres kontor?)

Det er klart at du rammer ind i denne verden af tekniske termer og ubehjælpsomhed for du er ved at opsætte en meget teknisk server der er beregnet til at kunne afvikle custom-skrevet software.

Det er ikke et område for en humanist, det er et område for teknikere og insisterer du på at være ansvarlig for opsætningen uden at forstå denne verden så er dit lognings-problem formentlig blot det første i rækken.

Held og lykke.

Jeg ser desværre ofte at udviklere selv vælger sætte udviklings, test og nogle gange, endda produktionsservere op - uden at de er særlig gode til det. Det sker ofte fordi driften ikke leverer varen, og så må udviklerne jo selv - men de har ikke fokus på drift og sjældent erfaring med den virkelighed, så resultatet bliver ikke altid det mest optimale.

Og faktum er at "IT" jo er et meget meget bredt fag - hvor du ikke kan være super god til det hele.. det svarer til at kunne alle håndværksfag (elektriker, tømrer, vvs mm.) - og det er altså meget svært at spænde over, og samtidigt være opdateret indenfor alle felter.

Derudover så ved de færreste udviklere at man også kan (og bør!) skrive kode, til at automatisere sin opsætning af f.ex. tomcat mm. - således at alle udviklere ikke behøver at kunne alt, men kan stå på skuldrene af andre.

Kort sagt - så bør man ved samarbejde kunne opnå en dækning og redundans indenfor alle felter man har behov for at arbejde med.

F.ex. er det min erfaring at optimal opsætning af servere og programmer (inkl. f.ex. Tomcat) kan håndteres bedre i en god driftsafdeling - hvis formål det er, at servicere (og samarbejde og udfordre) udviklerne, således at driften rent faktisk leverer det de burde være/er gode til, nemlig serveropsætning mm. - især fordi det man udvikler jo normalt ender med at skulle køres af/hos driften bagefter (eller ideelt set bør der være udviklere, som er en del af driften) - af nogen kaldet devops - hvor man udvikler sin operations.. :) http://puppetlabs.com/blog/devops-team-no-devops-toolchain-yes

f.ex. kan Driften så sørge for at sikre, at de erfaringer draget i en kontekst, også kan bruges til at forbedre det for alle andre.

Her anvender jeg selv Puppet som automatiseringsværktøj, til bl.a. opsætning af Tomcat, således at alle tomcat installationer løbende forbedres, og nye rulles ud 100% fuldautomatisk (også gerne på udviklernes egne maskiner - f.ex. vha. vagrant+puppet) - og korrekt opsat hver gang.

Godt at høre at humanister/generalister også kan bruge deres akademiske færdigheder på et ukendt område. Som Henrik siger, så gælder det samme for os udviklere. Hvis man bare tager sig tiden og tålmodigheden, så er det meste jo til at finde ud af.

Det er vel heller ikke så tit, at man sætter sådanne systemer op, og det kræver sin viden at gøre det, og det kræver tid og energi at tilegne sig den viden. Oven på det, er der forfærdeligt mange indviklede og uhyggeligt store systemer, man kan blive ekspert i, og det er højst sandsynligt at de fleste IT folk er eksperter i 2-3 stykker og kender resten perifært.

Alligevel bliver man ofte opfattet som ekspert i alt, fordi man arbejder dybt i nogle få systemer. Derfor kommer arrogancen nok lidt som at klemme en sur citron.

Det undrer mig ikke en meter at en IT udvikler svarer sådan, når han ikke selv har den viden, og skal dermed skal bruge lang tid på at tilegne sig den først, før han kan forklare dig den.

Bolette: årsagen til at du har en (mindre?) konflikt med udvikleren er, at I slet ikke har samme mål. Du har åbenbart fået en testopgave og han opfatter det ikke som sin opgave at hjælpe dig med noget, som godt kan være temmelig langhåret udi teknik.

Fejlen er helt grundliggende: I to har ikke det samme mål. Hvis I havde en fælles opgave som gik ud på at teste et system, ville du nok ikke være løbet ind i samme problemer. Det du omtaler, er et ledelsesproblem. Kig på din nærmeste projekt- eller linieleder og spørg dig selv om du synes at målene for din gruppe/team/hold/enhed/afdeling (eller hvad I nu kalder det) er helt klare.

Muligvis kan du så svare ja (omend jeg tvivler), men har du så fået de ressourcer, du skal bruge? For nej - selvfølgelig skal du ikke uddanne dig til driftstekniker samtidig med at du tester - med mindre også dét er et mål i sig selv (iht. afsnittet om fælles mål ovenfor).

Martin Kofoed har ret, udvikleren er uskyldig og skal takkes for tålmodighed.

Nej, udvikleren er ikke uskyldig, og skal så afgjort ikke takkes for noget. Vedkommende skal tværtimod straffes for inkompetence og idioti.

Det er ikke fordi han ikke prompte fikser problemet - det er fordi han svarer som en tåbe. Bare fordi den person, der spørger, ikke er inde i emnet, behøver man ikke være et røvhul af karakter. Hvis samtalen er forløbet bare nogenlunde som beskrevet, så har det med al tydelighed været klart at personen der skulle bruge hjælp netop ikke var inde i emnet - og på ingen måde får noget som helst ud af at en udvikler skal vise sig med tekniske forklaringer.

Jeg ville hade at arbejde sammen med sådan en person.

En helt anden vinkel:

Lad os starte med en antagelse: det du spørger efter er indviklet både at løse og forklare, også for en udvikler.

Hvis nu udvikleren deler samme antagelse, kan jeg ikke læse dit indlæg anderledes end at du er skuffet over at han ikke lige kunne koge en meget indviklet, lang og besværlig historie ned til noget, der kunne siges med et par sætninger.

Jeg synes selv at jeg kan genkende situationen: en lægmand (m/k) spørger ind til et eller andet datalogisk problem, man begynder at forklare og samtalen løber hurtigt af sporet fordi modparten forventer et kort, enkelt svar. Ofte ender den slags samtaler med opgivende vendinger som "Jamen så må jeg jo bare..." (underforstået: du kunne have hjulpet mig, men ville ikke).

Kan man bruge prædikatet "arrogant" om nogle af de to aktører?

Jeg har svært ved at se hvordan udvikleren skulle gribe det anderledes an.

Han prøver at forklare.

Du forstår ikke.

Til sidst gør han præcis dét, han ville gøre for en hvilkensomhelst anden udvikler:

Sender dig i retning af dokumentationen.

For ja - systemudvikling og meget andet inden for IT kræver at man tilegner sig ny viden hele tiden.

Bare fordi den person, der spørger, ikke er inde i emnet, behøver man ikke være et røvhul af karakter. Hvis samtalen er forløbet bare nogenlunde som beskrevet, så har det med al tydelighed været klart at personen der skulle bruge hjælp netop ikke var inde i emnet - og på ingen måde får noget som helst ud af at en udvikler skal vise sig med tekniske forklaringer.

Der er da også andre forklaringer: (a) han kan faktisk ikke finde ud af at forklare det (ja - den slags findes) og (b) han vurderer ud fra hendes måde at spørge på, at han er nødt til at trække hende hele vejen igennem to-tre moduler fra Datamatikeruddannelsen, før hun forstår og beslutter sig for at hjælpe hende på vej til at tilegne sig den fornødne viden selv.

Enten er det a) hans problem og han bør derfor fikse det, i stedet for at spilde alles tid, eller også er det b) ikke hans problem, og han bør derfor på en venlig måde påpege dette, samt evt. pege OP i den rigtige retning. I stedet vælges løsning c) blah blah blah du fatter ikke noget blah blah blah læs dokumentationen blah blah.

Prøv at læse posten ovenfor igen og spørg dig selv hvad du ville få ud af at en humanist belærer dig om forskellen på Descartes og Derrida på en lettere teknisk måde. Hvad er det præcist der får dig til at tro at samtalen ovenfor har været andet end spild af resurser for de involverede samt firmaet?

Med fare for at blive kaldt arrogant, så undrer jeg mig over hvordan i alverden du er kommet til at rode med opsætning af Tomcat i første omgang. Det er absolut ikke et let bæst at få til at virke for lægmand. Det er heldigvis mange år siden jeg sidst har haft med den at gøre, og det er ikke et varmt minde :-)

Hvad var det nu den virkelige opgave var, som du ville løse? Måske ville din venlige udvikler hellere hjælpe dig med det - han/hun kunne fx installere det for dig, så du kan komme videre med din opgave.

Nu vil jeg normalt ikke karakterisere mig selv som arrogant, men i ovenstående samtale kunne jeg godt forekomme sådan, fordi jeg har en helt speciel agenda. Først skal det siges at jeg installerede min første Tomcat i 2002, og nok nok har mere styr på Tomcat end den gængse Java udvikler. Jeg kunne sagtens have installeret og konfiguret en Tomcat til Bolette i vores VMWare miljø, men jeg tror jeg ville ha gjort os begge en bjørne tjeneste i det lange løb - under følgende forudsætninger: 1) Jeg ved Bolette kommer til at installere vores applikation på Tomcat mere end én gang (og sikkert også Tomcat igen). Vi har halvårlige releases og der er altid bugs som skal verificeres. 2) Jeg ved Boletter kommer til at konfigurere Log4j igen. Den bruges i produktet generelt, og i vores webapp (og der skulle gerne stå i hjælpen hvordan man gør). I default opsætningen bliver dens output blandet med Tomcats JULI logs, så det er vigtig at kunne se forskel. 3) Jo mere Bolette ved om Tomcat, des nemmere bliver mit arbejde. Hvilket jo i virkeligheden er min "lumske" bagtanke. 3a) Hun vil lave bedre bug reports, med de rigtig staktraces, i stedet for bare at skrive at feature X ikke virker (hvilket den jo muligvis gør på mit udvikler setup). 3b) Hun får en dybere forståelse af produktet, og har dermed bedre mulighed for at vurdere hvor de skjule bugs/risici ligger begravet. 3c) Hun vil være i stand til at forså den installations guide vi levere til kunderne, og teste at der står det man har bruge for at vide.

Andre folk har udtrykt det således "give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime".

Det skal dog siges at der er ting jeg ikke forventer at Bolette skal være i stand til selv at sætte op. Vi har blandt andet et clustered high availability setup, med 2 Tomcats, mod_jk og apache2. Dette er selvfølgelig tilgængelig i vores VMWare miljø. Her forventer jeg at Bolette kan installere vores applikation, og kan verificere de bugs som rapporteres i dette miljø.

@Peter Lind: Tror nu generelt folk er glade for at arbejde sammen med mig ;-)

"Lyder som om, du er blevet efterladt lidt på herrens mark af din organisation. Jeg vil ikke mene, at det nogen sinde er en testers opgave at sætte en java application server op. Endnu mindre at have en sådan kørende på sin lokale maskine (hvis man ikke er udvikler). Det virker lidt som at bede værkstedets kontordame montere nye skivebremser - altså i bedste fald spild af alles tid. Du bør naturligvis bekymre dig om det, du er god til: at teste bemeldte webapp." Så svært er det altså ikke at installere Tomcat. Bolette har jo lært det vigtigste på 1 dag (men hun er naturligvis også usædvanligt godt begavet). Nu er hun i stand til at deploye nye war filer og melde gode fejl når der går noget galt fordi hun kender log filen.

En helt anden vinkel:

Lad os starte med en antagelse: det du spørger efter er indviklet både at løse og forklare, også for en udvikler.

Hvis nu udvikleren deler samme antagelse, kan jeg ikke læse dit indlæg anderledes end at du er skuffet over at han ikke lige kunne koge en meget indviklet, lang og besværlig historie ned til noget, der kunne siges med et par sætninger.

Jeg synes selv at jeg kan genkende situationen: en lægmand (m/k) spørger ind til et eller andet datalogisk problem, man begynder at forklare og samtalen løber hurtigt af sporet fordi modparten forventer et kort, enkelt svar. Ofte ender den slags samtaler med opgivende vendinger som "Jamen så må jeg jo bare..." (underforstået: du kunne have hjulpet mig, men ville ikke).

Kan man bruge prædikatet "arrogant" om nogle af de to aktører?

Jeg har svært ved at se hvordan udvikleren skulle gribe det anderledes an.

Han prøver at forklare.

Du forstår ikke.

Til sidst gør han præcis dét, han ville gøre for en hvilkensomhelst anden udvikler:

Sender dig i retning af dokumentationen.

For ja - systemudvikling og meget andet inden for IT kræver at man tilegner sig ny viden hele tiden.

Spot on.

Jeg må indrømme, at da jeg læste følgende:

Mig: Det der Tomcat - jeg har installeret det, og vores applikation kører – men den skriver en masse fejl, og disse vil jeg gerne have ned i en fil.

Udvikler: Hvordan kører du Tomcat? Hvad mener du med fejl?

Mig: Øh, altså jeg trykker på startup i en windows stifinder og så starter Tomcat....

Udvikler: Det er jo fordi, du kører den forkert. Du har bare pakket zip-filen ud. Du har jo ikke installeret Tomcat. Du skal installere den som en service (eller gøre en masse andet jeg ikke kan huske, hvad han sagde. Læs: lang teknisk forklaring)

Mig: Nåh.... Så det, du siger, er, at jeg skal installere Tomcat som en service?

Udvikler: Ja. (endnu længere teknisk forklaring)

Mig: Ok. Men jeg vil altså stadig gerne have de fejl, den udskriver, ned i en fil, så jeg kan bruge det til at rapportere fejl med...

Så sad jeg med forståelsen af:

Tester: Jeg har installeret Tomcat, og vores test viser at applikationen giver en masse fejl, som jeg vil gemme og sende tilbage til udviklerne.

Udvikler: Nu har du vel installeret Tomcat korrekt, da det er vigtigt at teste applikationen på korrekt opsat system.

Tester: Øhbøø.. Jeg har bare startet den.

Udvikler: Så er Tomcat ikke startet på en måde der afspejler miljøet vores applikation skal køre under. Den skal køre som en service.

Tester: Aha!

Udvikler: Uddyber, og begrunder - måske præcist og for teknisk.

Tester: Godt, så. Men applikationen giver altså en masse fejl, som jeg gerne vil gemme og sende tilbage til udviklerne.

Og det kan jo være min forståelse som er i skoven. Men jeg synes det lugter lidt af at Tester er alt for fokuseret på at videresende fejl, som er fremkommet i forkert opsat miljø.

Edit: Var for langsom på tasterne. Udvikler har uddybet :-)

K

@Peter Lind: Tror nu generelt folk er glade for at arbejde sammen med mig ;-)

Det håber jeg da :) Men jeg tvivler kraftigt på det er på baggrund af samtaler som den ovenstående. Hvis den er bare nogenlunde i nærheden af virkeligheden, så fremstår du arrogant og bedrevidende.

Andre folk har udtrykt det således "give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime".

Det er en rigtig god tanke. Den skal bare kobles med en god lærer, der ikke fremstår arrogant.

Prøv at læse posten ovenfor igen og spørg dig selv hvad du ville få ud af at en humanist belærer dig om forskellen på Descartes og Derrida på en lettere teknisk måde.

Det ville jeg muligvis få en del ud af, men læg nu det til side :-)

Nej - selvfølgelig er forklaringerne temmelig uforståelige, men det er jo netop det, hun spørger efter. Nu er Bolette jo ikke projektleder eller noget andet organisatorisk "middleware", men en tester som må forventes at kunne håndtere et relativt bredt spektrum af problemer selv. Som regel er testere der for at aflaste udviklerne, ikke omvendt, så nej, jeg synes slet ikke at der er noget galt i at udvikleren faktisk prøver at trække Bolette med ind i det tekniske univers, han befinder sig i.

Jeg havde haft en fuldstændig anden holdning, hvis Bolettes jobbeskrivelse var en anden.

Hvad er det præcist der får dig til at tro at samtalen ovenfor har været andet end spild af resurser for de involverede samt firmaet?

Det er da spild af ressourcer, men jeg skyder primært efter Bolette og udviklerens åbenlyst manglende ledelse. Se min kommentar vedrørende fælles mål ovenfor.

Jeg lægger mærke til en hel del kassetænkning i kommentarerne som går mig på.

"Som humanist bør du ikke... det bør gøres af fagfolk"

Tak for at sætte folk i bås. Har man først taget én specifik uddannelse er det åbenbart ikke velset at dygtiggøre sig inden for noget som helst andet.

Jeg vil i modsætning hertil tage hatten af for at overkomme en fremmed problemstilling, se ud over egen titel/uddannelse og tilegne sig ny viden. Dette endda på trods af miljøet som du indgår i, ikke på grund af.

Jeg ville ønske at flere havde den slags gå på mod. Og jeg ville i samme omgang også ønske at flere fra vores fag ville være imødekommende på en måde som opfordrede ikke-fagfolk til at fatte interesse og få lyst til at lære lidt mere.

Ville det ikke være rart hvis vi i fællesskab kunne vende opfattelsen af det utilnærmelige fag fyldt med arrogante røvhuller? Hvem ved, måske ville vi så enddda få flere til at søge ind på vores uddannelser.

Jeg har tit begivet mig ud i at forklare hvordan noget virker/ikke virker. Hvis det virker arrogant, så er jeg bange for at jeg virker arrogant ret ofte. Det er jo slet ikke sådan ment. Jeg vil jo bare gerne forklare om det arbejde jeg er så betaget af. Når folk så spørger, tror jeg oprigtigt at de gerne vil vide, hvorfor X virker eller ikke virker.

Jeg prøver da at reducere mængden af fagtermer, således at jeg snakker et sprog som vedkommende forstår.

Hvis jeg spørger en jurist hvorfor noget er lovligt eller ikke lovligt, regner jeg da med at få en forklaring, med nogle fagtermer jeg ikke helt forstår. Jeg vil endda gå så langt som at sige, at hvis juristen overhovedet tager sig tid og energi til, at forklarer det i et sprog jeg forstår, så har jeg fået MEGET mere end jeg regnede med. Det ville da være fedt.

Hvis en bilejer går til mekanikeren og spørger hvorfor bilen ikke virker, vil vedkommende sandsynligvis få at vide at X dims er gået i stykker pga. Y og Z. Hvor X, Y og Z er termer de færreste ved hvad er.

Udvikleren som omtales i artiklen bliver i den grad udstillet, for sin mangel på pædagogik og dialektik. Det synes jeg egentlig er meget værre en den behandling Bolette har fået, specielt set i lyset af at han ikke har en ærlig chance.

http://xkcd.org/627/

Tak for at sætte folk i bås. Har man først taget én specifik uddannelse er det åbenbart ikke velset at dygtiggøre sig inden for noget som helst andet.

Nu er artiklen jo i sig selv et udtryk for kassetænkning og opdeling af folk i "humanister" og "teknikere/udviklere (aka nørder)".

Og det er klart at hvis man kan karakterisere nørder som folk der primært snakker volapyk og drikker cola, så kan man vist også tillade sig at sige en ting eller 2 om humanister.

I sidste ende er det ligegyldigt om vi kalder det en humanist eller ej, det handler om indstilling.

Hvis Bolettes indstilling er at der dukker for mange 3-bogstavers akronymer op når hun prøver at opsætte en teknisk server og ikke mener at det er noget hun som almindelig humanist bør skulle sætte sig ind i og har svært ved at forstå at folk ikke bare liiige kan fikse problemerne for hende så hun selv slipper for at google dem.

Ja, så lyder det ærlig talt mest af alt som om Bolette er gået i kast med noget der teknisk ligger på et alt for højt niveau i forhold til hendes grundviden og at hun ikke er vildt interesseret i at opbygge den nødvendige viden.

Det er svært at ændre på, så løsningen er jo nok at sætte humanisten til at lave noget der interesserer hende mere og lade nørderne om det de synes er sjovt.

Jeg tror alle vi kender situationen. Vi bliver spurgt om noget, som er teknisk og kræver en del baggrundsviden. Du ved det faktisk ikke, fordi udenads viden er for katekismus og certificeringer. Rigtige udviklere holder sig til baggrundsviden og google. Derfor kan du få den viden i løbet af 5 minutter, hvis du selv skal bruge den.

Scenariet her er bare at: 1. Du skal slå denne viden op og svare på spørgsmålet samtidig. Hvilen vil forvirrer spørgeren. 2. Du ved ganske udemærket at den nødvendige baggrundsviden ikke ligger hos spørgeren, hvilket du skal tage hensyn til når du svarer. 3. Du hænger nu på supporten af hvad end det er spørgeren roder sig ud i. Og du får hverken løn eller køs for det. 4. Spørgeren har selv svært ved at forklarer hvad formålet i det hele taget er. 5. Spørgeren er utålmodig. Især hvis du stiller relaterede spørgsmål.

Hvad gør man? 1. Svarer nej, det ved jeg sørme ikke noget om. ( Hvilket sender aben videre til en anden udvikler ) 2. Forklarer hvorfor du ikke vil svare i stedet for faktisk at svare? 3. Udøver hjælp til selvhjælp, ligesom vores arrogante kollega gør i dette indlæg? Hvilket i dette tilfælde har givet spørgeren den viden der er nødvendig for at bruge tomcat. Måske har spørgeren endda fået lidt baggrunds viden som udvider hendes horisont. 4. Siger flyt dig og tager computeren fra hende, og sætter skidtet op sådan som du ville have gjort, hvis det var din egen computer. Vel vidende at spørgeren vil komme igen med det samme eller et relateret spørgsmål, fordi spørgeren stadig ikke ved hvad tomcat er, eller hvad det gør.

Hvis spørgeren har intentioner om at blive en dygtig udvikler, så er 3 klart det rigtige svar. Men dette drejer sig om tilfælde hvor spørgeren ikke er interesseret i at blive udvikler. Ofte ønsker de ikke at vide noget om hvordan deres computer virker overhovedet.

Hvad siger I? Hvornår skal man svare hvad? Jeg tror også jeg lander på svar nummer 3 alt for ofte.

Faktisk tror jeg at jeg vil fremgå som en mindre arrogant person, hvis jeg oftere svarer nummer 1. Dog er jeg bange for at spørgeren vil opdage mit bluff.

Så hvad skulle denne udvikler have gjort? Hvilket træk vinder?

Andre folk har udtrykt det således "give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime".

Nu er det med fiskene jo mest en metafor her, tænker jeg. Vi snakker i lige så stor grad om hvordan nogle it-folk har en manglende evne til at formidle, og at man som konsekvens uberettiget kan føle sig dum. I så fald kan jeg bedre lide følgende ordsprog:

Light a man a fire and you keep him warm for an evening. Set a man on fire and you keep him warm for a lifetime.

Jeg har i hvert fald brændt fingrene nogle gange ved, i mit sprogbrug, at antage at ting er simple og efterfølgende gjort folk kede af det / frustrerede. Det har hjulpet mig at tage matematikkurser på universitetet i at fjerne ordet "bare" fra mit ordforråd. Det tjener nemlig kun formålet at fortælle nogen at noget er virkelig simpelt for mig. Det er ikke så ofte at jeg faktisk har brug for at sige dette.

En sjovere variation af "Teach a man to fish..."-ordsproget findes her:

http://funnyasduck.net/wp-content/uploads/2013/11/funny-pictures-teach-a...

Hej Bolette

Tomcat er ikke et rigtigt venligt bæst synes jeg, så jeg er glad for når begyndere der lige har lært noget om tomcat rent faktisk beskriver hvordan man gør .

Så, hvordan gør man når man skal have tomcat installeret som service? Og hvordan får man tomcat til at logge til de rigtige filer?

/Sune

En sjovere variation af "Teach a man to fish..."-ordsproget findes her:

Give a man a match, and he'll be warm for a minute, but set him on fire, and he'll be warm for the rest of his life.

Mere om fisk: http://dilbert.com/strips/comic/2001-12-27/

Tak for at sætte folk i bås. Har man først taget én specifik uddannelse er det åbenbart ikke velset at dygtiggøre sig inden for noget som helst andet.

Jeg må tilstå at jeg havde meget svært ved at læse Bolettes indlæg, af netop samme grund.

Jeg kan godt forstå at teknikkeren kommer til at fremstå som utilsigtet arrogant og vi tekniske personer skal være bedre til at kommunikere. Men den egentlige arrogante i Bolettes historie er da Bolette selv der med sin nedladenede beskrivelse af sine kollegaer kunne blive veninde med en vis politiker.

Hvis jeg har en kollega der tydeligt giver udtryk for at dele den karakterisering af tekniske kollegaer som Bolette giver i indledningen, så ender jeg da med at være langt mindre tålmodig end Klaus Groenbaek og forsøger at rede mig ud af den med et "Nej, det ved jeg ikke lige".

Hvis man beskriver det, folk siger for at hjælpe én, som "blablabla som jeg ikke forstod", så ser jeg nu heller ikke den store velvilje.

Kommunikation kan være en svær én, allerede her i denne debat er der flere eksempler her på.

Det virker som om Bolette og Klaus ikke taler helt samme sprog, i hvert fald har de forskellige måder at kommunikere spørgsmål og svar hen over bordet. Jeg tænker, at Bolette oplever Klaus' kraftigt teknisk prægede forklaringer som værende svære at forstå og fordøje, og at dette er en plausibel forklaring på (@Peter og @Morten), at Bolette ikke kan recitere Klaus ordret, da ordene simpelthen er pilet hen over hovedet på hende. Klaus har måske oplevet Bolettes "low-tech" spørgsmål som værende svære at svare på, da han mener at de kræver en "hi-tech" forklaring, og en sådan forklaring giver ingen mening med mindre baggrundsvidenen er i orden hos modtager.

Bolette indså, at Klaus' forklaring ikke var fyldestgørende for hende for pågældende problemstilling og hun gjorde efterfølgende det helt rigtige: Hun brugte tid på at udvide sin horisont ved at gøre sig begreb om Tomcat og Log4J.

Klaus gjorde også det rigtige ved at lade Bolette søge baggrundsviden selv... og jeg er 100% enig med hans 6 grunde derfor!

Det plejer at være en forholdsvis teknisk præget verden softwareudvikling foregår inden for, og derfor mener jeg at det må være alle medarbejderes ansvar at sætte sig ind i, hvordan tingene hænger sammen og opbygge en grundviden om de mest vitale platforme, som produktet er baseret på. Ved at testeren tilegner sig denne viden, skaber det et rum for kommunikation omkring de tekniske aspekter ved produktet, som både tilfredsstiller testeren i form af at "dingenoten" og "duppeditten" får de rigtige tekniske termer og tilfredsstiller udvikleren, som pludselig forstår testeren og nu oplever at deres forklaringer rent faktisk fiser ind på lystavlen.

"Give man a fish and feed him for a day, give fish a man and feed them for months"

Som Henrik Kramshoej er inde paa, saa er det en udfordring jeg tror de fleste af os staar over for naar vi skal finde ud af et nyt emne. For mit vedkommende ender det som regel med en masse browser tabs der er aabne paa samme tid. Nok ikke meget anderledes end hvad du gjorde.

Klavs Klavsen er ogsaa inde paa at bruge Chef og Puppet, det vil jeg helt klart anbefale at du kigger naermere paa; saa kan du oparbejde en detail viden om miljoe som jeres app faktisk koerer det, og det er utroligt utroligt godt hvis du skal saette reproducerbare miljoer op (og med lidt snille, saa kan du maaske faa dine udviklerkollegaer til at hjaelpe med dele af det - da det ogsaa bare kan vaere hjaelp til deres daglige arbejde - potentiale er endnu stoerre i at du med dette kan lave tests der koeres via et xUnit framework, og hvor du saa automatisk smider f.eks. en Chaos Monkey (fault-injection) efter de maskiner og miljoer du spinner op via Vagrant-Chef). Det har kaempe potentiale hvis det er lidt mere komplekse miljoer I arbejder med.

Derudover genere det mig lidt at du saetter ‘testeren’ i baas med ‘almindelige doedelige’/humanister/ikke-udviklere, da en tester kan vaere fint lige saa teknisk kompetent som ‘udvikleren’. Det afhaenger selvsagt af den enkeltes profil, men jeg ser ikke noget latent modsaetningsforhold der.

Jeg var for aar tilbage ansat som den foerste tester ved Kapow, og jeg mindes da at Quickstart Guiden havde instruktioner om hvordan Tomcat skulle saettes op - maaske er det paa tide at I revidere det eller giver den et eftersyn? (hvis der selvsagt stadig er en quickstart guide og de problemer den tog haand om stadig er relevante)

Men det lader til at indlægsskriveren ikke har den store IT-tekniske viden, i hvert fald omkring serverteknologier. Det er der ikke noget i vejen med, men så er det ikke så overraskende at man ikke lige hurtigt kan finde ud af hvad "Tomcat" er, hvis det eneste man overhovedet ved om serverteknologier er at der findes et eller andet der hedder Tomcat. Man kunne givetvis forklare hvad en Tomcat server er uden at bruge så mange tekniske termer, men så ville det være en ret upræcis beskrivelse og for teknikere ret ubrugelig, og jeg tror også den vil være ubrugelig i den situation som testeren stod overfor i dette tilfælde, da problemstillingen tydeligvis var teknisk.

Dda Tomcat er en teknisk komponent som det ikke er meningen skal bruges af andre end netop folk der laver noget teknisk, så er det helt fair at beskrivelsen af komponenten er teknisk. Og det kræver således en masse forudsætninger at forstå beskrivelsen.

På samme måde, hvis man slår op i en bog indenfor et hvilket som helst fagområde, er der sikkert også ord der kan være meget svære at give en ikke-teknisk forklaring på. I hvert fald hvis den også skal være 'operational rigtig' d.v.s. at forklaringen ikke er mere simplificeret end at man stadigvæk kan arbejde seriøst og få resultater ved brug af forklaringen (dette er f.eks. ikke et krav hvis det blot skal være en forklaring i en avisartikel til oplysning for den brede befolkning).

Man har så to valg: Prøve at sætte sig ind i de tekniske termer (og det vil sikkert kræve det meste af en dag at klikke sig rundt i 3-4 niveauer af forklaringer på de forskellige forkortelser indtil man rammer noget man forstår - men sådan er livet!) eller sige man ikke har forudsætningerne for opgaven og derfor ikke kan løse den.

Det virker som om Bolette og Klaus ikke taler helt samme sprog, i hvert fald har de forskellige måder at kommunikere spørgsmål og svar hen over bordet.

Jeg mener ikke at den sædvanlige frase om at tale forskellige sprog generelt er dækkende for hvad der går galt i kommunikationen. Efter min mening er det mere interessant at snakke om forskellige forventninger til hinanden.

Muligvis har Klaus og Bolette forskellige forventninger til hvad en tester og en udvikler skal lave. Hvis Bolettes forventning er at hun som tester tager det færdige produkt og gennemfører en test som bruger og Klaus som udvikler kun forventer at være ansvarlig for den komponent der er udviklet i virksomheden, så mangler der helt klart nogle roller som både Bolette og Klaus forventer at den anden kan tage sig af.

Forventninger om roller er først og fremmest et ledelsesproblem. Måske sidder der en i organisationern lige i øjeblikket og tænker "hvorfor spurgte hun ikke mig, jeg er ansvarlig for at drifte vores testmiljø".

Det kan også være at Bolettes forventning til hvordan en tekniker løser et problem er forkert. Det er så den forventning som Klaus korrigerer på fornem learning by doing-maner og jeg kan kun bifalde at vi "underviser" folk i hvordan vi tænker istedet for bare at tænke for dem.

Når jeg stille og roligt læser Bolettes indlæg (bagfra, så jeg ikke bliver generet af indledningen) lyder dette også til at være Bolettes lære: "Har vi en forventning om, at softwareudviklere kan løse vores problemer med et klik", selvom jeg gerne ville tilføje et lille "forkert".

I mit arbejde forsøger jeg at bruge en del tid på at afstemme forventnignerne med andre dele af organisationen. Det gælder både vores supportere og de andre udviklingsafdelinger vi arbejder sammen med. Desvære ikke altid tid nok, for jeg vil hellere sidde og kode (som er min egentlige rolle).

I mit arbejde forsøger jeg at bruge en del tid på at afstemme forventnignerne med andre dele af organisationen. Det gælder både vores supportere og de andre udviklingsafdelinger vi arbejder sammen med. Desvære ikke altid tid nok, for jeg vil hellere sidde og kode (som er min egentlige rolle).

Her vil jeg gerne komme med en reklame for en fabelagtig bog, som handler om at afstemme forventninger på en konstruktiv måde. Den hedder How did that happen? - Holding people accountable for results in the positive [...] way. Den er meget amerikansk i sin stil, men beskriver ret præcist det som vi i Danmark er rigtig gode til, når vi er bedst: nemlig at samarbejde for at nå et fælles mål i relativt flade organisationer.

... siger man jo, at der er 3 der peger tilbage på een selv. Det kan man vist roligt sige i dette tilfælde, og der er da også så meget helt galt i denne sag - fra situationen selv til blogindlægget om det - at man kan blive helt forpustet.

Kun et enkelt andet blogindlæg i år har været mere arrogant og generaliserende end dette og fællesnævneren er da også, at de begge er skrevet af ekstroverte, velformulerede humanister, der med udnævnelsen af de oplagte prügelknaber som årsagen til alle problemer, blot får pustet til andre uventede fordomme, der helst skulle manes i jorden. I dette tilfælde tilsyneladende skrevet i et frustreret øjeblik over manglende evne/tålmodighed til selv at løse problemer af samme sværhedsgrad som deres mindre opmærksomhedskrævende tekniske kolleger, der egentlig blot vil have lov at koncentrere sig om deres eget arbejde i fred og ro. Det meste er heldigvis blevet kommenteret ovenover.

Hvad siger ledelsen i Kapow til at få evnerne og teamet udstillet i mere eller mindre gennemtænkte blogindlæg her?

Hvad siger ledelsen i Kapow til at få evnerne og teamet udstillet i mere eller mindre gennemtænkte blogindlæg her?

Det sidste jeg synes der er værd at diskutere er da om Kapow skal blande sig i hvad deres medarbejdere blogger om. Det kan da godt være at man se dette her som tegn på at de ikke har helt styr på deres processer, men min erfaring siger mig at denne type problemer fuldstændigt almindelige.

I det lys er det da fabelagtigt at nogen har mod nok til at blogge om det - også selvom man bevæger sig på tynd is og ved at der er fare for at blive klogere undervejs.

Det sidste jeg synes der er værd at diskutere er da om Kapow skal blande sig i hvad deres medarbejdere blogger om.

Det skal de da naturligvis også kun i det omfang at det bloggede involverer Kapow (eller en hvilken som helst anden arbejdsgiver) i så åbenlyst omfang, som det er tilfældet her. Jeg ville da være stærkt bekymret hvis een af mine medarbejdere fik det til at fremstå udadtil som om vedkommende fik afløb for interne problemer og konflikter - og ikke bare i et hvilket som helst ligegyldigt offentligt forum, men endda i DET offentlige forum i branchen, der kan have betydning for samme virksomheds anseelse blandt eventuelt kommende kandidater til job. Så jeg tillægger det bestemt at være alt andet end ligegyldigt, men det behøver vi jo ikke nødvendigvis være enige om!

Det har været spændende og lærerigt at følge ovenstående debat, da det virkelig viser hvor forskelligt man kan opfatte et indlæg om læring, kommunikation og forskellig indgangsvinkel til tekniske problemstillinger. Som kollega til både Klaus og Bolette har jeg også fulgt debatten internt ved Kapow, der har været præget af megen morskab over kommentarerne. Der har absolut ikke været nogle dårlige vibrationer angående selve indlægget kun undren over modtagelsen af det bloggede. Den sidste bemærkning jeg hørte var at vi burde lave et dong spil hvor Klaus skal drikke et shot til vores julefrokost for hvert indlæg der er negativt mod ham og det samme for Bolette. Læren må være at med den implicitte viden vi har her i huset om Klaus og Bolette og vores fantastiske arbejdsmiljø bevirker at Bolettes indlæg læses som et frisk lettere karikeret indlæg der handler om læring og forholdet mellem udviklere med teknisk baggrund og en teknisk begavet humanist.

Der har absolut ikke været nogle dårlige vibrationer angående selve indlægget kun undren over modtagelsen af det bloggede.

Hvis der er udbredt undren over modtagelsen, så må der jo i givet fald mangle en masse kontekst, som efterlader læseren af bloggen ude af stand til at forholde sig til indholdet? Jeg har en fornemmelse af, at indlægget skulle have været ude på jeres intranet i stedet for ...

Hvad siger ledelsen i Kapow til at få evnerne og teamet udstillet i mere eller mindre gennemtænkte blogindlæg her?

Det er så mig ;-)

Jeg synes, at det er meget modigt af Bolette, at hun tør dele sine oplevelser i et forum, hvor man er næsten garanteret at få en masse negative kommentarer tilbage - og selvfølgelig bliver det langt mere firkantet og stillet-på-spidsen i et blogindlæg, end virkeligheden er. Jeg tror ikke, at Bolette havde turdet at skrive eller publicere sådan et blogindlæg, hvis hun ikke i forvejen havde et rigtig godt forhold til sine kolleger, inklusive Klaus.

Det er efter min mening ærgerligt, at diskussionen i høj grad har handlet om, hvem der er "galt på den", er det nu udvikleren, testeren eller ledelsen? Hvis man leder efter syndebukke, så får man ikke det ud af blogindlægget, som jeg mener er dets intention, nemlig at vi kan opleve den samme situation meget forskelligt afhængigt af vores eget perspektiv. Og at det uanset om man er udvikler, tester, leder eller noget fjerde er muligt at blive klogere af at høre en oplevelse fra den anden side.

Det er efter min mening ærgerligt, at diskussionen i høj grad har handlet om, hvem der er "galt på den"

Hvis den skulle have været modtaget på en ret meget anderledes måde, så skulle vinklen i blogindlægget nok have været mere filosoferende over de reelle problemstillinger og tilgå "fagstereotyperne" på en mere anerkendende måde.

Det er efter min mening ærgerligt, at diskussionen i høj grad har handlet om, hvem der er "galt på den", er det nu udvikleren, testeren eller ledelsen?

Når jeg læser afslutningen igen - og antager at det ikke er sarkastisk ment - kan jeg heller ikke forstå hvorfor modtagelsen af blogindlægget er som den er. Titlen sætter selvfølgelig en tone om at udvikleren var arrogant, men indholdet beskriver da at han hverken var arrogant eller uvillig til at hjælpe.

Der forhåbentlig en balance imellem hvornår det er bedst for alle parter at udvikleren hjælper til med opsætningen, eller i stedet sender testeren afsted med nogle brugbare pointere til at komme videre. Det kommer an på så mange flere faktorer end hvad der kan skrives i et blogindlæg. Vi udviklere har en uvane med at ville forholde sig til hvad der er hvis skyld, og hvem der er galt på den -- for mange hænger det sammen med et dybfølt ønske om at tingenes tilstand bare havde været bedre ("Nej, Mor, jeg kan desværre ikke hjælpe med din Windows maskine, jeg synes også det er urimelig sølle"). Det ønske giver et behov for at i det mindste selv at gøre det bedre, inden for hvad man selv kan påvirke. Og så begynder grænsedragningen og fingerpegningen.

Det er surt hvis udviklere ender med et ry for let at blive stødt på manchetterne. Hvis tennissok-gate er et eksempel på én pol af misforståede stereotyper, så er dette indlæg den anden pol: Nogle føler sig ramt af en stereotypificering, som faktisk ikke er til stede - hvis de bare læste indlægget til ende.

P.S.: Tomcats dokumentation ... kunne være bedre.