Hvad skal en god udvikler kunne?

Har I nogensinde overvejet om I er gode udviklere? Prøv for eksempel bare at indplacere jer på en skala fra 0 (uøvet) til 3 (ekspert). De fleste af os vil nok umidelbart sige 2 eller 3, men tænk lige lidt over det inden I læser videre.

Nogle vil måske sige "Jamen, jeg har titel af seniorudvikler og ifølge lønstatistikken tjener jeg i den pæne ende", så er jeg vel at betragte som 'ekspert'' Men spørgsmålet handlede vel hverken om titel eller løn, men om hvad man kan'

Så hvad skal man kunne for at med rette kalde sig en god udvikler?

En kollega faldt over et blogindlæg Programmer Competency Matrix - 32 attributes to evaluate programmers. På 32 områder gives forholdsvis konkrete kundskaber der skal til for at være på et niveau fra 0 til 3. En ren 3'er vil jeg ikke prale af, men jeg ligger pænt fremme, og jeg er blevet gjort opmærksom på nogle områder hvor jeg konkret kunne øge min viden.

Hvad mener I' Har han ramt rigtigt eller er magler der nogle klare målepunkter'

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Rene Nejsum

En god udvikler skal kunne omsætte kundes ønsker til gode IT systemer, hverken mere eller mindre.

Derfor er det en smule foruroligende, men også nok typisk at ikke ét af de 32 spørgsmål går på om man kan noget nyttigt.

  • 0
  • 0
#2 Mads N. Vestergaard

Det minder mig meget om en ansøger vi havde til samtale for noget tid siden. Han havde vurderet sig selv i det hele på en skala fra 1 til 5. Alt hvad der omhandlede programmering, og programmerings sprog, havde han givet sig selv 5 i.

Vi var selvfølgelig stadig ivrig efter at se hvad han kunne, men antog at han nok kun kunne halvdelen af hvad han havde skrevet sig til.

Det viste sig jo hurtigt ved samtalen at han også selv måtte indse, at han nok havde givet sig selv en ret god vurdering.

Jeg er selv af den overbevisning, at folk der giver sig selv en topscore, i sådanne ting, heller ikke er villig til at lære mere, da de jo mener de er expert, og det duer bare ikke.

  • 0
  • 0
#3 Ole Elkjær Christensen

Er dette en liste der beskriver en god udvikler eller er det den liste en udvikler ville gå efter at opfylde, hvis han/hun ikke hele tiden blev forstyrret af rigtigt arbejde ?

Da alle projekter som regel har for kort tidsplan eller for lille et budget (somregel begge), vil man som udvikler meget ofte skulle gå på kompromi med flere af disse level 2-3 ting. Ikke fordi man ikke gerne ville skrive god kode, men fordi projektplaner og lign. forhindrer det.

Der ud over er der nævnt et par interresante level 3 ting så som prolog og lign. Det er heller ikke det mest fremtrædende sprog jeg har set ude i virkeligheden :-)

Den mest interresante er dog at man skal have en blog, hvor man deler sin fantastiske indsigter ud i programmeringens verden, er nok den bedste. Dette har intet med at være en god programmør at gøre. Dette har noget med personlig markedsføring at gøre og ikke noget som helst andet.

  • 0
  • 0
#4 Esben Nielsen

"Der ud over er der nævnt et par interresante level 3 ting så som prolog og lign. Det er heller ikke det mest fremtrædende sprog jeg har set ude i virkeligheden :-)"

Nu er det jo sådant, at selvom teknologier ikke direkte anvendes ude i "virkeligheden", kan de give inspiration til, hvordan tingene også kan gøres. Jeg vil sige, at jeg først ordentligt kunne bruge functors i C++, da jeg havde prøvet ML.

  • 0
  • 0
#5 Torben Frandsen

Jeg husker en undersøgelse af menneskers evne til at vurdere sig selv. Resultatet var, meget kort fortalt, at når man bliver bedt om at vurdere sine evner i et specifikt felt, placerer man sig selv i tredje kvartil.

http://www.apa.org/journals/features/psp7761121.pdf

Desværre medfører den slags undersøgelser at vi, der ligger i tredje kvartil, pludselig bliver set som utroværdige når vi fortæller om vores evner ;-)

  • 0
  • 0
