Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum tre års erfaring som utvikler, UX eller UI-designer, systemarkitekt eller prosjektleder. Ta kontakt og bli med på laget!

Bli en av oss banner

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur.

Møt en X banner

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur. Les noen av våre Medium blog posts her!

Bloggen - Dfind Consulting

Restore Commit History with Git Reflog

Dfind Consulting — Internship 2022

Hva er Dfind Direction?

European Women in Tech 2022 - Tre takeaways

Help, I’m a proxy product owner!

React Scroll Hook with Shadows

Stop Overusing Console.log in JavaScript

Benefits of Static Site Generation

Hvordan få opp farta på utviklingen med et testpanel

La oss inspirere hverandre og sammen øke kvinneandelen i techbransjen

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NNpIKZmLZ8bDSz79"><figcaption>Photo by <a href="https://unsplash.com/@vonshnauzer?utm_source=medium&amp;utm_medium=referral">Egor Myznik</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Did you know we can use Git reference logs to restore Git commit history(?) Often we developers experience challenges when working with Git. We can accidentally force-push commits to the remote main branch, complete a rebase that went bad, delete a branch we wanted to keep or hard reset to the wrong commit. In this post, we will look at git reflog and git reset. We will review some common scenarios on restoring local commits, restoring a deleted branch, and reverting force-pushed changes due to a rebase.
<h3>Git reflog</h3>
<a href="https://git-scm.com/docs/git-reflog">git reflog</a> is a tool that can help us recover almost anything — at least everything we have committed. The tool keeps track of commits that have been created but also discarded ones in a log called the reference log. The reference log is kept on our local computer under the .git directory in a local repository. It contains a list of commits that HEAD has pointed to and keeps track of the entire history of a commit. Besides the reference log for branches, we have a separate reference log for stash.
It’s important to know that reference logs do not track in the remote repository, like pushes, fetches and clones; it is purely local and current to the working environment. Below is two screencaps, the first from Github Codespaces and the second from a local filesystem that initially created all the commits of the main branch in the same repository:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/964/1*L1DTjYe4kiUo01_95hL-dQ.png"><figcaption>Reference log from a workspace in Github Codespaces</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/930/1*d175xjAzVotgtgHlFvjtQg.png"><figcaption>Reference log from local computer where the commits were initially created</figcaption></figure>Records of the history on a branch will expire after 30 days by default. We can change the expiration days running git reflog —expire if we want to keep the history for a longer time or just want to change the duration.
<h3>Git log vs reflog</h3>
<a href="https://git-scm.com/docs/git-log">git log</a> is a command that shows a list of commits related to a branch.git reflog is similar to git log but shows a list of snapshots and times when HEAD was changed. reflog can also reference other types such as stash, branches, rebase, merge and tags. A reference is known as refs, and the syntax for accessing these is name@{qualifier}. Running git reflog is the most basic use case and essentially the equivalent of writing git reflog show HEAD. The output will look like this:
<pre>=&gt; git reflog</pre>
<pre>47efaa2 HEAD@{0}: commit: refactor: remove post schema f243f12 HEAD@{1}: commit: refactor: change author fields 4783ba0 HEAD@{2}: commit: chore: add .env to gitignore a19d142 HEAD@{3}: commit: chore: update readme f5ade9a HEAD@{4}: commit: chore: update yarn.lock 854c08f HEAD@{5}: commit (initial): feat: bootstrap sanity studio</pre>
<h3>Git reset</h3>
<a href="https://git-scm.com/docs/git-reset">git reset</a> is a command we can use to move back to a previous commit, discarding or undoing previous changes. We can run git reset -hard &lt;commit_sha&gt; to move our branch back in the commit history.
A hard reset (git reset --hard) will completely destroy any changes and remove them from your local repository.
A soft reset (git reset --soft) will keep your changes, and stage them back automatically.
A mixed reset (git reset --mixed) which is the default, will keep you changes but they will also become unstaged. Even tho it is flexible, you will have to stage the changes manually.
<h3>Restore local commits</h3>
<h4>
Scenario:</h4>
We have made some commits that haven’t been pushed to the remote repository yet. We do a git reset —-hard &lt;commit_sha&gt; to a previous commit, and our local branch is set back to an earlier point and discarded all history after the chosen commit. We then run git log and see that the commits are gone. We cannot pull the changes from the remote repository since we never synced the changes.
<h4>
How to restore:</h4>
When running git reflog we can see that our changes still are tracked by the reference log; we even have a separate commit for the hard reset that we did earlier:
<pre>f243f12 HEAD@{0}: reset: moving to f243f12 eec6f27 HEAD@{1}: commit: refactor: author should not have image 47efaa2 HEAD@{2}: commit: refactor: remove post schema f243f12 HEAD@{3}: commit: refactor: change author fields</pre>
With this information, we can reset our branch back to the state we discarded by using one of the references in the reflog. We can move our branch to the selected commit by running git reset --hard &lt;commit_sha&gt;:
<pre>=&gt; git reset --hard f243f12 =&gt; git reflog</pre>
<pre>f243f12 HEAD@{0}: reset: moving to eec6f27 f243f12 HEAD@{1}: reset: moving to f243f12 eec6f27 HEAD@{2}: commit: refactor: author should not have image 47efaa2 HEAD@{3}: commit: refactor: remove post schema f243f12 HEAD@{4}: commit: refactor: change author fields</pre>
<h3>Restore a deleted branch</h3>
We can recover deleted branches using SHA’s in the reference logs.
<h4>Scenario:</h4>
Not uncommonly, we might checkout a new branch in our local environment. We could have a branch called chore/update-packages and commit a change that adds <a href="https://day.js.org/">dayjs</a> as a package:
<pre>=&gt; git checkout -b chore/add-dayjs-package =&gt; yarn add dayjs =&gt; git add . =&gt; git commit -m 'chore: add dayjs package'</pre>
<pre>5a75042 HEAD@{0}: commit: chore: add dayjs package</pre>
At a later point, we checkout the main branch and deletes the chore/add-dayjs-package branch — maybe we did not need it anymore for some reason:
<pre>=&gt; git checkout main</pre>
<pre>47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main</pre>
<pre>=&gt; git branch -D chore/add-dayjs-package</pre>
<pre>Deleted branch chore/add-dayjs-package (was 5a75042)</pre>
We will get a confirmation message that git deleted the branch. After a while, we discover that we could need the changes after all, so how do we get them back?
<h4>How to restore:</h4>
We can undo these changes with git reflog and git checkout. If we run git reflog we won’t see any references to the deleted branch. What we could do, is to use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we can run git reflog. And if you named your commits propertly it should be easy to find back to the missing commit:
We can undo these changes with git reflog and git checkout. If we run git reflog we won’t see any references to the deleted branch. We could use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we need to use the reference log. And if you named your commits well, it should be easy to find the missing commit:
<pre>=&gt; git reflog</pre>
<pre>// deletion of a branch is not logged to reflog 47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main 5a75042 HEAD@{1}: commit: chore: add dayjs package 47efaa2 HEAD@{2}: moving from main to chore/add-dayjs-package</pre>
We can now checkout the deleted commit SHA and create a new branch from that commit running git checkout -b &lt;branch_name&gt;:
<pre>=&gt; git checkout 5a75042 =&gt; git checkout -b chore/add-dayjs-package</pre>
<h3>Revert force-pushed changes</h3>
<h4>Scenario</h4>
We reset our branch using git reset —-hard to an earlier commit and run git push — force to override any changes that we otherwise could pull from the remote repository. But at some point, we want those changes back.
<pre>=&gt; git reset --hard &lt;commit_sha&gt; =&gt; git push --force</pre>
<h4>How to restore:</h4>
We can use git reflog and git reset to restore force-pushed changes.
<pre>=&gt; git reflog f243f12 HEAD@{0}: reset: a19d142 to f243f12</pre>
By the log we can see that the message on HEAD@{0} is reset: a19d142 to f243f12, which means that commit with hash a19d142 was force-pushed by f243f12. That also gives us information about which commit we need to restore, the one with hash a19d142. We can simply do the same procedure as initially to move back to the overriden commit:
<pre>git reset --hard a19d142 git push --force</pre>
Finally, we force-push the new changes to the remote repository. Always be careful and check that you are on the correct branch before doing a force push. Especially to prevent that production code is not being affected or team member code is not being overwritten.
Thanks for reading! I hope you enjoyed this content. Feel free to clap, comment or share.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=67f7676e902f" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/restore-commit-history-with-git-reflog-67f7676e902f">Restore Commit History with Git Reflog</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<h3>Dfind Consulting Internship 2022</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*bIkHM8F11nVKVT1pVOiACQ.jpeg"><figcaption>Jannicke Hamarsnes, Helena Skants, Skjalg Hovland Holtbakk, Eskil Schjølberg, Kavusikan Sivasubramaniam, Thea Kvinnegard, Ida Anseth, Duvara Nishaharan, Elsa Lossius (bak fv.) og Patrick Wulff.</figcaption></figure>Skrevet av Axel Aasen
Dfind Consulting har i år hatt sitt første internship. Over seks uker har ti sommerstudenter hatt ansvar for å lede et prosjekt for selskapet. I løpet av perioden har de utviklet en mobilapplikasjon og en webapplikasjon. Jeg har tatt en prat med sommerstudentene Thea Kvinnegard, Jannicke Hamarsnes og Ida Anseth for å få innsikt i hva de har arbeidet med og lært i løpet av perioden.
Sommerstudentene var delt inn i to team; Team App og Team Admin. Team App hadde ansvar for å utvikle mobilapplikasjonen, mens Team Admin hadde ansvar for å utvikle webløsningen. De to teamene var avhengige av hverandre gjennom hele prosjektet, og samarbeidet på tvers. På denne måten fikk de en realistisk opplevelse av hvordan man som konsulent jobber i prosjekt, med viktigheten av kommunikasjon, forventningsstyring, koordinering, prioritering og hvordan eget arbeid påvirkes av andres. Thea beskriver dette som en av de viktigste erfaringene hun tar med seg fra perioden.
“Å jobbe i parallelle team og se hvordan et slikt samarbeid kan fungere, å faktisk oppleve at det ikke alltid går smidig eller blir helt sånn man hadde tenkt har jeg lært utrolig mye av.”
For best mulig prosessgjennomføring benyttet teamene scrum som metodikk. Med daglig standup, ukentlig sprintplanlegging, demo og retro sikret studentene evaluering og progresjon underveis i prosjektet. Likt for begge teamene var at de rullerte uke for uke på hvem som var Scrum Master, slik at de som ville fikk prøve seg på denne rollen. Av studentene jeg har pratet med mente samtlige at dette var relevant og lærerik erfaring å ta med seg, og Thea beskriver hva hun erfarte i rollen::
“Å få jobbe ordentlig etter scrum-metodikk har vært en stor forskjell fra studiehverdagen til arbeidslivet. Som student er det ikke mulig å benytte slike metodikker fordi det ikke er nok kontinuitet i prosjektene. Det var en øyeåpner å se hvor bra scrum faktisk fungerer — gøy å oppleve.“
Jannicke legger til:
“I en uke hadde jeg hovedansvar for at teamet fulgte arbeidsformen vi hadde blitt enige om, og så til at vi kommer oss gjennom oppgavene som er prioritert. Dette er første gang jeg har fått prøve meg som Scrum Master, så veldig gøy å få prøvd meg på den rollen.”
Gjennom hele internshipet var produkteier og flere konsulenter fra Dfind Consulting tilstede for å bistå og støtte studentene underveis. Dette bidro naturligvis til trygghet for studentene, samtidig som det ga synergier på bakgrunn av mangfoldet de sammen utgjorde. Både Thea, Jannicke og Ida beskriver dette som en av de største forskjellene mellom studiehverdagen og arbeidslivet, og som noe av den viktigste erfaringen de tar med seg.
“Det var en trygghet å ha erfarne konsulenter fra Dfind Consulting i ryggen. Det å ha noen å spørre og sparre med gjør det lettere å komme videre om man står fast.”
“Dette er er jo en bransje som utvikler seg veldig raskt, så det er gøy å få sparre med konsulenter som er aktive i rollen … Vi får både bruke teknologier som er veldig relevante i arbeidslivet òg prøvd oss på de i trygge miljøer.”
Som studentene påpeker har vi sørget for å ta i bruk moderne teknologi som gir studentene relevant og etterspurt erfaring. Mobilapplikasjonen, som Team App hadde ansvar for, var en quiz-løsning som lar brukerne spille quiz live. Applikasjonens frontend ble utviklet i React Native, mens det i backend ble brukt Firebase, hvor Firestore ble brukt som database og Firebase Authentication ble brukt til logg-inn. Det ble også laget Firebase functions, blant annet for å håndtere Push-notifikasjoner. For å lage og administrere innholdet i quizen ble en webløsning utviklet som Team Admin hadde ansvar for. Løsningen ble utviklet i React og hostet på Firebase hosting. Som vi gjorde med mobilapplikasjonen, brukte vi også Firebase som backend i webløsningen.
Basert på tilbakemeldinger fra Thea, Jannicke og Ida, og de andre sommerstudentene i Team App og Team Admin, kan vi trygt si at vi har lykkes i Dfind Consulting sitt første internship. Thea påpeker at vi har bidratt til at hun har funnet sin plass i IT-verden, og med den tilbakemeldingen kan vi ikke konkludere med annet enn at vi har skapt verdi og fått til noe mer enn bare å utvikle et produkt. Vi ser frem til samarbeid med flere sommerstudenter i årene som kommer!
“Jeg føler den viktigste erfaringen jeg tar med meg er at jeg har funnet min plass i et team, men også min plass i IT-verden. Jeg har skjønt at det er her jeg ønsker å være, dette jeg vil jobbe med fremover — at jeg har valgt riktig.“
Er du nysgjerrig på hvilke muligheter som finnes som student i Dfind Consulting? Ta en titt på våre studentsider <a href="https://www.dfindconsulting.no/jobb-hos-oss#internshipArticle">her</a> for å lese mer.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9db3fd9222e4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/dfind-consulting-internship-2022-9db3fd9222e4">Dfind Consulting — Internship 2022</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dfind Direction er vår satsning på ledelse, arkitektur og rådgiving, enkelt og greit.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3-u42TfNnSpbbJV5Y8M7zw.jpeg"></figure><h3>Hvorfor?</h3>
Vel, først blir det litt historiefortelling. Det hele startet i 2016. Consulting så dagens lys og i løpet av 2017 hadde de første pionerene blitt med på skuta. Hovedvekten av konsulenter var utviklere selv om man også hadde prosjektledere og arkitekter i tillegg til UX og andre roller. Det har vært en god vekst i selskapet og når vi etter hvert nærmet oss og passerte 150 ansatte ble utfordringene tydeligere. Flesteparten av konsulenter og kunder kjente oss som et konsulentselskap med utviklere og det ble vanskelig å vise mot både kunder og potensielle nye kolleger at vi hadde mange andre bein å stå på. I tillegg så vi at det var forskjellige behov både avhengig av hvilken profil man har, men også også mtp. senioritet. Man er på forskjellige steder i livet rett og slett.
Dfind Direction ble etablert som vår satsning på ledelse, arkitektur og rådgiving med de av våre konsulenter som kjente seg igjen i denne beskrivelsen. Flere har blitt med siden den gang.
<h3>Hvorfor prosjektledere og arkitekter i samme gruppe?</h3>
I bunnen er vi IT-konsulenter alle sammen. Det vil si at vi er prosjektledere, produkteiere, scum mastere, team lead, tech leads og arkitekter i IT-prosjekter. Alle er tekniske i bunnen eller direkte i sin rolle.
I et samfunn som stadig blir digitalisert og hvor nye og kommende generasjoner er født digitale, vil flere og flere selskaper, organisasjoner og offentlige aktører ha alle sine prosesser digitalisert. Conways lov og prinsippet om at organisasjoner vil utvikle IT-systemer som gjenspeiler organisasjonen, viser oss at det er en særdeles sterk link mellom arkitektur og ledelse. På mange måter går de hånd i hånd og det er behov for lik kompetanse i begge leire.
Til sist vil jeg også poengtere at arkitekt og prosjektleder bare er paraplybetegnelser i mine øyne. De favner flere og mer definerte roller slik som jeg har forsøkt å illustrere under. Noen konsulenter har flere av disse hattene, mens noen har gjort et dypdykk ned i én. Det de har til felles er at det kreves en del erfaring og senioritet
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ErV5_5dCaAqwZm9glCx10A.png"></figure>Erfaringen vi har gjort oss i vekstperioden er at det er krevende å kombinere mange spesialiseringer i samme gruppe. Det er veldig mye man har til felles, men det er også en del unike og egne behov. Det krever et visst fokus og det krever muligheten til å gjøre ting annerledes. Med vår filosofi om autonomitet, selvstyre og et selskap bygget av og for konsulenter, er den naturlige tilnærmingen å starte opp en egen divisjon, så selvstyrt som mulig, og nesten som et eget selskap i selskapet.
<blockquote>Poenget er at det er må være fleksibelt nok til å forme seg i takt med konsulentene i selskapet.</blockquote>
På bakgrunn av alt dette ble Dfind Direction etablert. Vi jobber fortsatt med “å finne oss sjæl”. Dette er kontinuerlig arbeide og aller viktigst; det er noe vi gjør sammen.
<h3>Første strategisamling</h3>
Pandemien gjorde at vi ikke fikk startet slik vi ønsket så når høsten 2021 kom så vi vårt snitt til å samle alle i direction og gjennomføre den første strategisamlingen vår.
Målet var å finne ut hva Direction er for oss og hva som er de viktigste verdiene for alle som er med i Direction.
Workshoppen gikk som følger:
<h4>Halen på grisen, aka hvor er vi i markedet</h4>
For å skjønne litt mer om oss selv var det interessant og også se på andre. På den måten kan vi se hva som var unikt for oss, men også bekrefte enda litt tydeligere hvem vi er.
Vi startet med å definere to akser hvor den ene går fra teknologi til forretning og den andre fra rådgivende til implementerende. Deretter plassere vi oss selv og andre konsulentselskaper i denne matrisen. Det er ikke så interessant hvor andre er, men det vi oppdaget om oss selv er at vi vil være mer implementerende enn rådgivende når det gjelder forretning og mer rådgivende når det gjelder teknologi.
Det er ikke et veldig overraskende resultat for prosjektledere og arkitekter, men det er en fin måte å visualisere det på. Det er også mulig å snakke om hvor man er og hvor man vil være og utvikle en strategi for å bevege seg i den retningen man vil.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/796/1*Ns4Q_Xyp3Yg4MrQb2SNVTw.png"></figure>Her er noen eksempler på konsulentoppdrag og hvordan det ville plassert seg i matrisen
<ol>
<li>Rådgivende/teknologi: Teknisk revisjon</li>
<li>Teknologi/implementerende: Utvikler i et team</li>
<li>Implementerende/forretning: Forretningsutvikler eller produkteier</li>
<li>Forretning/Rådgiver: Markedsundersøkelse/rapport</li>
</ol>
De aller største selskapene har gjerne en fot i alle kvadranter og det blir sånn sett vanskelig å plassere de. Derfor havnet alle i midten
<blockquote>Et svært viktig prinsipp vi fikk ut av denne øvelsen er at de gangene vi har rådgivende roller eller er i en posisjon hvor vi blir spurt om å gi råd, så skal vi også være i stand til å implementere det vi snakker om.</blockquote>
<h4>Cover story</h4>
For å få brukt kreativiteten litt krydret vi med noen “klippe og lime” aktiviteter. Med “Cover story” skal man ha litt vyer og se for seg en tenkt avis eller magasinforside om 15 år. Det skrives om dere. Hva står det?
Gruppa klippet og limte med både hvitt og farget papir. Det ble mye forskjellig, men felles for de alle var at Dfind Direction skulle være et sted hvor folk ønsket å bli værende.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/526/1*CNH74xBBEI_uo3iqaKunrg.png"><figcaption>Et av bidragene</figcaption></figure><h4>Verdibrainstorming</h4>
Kanskje det viktigste aktiviteten for dagen. Den gjennomføres ganske enkelt som en brainstorming med påfølgende presentasjon og diskusjon før vi grupperer like lapper og til slutt stemmer på hva vi mener er viktigst.
For å fokusere på verdier hadde vi noen “knagger” man kunne bruke for å komme i gang:
<ul>
<li>Kollegaer og sosialt</li>
<li>Faglig innhold og utvikling</li>
<li>Verdier og holdninger</li>
<li>Roller og oppgaver</li>
<li>Bli motivert</li>
<li>Kompensasjon</li>
<li>Familie og venner</li>
</ul>
Vi fylte en vegg med post-it lapper og vell så det. I mylderet viste det seg etter hvert at det var noen områder som var viktige for alle sammen
Work/life: Mange har famile eller andre utenomsportslige aktiviteter. Vi ønsker en arbeidsplass som tilrettelegger for at vi yter og utvikler oss så godt som mulig
Fag: Faglig styrke er ikke bare en enorm styrke for selskap og kunde, det er også hvem vi er. Vår stolthet ligger i å gjøre en god jobb, designe gode systemer eller etablere vellykkede team og produkter. Om vi ikke kontinuelig utvikler oss og selv vil vi hverken trives eller lykkes.
Sosialt: Den store utfordringen for de fleste konsulentselskaper hvor vi er hos kunde store deler av dagen er å holde på et sterkt bånd med sine kollegaer. Dette er viktig for oss og vi må jobbe for å skape arenaer som legger til rette for dette.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/455/1*HEPFM5hPRbvyUCNskcohCQ.png"></figure>Til slutt snakket vi om sammenhengen mellom disse. Fag og sosialt må balanseres med work-life. Finner vi balansen mellom disse tre er vi på riktig vei
<h4>Product box</h4>
Den siste øvelsen vi gjorde på denne samlingen var også av det kreative slaget. Her skulle vi se for oss hvordan det hadde sett ut om en Dfind Direction hadde vært et produkt som ble levert i en boks. Hva trekker vi frem som unike egenskaper på innpakningen?
<figure><img alt="" src="https://cdn-images-1.medium.com/max/781/1*vYTha1EYNXavlzSe2rU2Tg.png"></figure>En fantastisk morsom øvelse hvor vi fikk brukt alle kvaliteter vi lærte oss på kunst og håndverk på ungdomsskolen. Skal vi trekke frem noen av de viktigste egenskapene ved Dfind Direction er det (1) Faglig styrke og kvalitet, (2) Familie og work-life balance, (3) likestilling og (4) levere det vi prater om.
Mange av de samme punktene gikk igjen gjennom alle øvelsene. Dette er mye fordi det etter hvert blir forankret i gruppa og gjentar seg selv av den grunn, men også fordi vi lykkes med å finne noe som er viktig for alle. Det er sånn vi skal utvikle oss i Direction. Det er høy kompetanse og folk med såpass lang erfaring at når vi legger hodene sammen så får vi det til.
<h4>Oppsummert</h4>
Om vi skal prøve å oppsummere det som er starten på en strategi for Direction ser det ca sånn ut.
<ul>
<li>Gir solide råd og veileder, men må kunne “walk the walk” og implementere det vi snakker om, både teknologi og prosess for teknologiutvikling.</li>
<li>Vi er sterke på teknologi, men også forretning, siden teknologi i større og større grad driver og definerer forretning og organisasjon</li>
<li>Dette er summen av Direction, hver enkelt konsulent har forskjellig kompetanse, men vi spiller på hverandre og utnytter hverandres kompetanse inn i prosjekt og problemløsning</li>
<li>Vi må legge til rette for fortsatt sterk faglig utvikling og sosialisering med kollegaer slik at det lar seg kombinere med disse andre viktige delene av livet. Og ikke minst gjør alt det andre lettere.</li>
</ul>
Direction har i dag blitt utvidet til alle Dfind Consulting sine kontorer og vi jobber med å definere oss selv som et nasjonalt nettverk på best mulig måte. Denne høsten ser vi på faglig utvikling så vi kan tilrettelegge for at både arkitekter og prosjektledere fortsetter med å styrke sin kompetanse på sine premisser.
Vi skal fortelle hvordan det har gått ved en senere anledning..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ea82454942b8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hva-er-dfind-direction-ea82454942b8">Hva er Dfind Direction?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