#6 Ole Elkjær Christensen

Nu skulle det ikke forståes sådan at jeg har noget imod prolog eller lignende sprog og som du siger kan de ofte bidrage med en anden synsvinkel og forståelse. Det jeg nok synes er lidt underligt er at det er en level 3 ting. Det er vel ofte på universiteter og lign. man stifter bekendskab med flere af disse sprog, men efter at man har forladt denne universitets verden til fordel for arbejde som programmør, er det sjældent man får tid til at arbejde med det igen. Jeg ville da gerne se min chef i hovedet, hvis jeg bad ham om at komme på kursus i ADA, fordi det kunne bidrage til min teoretiske forståelse af PL/SQL :-) Alt i alt er de programmeringssprog spændende og lærerige, men jeg forstår bare ikke at de er en level 3 ting.

  • 0
  • 0
#7 Peter Makholm Blogger

Pointen er ikke at at gode programmøre kan mange sprog, men at en af de ting der adskiller gode programmøre fra mindre gode er at de gode har et bredt kendskab til de forskellige grundlæggende typer af programmeringssporg.

At imperative og objektorienterede sprog så kommer på de første niveauer og funktionsorienterede sprog først senere ser jeg lidt som listens kulturelt bestemte subjektive slagside. Men den passer lidt med den virkelighed jeg ser. Alle programmerer imperativt, men de gode programmøre kan trække på erfaring fra funktionsorienterede sprog eller logikprogrammering.

Folk som går i stå efter de slipper ud af uddannelsessystemet trorjeg ikke bliver rigtig gode til noget som helst - det være sig programmering eller noget andet fagområde.

  • 0
  • 0
#8 Peter Makholm Blogger

En god udvikler skal kunne omsætte kundes ønsker til gode IT systemer, hverken mere eller mindre.

Det er ikke en særlige operationel definition, desuden er jeg uenig.

Den gode udvikler vil såvel overveje kundens ønsker som kuneden nuværende og fremtidige behov. Men grundlæggende set er dette bare den linje der hedder 'requirement'.

Men jeg vil slet ikke mene at man overhovedet kan lave gode IT-systemer uden at have viden om data strukture, algoritmer og funktionen af de værktøjer man bruger, for nu at tage de tre første linjer i skemaet.

  • 0
  • 0
#9 Poul-Henning Kamp Blogger

Jeg stødte selv ind i den tabel for nogen tid siden og efter at have kigget lidt på den trak jeg på skulderen og tænkte "Godt forsøgt, men: nej".

Listen lider af et bestemt syn på verden, f.eks antages distriburede VCS at være "bedre" end centraliserede VCS systemer. I min verden havde det højeste niveau været "ved hvordan man vælger et VCS".

Tilsvarende viser "Author of Framework" en indfaldsvinkel til verden der er alt for idolbaseret og hierarkisk.

Hvordan man kommer fra "scripting" kategorien til "Has written and published reusable code" fatter jeg ikke. Gælder det ikke hvis det er C++ eller C kode man har publiceret ?

I "Languages exposed to" er idealet Erlang og Prolog, jeg ville have skrevet "Doesn't hurt anybody when using C".

Svaret på tabellens decentrering ligger muligvis i rækken "domain knowledge", der ikke burde forefindes, hvis man prøver at finde den "almene dannelse" for en programmør.

Poul-Henning

  • 0
  • 0
#10 Ole Elkjær Christensen

Jeg tror også at det er denne opdeling af hvad man skal have beskæftiget sig med og behærsker der får mig til at krumme tæer. Der mangler også punktet : Skal have udgivet mindst en bog om progammering !!!

Jeg er også af den opfattelse at folk som går i stå efter endt uddannelse er lidt på den. Det er jo de folk der forsat hænger fast i prolog og ikke er kommet videre :-)

Måske det som gør en god udvikler ikke er antallet af "skills" men nogle specille egenskaber som f.eks. :

Logisk tankegang. Evne til at se mønstre. Nysgerrighed. Stædighed. Vilje til at lære.

Og måske til sidst en god portion humor for at undgå at blive kugle skør :-)

Hvis man har nogle af disse egenskaber som person og man finder programmering interresant er jeg sikker på at diverse "skills" kommer med tiden, da man ikke kan lade være med at udvidde ens værktøjskasse hele tiden.

/Ole

  • 0
  • 0
#11 Anonym

Folk som går i stå efter de slipper ud af uddannelsessystemet tror jeg ikke bliver rigtig gode til noget som helst - det være sig programmering eller noget andet fagområde.

Jeg tror ikke at mange decideret går i stå efter endt uddannelse, da man jo hele tiden lærer af erfaring, men apatien melder sig nok hos de fleste efter et par år i softwarebranchen. Har man en decideret softwareuddannelse bag sig, kan det være svært at tilpasse sig arbejdsgangen i en virksomhed og de fleste, der ellers giver den en skalle til at begynde med, brænder ud og begynder blot at lade "tingene stå til".

Efter at have arbejdet i branchen siden 1999, har jeg kun haft et enkelt job (i England), der var teknisk udfordrende - resten har været arbejde med bind for øjnene. De "udfordringer" som ledelsen præsenterede var brandslukninger efter ledelsesssvigt/fejl.

  • 0
  • 0
#13 Ole Elkjær Christensen

Har man en decideret softwareuddannelse bag sig, kan det være svært at tilpasse sig arbejdsgangen i en virksomhed og de fleste, der ellers giver den en skalle til at begynde med, brænder ud og begynder blot at lade "tingene stå til".

Problemet er nok noget af det samme som jeg oplevede for en del år siden på hardware området, hvor jeg har min første uddannelse. I starten var det rigtigt elektronik der skulle repareres og produceres. D.v.s. at man skulle fejlfinde, lodde og udskifte komponenter eller bygge helt nye konstruktioner. Så skete der mere og mere det at elektronik blev komplekse, modulariseret og billige. Pludselig var ens arbejde der var et teknisk håndværk blevet til et moduludskifter arbejde, som basalt set var død sygt.

Det samme er der sket inde for software mange steder. Firmaer køber store systemer og frameworks, som de så laver moduler og rettelser til. Derfor bliver udviklerens job ofte at tilrettelser, integrationer og nye moduler til et mega framework. Det var ikke nødvendigvis det man havde forestillet sig da man tog sin uddannelse som software udvikler. Det kan være svært at finde et "rigtigt" software udviklings job, og derfor kan man nemt ende udbrændt og desillusioneret. Det kan sågar gå så galt at man ender med at skrive tilrettelser i ABAP, for at tilrette SAP til en virksomhed, selv om de fleste godt ved at det sikkert var billigere at tilrette virksomheden til SAP :-) Der er et par løsninger, hvis man er rigtig udvikler. Man kan prøve igen med et nyt job. Det rigtige job kan jo være der. Hvis tiden og fammilien tillader det, kan man jo kaste sig over nogle af de open source projekter der er. Der er god mulighed for at lave noget fornuftigt. Så kan man jo bare beholde sit job for indkomstens skyld :-) Man skal ikke bare give op og lade tingene stå til. Man må istedet vende tingene lidt på hovedet og bruge det man har til det det er bedst til. Der er mange muligheder for at komme til at lave det man egentlig gerne ville, selv om det ikke lige pt. tilbydes på ens job. Så må man jo som sagt bruge ens job til det man kan og så få opfyldt ens interesser andet steds. Det er selvfølgelig ærgeligt, men mest for den pågældende virksomhed, da de ikke får fuld valuta for deres penge. Men det er heller ikke altid det betyder noget. Bare man i det mindste kan sikre ens chefs bonus, så er man godt kørende :-)

/Ole

  • 0
  • 0
#14 Eskild Nielsen

En god udvikler skal kunne omsætte kundes ønsker til gode IT systemer, hverken mere eller mindre.

Dette er et pragtekseemplar af en one-liner floskel.

I den virkelige verden er kundens ønsker - sådan som han selv er i stand til at beskrive dem - som oftest ikke beskrevet i en form som kan bruges til udvikle udfra.

Desuden - hvad er gode IT-systemer? Er det systemer, der - er lette at lære at bruge? - er lette at bruge når man har lært at bruge dem? - er opfattes som effektive, når man bruger dem af og til? - opfattes som effektive, når man bruger dem flere timer dagligt? - løser opgaven 'godt' på bestillingstidspunktet? - er lette at vedligeholde? - som kan anvendes i mange år på trods af udskiftninger i det øvrige IT miljø?