European Women in Tech er Europas største tech-arrangement for kvinner, og tar for seg temaer innen teknologi, ledelse og karriereutvikling. Etter to år med pandemi var en gjeng på femten ansatte fra Dfind Consulting sultne på kompetanseutvikling og networking — og dette fikk vi. Etter to inspirerende konferansedager med flere av techbransjens mest innflytelsesrike kvinner har vi plukket ut tre takeaways vi nå ønsker å dele med fler.
European Women in Tech fant sted på det velkjente konferansesenteret RAI midt i Amsterdam. Konferansen gjestet over 250 speakers, hadde over 250 sesjoner og workshops, og over 4000 deltakere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*x5OL_HU_PGVA2bEyGJV9xg.jpeg"><figcaption>Dfind Consulting på European Women in Tech 2022</figcaption></figure>Den viktigste kompetansen vi tar med oss og ønsker å belyse:
<h4>Rollemodeller</h4>
Et av de mest fremmende tiltakene for å øke kvinneandelen i techbransjen er å eksponere unge jenter for rollemodeller som inspirerer og viser at det er mulig å få en spennende karriere innen teknologi.
Microsoft gjennomførte en studie med flere enn seks tusen kvinnelige deltakere i alderen ti til tretti år. Av studien fremkom det at interessen for STEM (science, technology, engineering, mathematics) nesten dobles når de har en rollemodell som inspirerer dem, hvor foreldre og lærere her ble trukket frem som aktuelle rollemodeller. Studien viste at sannsynligheten for at jenter vil studere datateknologi og informatikk øker med 81 % dersom en forelder oppmuntrer til en STEM-utdannelse, sammenlignet med en som ikke oppmuntres.
I stor grad handler det om å i det hele tatt prate om og kommunisere STEM som et alternativ til valg av studieretning, og samtidig bryte tabuer om at jenter ikke mestrer realfag like godt som gutter. Studien viser at 91 % av unge jenter regner seg selv som kreative, og at hele 72 % ønsker arbeid som hjelper verden. Vi som jobber i bransjen vet jo hvor fantastisk store muligheter det er for kreativ utfoldelse og arbeid med samfunnsnyttige løsninger — dette må prates om! Vi må bidra til økt bevissthet og kunnskap rundt de faktiske mulighetene som finnes ved å jobbe i techbransjen. “If you cannot see it, you cannot be it”. For at foreldre og lærere skal kunne være gode rollemodeller, må også vi som arbeider i bransjen ta ansvar og være rollemodeller gjennom kompetansedeling og bevisstgjøring.
<h4>Bias i kunstig intelligens (AI)</h4>
Bias i AI er et reelt problem med potensielle alvorlige konsekvenser. Algoritmer er ikke objektive, men virker ut fra det som defineres av den som lager algoritmen. Det er sannsynlig at vi mennesker tar med oss våre biaser inn i koden. Samtidig vil også datagrunnlaget som algoritmen lærer av og baserer sine resultater på, kunne ta med seg biaser. Dette er to viktige faktorer til at bias i AI forekommer i utgangspunktet.
“One size doesn’t fit all”. Techbransjen må være en sann representasjon av mangfoldet som finnes i samfunnet, slik at mangfoldet også blir representert når ny teknologi utvikles. Konsekvensene av en teknologisk utvikling som ikke er representativ sees allerede, som ved talegjenkjenning som ikke gjenkjenner pronomenet “hers”, men gjenkjenner “his”. Eller ansiktsgjenkjennings-programvarer som ikke klarer å skille personer med mørk hud.
Vi har fortsatt en vei å gå innenfor teknologi for å unngå bias i AI. Mye av følgene som sees er skapt av manglende mangfold eller allerede samfunnsdefinerte forutantakelser. Ved å tilføre mer mangfold og ikke minst ta høyde for at bias i AI kan og vil oppstå er vi allerede et stykke på vei for å unngå konsekvensene det kan få.
For mer informasjon og flere tips til hvordan vi unngår bias i AI, les innlegget European Women in Tech har postet om tematikken: <a href="https://www.europeanwomenintech.com/blog/bias-in-ai">https://www.europeanwomenintech.com/blog/bias-in-ai</a>
<h4>“Claim your space!”</h4>
En siste og generell oppfordring vi tok med oss og mener er viktig å bringe videre, er å våge å ta plass og ta kontroll over egen karriere. Dette var en fellesnevner ved flere av foredragene, og samtlige av foredragsholderne delte sine historier om hvordan deres karriere skjøt fart eller endret kurs den dagen de tok et valg om å ta plass.
Snakk høyt om egne ambisjoner, fremhev og vis hva du kan. Vit din verdi og be om det du fortjener, med en antagelse om at ingen kommer til å gi deg noe gratis. Det handler om å synliggjøre seg selv og vise hva du er god for. Hvordan skal ellers din leder eller mentor kunne støtte deg og påvirke din faglige og personlige utvikling for å nå dine karrieremål?
Delta i og inkluder alle i diskusjonen. Prat med de med andre synspunkter enn deg selv, også de personene du vet du får en utfordrende samtale med, eller den som vanligvis ikke inkluderes i diskusjonen. Med en oppriktig nysgjerrighet overfor alle perspektiver utvikler du deg. Å skape nettverk som både inkluderer de som kan støtte, rådgi og utfordre deg kan åpne fantastiske utviklings- og karrieremuligheter. Ved å tørre å ta denne plassen, fremme egne meninger og kompetanse samtidig som andre også inkluderes, skapes perspektivbevegelighet og synergier. Det skaper en arena for å selv kunne utvikle seg og motta andres respons.
Med det håper vi å ha inspirert flere kvinner og menn der ute til å være gode rollemodeller og utfordre seg selv til å ta litt større plass. Vi mener at European Women in Tech-konferansen er like relevant for menn som kvinner, og oppfordrer alle menn til å engasjere seg på tilsvarende arrangementer, selv om det inkluderer “women” eller “kvinner” i tittelen. Som vi nå har presisert — hvordan skal kompetansedeling og endring skje om ikke alle inkluderes i diskusjonen og kunnskapsdelingen? Vi i Dfind Consulting fortsetter i hvertfall vårt arbeid med å dele kompetanse, og håper vi har bidratt til å belyse viktigheten av mangfold i techbransjen.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d3cc717610e8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/european-women-in-tech-2022-tre-takeaways-d3cc717610e8">European Women in Tech 2022 - Tre takeaways</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BF2vA6dM2PHRFyaMoWq8kQ.jpeg"></figure>Some years ago, I was working as a facilitator or coach, if you like, for a team of product owner. It was a complex organisation and the product we were working on had many stakeholders from different parts of the organisation. All with different needs and priorities. It is often difficult to do propper, customer centric product development in this situations as it often end up in a discussion about who should get their way and the features they want.
The challenge:
<ul>
<li>
Different needs and priority between stakeholders</li>
<li>Great business understanding, but not much experience with analysing insight and breaking it down into product requirements
</li>
<li>
High expectations from the rest of the organisation towards what the stakeholders will “deliver” for their team or department</li>
<li>
Difficult to move forward as a PO as the same discussions are being repeated</li>
</ul>
All of this resulted in us not being able to move forward and no-one getting what they wanted. We came up with a workshop concept to takle this challenges and be able to continue with everyone more or less on board
Where can this workshop be helpful?
<ul>
<li>A lot of stakeholders with different needs and opinions</li>
<li>Different seniority between stakeholders</li>
<li>Stakeholders not focusing on problems and insight and more on gut feeling</li>
<li>Stakeholders with a strong opinion on solution, but not necessarily the solution to the problem</li>
<li>You find yourself as a proxy PO without mandate</li>
</ul>
<h3>The works</h3>
For a group of about 12 ppl, you probably need two days to allow for discussion. The agenda will look something like this
<ul>
<li>
Homework — Participants need to prepare an “opportunity statement/description” . You will have to send this out a bit in advance.</li>
<li>
Opportunity workshop — Work with the opportunities provided by participants and stakeholders</li>
<li>
Ideation workshop based on opportunities</li>
<li>
Detailing — Work with selected ideas and start to detail in groups</li>
<li>
Afterwork — Still a lot of work to do, but you hopefully have direction and priority</li>
</ul>
To run a smooth workshop, you might also want to add a bit of motivation and warmup before you kick off the opportunity part. Personally I have had good results talking about the overall product development process and product lifecycle and I can also recommend running a short brainstorming about expectations from all participants.
<h4>Homework</h4>
I find it very helpful to give the participants some homework. It helps to get the right focus going into the workshop and also to control the scope a bit. The workshop itself can also be done in shorter time.
We ask all participants to fill in as many “Opportunity statements” as possible. You will probably get one or two from each. The name “opportunity” is chosen because it’s not related to the solution at all. We don’t commit to anything, but it’s rather a positive upside we can address. The solution will come later to address the opportunity.
<a href="https://docs.google.com/document/d/1N0ZMTle1tBLGzdnsslAJTIbnR8PtRdf_TwwnmtNvZa8/edit?usp=sharing">Download the template</a>
The template also encourage the writer to think about insight and reasons for why this opportunity is valid. E.g “X% of our user base spend on average 30 minutes for each task. By making this easier, we can save them 8 hours of work each day”. “This and that competitor have this feature and X% of the market. We also got this feature, but our customers doesn’t use it”
<h4>Opportunity statement template</h4>
Title and description — Describe the opportunity. Be as detailed as possible. Remember that the one reading this don’t know what you know.
<ul>
<li>What is occurring? What is the observations made and what is the insight from this?</li>
<li>The objective. What are we going to accomplish?</li>
<li>Who does it affect and where are they affected?</li>
</ul>
Background - Use this section to document your findings and insight
Who is involved - We need to involve them in the verification stage later.
<ul>
<li>Who is involved at your company?</li>
<li>What customer/customer segments are affected?</li>
</ul>
Impact - How big is this opportunity or the problem behind the opportunity?
<ul>
<li>How big market size will it affect?</li>
<li>How many customers are affected?</li>
</ul>
Risk — Challenge your own observations and the opportunity you see
<ul>
<li>Have you made any assumptions?</li>
<li>Why could you might be wrong about the opportunity?</li>
</ul>
<h4>Opportunity workshop</h4>
The day is finally here. It’s workshop time.
Our main purpose for this section is for everyone to get an understanding of the different opportunities from all stakeholders and a priority for what to cover in the next sections
Agenda
<ol>
<li>Make sure you have printed out the opportunities before start</li>
<li>The opportunity owner presents the opportunity in front of everyone</li>
<li>Feedback, questions and discussion</li>
<li>Repeat 2–3 until your are done or spent the time you have timeboxed</li>
<li>Grouping of similar opportunities. This step is important as you hopefully start seeing synergy across the organisation. Things that might have been lost because everyone have been so busy focusing on their own problems.</li>
<li>Prioritization vote — Use red dots. Give each participant 3 dots each, they can place all on one opportunity (group) or spread the votes between different ones.</li>
<li>You now have a prioritised list of the biggest opportunities for your company</li>
</ol>
<h4>Rephrase</h4>
I didn’t mention this earlier, but you actually have some more work to do. Before starting the ideation part of the workshop, you need to rephrase the opportunity as a challenge. By doing this you frame it as a question it is easier to answer and and you will get more precise suggestions.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*liMtxIzzGp0UtP3pD696Mw.png"><figcaption>Rephrase the opportunity into a challenge before going into ideation</figcaption></figure>Example
Say that you have a Saas solution. Your opportunity could be something like: “70% of revenue comes from customers upgrading their licenses. By improving the software license upgrading process, we should be able to see 15% increase and reduce churn by X%. Customer feedback indicate that they don’t know what licence model they should use and they find it hard to find the upgrade section in the Saas dashboard”
Rephrasing: “How might we improve the licence upgrade process by making it more understandable and easier to find”
Do this with every opportunity or grouped opportunity. Write it out on a piece of paper and mention what opportunity it addresses as bullet points on the same paper.
<h4>Ideation workshop part 1 — Brainstorming</h4>
Back to workshopping!
Ideation come in many forms. Some will probably think that this approach is too rigid and doesn’t foster creativity. You are probably right as the purpose of the following activities is to gather as much input as possible from stakeholders. PO and product designers still need to spend time iterating to further improve the suggested solutions.
First we want to do an activity with all participants. We do this because we need buy-in and consensus about the priority going into detailing. We also get to hear everyones voice about all issues before continuing in groups.
Agenda
<ol>
<li>Kick everything off with a walkthrough of the opportunities and the rephrased version. Place them on the wall in prioritised order.</li>
<li>Start with the first on. Brainstorm individually for 5 minutes. “What ca we do to address this opportunity”. It should be very high level as we will go into details later. If we go back to the SaaS licensing case it could be “Create a tutorial video explaining the licensing modell” or “Redesign the licensing tier packages”</li>
<li>Everyone presents their suggestion one by one</li>
<li>Group similar suggestions together.</li>
<li>Prioritization vote — Use red dots. Give each participant 2 dots each. They can place all on one suggestion or spread the votes between different ones.</li>
<li>Repeat step 2–5 until you have 1–3 top ideas for each opportunity. Don’t do too many opportunities as you will get too much ideas to detail. Its better to run the workshop more often than to cover too much during each workshop</li>
</ol>
<h4>Ideation workshop part 2— Detailing</h4>
This next and last part of the workshop is detailing, and it is done in groups. I suggest to split into groups of three. PO or product designer and maybe a tech-lead or architect can move between groups and help out if needed
The output of this section should be different concept drafts we can further develop and verify.
A concept draft in this case is a piece of A3 paper split into 4 sections
Description: Describe the concept/solution. For our SaaS example it could be: “Redesign the license upgrade page so the user sees what licence they are currently on and how many free seats they have. All levels should be shown and the diff in cost and functionality should be clearly stated. We should also give a small discount if the user pay annually and not monthly to nudge them into making a bigger commitment”
Drawings and wireframes: A picture say more than a thousand words. It’s always easier to communicate your thinking with some visuals. It also help you better understand your own suggestion and identify any pitfalls or issues. This section can also be used to sketch out a simple data model, or flow diagram for the more tech savvy participants
Technical aspects: This sections is for writing down all technical aspect that you need to consider or verify as part of the concept. If our concept is a brand new licensing model where users pay for each feature, we might need to consider a complete redesign of our software architecture to encapsulate features and toggle on or off on a user level. Capabilities the system might not have today.
Verification and validation: What to we do to verify the concept, what is the criteria, market, segment etc. This should go all the way back to the opportunity and it is key for the success of this workshop. If we don’t do propper verification and agree on the criteria we might as well just follow the anti-pattern of key stakeholders having their ideas implemented, not focusing on customer value
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NskqZCQGIdzvrGJ2hmkztg.png"></figure><h4>Afterwork</h4>
This is your time to shine PO or product designer. You hopefully have the mandate, anchored in some insight and data, to further develop the concept drafts into propper concepts, verify them, build the MVP and iterate with many version after that. Good luck..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ad1d04982a60" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/help-im-a-proxy-product-owner-ad1d04982a60">Help, I’m a proxy product owner!</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ml53jqb5uYA704hbuPiK5A.jpeg"><figcaption>Photo by: <a href="https://unsplash.com/@asci_en">https://unsplash.com/@asci_en</a></figcaption></figure>Have you ever thought of spicing up your scrollable content with nice-looking shadows? Yes, all browsers have the scroll bar, but we can make our content shine even better and, at the same time, improve usability. I think shadows add a smooth and excellent feel to our content and help by showing the users that “there is more content down here” or “there is more content up here”.
<blockquote>TLDR: You will find the final source code at the bottom of the article</blockquote>
<h3>The Scroll Hook</h3>
Recently, I’ve been working on a hook that adds inner shadows when scrolling an element with overflowing content. It is not very complicated, and it’s fun to make. We’ll break down the code throughout the post, look into how it works, and finally use it in our code.
<a href="https://medium.com/media/154ecf87431923f99747b31da71175d4/href">https://medium.com/media/154ecf87431923f99747b31da71175d4/href</a><h4>Handling scroll events</h4>
First, let’s go through the roll logic part of the hook. It’s not complicated, and I did not have to create three separate states for each event. But it is done for simplicity instead of holding an object with all the values.
<a href="https://medium.com/media/360751a2658643353a36a8f419148277/href">https://medium.com/media/360751a2658643353a36a8f419148277/href</a>onScroll is a React property that we can get on any scrollable HTML element for listening on scroll events, such as a div. It takes a function and returns an event of the target element. In native JavaScript, this would be somewhat equivalent to:
<pre>element.addEventListener(‘scroll’, (event) =&gt; /* do something*/)</pre>
The onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires and the onScrollHandler-method triggers. Then we can pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.
The onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires scroll events, and the onScrollHandler-method receives these events. We can then pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/570/1*cB16NN2s7k_3f-nW8smY_g.png"><figcaption>Illustration of scrollHeight and clientHeight on an element with overflowing children elements</figcaption></figure><ul>
<li>
clientHeight (visible content) is the inner height of an element, including padding. We can calculate it by CSS height + CSS padding. If a horizontal scrollbar is present, the inner height includes the height of the scrollbar.</li>
<li>
scrollHeight (visible + hidden content) is the height of an element’s visible content, including hidden content not visible on the screen for an overflowing element.</li>
<li>
scrollTop is the number of pixels scrolled vertically on the content of an element. Measuring the value takes the distance from the top of an element to the topmost of visible content.</li>
</ul>
(Read more about <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop">scrollTop</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight">scrollHeight</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/clientHeight">clientHeight</a> on MDN)
<h4>Calculate shadow position</h4>
We have to do some calculations to determine if and when we should show shadows on the top, bottom, or both. We want to show shadows concurrently when we’re neither at the top of the scroll nor the bottom.
<a href="https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href">https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href</a><ul>
<li>
isBottom is true when the inner height of the visible element equals the total height of the visible and hidden content minus (-) pixels scrolled from the top of the element.</li>
<li>
isTop is true when we’ve not scrolled yet, or scrollTop equals 0 pixels.</li>
<li>
isBetween is true when we’ve scrolled more than 0 pixels from the top, and the inner height of the visible element is less (&lt;) than the visible plus (+) hidden content height minus pixels scrolled from the top.</li>
</ul>
We can show this by example: we could have an element that has 400 pixels inner height [clientHeight], that is scrolled 150 pixels from the top [scrollTop]; we should then get that isBetween is true:
<a href="https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href">https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href</a><h4>Determine shadow type based on the calculated position</h4>
Our getBoxShadow()-function handles the logic for determining and returning the correct CSS box-shadow value as a string. This value we want to set to the target element reactive as we scroll. We’re here using the variables — isBottom, isTop and isBetween —from earlier to determine which shadow to use:
<a href="https://medium.com/media/dd244c457001664fff144489f9a1b027/href">https://medium.com/media/dd244c457001664fff144489f9a1b027/href</a>We want to add shadow to the edge with overflowing content because it makes sense to the eye watching it. So, if we are at the top of the element, we show shadow at the bottom. If we are between (as we calculated in the previous code example), we want to show both top and bottom shadows, or else if we are at the bottom of the element, we want to show the top shadow.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/894/1*1vDIJ5_pf17kz1tifdaBCw.png"><figcaption>Illustration of inner box shadow top and bottom on an element with overflowing children elements</figcaption></figure><h3>Using the Scroll Hook</h3>
Since this is a React hook, we need to create a component that can use it, and it should be straightforward since as there is to do is connect the props to the target element.
In the code block below, we have a component called App. We import the useScrollWithShadow-hook, destruct the onScrollHandler()-method and the boxShadow variable. We pass onScrollHandler() as the value of the div’ onScroll property and set boxShadow as an inline style.
<a href="https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href">https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href</a>Without some content that overflows the element, this would not look or work very well. All it is left is to add some content to the div and maybe some static height so we can get an overflow. We could also add CSS transitions for even more smoothening. But from here on, I will leave the rest to your imagination.
Look at the final result for the styled solution with content and source code on Codesandbox.
<h3>Final result</h3>
Here is the final result. Click “toggle shadows” to switch between with and without shadows (<a href="https://codesandbox.io/s/upbeat-sun-zgyyo5">source code on Codesandbox</a>):
<a href="https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href">https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href</a>Thanks for reading! (feel free to clap and share if you liked this article)
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9ba2d47ae32" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/react-scroll-hook-with-shadows-9ba2d47ae32">React Scroll Hook with Shadows</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The web browser console gives us more options than just the console.log()
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qbSBSYYEKTSCfXF5gKz6qQ.png"><figcaption>Image of a road sign containing the text: Watch out! overuse detected</figcaption></figure>OK, I admit it, and I’m not very a fan of it. Mostly I use console.log() for troubleshooting, checking that the arguments of a function get the correct values or that a function returns what I expect it to do. Sometimes I take shortcuts using the built-in browser method console.log() to clarify the result of some piece of code. On infrequent occasions, instead of rendering a ReactJS-component to the Graphical User Interface (GUI), I may print the component to the console to examine its properties.
I’ve seen many developers are using the web console in similar ways as I do. We developers should stop overusing the console.log() and instead draw advantages from what we can do with the web console than just reading simple logs.
I want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.
<h3>Issues and bad habits</h3>
How often do we think about why we use the console.log() method, and in what contexts? Is it just purely automatic that we use it? Why do we always have to do all this logging, especially with console.log()?
In many of these situations, instead of reading and understanding the code, we make guesses and try to help ourselves by logging stuff to the console. All this time we spend on logging can be very time-consuming (sometimes it can even make us even more confused), and we probably “learn” slower.
<h4>Unnecessary logging = less confidence</h4>
An unnecessary amount of logging to the console makes us less confident. Developers often log to the console in many parts of the code — especially if functions are deeply chained — to “test” our code is reliable.
<h4>Using the console for “confirmation”</h4>
In far too many cases, we also accept that when logging something to the console, we get an indication that “everything works fine.” We can prevent building agents or scripts from breaking if we read and understand the code thoroughly instead of relying on the “confirmation” that the console may give us.
We often use this “confirmation” to check whether something is wrong or not, whether an object is undefined or an array has a length. I would say that “confirmation” is OK when our code breaks, and there are no other options.
<h4>Debugging is time-consuming</h4>
Debugging in the console may be time-consuming. Sometimes we can sit for days logging things to the console, taking away the focus on understanding how the code “actually” works and other options that we could have tried instead of just logging stuff.
<h4>Logs may end up in production</h4>
Logging to the console can be deployed in production, which is not always that great — especially if we log critical information that should not be available to “everyone” on the web.
<h3>How we should use the web console</h3>
What is essential to know is that the console also is a <a href="https://en.wikipedia.org/wiki/REPL">REPL</a>. That means we can interact with JavaScript on the page we’re inspecting. Using the REPL is a great way to play with and learn JavaScript.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IJD_qI9I0EBnjxkcxUvlAw.png"><figcaption>Using the console REPL to add textContent to an HTML element with a wordmark CSS-selector. Here we add a string “Hello” above the Firefox logo.</figcaption></figure><h4>Useful console methods</h4>
The overusedconsole.log() is just one of many methods we may call on the console object. console.error(), console.info(), and console.warn() may be better in cases where we will separate different states of messages. And, to get a better representation of our data in the console we can use methods like console.group() and console.table().
console.error(): Prints an error message to the console, where the printed content will have a red colour. Most browsers also displays an error icon beside the console message.
console.error(‘Something is wrong’)
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tYcFUWNQmHoWvGFQL6geeA.png"></figure>console.warn(): Prints a warning message to the console, where the printed content will have a yellow color. Most browser also displays an warning icon beside the console message.
console.warn(‘Heads up! This is a warning’)
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*urjiiFrNXm3I2S_pYvVhBw.png"><figcaption>Illustration: console.warn example in Firefox. console message with a yellow triangle containing an exclamation mark</figcaption></figure>console.group(): Prints a group of console methods executed within the group. Such logging is usable when we need to do more than a single log in different files which is not related. We can also open and close groups in the console.
<pre>console.group(‘feature’) console.warn(‘Heads up! This is a warning’) console.error(‘Something is wrong’) console.groupEnd(‘feature’)</pre>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*rMwm77JyiXtzVsSljonvtQ.png"><figcaption>Illustration: console.group example in Firefox. console messages grouped within a console group called “feature.”</figcaption></figure>console.table(): Prints a table representation of the data provided. The method accepts objects and arrays.
console.table([{ a: 1, b: 2 }])
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*DB4_roBRCsKjULq_zPce-A.png"><figcaption>Illustration: console.table example in Firefox. console messages are displayed in a table representation</figcaption></figure><h4>Some final words</h4>
It’s not uncommon [for JavaScript beginners and professionals] to just print strings that say “works” or “done” or something similar and then use them to “confirm” that our code works as expected. I’ve seen far too many uses of console.log() in different places in a codebase simultaneously during a pair programming session.
Browser consoles are great tools, and we should use the great utils they provide to our benefit; testing JavaScript methods or extracts, playing with Document Object Model (DOM) or objects in our code. We can do much more with the console than log simple strings, numbers, or lengths on a list.
We should focus on understanding the underlying code and using the console for its benefits and not as a tool for confirmation; then, we will learn faster, become more confident and write better code in the future.
Thanks for reading
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ff4b85df5268" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/stop-overusing-console-log-in-javascript-ff4b85df5268">Stop Overusing Console.log in JavaScript</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*nbN27RdqN2KqpTZGCjWUAA.jpeg"><figcaption>Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served. Photo by: <a href="https://unsplash.com/@kyleunderscorehead">https://unsplash.com/@kyleunderscorehead</a></figcaption></figure>Single-Page Applications (SPA’s, or dynamic) and server-based, also called Server Side Rendered (SSR) applications, are probably the most popular ways to create websites these days. But also Static Site Generation (SSG) has become very popular in the past years.
When we need a fast, simple, secure, and cheap website, our next project should be using Static Site Generation.
<h3>Static vs. dynamic websites</h3>
To begin with, we should clear up what the main differences between a static generated website and dynamic websites are:
A static website is pre-built (on the server) and fetched once on the client without a server.
<ul><li>Static-generated sites are just a bunch of HTML files. The site may be updated and re-build when publishing new content through a Content Delivery Network (CDN) or when pushing new features. With static site generation, websites become fast; they are easy to publish and secure! We will drill deeper into these benefits later on.</li></ul>
A dynamic website is when files are changed on the server and fetched on the client on each change.
<ul><li>Dynamic sites consist of a backend with servers and databases. The site’s content changes dynamically and needs to interact with a database to generate the files “on the fly.” Also, the site needs to fetch the content every time someone revisits the site. Dynamic sites are harder to maintain and less reliable.</li></ul>
<h3>Benefits of Static Site Generation</h3>
Dynamic and statically generated websites are suitable for different types of applications. Static Generation has unique features for creating a website with few dependencies, and suites better when meeting business goals is crucial.
We will look at eight benefits that SSG provide, whereas dynamic websites are not quite as good:
<h4>No need for a backend developer</h4>
We won’t need a backend developer to make an SSG website. Content Administrators and Writers can maintain a Content Management System that stores and have manageable content. Also, a Content Delivery Network (CDN) is a great place to upload our static files.
<h4>Better reliability</h4>
We won’t receive irritating error messages like “500 Internal Server Error.” on an SSG website. The only possible time we will get errors is when the hosting provider gets issues, which rarely happens. Besides that, our website will not have downtime or be unavailable. We will also not need to worry about dynamically scaling our servers or databases.
<h4>Simplicity</h4>
With Static Site Generation comes simplicity. They require no servers or databases. Some JavaScript frameworks, like React-based ones NextJS or GatsbyJS and SvelteJS, provide build-in support and help us generate, minify, and bundle static HTML files at build time. The static files can easily change or move from one hosting service to another.
<h4>Performance</h4>
Static Site Generation gives excellent performance and is fast. We won’t need to wait for many spinners [or skeletons] to tell the user that something is on the way and will replace it at some point.
Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served.
<h4>Security</h4>
We will have excellent security since we don’t need a database or servers running, and they are vulnerable to security breaches. Compilation of source code and content ahead of time (AoT) makes it impossible for hackers to access our databases, CMS, or servers. Since there are no servers involved, the site is also more resilient to DDoS attacks.
<h4>Lower costs</h4>
We may choose to upload our static content to services like Netlify, Vercel, Amazon S3, Google Cloud Platform, and Microsoft Azure; these services are also entirely free. Hosting static content is cheap and requires less bandwidth. And since our site will be less vulnerable to security breaches, we may use that left-over-money for other essential business goals instead of thinking of security monitoring.
<h4>Improved SEO</h4>
Dynamic sites can be complex when we want to optimize our website for search engines. And if it’s crucial for our site and content. The most common problems with dynamic sites are that these are fast at first page-load, but most critical content is fetched and displayed asynchronously.
We get well-optimized content for SEO with pre-rendered content and fast page load. Good SEO optimization will give a low or decreased “bounce rate,” which is the proportion of visitors leaving the website. It also improves search traffic, better lead generation, and customer engagement.
<h4>Scalability</h4>
Static Site Generation provides excellent scalability; we cannot always say the same with dynamic sites. So let’s take a scenario where we may have scalability issues with a dynamic site:
<ul><li>We have a website that a few visitors typically use. At one point (maybe just a few minutes), the site can be used by thousands of users simultaneously. Maybe we’ve published something that has gone viral — such as news — or a DDoS attack. Such an event can be costly, grow rapidly in volume and take down our servers in the worst case. Such events can cause an unexpectedly large number of server requests and will potentially generate dynamic content for each of the thousands of unexpected users.</li></ul>
Static content and SSG are different: The website is pre-generated, with styles and content. Users only need to download the page’s content that they are visiting.
<h3>Conclusion</h3>
We should use Static Site Generation when making a blog, landing page, newspaper, hotel booking service, or e-commerce store. On some occasions, we may even combine dynamic and static content, where our public pages as static pre-rendered content and internal or user-oriented pages are dynamic.
When running an online newspaper, combing dynamic and static content might be a good choice. The front pages can be of static content presented on the page to the users as soon as they enter, with main headlines and images, and videos can have a generated GIF instead of loading in a preview. Articles can then be fetched by an identifier (id) in the URL and rendered in a separate application or on a different route on the website that dynamically retrieves the content.
Static Site Generation should be considered over dynamic SPA’s if any of the abovementioned points are crucial for our organization, whether costs, user experience, or performance.
Thanks for reading!
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fb187d1ffe6" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/benefits-of-static-websites-5fb187d1ffe6">Benefits of Static Site Generation</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*UXGeBLBT2vMnr4mmF_cWwQ.jpeg"><figcaption>Photo by National Cancer Institute on Unsplash</figcaption></figure>Vi hadde brukt 10 måneder på å lage et nytt design for vår digitale tjeneste. Endelig kunne vi gjennomføre brukertestene, <a href="https://medium.com/dfind-consulting/hvordan-bruke-data-for-%C3%A5-forbedre-designl%C3%B8sningene-dine-ae458fc2d1f4">følge med på dataen</a>, og få svar på hvordan tjenesten faktisk fungerte.
– Men, 10 måneder? Hvorfor i alle dager hadde det tatt så lang tid?
Av <a href="https://medium.com/u/71882bf4de0a">Ida Kalfoss</a>
Vi jobber i en stor organisasjon med en løsning som retter seg mot (travle!) bedriftskunder. Man skulle jo tro at det var oppskriften for langsom utvikling, men det kunne vi ikke skylde på. For sannheten var at teamet faktisk hadde stor frihet til å styre prosessen, og lett tilgang til brukere når vi trengte tilbakemeldinger. Allikevel hadde det altså tatt 10 hele måneder.
Det var ikke ledelsen som stilte krav til raskere utvikling, eller mer effektivitet i arbeidet. De var godt fornøyde med lanseringen. Men internt i teamet opplevde vi at fallhøyden ble veldig stor pga. tidsbruken, og ikke minst kjente vi på at den langtekkelige prosessen ble demotiverende for oss. Veldig demotiverende!
Finne balansen i et tverrfaglig team På teamet var vi en utvikler, en UX-designer, en innholdsdesigner, en produkteier og en teamleder. Vi jobbet godt sammen, men likevel var det noe som skurret. Det første vi så var at balansen/arbeidsfordelingen mellom rollene var skjevfordelt. Vi var to på design/UX, to administrative roller, men kun en utvikler. Med måten vi jobbet på så ble det i perioder mye alene-koding for utvikleren, uten noen å sparre med, og det var verken effektivt eller inspirerende. Så den første endringen vi gjorde var å utvide teamet med enda en utvikler.
Da hadde vi skaffet oss et velbalansert tverrfaglig team, som kjente hverandre, og som var få nok til å raskt kunne gjøre avklaringer og fordele oppgaver, men mange nok til å alltid ha én innenfor sitt fagfelt å sparre med. Men det løste ikke automatisk utfordringen med den langsomme utviklingen.
Vi ble Inspired På dette tidspunktet så hadde vi en boksirkel der vi alle leste Inspired av Marty Cagan. Han skriver om hvordan noen av de store produktorganisasjonene brukte referance customers, i et customer discovery program. Dette var noen få reelle brukere som ble brukt som referansegruppe gjennom en utviklingsprosess. Gruppen bistod som sparringspartnere, testere og gav kontinuerlige tilbakemeldinger på løsningene. I tillegg var referansegruppen en viktig del av organisasjonenes markedsføring, ved at de hadde et sterkt eierskap til produktene, og på den måten ville spre det gode ord etter lansering. Formålet med en slik gruppen er å ha enkel tilgang til relevante brukere, slik at de kan gi raske tilbakemeldinger på nye ideer på noe de selv hadde lyst (eller trenger) å bruke. Dette var jo akkurat det vi hadde behov for!
Finne de rette folka til testpanelet Siden vi var et lite team bestående av seks personer, var det ikke langt fra ønske til handling, og i løpet av en uke hadde vi vi satt i gang rekruttering av brukere til vår egen referansegruppe, eller testpanel, som kanskje er mer beskrivende for vårt bruk.
Vi gjorde dette ved å legge inn et spørsmål i slutten av vår digitale tjeneste, der vi spurte om de hadde lyst til å være med på å forbedre løsningen vår. Ved at spørsmålet lå på siste steg i løsningen, sikret vi at brukerne vi rekrutterte hadde et reelt behov. I tillegg sikret vi at de var motiverte, da de aktivt måtte sjekke av for å vise interesse. Etter kort tid hadde vi seks brukere i vår testpanel!
Testpanel for å få opp farta Endelig kunne vi kjapt teste ut nye ideer og konsepter. Teste og feile kjapt. Så fort vi hadde en ny idé eller konsept så kalte vi inn brukerne fra testpanelet. Vanligvis rekrutterte vi brukere gjennom et eksternt byrå, og det fungerte fint når vi skulle ha brukertester, men det tok ofte lang tid når vi bare ønsket en rask avklaring. I tillegg er det ikke bærekraftig å gå gjennom en lang og dyr rekrutteringsprosess, for så å teste en bitteliten detalj (mock-up). Men med testpanelet så kunne vi teste allerede samme uke!
Nå kunne vi raskt teste enkle prototyper og små mock-ups. Hensikten var å få tilbakemeldinger på om noen av våre hypoteser stemte og prioritere hvilke ideér vi skulle bearbeide i neste iterasjon..
Hver test tok ca 20 til 30 minutter, og vi samlet testene til en dag. Vi var to personer fra teamet og en testperson, som sammen så på skissene. Deltagerne i testpanelet er travle bedriftskunder, derfor ble testene gjennomført digitalt. Dette senket også terskelen for å bli med. Dermed ble det enkelt for resten av teamet å være med som observatører med kamera og mikrofon av.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/531/0*rZv6W5TJoFt7KMiv"><figcaption>Testingen med testpanelet, eller mock-up testing, er en god måte å komplettere andre metoder (triangulering) for å skaffe seg innsikt om et produkt/løsning.</figcaption></figure>– Men hjalp det da? Ja. Og ja! Nå kunne vi teste ut de rareste ideene nesten samtidig som de oppstod. Og fremfor alt kunne vi forkaste dem like kjapt! Vi brukte eksempelvis 15 min på å skisse opp ulike måter å vise en prisindikasjon på. Særlig den ene ideen, et slags kakediagram, syntes vi alle var helt genialt og utrolig intuitivt (nå hadde vi nailet det!). Brukerne i testpanelet var dog ikke like begeistrede (– heh? Tre kvarts full? Sammenliknet med hva?). Javel, nailet ikke den. Men brukte heller ikke mange minutter på å finne ut av det.
Det å involvere brukerne tidlig i designprosessen gav oss mulighet til å få kvalifiserte tilbakemeldinger på små deler av løsningen. Dette gjorde at vi fikk litt mer tro på det vi lagde, og lanserte mindre deler av løsningen iterativt, istedenfor å samle opp til en stor lansering til slutt. Da var alle roller aktive til hver tid, istedenfor å gå fra først en langvarig designperiode til en lang utviklingsperiode. Noe som føltes mer givende og motiverende for alle på teamet!
Hvorfor vi digget testpanelet · Det ga oss enkel tilgang til brukere · Vi hadde brukere som hadde brukt vår løsning — gir oss relevante tilbakemeldinger · Brukeren føler seg komfortabel i å si hva de tenker, ettersom de lærer kjenne oss over tid (og bonus: det er sykt hyggelige samtaler!) · Vi kunne holde møtene korte — trengte ikke bruke tid på introduksjon · Teste en idé/konsept kjapt — feile kjapt. Blir ikke like hardt å «kill your babies».. · Tidseffektivt · Fremdrift — fikk oss å til å bevege oss raskere
Hva vi har lært av hva som fungerte — og ikke fungerte — for oss · Tre personer i samtale under testene gir god dynamikk (vi pleier ellers å kun være en fra oss sammen med brukeren, når vi gjennomfører brukertester) · Det å rekruttere personer som har vært igjennom løsningen vår, gir oss brukere med et reelt behov å løse · Vi fikk brukere som var motivert av problemløsning, ikke penger (de fikk «kun» 500kr etter fire tilfeller) · Hold møtene korte — test heller færre ting ettersom man ikke rekker å gå i dybden på kort tid, men vi ville heller ikke skremme vekk brukeren med lange møter som spiser av arbeidsdagen deres · Brukes ikke for å validere en idé, men for å få kvalifiserte tilbakemeldinger · Brukeren er mer som en sparringspartner — blir mer ledende spørsmål enn i for eksempel en brukbarhetstest (usability test). Dette var noe vi måtte ha i bakhodet når vi gikk i gjennom innspillene etterpå. · Skal ikke brukes istedenfor andre metoder, men som en komplementerende metode · Dediker en person til oppfølging av testpersonene. Vi trengte å bruke mer tid på å følge opp testpanelet, enn når vi rekrutterte gjennom eksterne rekrutteringsbyråer. I tillegg var det viktig å holde testpersonene «varme» over tid · Det er en team aktivitet, og fungerte best når hele teamet var involvert i hva vi skulle teste, gjennom testene, og i oppfølgingen etter testene. Ikke for å forankre eller inkludere interessenter.
Så hvis du eller ditt team også er en av dem som sliter med å holde motivasjonen oppe gjennom litt vel langtekkelige utviklingsprosesser — finn dere en relevant og motivert gjeng som har bruk for løsningen deres, og sett i gang med litt mock-up testing! Ikke bare er det effektivt og motiverende, det er faktisk utrolig hyggelig i tillegg.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9369fa2af030" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hvordan-f%C3%A5-opp-farta-p%C3%A5-utviklingen-med-et-testpanel-9369fa2af030">Hvordan få opp farta på utviklingen med et testpanel</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

av <a href="https://medium.com/u/e30b5da9a1ad">Kristine Helle-Andresen</a> og <a href="https://medium.com/u/33d36f229662">Emilie Haugen</a>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/700/0*Mo-0gqIfXXaoakcs.jpeg"><figcaption>Foto av <a href="https://unsplash.com/@giuvicente">Giu Vicente</a> fra <a href="https://unsplash.com/s/photos/motivated?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Gratulerer med kvinnedagen, alle sammen!
I dag ønsker vi å sette fokus på alt det gode arbeidet som gjøres for å øke kvinneandelen i techbransjen, av aktører på alle nivåer. De siste årene sees det en positiv endring med økt fokus på å få flere kvinner til å studere og jobbe i techbransjen. Det starter med 5.klassinger som utfolder seg på Girl Tech Fest-arrangementer over hele landet. Ungdomsskole-elever som besøker techselskaper på inspirasjonsdagen «Girls Day in Tech». Andelen jenter som velger teknologi-relaterte studieprogram øker. De positive trendene er mange, og på en dag som denne er det på sin plass å framsnakke alle som jobber målrettet med å øke kvinneandelen i techbransjen.
<h3>En trygg og bærekraftig fremtid for alle</h3>
Dfind Consulting har latt seg inspirere av selskaper som deler åpent om positive erfaringer med bevisst arbeid rundt mangfold, og har bestemt oss for å målrettet arbeide med å øke kvinneandelen i selskapet og i techbransjen forøvrig. Hvorfor er dette arbeidet så viktig? En kan umiddelbart tenke seg åpenbare etiske årsaker til hvorfor det bør rettes fokus mot dette, med verdier som likestilling i arbeidsmarkedet, like muligheter uavhengig av kjønn og så videre.
Men hva er egentlig konsekvensene av et arbeidsmarked uten likestilling mellom kjønn? Om ikke kvinners perspektiver inkluderes i kartlegging, planlegging, gjennomføring og implementering av fremtidens løsninger tilpasses de ikke deres anatomi og behov. Konsekvensen er at teknologien i større grad tilpasses menn og ikke kvinner. Et eksempel er smarttelefoner — de største og gjerne beste telefonene er ofte alt for store for kvinnelige hender. Mens ved AI-teknologi ser man for eksempel at Siri responderer raskere og mer “to the point” når menn prater enn kvinner. Eksemplene virker uskyldige, men med samme trend i utviklingen risikerer man at teknologi innenfor blant annet medisin og sikkerhet har samme følger. For å skape en trygg og bærekraftig fremtid må alle inkluderes.
For det enkelte selskap finnes det også gode grunner til å øke kvinneandelen. Forskning viser nemlig at mangfold kan generere kreativitet og innovasjon som et resultat av ulike perspektiver og potensialer (Hoffman 1959; Hoffman og Maier 1961; Watson et al. 1993). Med flere kvinner i bransjen øker mangfoldet, og kan dermed berike og gi fordeler basert på elementære ulikheter mellom mann og kvinne. Eksempler er ulik problemløsning, ulik utførelse av oppgaver og andre perspektiver ved diskusjon basert på ulik persepsjon. Når dette fungerer skapes en arena for kreative og innoverende løsninger — og det er jo dette bransjen vår lever av!
<h3>Inkludering og kultur som nøkkelord</h3>
Vi ønsker å bidra til en trygg og bærekraftig fremtid for alle. For å gjøre dette må aller inkluderes. Hos oss sees fokuset på mangfold i alt vi gjør; fra rekrutteringsprosessen, til oppfølging av konsulenter, utviklingsmuligheter, aktivitetstilbud og ansatte i ledelsen.
En sunn og åpen kultur er vårt fundament og gjør oss til et attraktivt selskap, også for kvinner. Med gode og lett tilgjengelige kommunikasjonskanaler skaper og deler vi kunnskap og bevissthet rundt tematikken, samtidig som det sikrer involvering ved å legge til rette for å kunne kommunisere ønsker og behov. Dette har bidratt til engasjement og samhold om å ta vare på kvinnene vi har og øke kvinneandelen hos oss ytterligere. Det åpner også muligheten for å revidere og skape et aktivitetstilbud som appellerer mer til kvinner basert på deres ønsker. For å bidra til rekruttering av fremtidens kvinner til techbransjen er det også viktig å være engasjert på utdanningsnivå. Dfind Consulting er partnere med Ada-nettverket til NTNU, i tillegg til flere andre samarbeid med universiteter og høyskoler. Vi samarbeider også med andre institusjoner og skal i fremtiden være med å arrangere “Girls Day in Tech” og “Girl Tech Fest”. For å sikre engasjement i bransjen generelt legger vi opp til deltagelse på initiativer arrangert av andre institusjoner ved å tilrettelegge for felles aktiviteter før, under og etter arrangementene. I juni drar tolv stykker fra Dfind Consulting, både menn og kvinner, sammen til konferansen European Women In Tech i Amsterdam. Mange av oss er selvsagt også å finne på ODA’s inspirasjonsdag 2022 — vi gleder oss!
Vi er i gang, men reisen har bare såvidt begynt. Alle er tjent med mangfold. I kjønn, i etnisitet, i religion, i livssyn, i alder. Ulike perspektiver skaper løsninger som appellerer og fungerer til ulike mennesker. Og er det noe vi vet, så er det at teknologi er kommet for å bli. Vi håper våre tanker og innspill kan bidra til å belyse en viktig utfordring i en helt sentral bransje for samfunnets utvikling, og være til inspirasjon for flere — både som selskap og enkeltmenneske.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f4d7607f5068" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/la-oss-inspirere-hverandre-og-sammen-%C3%B8ke-kvinneandelen-i-techbransjen-f4d7607f5068">La oss inspirere hverandre og sammen øke kvinneandelen i techbransjen</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.