/esni

  • 0
  • 0
#15 Anonym

En interessant matrice med mange dimensioner - også flere end jeg vil forsøge at gøre mig klog på da de rummer tekniske aspekter som jeg ikke har beskæftiget mig med eller det er længe siden jeg var blot tilnærmelsesvis up-to-date omkring.

Der er megen fokus på test, hvilket er glimrende fordi der laves alt for mange kodefejl.

Jeg vil dog kommentere at der mangler en systemforståelse af Security by design. Hele spørgsmålet omkring fejltolerance, dependability, undgå interdependance og hvordan man sikrer fallbacks på alle niveauer er dårligt dækket.

For mig at se er hovedproblemet ikke kodefejl, men at man laver strukturelle designfejl. Der vil altid være kodefejl, men spørgsmålet er om det strukturelle design antager disse og indrettes til at være holdbar overfor sådanne fejl, dvs. indbygget har både aspekter som revokability og recoverability.

Et veldesignet system kan opgradres i takt med at kodefejl identificeres og elimineres uden at strukturen lider nød eller sikkerheden ryger. Modellen bør specifikt altid tilsikre at sikkerhedsbrud ikke kan skalere i modsætning til f.eks. Digital Forvaltning i Danmark som bevidst designes uden sikkerhed.

Et godt eksempel på en klassisk designfejl er at antage Identifikation fremfor Authentifikation, dvs. at man genbruger nøgler udenfor kontekst i stedet for at isolere sårbarhedne til den specifikke kontekst.

Men det er nok også en af de allersværeste discipliner fordi den kræver at man tager udgangspunkt i en tilgang som antager at it-systemer fejler - både ved fejl og grundet bevidst misbrug. Kan det fejle, vil det fejle.

En sådan tilgang vil f.eks. ALDRIG have tillid til en server - serversystemer fejler før eller siden næsten uundgåeligt. Er sikkerhedsmodellen på plads NÅR - og ikke hvis - sikkeheden ryger !?

Vi laver kun systemer, hvor vi antager at alle "trustede" parter arbejder sammen i et angreb - kan det ikke holde i en sådan situation, så er det tilbage til tegnebrædtet.

Ovenpå og udenpå sådanne systemer kan man så lave BEVIDSTE fejlmodeller, dvs. hvor f.eks. en dommer kan initiere en process, der kan lukke noget op som ellers aldrig antages skulle kunne ske.

Essensen er at du designe med en forståelse at du KAN og slet ikke at du SKAL stole på systemet, men på dommeren og hele det eksterne domstolsapparat som er vores sidste forsvarsværk mod anarki og magtmisbrug.

I praksis er vi nødt til stole på mennesker (enkelt-personer såsom din læge), men aldrig på servere.

Just my 2 bits.

PS. Den - for teknikkere - svære erkendelse er at stole på mennesker, men ikke på systemer. Teknikkere har typisk den omvendte tilgang, men glemmer at tillid til systemer forudsætter tillid til mennesker, fordi systemer kontrolleres af mennesker og særinteresser.

  • 0
  • 0
#16 Anonym

Eskild.

Du glemte semantisk interoperabelt eller åben for nye måder at gøre tingene på.

Det største problem ved digitalseringen i dag er at den oftest er diktatorisk standardiseret, dvs fastlåser udviklingen omkring en tvangsmodel der i praksis både udtrykker interesser (og f.eks. som med kredit kort etablerer et kartel som markedet ikke kan bryde) og legacy (som f.eks. de biometriske pas der er en af vor tids nemmest forudsigelige katastrofale fejldesign uden sikkerhed for nogen).

Det gælder ikke kun sikkerhedsaspekterne, men det er her problemerne er størst, fordi så godt som alle sikkerhedsmekanismer tilgængelige i dag forudsigelgit vil bryder sammen over de næste 5-20 år med krav om gradvist udskiftning til følge.

Designs som ikke tager højde herfor er per defition forældet førend de er implementeret.

  • 0
  • 0
#17 Deleted User

Jeg havde ikke selv tænkt meget over at der findes gode og mindre gode udviklere, før jeg selv forlod programmering til fordel for at være projektleder.

Hold da op en forskel jeg oplevede/oplever på de programmører der er med i mine projekter.

Set med mine "nye" briller, kan jeg nu se at udviklere kan: - løse en opgave hurtigt eller mindre hurtigt - forstå en opgave hurtigt, eller være langsomt forstående - arbejde med vide rammer, eller have behov for meget klare instrukser - arbejde sammen med andre, eller være enspænder - knalddygtig til et domæne, eller bred - sætte sig ind i ny teknologi selvstændigt, eller have behov for støtte - have mere eller mindre forståelse af værdien af softwaren for kunden - være opstarter eller afslutter

Vi har alle vores svage og stærke sider, og jeg synes ikke det er rimeligt at tale om "dygtige" og "dårlige" programmører. Vi er som regel stærke til noget, men sjældendt stærke til alting. Lad os hellere tale om de stærke og svage sider istedet. Jeg har f.eks. set en meget dygtig java programmør, som man godt kunne give en teknisk kompliceret, før uprøvet opgave, men som simpelthen ikke kunne finde ud af at arbejde i teams eller få noget gjort HELT færdigt. Han vil sikkert vurdere sig selv som meget kompetent udvikler, men set fra projektlederens synspunkt har han nogle svagheder der skal kompenseres for.

Skemaet har teknisk slagside, og jeg synes ikke det er så brugbart. Det kan måske give et fingerpeg i retning af teknisk know-how, men jeg ville egentligt også fokusere på de blødere egenskaber.

  • 0
  • 0
#18 Ole Elkjær Christensen

Vi har alle vores svage og stærke sider, og jeg synes ikke det er rimeligt at tale om "dygtige" og "dårlige" programmører.

Det er nok et faktum at man ikke kan dele nogle mennesker op på denne måde, heller ikke programmører :-) . Den store udfordring, som de fleste chefer eller projektledere har, er evnen til at finde folks talenter og bruge dem optimalt. Da de fleste chefer ikke er uddannet psykologer, bruger de tests og teambuilder kurser, for at ryste folk sammen og for at finde ud af hvilke typer de er. Men i virkeligheden kunne de bare bruge tid til at snakke og lytte til medarbejderne for at finde ud af hvad de egentlig kan og vil.

Det forholder sig nok sådan at hvis man er villig til at lade medarbejderen lave det, han selv føler han er bedst til, vil man opnå de bedste resultater.

Det er ofte det mange ledere gerne vil, men det er svært at håndtere for en leder, for det kan betyde at den ekspert man har siddende i en stilling, måske helst vil lave noget andet. Hvordan kan man flytte ham der over, når han nu er den bedste til det han laver nu.

Derfor vil den "gode" udvikler måske være et produkt af nogle af de personlighedstræk jeg nævnte tidligere og en leders evne til at se og udnytte dem sammen med udvikleren.

Er det måske et spørgsmål om at en glad udvikler er er god udvikler ?

Det er måske overdrevet, men det er en god vej for at skabe en "god" udvikler, men det kræver at en del ledere får et andet fokus ud over det økonomiske og glæden ved at kunne rubricerer alting i Excel :-)

/Ole

  • 0
  • 0
#19 Eskild Nielsen

Stephan

Mit mål var jo ikke at give en udtømmende liste, men blot at illustrere at en 'god' IT-løsning ikke var noget entydigt.

At totalt glemte enhver detalje der smagte af sikkerhed i bred forstand - det betyder kun at IT-verdenen skal være glad for at jeg ikke ernærer mig som IT-udvikler...

/esni

  • 0
  • 0
#20 Deleted User

Er det måske et spørgsmål om at en glad udvikler er er god udvikler ?

Ole,

Det er nogle vigtige pointer. Udvikleren er i alt fald ikke god, hvis han eller hun ikke er overordnet tilfreds med sit arbejde. Men som leder skal man nok ikke bare forvente at så længe der bliver smilet og grinet på kontoret, så kører alting som det skal :)

Det ville selvfølgelig være lettest hvis vi altid kunne få lov at lave det vi synes er sjovt. Men i den virkelige verden, er der ikke så ofte mulighed for 100% fordybelse i ønske-emnet. De tilgængelige opgaver skal altid matches med de tilgængelige ressourcer, og der er det ofte nødvendigt at være pragmatisk.

Vi skal alle forvente af vores ledelse, at de gør hvad de kan for at opfylde ønskerne og optimere vores muligheder for at gøre det bedste vi kan. Jeg er helt enig i at det er noget som rigtigt mange kan blive meget bedre til - både på det operationelle, taktiske og det strategiske niveau. Men det er ikke realistisk at forvente af arbejdspladsen, at det altid kan lade sig gøre. Skudt fra hoften, er min egen oplevelse, at over 50% af arbejdet er med andre ting end der hvor interessen primært ligger.

Som arbejdstagere må vi også være indstillede i at give noget igen, og arbejde med os selv der hvor vi er lidt svagere. Vi må også være indstillede på at arbejde konstruktivt med i de situationer, hvor der er behov for at vi levere andre ydelser end dem der står øverst på vores egen liste. Det er måske et spørgsmål om at hanke op i os selv for at få gjort noget HELT færdigt, eller et spørgsmål om at sige - nå ja det her ser svært ud, men nu giver jeg den en skalde! Det er heldigvis også det som langt de fleste udviklere gør hver eneste dag på arbejdet :)

Jeg tror det er noget med at ledelsen skal fokusere, og forstå (og her er samtalen, og besøgene rundt i kontorene og i projekterne, jo et rigtigt godt bud på metoden) medarbejdernes kompetencer og interesseområder, samtidigt med at medarbejderne er både pragmatiske og i stand til hele tiden at udvikle sig.

  • 0
  • 0
#21 Ole Elkjær Christensen

Som arbejdstagere må vi også være indstillede i at give noget igen, og arbejde med os selv der hvor vi er lidt svagere.

Jakob

Jeg er heller ikke så naiv og tro at jeg 100% kan få lov til at lave det jeg gerne ville, men jeg vil nok forsøge at komme over de 50% som du nævner :-) Det ville dog være dejligt hvis verden var så lyserød. Den evige "jeg skal tilpasse mig arbejdsgiverens behov og optimere mine processer for at yde maksimalt for arbejdsgiveren" er dog interessant. Jeg kan godt forstå at det er arbejdsgiverens ønske, men jeg er ikke sikker på hvornår det er blevet noget medarbejdere går og messer for sig selv og hinanden. Det er noget jeg har set flere steder i flere virksomheder at medarbejderne går rundt og slår sig (og andre) selv oven i hovedet med sætninger som : Jeg skal være forandringsvillig, yde noget mere og være mere effektiv. Samtidig falder medarbejderne bogstavelig talt omkuld på gangene af stress. Hvornår skete det skift der gjorde at personlig udvikling er noget man skal foretage for at arbejdsgiveren bliver glad ? Jeg troede at det var noget jeg foretog mig for at jeg skulle blive glad og få mere overskud til mig og min famillie !!!

Nu er det heller ikke fordi jeg ikke mener at man skal give den en skalde, men når man først har prøvet det 10 gange på 10 projekter og hver gang fået at vide at det næste projekt bliver anderledes. Det bliver ikke underbudt og under estimeret, for så endnu engang at konstatere at man lige skal give den en ekstra skalde for at redde røven på en eller anden, så holder musikken som regel op med at spille helt så højt. Når man så heller ikke har fået noget "bonus" ud af at give den en skalde, andet end endnu et nyt håbløst estimeret projekt, så begynder man at stille krav om at ledelsen måske skulle æde egen medicin og begynde på lidt personlig og ledelsesmæssig udvikling, der ikke bare går ud på at klappe hinanden på rykken og objektivisere medarbejderne så de kan behandles som celler i et regneark med en projektplan !!!

Nu begynder jeg at forstå hvorfor at udviklere skal have en blog. Man bliver jo nødt til at have denne ventil hvor man kan få alt sin brok ud :-) Dette er en mulighed jeg aldrig havde overvejet, selv om jeg også her en terapeutisk uddannelse. Genialt :-)

/Ole

  • 0
  • 0
#22 Ole Elkjær Christensen

Hmmm - Jeg kunne godt bruge lidt mere tid til at opdage og rette stave, tryk fejl her på siden. Redigeringes muligheden timer lidt for hurtigt ud til mig :-) Jeg mener ellers altid at min source kode burde kunne tilrettes, redigeres og optimeres, men sådan er det åbentbart ikke altid :-)

/Ole

  • 0
  • 0
Log ind eller Opret konto for at kommentere