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

Hvordan bruke data for å forbedre designløsningene dine?

La hodet ligge litt på blokken før du legger det i bløt!

Tre faktorer som genererer indre motivasjon

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”.
If you’ve had the same thought (I’ll guess so since you’re already reading this) but have not figured out a solution yet, you should read on.
<blockquote>TLDR: You will find the final source code at the bottom of the article</blockquote>
<h3>The Scroll Hook</h3>
Recently, I made this 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 finaly 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.

<figure><img alt="Et bilde av en graf i Analytics" src="https://cdn-images-1.medium.com/max/1024/1*LKKO_N-srrgvVB0poFF6bw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@olloweb?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Agence Olloweb</a> on <a href="https://unsplash.com/s/photos/analytics?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det kan være skummelt å dykke ned i dataene for å finne ut av hvordan løsningene dine presterer. Fordi det er jo her man ser resultatet av det harde arbeidet man gjør hver dag. Man stikker liksom fingeren i jorda, og det kan være ubehagelig. Men har man fingeren i jorda er man i alle fall skikkelig jordet, og det er jo smart i tilfelle lynet skulle slå ned!
<h3>Hvor skal man starte?</h3>
Det sies at dersom man skal gjøre de store oppdagelsene må man starte med spørsmål, og ikke med data. Jeg tenker allikevel det er en fordel å ha en idé om hva du kan finne ut med data. Fordi det krever en viss innsikt for å kunne stille de riktige spørsmålene, og å vite hva man kan få svar på.
Det er vanskelig å få konkrete svar på store strategiske spørsmålene gjennom data. Så det gjelder å bryte dem ned. Dersom du lurer på om innholdsstrategien fungerer, vil det være smart å bryte det hele ned til litt enklere spørsmål, for eksempel: «Hvilket innhold gir høyest konvertering?», eller “Gjør kundene det vi ønsker at de skal gjøre?”
<h3>Tenk på hva du prøver å oppnå med løsningen, og om intensjonen samsvarer med kundens forventning og bruk?</h3>
Start med å finne ut hva de mest brukte sidene er. Setter du deg inn i sidevisninger får du et godt bilde av hva som er mest brukt, og da vet du også hvilke sider du vil få mest igjen for å optimalisere.
Finn ut hva kundene gjør når de er på siden. Tracker du brukeradferd/“hendelser” får du et kjapt overblikk over hva kunden er interessert i på siden din. Her kan også heatmaps være nyttige da den visuelle fremstillingen er enkel å forholde seg til. Men man må være litt oppmerksomme når man benytter heatmaps. Et heatmap viser deg et bilde av defaulten av siden, uten pop ups og drop down menyer. Så dersom heatmapen ser litt underlig ut med mange klikk på et sted du ikke har noe innhold, er det sannsynligvis noe som dukker opp, på akkurat det stedet i virkeligheten, som ikke er synlig i heatmapen.
Scrolling heatmaps kan også være et nyttig verktøy dersom du ønsker å se om kundene leser nedover siden. Der man kanskje antok at kunden hadde lest alt, fordi Analytics forteller deg at personen hadde brukt 7 minutter på siden din, kan ikke Analytics vite om kunden var der i 7 minutter fordi de faktisk leste alt, eller ble forstyrret av en kollega, og i realiteten bare leste ingressen.
Finn ut hvordan løsningen din presterer. Hva konverterer og hvor faller kundene av? Frafallstrakter er gull å grave seg ned i dersom løsningen din skal geleide kunden gjennom flere gitte steg for å komme «til et mål».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*VXg_XmHa5bKa6FXX2UMrPQ.png"></figure>Den enkle visualiseringen gir et kjapt bilde på hvor mange kunder som besøker hvert steg i løsningen. Ser du at dere mister en stor andel kunder på et spesifikt sted i flyten, vet du akkurat hvor du trenger å følge ekstra nøye med når du gjennomfører den neste brukertesten.
<h3>Hva betyr tallene, og hvor viktige er de?</h3>
Da jeg var liten, og spurte «Er det lenge til vi er fremme?», svarte min far: «Neida, det er rett rundt svingen her», mens storesøster nesten samtidig svarte: «Kjempelenge!».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*r-m7H_5mEKjWv9KoS4hcsA.png"></figure>Jeg lurte da naturligvis på hvem som løy. Da spurte pappa meg; «Syns du 7 er mye?» Jeg husker jeg funderte på det… Hvis det er kroner vi snakker om kan det være lite. Spesielt dersom det er det du får i lønnsjustering på årsbasis. Men hvis 7 millioner mennesker benytter 7 kroner mer hver gang de handler i løsningen du lager. Da er 7 veldig mye. Da er 7 faktisk 49 millioner! Og hvis du har hatt 7 hundre besøkende på nettsiden din den siste måneden, kan det hende du har god grunn til å juble høyt. Men ikke hvis du er Amazon.
Så det er ikke alltid så lett å forstå tallene og vite hva de betyr. Og man må i tillegg ha litt is i magen. For det tar tid å samle data, og alt henger sammen med alt. For eksempel; dersom konverteringen går ned, er det ikke gitt at at det er løsningen din det er noe i veien med. Det kan like gjerne være at markedskampanjer har truffet feil målgruppe. Altså du har fått veldig mange besøk, men av feil folk. De blir sjelden til middag! Så for å forstå tallene må man bli godt kjent med løsningene og vite hva utgangspunktet er. Fordi tall uten kontekst er bare… — ja, siffer ved siden av hverandre.
Bounce rate er noe man ofte hører om. Som om det er en krise dersom en kunde forlater nettstedet ditt etter bare å ha besøkt én side. Men i enkelte sammenhenger kan en høy Bounce rate være helt ok. For eksempel når en kunde søker på google, går inn på foreslått lenke, får svar på det hun trenger og går ut igjen for å fortsette med livet sitt. Det er jo en god ting! Vi vil jo ikke være så selvopptatte at vi på død og liv ønsker at kundene skal valse rundt på hjemmesidene våre i timesvis uten mål og mening? Fant de svaret på akkurat det de lurte på ved første klikk, bygger vi tillit. Noe som øker sjansen for at de faktisk kommer tilbake igjen ved en senere anledning — når de trenger det.
<h3>Bli kjent med brukergruppene</h3>
Har du fått oppgaven; “Bare tegn ut den typiske brukerferden, den som er mest vanlig, liksom”? Helt sikkert. Vanlige folk gjør vanlige ting, så det bør være enkelt. Men sånn er det jo ikke. Helt vanlige folk gjør ikke helt vanlige ting. De gjør veldig mye rart. Så den «typiske brukerferden» finnes kanskje ikke. Og finner du den mest brukte brukerferden, utgjør den kanskje bare 5% av kundene. Så kan vi egentlig kalle disse fem prosentene «typiske» da?
Det du kan se på, er hvilke kundetyper som gjør hva. Da kan du forsøkeå koble personas på målingene, ved å legge på sannsynlige filtreringer gjennom segmenter. Et segment er et utdrag av alle dataene dine som lar deg isolere og analysere mønstre basert på handlingene de har gjort i og før de benyttet løsningen din.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*hUprpquhZBVm8QO0uaelzw.png"><figcaption>Finn et mønster!</figcaption></figure>For eksempel: Er personasen en forsiktig type som er opptatt av datasikkerhet, og er medlem i en bedrift som gir han fordeler i din løsning? Da kan man kanskje anta at han kommer fra en samarbeidspartners side og logger inn i din løsning med BankID. Og her kan man bygge på med antagelser ut i fra beskrevet persona. Man klarer selvsagt ikke å treffe 100% på beskrevne personas, men man kan kanskje få et overordnet bilde på adferden til de forskjellige kundegruppene, og finne ut hvordan man kan jobbe målrettet mot enkelte segmenter.
<h3>Ingen verktøy gjør jobben alene</h3>
Selv om du har vært flink og benyttet analyse for å finne ut hva som skjer, og for hvor mange det skjer, vet du fremdeles ikke hvorfor det skjer. Det er da brukertester og spørreundersøkelser blir virkelig gøy! Når du har identifisert en ekte utfordring, som du vet påvirker mange mennesker. For ingen verktøy gjør jobben alene. Man må benytte flere kilder for å få én sannhet.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ppJYTUN8dvkQ525H60TZIA.png"><figcaption>Triangulering</figcaption></figure><h3>Videreutvikling og endringer i løsningene</h3>
I brukertester og spørreundersøkelser kan man få mye innsikt i hva som fungerer best for sitt formål, men siden det aldri er to streker under svaret når man brukertester med 10 personer, og fordi vi vet at det kundene sier i spørreundersøkelser ofte ikke samsvarer helt med hva de gjør, er det godt å gå tilbake til dataene igjen. Bestem på forhånd hva du trenger å observere når endringen trer i kraft, og følg nøye med på utviklingen, både på smått og stort. Det er ikke alltid de store strukturelle endringene som gir de største utslagene i konvertering. Den lille hjelpeteksten, eller CTA-teksten kan ofte utgjøre en større forskjell.
Er A/B-testing verdt bryet? I mange tilfeller er A/B testing noe man kan lære mye av. Men ha i bakhodet at dersom du tilbyr én løsning til halvparten av kundemassen din, og halvparten til den andre, betyr det at det tar dobbelt så lang tid å få svaret på om endringer fungerer eller ei enn om du hadde gitt alle samme løsning. Man bør derfor ha et ganske stort volum av besøkende for at A/B-testing skal ha noe for seg, spesielt dersom du trenger svaret fort. En annen faktor er at det er kostbart å utvikle to løsninger av samme sak. Så A/B-testen bør være temmelig spisset, med små konkrete variasjoner mellom løsningene så man sikrer at man måler epler mot epler, ikke epler mot pærer. Dersom designet krever store strukturelle modifikasjoner på informasjonsarkitektur i de forskjellige variantene vil det være umulig å sammenligne, og mest sannsynlig være meget ressurskrevende.
<h3>Skal man alltid stole på alle tallene?</h3>
Tallene lyver sjelden, men hvis du ikke har hentet de riktige tallene kan de gi et feil bilde av virkeligheten. Så om du ser tall som virker for gode eller dårlige til å være sanne, er de ofte ikke det. Tracking settes opp av helt vanlige (stort sett meget kompetente) mennesker. Men de kan også gjøre feil. Og en liten feil i trackingen kan gi ganske store utslag. Har du som UX-designer satt opp målingen selv, kombinert med at trackingen ikke er optimal kan det gi noen rare tall. Så er det noe som virker uriktig, snakk med fagfolk. Forresten; snakk med fagfolk hele veien!
Og til slutt; ikke tenk du at du skal klare å følge med på all data alene.
- For du skal jo tross alt levere et design også.
<blockquote>Lykke til!</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ae458fc2d1f4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hvordan-bruke-data-for-%C3%A5-forbedre-designl%C3%B8sningene-dine-ae458fc2d1f4">Hvordan bruke data for å forbedre designløsningene dine?</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.

I større eller mindre grad er vi alle avhengige av tilbakemeldinger fra de rundt oss. Både for å få en bekreftelse når vi gjør noe riktig, og for å gjøre noe bedre neste gang.
Noen fagfelt er vanskelig for andre å mene noe om. Jeg kan for eksempel ikke si «Kjære pilot, jeg ville ikke dratt i den spaken om jeg var deg». Det ville blitt litt dumt tror jeg. Såpass selvinnsikt har man.
Vi som jobber med design, i alle sine former, er vant til å få tilbakemeldinger på alt vi gjør. Fra alle. Hele tiden.
Alle har sin subjektive mening om budskapet du forsøker å formidle. «Jeg tror ikke noen vil trykke på den knappen», «Jeg syns ikke fargen passer» eller «Jeg føler ikke at det sitter 100% enda».
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*w8RCbCtb-K4uPhEqn_aKXg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@zacharykadolph?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Zachary Kadolph</a> on <a href="https://unsplash.com/s/photos/crying-kid?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Og så innmari kjipt det kan være å få dårlige tilbakemeldinger på noe du har lagt sjela di i…
Spesielt fra mennesker som overhode ikke har din erfaring. Mennesker som jobber med helt andre ting. De kommenterer på ting som tilhører ditt fagfelt, og du river deg i håret over alle disse innspillene som ikke passer i dine egenoppbygde bias.
Det må du slutte med! Fordi de har all rett til å mene noe. De skal mene noe. Og du skal være evig takknemlig for alle tanker, meninger og innspill uansett hvem det kommer fra.
Jeg husker at det å ha “Fingerspitzgefühl”, (teft, finfølelse og intuisjon) var et stort kompliment for 20 år siden. Hadde du fingerspitzgefühl hadde du “alt”. Det er fortsatt ingen tvil om at noen har et ekstra godt blikk for hva som fungerer visuelt, eller hvordan man kan gjøre et budskap interessant… Så jeg vil nødig tråkke noen på tærne her. Men det å bruke fingerspitzen til å bare designe på gefühlen, er langt fra nok. For hvem er det som skal bestemme om teften eller intuisjonen din er riktig?
Som UX-designer er det bare ett riktig svar: «Kunden bestemmer alt!» En annen fin setning er: “All kommunikasjon skjer på mottakers premisser”. Sier man det, har man liksom skjønt det. Det høres veldig smart ut. Spesielt dersom man tar av seg brillene sine, og benytter dem til å peke på forsamlingen mens man sier ordene, og legger til en selvsikker “…alltid!” på slutten av setningen. Da er det etablert. All kommunikasjon skjer på mottakers premisser.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Ndt6NLUVtLEPRgRwyxtOzQ.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@sammywilliams?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Sammy Williams</a> on <a href="https://unsplash.com/s/photos/confused?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Problemet er jo bare at det er så innmari mange mottakere. Og ingen av dem mener det samme. Hadde de gjort det så hadde jobben vært såre enkel. (Og kanskje litt kjedelig…)
Så når enkelte respondenter i brukertesten din sier at “det er for lite informasjon”, kan du være sikker på at andre syns det er alt for mye tekst å forholde seg til. Samtidig mener den meget erfarne kollegaen din, at det beste er å kutte informasjonen helt, og legge inn en knapp som kan lede kunden til et annet sted der du kan få all informasjon, hvis de ønsker det.
Så hva skal man gjøre da, dersom det tross alt bare var én person i brukertesten som snublet over «den rare greia» i løsningen din, når de ni andre ikke møtte det samme problemet? Hvordan kan vi vite at ikke denne ene personen faktisk var den som satte fingeren på hvor skoen egentlig trykker?
Kvantitativ innsikt. Og nå må jeg rope skikkelig høyt:
Analyse kan ikke være en egen avdeling som sender ut generell informasjon på overordnet nivå til produktteamene i et selskap!
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CcOOGk5m0QXU_x8cSrTwAw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@jasonrosewell?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Jason Rosewell</a> on <a href="https://unsplash.com/s/photos/megaphone?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Vi må ha analyse med oss hele veien. Vi må ha hodet langt ned i grøten på massene, slik at vi vet hvilke problemområder som faktisk er viktige når vi gjennomfører brukertesten. Og slik at vi kan vite hvilke oppgaver som bør prioriteres når oppsummeringen av brukertesten foreligger.
Vi må monitorere alt vi gjør. Og vi må kryssjekke resultatene. For hva hjelper det om flere kunder gikk et steg videre i flyten din med det nye designet, eller at flere trykket på den nye knappen, — dersom den totale konverteringen går ned?
Man kan selvfølgelig ikke være ekspert på alt. Og det er nok ingen som forventer at du som designer skal være en Google Analytics ekspert. Men selv om du ikke har tilgang til en dedikert ressurs med inngående kunnskap om analyse på teamet, er det allikevel ganske mye man kan finne ut av selv.
Det krever selvfølgelig litt tid, og mest sannsynlig må du få hjelp av noen som er litt mer kyndig på fagfeltet for å sikre at du ser på riktige tall. Og det er slett ikke sikkert du blir så mye klokere på akkurat det du lurte på i starten. Kanskje fordi det ikke var satt riktig tracking på det du ville sjekke, eller kanskje det ikke finnes et svart/hvitt svar?
Men jeg kan love deg at du finner ut noe!
Kanskje noe helt annet enn det du hadde tenkt på? Noe som gjør at du må parkere din egenoppbygde bias? Kanskje noe som gjør at du må legge fra deg komponenten du har brukt ukesvis på å forbedre med din fingerspitzgefühl, fordi den ikke blir brukt av kundene uansett hvor fantastisk den fungerer i seg selv?
Så ja; det kan være meget smertefullt å legge hodet på blokken.
Men det er helt nødvendig, dersom du skal ha et grunnlag for å legge hodet i bløt, — og ikke i tåke!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8cc85275ba5d" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/la-hodet-ligge-litt-p%C3%A5-blokken-f%C3%B8r-du-legger-det-i-bl%C3%B8t-8cc85275ba5d">La hodet ligge litt på blokken før du legger det i bløt!</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.

Arbeidslivet utvikler seg i en retning med høyere krav, tempo og press overfor de ansatte. For å henge med i utviklingen og overleve dagens marked er forventninger til kvalitet og effektivitet i arbeidet som leveres høye. Særlig i tech-bransjen skjer utviklingen i rekordfart, noe som skaper et desto høyere press på IT-konsulentene. Presset kan raskt gjøre arbeidshverdagen for en IT-konsulent svært krevende, og da er det arbeidsgivers ansvar å komme på banen for og sikre et godt arbeidsmiljø og trivsel hos den enkelte. For at dette skal være gjennomførbart er vi nødt til å være proaktive i måten vi jobber på. Å skape et fundament hvor behov som gir indre motivasjon dekkes bidrar til å skape trivsel på arbeidsplassen. Dette omhandler behovet for autonomi (selvbestemmelse), tilhørighet og kompetanse. Er disse behovene dekket, går resten av seg selv — konsulenten har indre motivasjon til å prestere i jobben.
I Dfind Consulting jobber vi kontinuerlig med å tilrettelegge for økt indre motivasjon for alle ansatte. I Great Place to Work 2021 nådde vi andreplassen. Gjennom tilbakemeldinger visste vi allerede at vi var gode, men å motta dette kvalitetsstempelet ble enda en bekreftelse på at vi gjør så mye riktig. I rapporten fremkommer det at de beste arbeidsplassene blant annet er særlig gode på å skape tilhørighet og fellesskap, å involvere og lytte til samt å være fleksible, vise tillit og støtte overfor hver enkelt. Resultatene skiller seg sterkt ut fra gjennomsnittsbedriften. Dette arbeidet skal vi i Dfind Consulting selvfølgelig fortsette med!
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6tZ9qha4HcQm-PzIo0iO_A.jpeg"><figcaption>Foto av <a href="https://unsplash.com/@priscilladupreez?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Priscilla Du Preez</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>Autonomi. Muligheten til selvbestemmelse, det å selv kunne styre egen arbeidshverdag i størst mulig grad. En som har innvirkning på egen arbeidssituasjon opplever tilfredshet i større grad enn en som ikke har det. Fokuset vårt er hele tiden å finne oppdrag konsulentene selv ønsker seg inn i. Alt som kreves er en tilgjengelig arbeidsgiver som lytter til den enkeltes ønsker og behov før konsulenten settes i prosjekt. Ved å gjøre dette vil den enkelte føle på økt motivasjon og få en naturlig indre drive til å utføre arbeidsoppgavene på best mulig måte. Dette øker produktivitet, gir bedre resultater som igjen påvirker egen mestringsfølelse og trivsel. Konsulenten befinner seg i en spiral av positive effekter, noe som øker sannsynligheten for at både konsulent og kunde blir fornøyd.
Tilhørighet handler om følelsen av å være en del av noe større. Dette handler om tilknytningen en har til kollegaer, men også tilknytningen en har til selskapet. Jo sterkere tilknytning jo større blir ønsket om å bli værende i selskapet Men hvordan får man dette til når konsulenten tilbringer mesteparten av sin arbeidstid ute hos kunde? Det sier seg selv at dette er mer utfordrende i konsulentselskaper enn i andre selskaper. Å bygge relasjoner mellom ansatte for å skape fellesskap innad i selskapet er viktig, hvor kultur er et nøkkelord. Å skape kultur for sosiale sammenkomster som appellerer til alle er krevende når behovene er ulike — arrangementene skal treffe både de som ønsker fotballturnering og de som vil løpe holmenkollstafetten, de som ønsker sjakkturnering og de som vil spille poker. Covid-19 har lært oss at følelsen av tilhørighet kan skapes og opprettholdes hjemme i stua, enten gjennom digitale kaffeprater eller virtuell lønningspils. Det er likevel ikke til å legge skjul på at vi ser frem til å kunne møtes mer fysisk fremover nå som samfunnet gradvis gjenåpnes. Hos oss har vi lyktes i å etablere et arbeidsmiljø i selskapet der hver ansatt føler seg som en del av fellesskapet. Årshjulet er fylt med sosiale eventer av både sportslig og festlig karakter, inkludert utenlands- og hytteturer.
Følelsen av tilhørighet i form av tilknytning til selskapet er også viktig. Føler du deg som en liten brikke i et digert puslespill, eller som en nøkkelperson som er avgjørende for å drive selskapet fremover? I et stort selskap kan man fort føle seg usynlig. I et mindre selskap er det enklere å ivareta en personlig profil der hver enkelt blir sett og satt pris på. Flat struktur og det faktum at “alle kjenner alle” gjør muligheten for å påvirke betydelig større, noe som igjen styrker den enkeltes tilknytning til selskapet. Kort vei til beslutning og mulighet til å påvirke egen karriereutvikling opplever vi at styrker følelsen av å være en viktig bidragsyter for selskapets utvikling.
Kompetanse innebærer følelsen av å mestre arbeidsoppgaver og å utvikle egen kompetanse. Det er viktig at forventningene til arbeidet som utføres samsvarer med kompetansen du som konsulent innehar. Ingenting er vel mindre motiverende enn å føle at du ikke strekker til eller ikke leverer resultatene som forventes av deg? Hos oss jobber konsulentene tett med et salgsteam som lytter til ønsker og behov for å finne riktig kunde og prosjekt. På den måten sikrer vi samsvar mellom forventninger, ønsker og kompetanse. Men hvor går egentlig grensen til hva som skaper mistrivsel som følge av manglende mestringsfølelse og hva som utfordrer deg såpass at du føler på kompetanseutvikling. Dette er en hårfin balanse. Kompetanseutvikling er det andre aspektet ved kompetanse som genererer indre motivasjon. For å fremme kompetanseutvikling er det viktig med utfordringer. Å få bryne seg på utfordringer en ikke har jobbet med før, komplekse arbeidsoppgaver og lignende er avgjørende for å oppnå indre motivasjon. Da er det arbeidsgivers ansvar å legge til rette for at utviklingen går smidig, at det er rom for å feile og mulighet til å være en del av et team du kan lære av. Særlig viktig er dette i tech-bransjen hvor utviklingen skjer i rekordfart. Sterkt fagmiljø innad i selskapet og mobilisering av kompetanse er viktige faktorer for å fremme kompetanseutvikling. Gjennom fagkvelder kan kunnskap, erfaringer og kompetanse deles med hverandre slik at man sammen utvikler seg. Mulighet for å kunne delta på foredrag og seminarer, ta de sertifiseringene man ønsker, og ha tilgang på nødvendig utstyr for å best mulig kunne utføre jobben sin er også viktig for å fremme kompetanseutvikling. Uten utfordringer og tilskudd til egen kompetanse vil mange føle på stagnasjon og kjedsomhet. Likevel er det viktig å huske at menneskers behov er ulike. Selv om én utvikler motiveres av komplekse, “umulige” arbeidsoppgaver, vil en annen motiveres av forutsigbarhet og rutine.
For å oppsummere viser empiri at ved å legge til rette for autonomi, tilhørighet og kompetanse på arbeidsplassen øker de ansattes motivasjon og tilfredshet. De tre faktorene er nært knyttet til hverandre. Følelse av tilhørighet gjennom relasjonsbygging skaper trygghet som for mange gjør det enklere å fremme forslag, å diskutere uten å være redd for mottakerens respons og lignende. Samtidig vil flat struktur og kort vei til beslutning gjøre det enklere å i det hele tatt komme i kontakt med rett person for eventuelle beslutninger. Følelse av tilhørighet påvirker med andre ord også autonomi. Tilsvarende vil tilrettelegging for kompetanseutvikling øke følelsen av autonomi, og vise versa. Å generere indre motivasjon krever dermed ikke nødvendigvis så mye innsats fra arbeidsgiver. Ved å være oppmerksom og lytte til de ansatte er mye gjort. Arbeidsgleden den enkelte da føler vil øke den enkeltes kapasitet og produktivitet. Sånn blir effektene en oppadgående spiral som gagner både den enkelte, kunden og selskapet. Konsulentenes trivsel er alltid prioritet nummer èn — vi er et konsulenthus av konsulenter, for konsulenter.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c4de4a359c91" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tre-faktorer-som-genererer-indre-motivasjon-c4de4a359c91">Tre faktorer som genererer indre motivasjon</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.

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

– Fantastisk å kunne bytte prosjekt uten å måtte bytte arbeidsgiver

Systemutvikler Peder Thorup har aldri angret på at han ble konsulent. Spennende kunder, varierte dager og gode kolleger er noe av det som bidrar til at han trives så godt i rollen.

– Jeg har alltid vært interessert i datamaskiner og problemløsning generelt. Samtidig er jeg nok både tålmodig og analytisk, og den kombinasjonen er nok grei å ha med seg hvis man skal være systemutvikler, sier Peder Thorup.
30-åringen var ferdig utdannet i 2016, og har siden jobbet som konsulent. Dét stortrives han med - ikke minst takket være spennende oppdrag hvor utfordringene er mange og ingen arbeidsdager er like.
Nå for tiden er Dfind Consulting-konsulenten utleid til et prosjekt for Finn.no. Kort fortalt jobbes det med fornying av annonsene i nyboligsegmentet.
–Det er et spennende prosjekt hvor vi jobber i et veldig autonomt utviklerteam. Det er også veldig gøy at det man lager blir sett og brukt av mange mennesker, påpeker han.
Det sammensatte prosjektet fører ifølge Thorup også til svært varierte arbeidsdager.
– Vi jobber hele tiden mot nye lanseringer av nye tjenester og løsninger, men det er jo selvfølgelig også litt forvaltningsarbeid fra dag til dag, forklarer han.

- En del tenker nok at man kan føle seg litt alene som konsulent, men slik er det absolutt ikke. Vi jobber i stor grad i team, og man har mye kontakt både med kunder og andre internt i Dfind Consulting.

I tillegg til variasjon i selve oppgavene, har det utvilsomt også vært stor forskjell på prosjektene han hittil har vært involvert i.
Tidligere har han vært utleid til blant andre Eika Gruppen og Statens Pensjonskasse Hos sistnevnte jobbet han med systemet som beregner pensjonen for alle offentlig ansatte.
– Det var et tungt domene å sette seg inn i. Pensjon er et komplisert tema i seg selv, og i tillegg må man følge utviklingen av endringer i pensjonslovverket. Den ble man heldigvis kurset og fikk mye ny kunnskap både før og underveis i prosjektet, sier han.
I forbindelse med prosjektet var både advokater og en rekke prosjektledere involvert, og oppgavene var kort fortalt langt fra det han nå jobber med i Finn.
– Fellesnevneren mellom de to prosjektene er at det er spennende og givende å være med på. Man jobber med noe som kommer mange til nytte, sier Thorup.

På spørsmål om han ved prosjektslutt synes det er vemodig å forlate teamet han er utstasjonert hos, svarer han følgende:
– Det er veldig vemodig å forlate teamet man har sittet på. Slik er det jo også ellers i arbeidslivet, og på den måten er ikke dette noe unikt for oss konsulenter, sier Thorup og fortsetter.
– For øvrig var nettopp dette en av grunnene til at jeg valgte å bli konsulent. Det er jo fantastisk å kunne bytte prosjekt uten å måtte bytte arbeidsgiver, legger han engasjert til.
Thorup trekker også frem andre fordeler ved jobben som systemutviklerkonsulent.
– Læringskurven er ofte bratt, spesielt i begynnelsen av nye prosjekter. Fordi man ofte får være med på flere prosjekter enn interne utviklere, får man gjerne også oppleve denne bratte læringskurven. Videre får man sett veldig mye på relativt kort tid, og i tillegg er oppgavene veldig varierte. Det er dessuten alltids spennende at man ikke er helt sikker på hva neste prosjekt blir.

Han er riktignok er på ingen måte «redd» for hva som venter rundt neste sving når et prosjekt nærmer seg slutten.
– I Dfind Consulting kan man være helt sikker på at også neste oppdrag er spennende å ta fatt på. Variasjonen, kombinert med interessante kunder, gjør at jeg har det veldig godt som konsulent her, sier han.
Han skryter ellers av Dfind Consulting for godt miljø, dyktig ledelse og en sterk sosialkomité. Ifølge Thorup er det «veldig god takhøyde» både for å foreslå og å få gjennomført sammenkomster av ulike slag.
– En del tenker nok at man kan føle seg litt alene som konsulent, men slik er det absolutt ikke. Vi jobber i stor grad i team, og man har mye kontakt både med kunder og andre internt i Dfind Consulting. Når man på toppen får det sosiale, er det ingenting som tilsier at det skal bli ensomt, avslutter han.

Møt en utvikler artikkel

Møt en X banner

Peder

Utvikler

– Som konsulent rekker jeg ikke å bli utålmodig

Tommy Svendsen kunne endt opp som fisker, men hoppet etter hvert over på IT-utdanning. Også det har gitt god fangst – i form av spennende arkitektoppdrag for store kunder.
– Jeg har jo egentlig en litt spesiell bakgrunn. Som 16-åring ble jeg fisker og senere maritimt utdannet med sertifikat på skip. Jeg stortrivdes på havet, men etter hvert fristet det nok med litt andre rammer. Valget falt på IT-utdanning i Alta, forklarer Tommy Svendsen.
Det er nå over 15 år siden han var ferdig på skolebenken ved Høyskolen i Finnmark. Ifølge ham selv har han på ingen måte angret på at han valgte å nettopp den veien.
Det har nemlig ført til en rekke spennende arbeidsdager, ikke minst nå – i rollen som arkitektkonsulent i Dfind Consulting.
– Når man har vært en del år i bransjen, er det ofte naturlig å ta steget videre som prosjektleder eller arkitekt. For meg falt valget på det siste, og det er jeg glad for, sier han og fortsetter.
– Jeg stortrives med utfordringene som ligger i det å omforme forretningsmessige behov til tekniske løsninger.

– Jeg stortrives med utfordringene som ligger i det å omforme forretningsmessige behov til tekniske løsninger.

Svendsen forklarer videre at hovedoppgaven ofte går ut på å få en oversikt over dagens løsninger, og hvordan kunden per i dag har løst domeneproblematikken.
– Videre blir vi enig med med forretningsledelsen om et målbilde, og ut fra dette settes det opp et veikart for veien videre, forklarer han.
Og det er ikke småtteri han får være med på. Svendsen var blant annet én av to som tegnet opp hele den avanserte arkitekturen i KLP. Prosjektet vakte såpass oppsikt at han ble invitert til å holde foredrag på Java Zone.
– På samme tid hadde The Guardian brukt en tilsvarende løsning, noe som indikerte at det vi gjorde var fremtidsrettet og riktig, sier Svendsen.
Han har også jobbet med Deichman i Bjørvika, hvor det oppskaleres fra 120.000 til over 2 millioner årlige brukere – uten at de ansetter flere ressurser.

Ifølge arkitektkonsulenten har han ingen planer om å bytte beite.
– Jeg liker utfordringer - og ikke minst følelsen av at man bidrar til å utgjøre en forskjell for folk, sier Svendsen.
Han poengterer også han mener man som konsulent minimerer sjansen for å føle at man stagnerer eller blir lei av jobben.
– Jeg kan nok bli litt utålmodig i jobben etter et par, tre år. Konsulentrollen passer meg derfor helt utmerket, fordi man jevnlig får nye utfordringer og oppdrag.Som konsulent rekker jeg med andre ord ikke å bli utålmodig, sier han engasjert.
Ifølge ham selv øker dessuten trivselen i takt med erfaringen han tilegner seg gjennom ulike prosjekter.
– Når man går fra et prosjekt til et annet, har man gjerne fått med seg masse relevant erfaring som den nye kunden ikke selv besitter. Det er veldig givende å oppleve den takknemligheten man da gjerne møter.

Svendsen er ofte leid ut minst seks måneder av gangen - gjerne med opsjon på forlengelse. Stort sett hele perioden tilbringes ute hos kunde.
På den måten er man som konsulent ofte relativt «ny på jobben» og med lite hverdagskontakt med egne kolleger. Likevel føler han seg på ingen måte ensom eller alene i jobben.
– I Dfind Consulting er det sterkt fokus på trivsel og godt miljø. Som en del av dette har vi et eget årshjul med masse aktiviteter, blant annet kickoff, spillkvelder og så videre, sier han og fortsetter:
– Dette er noe som settes stor pris på. Selv da vi arrangerte digital lønningspils møtte 46 av 100 ansatte opp, og det sier vel sitt om miljøet, avslutter Svendsen med et smil.

Møt en arkitekt artikkel

Tommy

Arkitekt

Holder trådene samlet i spennende gigantprosjekt

Lars Martin Riiser Haraldsen var ikke «så dyktig som de andre» på å utvikle. Så valgte han å sy sammen kommunikasjons- og utviklerferdigheter - og ble prosjektleder.

– Helt fra dag én ønsket jeg å ta steget til prosjektleder. Det virket veldig spennende å være et bindeledd mellom kunden og utviklerne, og å få bruke ferdigheter innen både utvikling óg kommunikasjon, sier Lars Martin Riiser Haraldsen og fortsetter.
– Dessuten innså jeg nok at jeg ikke var like dyktig på å utvikle som mange av de andre var, legger han til med et smil.
Selv om han sier det med en spøkefull tone, står sivilingeniøren på at dette faktisk var noe av årsaken til at han tok valget om å satse som prosjektleder.
– Ettersom det ikke var så enkelt, måtte jeg gjennom noen år som utvikler og sertifiseringer - noe som i senere tid har vist seg å være en god ting. Det førte til at jeg tilegnet meg kunnskaper og mer teknisk kompetanse enn mange andre prosjektledere, sier han.
Det skulle vise seg å være helt riktig å følge magefølelsen om å bli prosjektleder – og konsulent. Han har nå vært i jobben i fire-fem år - og stortrives.
– Man får oppleve veldig mye spennende, sier han.

- Helt fra dag én ønsket jeg å ta steget til prosjektleder. Det virket veldig spennende å være et bindeledd mellom kunden og utviklerne, og å få bruke ferdigheter innen både utvikling óg kommunikasjon

Dfind Consulting-prosjektlederen forklarer at jobben kort fortalt går ut på å sørge for god prosess – helt fra start til slutt.
– Min hovedoppgave er jo å levere arbeid av god kvalitet til gitte datoer, sier han.
Dette innebærer blant annet å sørge for at de ulike teamene til enhver tid er i rute med gitte oppgaver.
– Og er det noe som ikke går helt på skinner, er det da min oppgave å ha fortløpende dialog og diskusjon med alle involverte, sier han og fortsetter.
– Målet er at teamet skal være så selvdrevet som mulig. På den måten kan du egentlig si at jo bedre ting fungerer, jo mindre behov er det for meg, sier en lattermildt Haraldsen - før han understreker at hverdagen som konsulent i Dfind Consulting er både travle óg spennende.

Haraldsen har jobbet som prosjektleder i Dfind Consulting siden 2018, og på disse årene er det nemlig ikke småtteri han har fått være med på.
– Jeg har fått jobbe med veldig spennende prosjekter på oppdrag fra Digitaliseringsdirektoratet. I det siste prosjektet, som vi startet på i midten av 2020, jobber vi med en portal som skal gjøre arveoppgjør enklere for folk, sier han.
Mens dette i dag innebærer lange og tunge papirprosesser og involverer en rekke aktører, samles dette nå i en felles portal.
– Prosjektet innebærer mye tverrfaglig jobbing og en rekke juridiske prosesser, hvilket er både interessant, komplisert og lærerikt på én gang. I tillegg er det jo givende å vite at det man gjør bidrar til å bistå mange i en vanskelig situasjon - som arveoppgjør gjerne er, sier Haraldsen.

Planen er ifølge Haraldsen at den nye portalen for arveoppgjør skal lanseres i 2022.
Hvor lenge han blir utleid som konsulent til Digitaliseringsdirektoratet, vet han ikke. Riktignok er det heller ikke noe han tilsynelatende bruker mye tid på å tenke på.
– Som prosjektlederkonsulent får man jo et nært forhold til kundene. De blir jo en form for kolleger. «Ulempen» er at det kan være litt trist å dra fra dem, sier Haraldsen.
Han er riktignok ikke i tvil om at dette mildt sagt kommer i skyggen av fordelene ved det å være prosjektlederkonsulent.
– Man får unike muligheter til å bygge nettverk. Som prosjektleder får man også nye team og med det følger variasjon og nye, spennende utfordringer. Hvert team er jo forskjellig, sier han.
– Dessuten har jeg på toppen av dette et veldig godt forhold til både kolleger og ledelse i Dfind Consulting. Vi er et veldig godt eksempel på flat lederstruktur, og miljøet generelt er veldig bra, avslutter han.

Møt en prosjektleder artikkel

Lars Martin

Prosjektleder

Opplever bedre «kontakt med virkeligheten» i jobben som konsulent.

Etter å ha fullført Bachelorgraden i Visuell kommunikasjon ved Monash University i Melbourne, jobbet Karianne Tørum som designer i byrå i 14 år.
– Det var et helt topp sted å starte en arbeidskarriere. Jeg hadde en hel gjeng med flinke folk rundt meg, og det var både trygt og lærerikt.

I byrået jobbet Karianne med alt fra pakningsdesign og identitetsdesign, til retailprosjekter og sist men ikke minst informasjonsdesign og veivisning for Ruter. Og hun er tydelig på at det var oppdraget for Ruters Trafikantinformasjon- og designprogram som hun jobbet med i nesten 7 år, som ledet henne inn i konsulentverdenen.

–Jeg elsket kompleksiteten i alt som skulle kommuniseres. Og som innleid konsulent på 100% engasjement fikk jeg muligheten til å dykke inn i de virkelige problemstillingene, og ikke bare for sluttkunde, men også for drift og vedlikehold av tjenestene. Karianne medgir at hun nok ble litt besatt; –Ja, når du drømmer om tidtabeller har det bikka litt, sier hun og ler.

Men opplevelsen av å «knekke en kompleks kode» gav mersmak. Og Karianne innså at det var dette som trigget henne.

- Å virkelig forstå innholdet, er jo helt vesentlig for å evne å formidle det, sier hun. Siden tiden i Ruter har Karianne jobbet halvannet år som UX designer i SpareBank1. I dag er det forsikringer Karianne setter seg inn i, og det er heller ikke gjort på 3 uker!

Karianne opplever at de store selskapene er gode på å sette sammen team. – De har skjønt effekten av tverrfaglighet, sier Tørum

Prosessen blir smidig når designere og utviklere jobber sammen hele veien. Tett dialog med Prosjekteiere og Team leads er vesentlig for å sikre at man jobber mot selskapets strategier og forretningsmål. Og for å vite at man jobber med de riktige tingene må man vite hva som skjer i virkeligheten. Derfor må analyse være påkoblet hele veien.

Noen lurer kanskje på om man blir en litt «ensom ulv» i konsulentrollen, men dette avfeier hun raskt.

– Ensom nei? Snarere tvert i mot. Jeg har dobbelt sett med kollegaer jo! Dfind er gode på å skape et fellesskap, selv om man sitter på forskjellige steder i hverdagen.
Siden det er hyppige eventer, er det også helt valgfritt om man vil delta på alt.
For man skal jo ha et liv utenom jobben også. Og hvordan man balanserer dette kan ikke være opp til arbeidsgiver. Alle har forskjellige behov og er i forskjellig livssituasjon, derfor bør det ikke oppleves som en plikt å være med på alt. Faglig påfyll må også komme etter konsulentens behov og ønsker, mener Karianne. – Det er vel ingenting som er mer demotiverende enn å bli fortalt hva man skal lære mer om, sier hun.

Gjennom konsulenttilværelsen opplever hun at hun har valgfrihet til å velge sin egen vei, samt tillit til at hun tilegner seg den kunnskapen hun trenger for å gjøre jobben sin på en god måte.

– For det er jo jeg som sitter i det oppdraget, hos akkurat den kunden. Og da er det jo bare jeg som vet hva som vil gavne kunden og prosjektet. Og ikke minst meg selv da... Må jo tenke litt på det også, avslutter hun.

Møt en designer artikkel

Karianne

Designer

Aase Thuestad 

Adrian er en strukturert og løsningsorientert fullstack utvikler som brenner for backend. Hans spisskompetanse ligger i komplekse backend-løsninger og integrasjoner med bruk av JavaScript, .NET, Microsoft Azure, SQL, REST og SOAP. Adrian trives godt i alle faser av systemutvikling, særlig når han får mulighet til å samarbeide tett med kunden. Han har jobbet som utvikler med komplekse leveranser, men også som teknisk arkitekt hvor han har måtte balansere mange ulike ønsker og behov. Videre har han tilegnet seg betydelig erfaring med prosjektgjennomføring, arkitektur, design, testgjennomføring og filosofi, kravspesifikasjon og implementering. Han har jobbet med en mengde varierte og utfordrende API-er og datagrunnlag. Adrian er meget fremoverlent og proaktiv. Han jobber meget selvstendig, samtidig som han trivdes godt i samarbeid med andre, både kunder og kolleger. Samtidig jobber han utrettelig for å imøtekomme kundens ønsker.

Adrian Severin Jensen

Albert Ohrem Larsen er fullstack-utvikler med kompetansetyngde på .NET og C# i backend, samt flere rammeverk som Angular, Vue, React, TypeScript og JavaScript i frontend. Han har solid kunnskap om SQL databaser ved bruk av ORM verktøy. Han har sin bransjeerfaring fra Integrerings- og mangfoldsdirektoratet og Luftfartstilsynet. Albert holder seg stadig oppdatert på det siste innen Microsoft .NET rammeverk og verktøy. Albert har erfaring med å utvikle frontend sammen med backend i sømløse mikrotjenester med REST api arkitektur. Han er opptatt av dokumentasjon og testing. Han har også god kunnskap om kontinuerlig leveranser og integrasjoner ved bruk av Azure DevOps (CI/CD). Albert har i alle sine prosjekter utført med smidig metodikk og synes at det beste løsningene løses i et tverrfaglig team. Albert er utdannet som Dataingeniør ved NTNU

Albert Ohrem Larsen

Aleksander har fire års erfaring som Java backend- og DevOps-utvikler. Han har god erfaring fra større smidige utviklingsprosjekter, og jobber med kontinuerlig leveranse og integrasjon, utvikling av infrastruktur ved f.eks bruk av Ansible og Kubernets, logghåndtering, deployment, monitorering.

Som DevOps-utvikler har Aleksander jobbet med å skape utviklingsmiljøer som fører til kortere time to market, større grad av automasjon og enklere deployment. Applikasjonene han har jobbet med har hovedsakelig vært utviklet i Java Spring og Python.

Aleksander Jacobsen

Aleksander er en utvikler med en unik forståelse for samspillet mellom teknologi og design som elsker å skape engasjerende brukeropplevelser med elegante og moderne tekniske løsninger. Hans mastergrad innen design, bruk og interaksjon underbygger hans forståelse for dette.

Aleksander har sin fagkompetanse innen programvareutvikling, brukeropplevelse og design med over 5 års erfaring innen utvikling for blant annet web og mobil. Han motiveres av å jobbe i tett samarbeid med designere slik at han kan bidra til å løfte brukeropplevelsen gjennom gode tekniske og brukersentrerte løsninger.

Aleksander har fått bred erfaring fra prosjekter innen systemutvikling, webutvikling, apputviking, interaksjonsdesign, forskning og produktutvikling, og bred bransjeerfaring fra blant annet offentlig sektor, telecom og finans. I tillegg har han erfaring som blant annet frontendutvikler samt backendutvikler i et javamiljø.

Aleksander Rem

Alexander er en erfaren fullstack systemutvikler med allsidig erfaring fra C#.NET og Javascript med både Angular og React. Han har jobbet som .NET-utvikler i ulike prosjekter hos Gjensidige Forsikring og samtidig opparbeidet seg erfaring på front-end-utvikling og agil arbeidsmetodikk. Det siste prosjektet han jobbet på var en webapplikasjon for fornyelser av forsikringer hos Gjensidige. Applikasjonen fjernet behovet for manuell innhenting av kundedata og førte til store tidsbesparelser for de ansatte i divisjon Næringsliv.

Alexander Kingdon

Alexander er utdannet ved Norges Teknisk-Naturvitenskapelige Universitet (NTNU) med en master i kommunikasjonsteknologi, retning nett, tjenester og applikasjoner. Alexander er en omgjengelig person som trives i teamarbeid. I prosjekter er han en drivende person med et løsningsorientert perspektiv. Han har godt humør, er lett å jobbe sammen med, og finner gode løsninger på vanskelige problemer.

Alexander har utviklingserfaring fra Statens Legemiddelverk, Direktoratet for e-helse, Kværner og Kongsberg Gruppen, samt vært studentassistent i algoritmer og datastrukturer på NTNU. Under studiene fokuserte han på nettverk og distribuerte reaktive systemer. Han har også vært interessert i algoritmer og hvordan disse kan brukes til å løse beregningstunge problemer.

Alexander kommuniserer godt og er vant til å få mye ansvar i prosjektene. I siste prosjekt hos Norsk Helsenett har han ansvar som teknisk arkitekt for teamet. 

Alexander Svae

Alexander er en dyktig og engasjert fullstack utvikler, som har et mål om å skape verdi for kunden og levere resultater av høyeste kvalitet. Han mener at det er ekstremt viktig å være en selvdrevet person, en teknisk ekspert og en effektiv kommunikator for å være en viktig del av et team. Alexander er utdannet ved NTNU hvor han har en Mastergrad i Petroleumsteknologi. Gjennom prosjekter i sitt eget firma, og hos Storebrand og Digitaliseringsdirektoratet, har han opparbeidet seg solid kunnskap om både frontend og backend utvikling. Han er også sertifisert som AWS Certified Developer og har kunnskap om hvordan skyteknologi kan benyttes i utviklingen av tjenester og produkter. Alexanders tekniske kompetanse gjør at han på en god måte kan fokusere på kundens behov og foreslå optimale løsninger. Alexander er opptatt av å skrive konsis og effektiv kode, som er enkel å lese, forstå og vedlikeholde. Videre er han overbevist om at i tillegg til individuell innsats, er det like viktig å være et aktivt teammedlem – en som kan lære fra andre og dele av sin egen kunnskap.

Alexander Zakharov

Amanda Høsøien Aasen

Anders har spisskompetanse på Java, Kotlin og Kafka. Han har tung erfaring med komplekse systemer og fungerer utmerket i agile team og trives godt med forvaltning samt nyutvikling av applikasjoner.

Han er opptatt av å utvikle kode som enkelt kan overvåkes. Anders har stor interesse for å automatisere hverdagen til utviklingsteamet og organisasjonen ved å utvikle enkle og robuste løsninger (CI/CD).

I prosjekt er han opptatt av å skape entusiasme og god fremdrift. Anders er en humørspreder og utpreget lagspiller som byr på seg selv. Anders er opptatt av de små detaljene samtidig som han ser også det store bildet.

Anders har en master i Kybernetikk og Robotikk fra NTNU.

Anders Brevik

Anders har en bachelorgrad som dataingeniør fra Høgskolen i Bergen, og master i programvareutvikling fra Universitetet i Bergen og Høgskulen på Vestlandet. Har har for det meste jobbet som backend-utvikler med Java og Kotlin, og har erfaring både med nyutvikling ved bruk av moderne skyteknologi, og vedlikehold og modernisering av legacy-applikasjoner.

Anders Flemmen

Anders er en dyktig og engasjert fullstack-utvikler med spisskompetanse på .NET, .NET Core og Azure. Han trives i hele stacken og bidrar med alt fra backend og oppsett av Azure DevOps til frontendutvikling på digitale flater.

I tillegg har Anders erfaring med JavaScript, Angular, ASP.NET, Xamarin og kryssplatform utvikling på digitale flater noe som gjør at han har god oversikt over hva som kreves for å levere en god brukeropplevelse.

Anders trives godt i team, han er ikke redd for utfordringer og liker å bidra til at prosjektet har god fremdrift. Han er en sosial person og er ikke fremmed for å dele av sin kunnskap til resten av teamet.

Anders Rommetvedt Malmo

Andreas har erfaring med systemutvikling på frontend, backend og mobil. Han er detaljorientert og tålmodig samt opptatt av å skape gode brukeropplevelser som er responsive og tilgjengelige. Andreas trives godt med å jobbe i team og deler gjerne sin kompetanse med andre.

Andreas har en stor bredde innen forskjellige teknologier, hovedsakelig innen web, men også innen native mobil. De siste årene har han opparbeidet dybdekunnskap innen Angular, TypeScript, GraphQL og .Net Core.

Andreas er en nysgjerrig og lærevillig person, glad i utfordringer og interessert i ny og spennende teknologi. Andreas holder en mastergrad i datateknikk fra Universitetet i Stavanger.

Andreas Bjerga

Andreas Børhaug er backendutvikler med kompetanse i Java og Spring Boot. Han har også god kontroll på ulike meldingskøer Kafka, ActiveMQ/JMS eller Camunda samt Elasticsearch. Han har god erfaring ved å bryte ned monolitter inn i mindre selvstendige mikrotjenester med Rest API via JSON. Dette har ført til at Andreas har fått god kunnskap om kontinuerlig integrasjoner og leveranser (CI/CD) for utvikling, monitorering og vedlikehold ved bruk av teknologier som OpenShift, SonarQube, Nexus, Jenkins, RedHat og Docker. I alle prosjektene til Andreas har han utvikling i et smidig team ved bruk av kanban. Andreas har en M.Sc. i Ingeniørvitenskap & IKT ved NTNU Trondheim med spesialisering innenfor IKT & Produktutvikling.

Andreas Børhaug

Andreas Hanssveen er en seniorutvikler med erfaring fra utvikling, spesifikasjon, design, produksjonsettinger og drift. I hele sitt arbeidsliv har han jobbet med problemløsning, både fra oppveksten på gård, fagbrev som Automatiker og som utvikler. Han har erfaring med små og større team, og har god kompentase fra integrasjoner med store datasett, hvor ytelse er viktig. Andreas er god til å løse problemer og liker en utfordring. Som person er han positiv, løsningsorientert, inkluderende og opptatt av å styrke teamet han er del av. Han har blitt omtalt som et sosialt bindeledd og er en motivator i teamet. Han har sin styrke i backend C#.NET, men har også erfaring fra frontend teknologier som JavaScript og TypeScript. Han er interessert i mikrotjenester og har erfaring med å jobbe mot REST APIer. Andreas har en bred forståelse for IT, er god til å lese mennesker og setter seg raskt inn i kunders behov og problemstillinger.


Andreas Hanssveen

Andreas er en dyktig backend-utvikler, som også har god erfaring med frontend-utvikling. Han brenner for å lage gode løsninger sammen med kunden, slik at et godt sluttresultat oppnås. Andreas er opptatt av at koden som leveres skal være lesbar, samt at den enkelt skal kunne forvaltes og videreutvikles.

Gjennom hans tid som utvikler har han fått erfaring med mange forskjellige teknologier, og han holder seg alltid oppdatert på det som skjer innenfor hans fagfelt. I prosjekter har Andreas fått erfaring med vedlikehold og videreutvikling av eldre kodebaser, men han har også jobbet med det siste tilgjengelige innen teknologi, og har god kompetanse på skyløsningene til MS Azure. 

Andreas Lilleskare

André er en strukturert og erfaren systemutvikler med spisskompetanse innen React, AngularJS, .NET stacken, MSSQL og MySQL. André har bred erfaring med både frontend og backend utvikling og er komfortabel i rollen som fullstack utvikler. Han har holdt på med programmering siden barneskolen, og med hans over 15 år lange arbeidserfaring styrker han ethvert utviklingsteam på flere nivå. André har alltid hatt fokus på kundedialog i de rollene han har hatt. Han deler gjerne av sin kunnskap for å løfte teamets generelle kunnskap, samt at han bistår gjerne dersom noen skulle møte utfordringer. André har erfaring fra flere bransjer, blant annet fra olje- og gass industrien. Her var han blant annet involvert i planlegging og utvikling av AVEVA sitt nye flaggskipprodukt for håndtering av operasjonell risiko ved utføring av arbeidsordrer - AVEVA Control of Work- og Safe Job Analysis-løsning. Denne løsningen ble utviklet i Microsoft Visual Studio / C# i back-end og AngularJS-rammeverket for front-end.

André Nordstrand 

André har god kompetanse innen Data science med Python og R. Han har god erfaring med å delta og drive prosjekter fra start til slutt, fra analyse og utforming av kravspesifikasjon til implementasjon av ferdig produkt.I tillegg har André solid kompetanse som systemutvikler, med spisskompetanse på Java.

André har stor interesse og erfaring innen dataanalyse og maskinlæring, og benytte både ustrukturert og strukturert data for å finne bruksmønstre i dataen. Han benytter gjerne data til å trene opp modeller for å gjøre diverse prediksjoner (tekstanalyse,anbefalingsmodeller, etc.)

André Orten

Ann Helen er en senior systemutvikler og har en B.Sc. grad i Dataingeniør fra Høgskolen i Bergen og har tatt en del master fag fra Universitetet i Delft, Nederland, med fokus på data visualisering og multivariat statistisk analyse. Hun har kunnskap om- og deltatt i alle ledd i utviklingsprosessen fra full-stack utvikling, testing og utrulling i komplekse løsninger, spesielt innen web-utvikling. Innen front-end utvikling har hun laget responsive og skalerbare løsninger i JavaScript med React og Redux, og innen back-end utvikling har hun laget løsninger i Python og .NET, gjort integrasjoner og laget REST API, samt har erfaring med bruk av sky-platformer som Azure. I tillegg til å være en habil utvikler er Ann Helen opptatt av gode brukeropplevelser og design. Hun har erfaring med å jobbe i agile team, og har det siste året opparbeidet seg god erfaring som scrum master. Hun er en pliktoppfyllende og positiv person som er dyktig på kommunikasjon, og er opptatt av at ikke bare kode og design skal være enkelt og brukervennlig, men også at utviklingsprosessen er oversiktlig og strukturert, samt at det som utføres stemmer overens med det kundens behov og ønsker.

Ann Helen Tangedal

Arild er en allsidig systemutvikler som også kan påta seg både frontend og backend-roller. Han har arbeidet i virksomhetskritiske prosjekter innen lotteri- og spillvirksomhet, eiendomsmegling og i det offentlige, han har utviklet applikasjoner som har over 500 000 unike brukere ukentlig og som omsetter for 38 milliarder kroner årlig.

Arild behersker teknologier som react, redux, nodejs, kotlin, java og databaser. Med en tilleggs bachelor i UX vet han godt hvordan man skal utvikle i henhold til etablertestandarder for universell utforming og design.

Arild behersker alle faser i systemutvikling, fra spesifisering av krav, analyse/design, utvikling til testing og videreutvikling/forvaltning. Han er meget strukturert, engasjert og selvstendig. Arild får stadig gode tilbakemeldinger på sitt arbeid og som person frakunden.

Som konsulent er Arild opptatt av å holde seg faglig oppdatert, dette praktiserer han ved å bruke fritiden sin på hobbyprosjekter og generelle egenstudier.

Arild Birkeland

Arne Daniel Iselvmo Bjerk er frontend-utvikler med spisskompetanse i React, Angular, TypeScript, JavaScript og NgRx. Han har god erfaring med å utvikle frontend-komponenter for å ivareta WCAG-prinsippene og universell utforming. Arne har også erfaring med backend-utvikling ved bruk av Java, Spring og ulike SQL teknologier. Arne har sin bransjeerfaring fra Tietoevry. Arne har flere ganger vært med på å utvikle applikasjoner som har utviklet seg fra idé til forvaltning. Han har derfor god erfaring med å forholde seg til økende kompleksitet ved ulike arkitekturer og API'er som Rest, mikrotjenester og webservices. Arne har god forståelse av feilhåndtering og er derfor opptatt av god og riktig testdekning. Arne har i alle sine prosjekter utviklet i tverrfaglige, smidige team. Arne har en bachelorgrad i informatikk fra Universitetet i Sørøst-Norge.

Arne Daniel Iselvmo Bjerk

Asle begynte å jobbe i Bouvet i januar 2019. Parallelt fullførte han sin bachelorgrad i data ved UiS.Han startet som utvikler med webapplikasjonen Spekter, hvor han jobbet med hele stacken som inkluderer Postgres, React m/ Typescript, Redux og Node/Express. Asle har hatt hovedansvaret for utvikling og forvaltning av Spekter. I denne rollen har han hatt et overordnet teknisk ansvar. Det innebar blant annet et ansvar for kvalitet gjennom codereviews, og at koden testes tilstrekkelig før den blir satt ut i produksjon. I desember 2019 gikk Asle inn i et nytt team hos Lyse. De har hatt ansvar for å forvalte og videreutvikle [lyse.no](http://lyse.no/). I Lyse teamet har det vært mye fokus på at alle skal ha en forståelse av alle delene av applikasjonen, å følge standarder og ha god kvalitet på code reviews. Asle har et variert sett med arbeidsoppgaver, men har sitt hovedfokus på frontend med React, Typescript og Next JS, samt utvikling av CMS'et Sanity.

Asle Berge

Audun er en frontend- og web-utvikler med genuin interesse for å levere løsninger som fungerer og er tilgjengelige for alle. Han har et utpreget fokus på brukervennlige løsninger. I tidligere prosjekter har han jobbet aktivt sammen med designere, prosjektledere og utviklere for å heve kunnskap om universell utforming. Med hans bakgrunn er han flink til å samarbeide med flere forskjellige roller, se helhetlige løsninger, samt tenke på sluttbrukers opplevelse av løsningen.

Han har den siste tiden jobbet mye med React og Vue, samt Redux og Vuex for å organisere data. Audun fikk hos SpareBank1 en sentral rolle i utforming av prosesser rundt implementering av god brukervennlighet. Her holdt han presentasjoner for utviklere for å øke kunnskapen rundt universell utforming og semantisk HTML for de andre utviklerne.

For VG satt han brukervennlighet på agendaen for hele utvikleravdelingen, prosjektlederavdeling og testere. Ved å holde workshops og presentasjoner for utviklere og prosjektledere fikk han ansvaret for å sjekke all HTML som ble levert i prosjektet for god semantikk. Koden som ble levert hadde enhetstester Mocha og integrasjonstester som kjørte på Browser Stack.

Som person er Audun en omgjengelig problemløser som trives med teamarbeid.

I prosjekter har han et pågangsmot som effektivt sørger for god fremdrift.

Audun Skjelvan

Audun Skjervold har jobbet som konsulent siden 2015, og har utviklet seg til en meget dyktig konsulent innen Vue.js, React og på .NET-plattformen. Den siste tiden har Audun jobbet med fokus på webutvikling hos Nordea Direct. Her har rollen vært front-end-utvikler på deres prosjekt med å skape verdens beste boliglånsplattform. Han har tidligere vært i prosjekt hos PayEx, hvor han som tech lead hadde hovedansvar for å løfte deres kortadministrasjonsløsning over på en moderne Vue.js front-end med en .NET Core back-end. Han har også erfaring med utvikling i AngularJS og KnockoutJS på front-end og Scala på back-end gjennom prosjekter hos Gyldendal og Oslo kommune, og har erfaring med automatisering av manuelle prosesser og opplæring av nyansatte.

Som person er Audun nysgjerrig og løsningsorientert og han liker å utforske nye teknologier. Han er svært interessert i brukerinteraksjon og brenner for kodekvalitet. Han jobber godt i team og er ikke redd for å ta ansvar der han ser det trengs. Han er alltid vennlig og imøtekommende, og tar imot utfordringer med et smil.

Audun Skjervold

Axel Aasen

Beate er prosjektleder med over 15 års erfaring. Hun har ledet en rekke digitale prosjekter fra start til slutt innen ulike bransjer, både offentlig og privat. 
Beate er en tydelig og stødig leder som evner å se helheten og skaper god samhandling og kommunikasjon på tvers av team og organisasjoner. 
Hun er sertifisert Agile Coach, Scrum Master og Scrum Product Owner og jobber med smidig gjennomføring i alle prosjekt hun leverer. 
Tidligere har Beate jobbet som webdesigner og webmaster, og har blant annet utdanning innen Produksjonsledelse, Multimedia og Bedriftsøkonomisk Analyse.

Beate Helene Thunes 

Bendik er opptatt av å benytte den teknologien som gir riktig gevinst for en organisasjon og applikasjon(er). Med dette som tilnærming har han opparbeidet seg en bred kompetanse med ulike verktøy, rammeverk og programmeringsspråk samt kan utføre oppgaver i alle arkitektoniske lag. Bendik er også Scrum sertifisert.

Bendik har spisskompetanse på backend-utvikling, både offentlige samfunnskritiske systemer så vel som store avanserte private distribuerte systemer. Utdannelsen har trent Bendik på å bryte ned og forstå komplekse problemer ved hjelp av matematikk, datasimuleringer og numeriske modeller.

Bendik er kjent for å være avbalansert og med gode kommunikasjonsferdigheter. Han er informasjonssøkende og alltid en lagspiller.

Bendik er utdannet som Sivilingeniør, innenfor Marin Teknikk ved NTNU.

Bendik Stavelin

Benjamin er erfaren utvikler som mestrer alle arkitektoniske lag i en applikasjon. Han er opptatt av å utforme den koden som gir mest verdi for det agile teamet og organisasjonen i sin helhet. Benjamin har 8 års erfaring med store java API integrasjoner og frontend utvikling i offentlig sektor.

I siste prosjekt hos Landbruksdirektoratet (LDIR) hadde Benjamin rollen som techlead. Typisk teknologi er typescript React/Redux mot mikrotjeneste REST api Java Spring Boot via JSON. (Microservices)

Samspillet mellom teknologi, mennesker og organisasjon har gjort Benjamin opptatt av «clean code principles». Med fokus på «kost-nytte» skriver han alltid tester først (Test Driven Development), og er tilhenger av domene drevet arkitektur (Domain Driven Development).

Bygg og deploy står også sentralt, uten de rette verktøyene (f.eks maven, travis, sonar, github osv) er det svært utfordrende å opprettholde kodekvalitet over tid. I alle sine prosjekter har han vært med å sette opp og fasilitere disse verktøyene og retningslinjene.

Med sine pedagogiske egenskaper er han en konsulent som er opptatt av å dele sine kunnskaper med andre og bistår alltid kunden med å definere og prioritere oppgaver i riktig rekkefølge. Han er kjent for å være en pådriver med gode kommunikasjonsevner.

Benjamin trives i mindre og større agile teams, der metodikken Scrum med Kanban regler står sentralt. Benjamin er sertifisert Scrum Master.

Benjamin Johansson

Bent har flere års erfaring med interaksjonsdesign, web-applikasjoner og webutvikling, med hovedfokus på frontend utvikling kombinert med universell utforming i kode og prototyping. Bent har stor lidenskap for gode brukeropplevelser og innovative løsninger, og blir ofte beskrevet som relasjonsbyggeren i teamet.

Bent Rynning

Bjørge er en kreativ og erfaren UX Designer med stort engasjement for utvikling av brukervennlige og intuitive tjenester og produkter. I over 15 år har han hatt ledende roller innen design og forvaltning av produkter og tjenester av variert karakter. 

Bjørge er en engasjert og proaktiv ressurs gjennom hele verdikjeden til et produkt eller tjeneste, og har god erfaring med å arbeide etter tjenestedesignprinsipper. Med sine evner til å raskt sette seg inn i nye fagområder, identifisere den viktigste informasjonen og brukerbehovet, skaper han gode og helhetlige brukeropplevelser. Dette gjør ham til et verdifullt prosjektmedlem, både ved utforming av nye eller forbedring av eksisterende tjenester og produkter. Bjørge jobber selvstendig og har god leveransekapasitet, samtidig som han setter pris på å jobbe i team og ha tett dialog med både brukere, fagpersonell og utviklingsressurser. Han har variert erfaring fra ulike bransjer, blant annet fra arbeid med kunder som Semine, UiA/UiT, Skatteetaten, Phonero/Telia og Kongsberg Digital.

Bjørge Stølen

Bjørnar Holmvik

Brian Dale

Bård Kristian Haaland-Sørensen er fullstack-utvikler med spisskompetanse i Kotlin, C#, Java, Spring Boot, samt React, TypeScript og JavaScript og ulike meldingskø-teknologier i backend. Han har også solid erfaring med ulike SQL teknologier som Oracle DB, MSSQL og MySQL. Bård Kristian har sin bransjeerfaring fra bank / finans og helsesektoren. Bård Kristian har flere ganger portert monolitter over til mindre selvstendige rest mikrotjenester. Han har også utviklet domene drevet arkitekturer som er integrert til forskjellige komplekse apier som BankID, Buypass, Banktjenester og ulike Helseregistre. Han har derfor god kompetanse med integrasjoner, transaksjoner og sikkerhet samt forstår verifisering-protokoller. Bård Kristian har i alle sine prosjekter utført smidig metodikk, og synes at det beste løsningene løses sammen i et tverrfaglige team. Bård Kristian deler gjerne sin kompetanse med sine teammedlemmer. Bård Kristian er utdannet ved Universitetet i Bergen.

Bård Kristian Haaland Sørensen

Camilla er en produktiv, ryddig og resultatbevisst designer som liker kreative prosesser. Hun er veldig nøye med å opprettholde mappestrukturer og ha et generelt godt og ryddig overblikk over prossess og mål. Hun blir inspirert av å kommunisere historier og informasjon gjennom design.

Camilla har erfaring med smidig tilnærming til oppgaver og mener de beste resultatene oppstår i tverrfaglige samarbeid der teknologi møter design. Hun er alltid nøye med å ivareta og opprettholde selskapets og kundens visuelle profil, og liker godt å dra elementer videre inn i nye løsninger på tvers av kanaler. Camillas design for digitale flater etterlever kravene i WCAG 2.0 (UU) og hun har spesielt god innsikt i kravene som gjelder til farger og kontrast. Camilla er nøye med at produktet som leveres skal være helhetlig, gjennomtenkt og utstråle god brukeropplevelse. Hun har utarbeidet komponentbibliotek og site-maps, og hun følger opp implementering direkte med front-end utviklere. Hun har også kjennskap til Bootstrap, CSS, HTML5, Umbraco og Javascript. Camilla har også arbeidserfaring fra salg- og servicebransjen og har blant annet utført behovsanalyser, administrative oppgaver, gjort kundeoppfølging ogutviklet en god forståelse for tilpasning av design til sluttbrukers behov og ønsker.

Camilla Tallarico

Carl Otto Steen er en fullstack utvikler med kjernekompetanse innenfor Java Spring Boot i backend og Angular i frontend. Han har også erfaring med Azure skyteknologi, og hans mastergrad med spesialisering i Databaser og søk gjør han særdeles kompetent innenfor databaseteknologier. 

Carl Otto har erfaring med utvikling av komplekse systemer med høye krav til sikkerhet, blant annet gjennom prosjekter for FHI og NorgesGruppen. Carl Otto har ved flere anledninger arbeidet med nyutvikling, oppgradering og forvaltning, samt migrert løsninger fra on-prem til sky. 

Han er opptatt av å følge SOLID-prinsippene og Clean Code, og brenner for å skrive testbar kode. Carl Otto er vant med smidig arbeid i tverrfaglige team, og har god erfaring med testdrevet utvikling (TDD). Han trives med ansvar i prosjekt, og har flere ganger vært med på løsningsutforming og tatt designavgjørelser i prosjektene han har vært en del av. Carl Otto er utdannet sivilingeniør fra NTNU, med spesialisering innen databaser og søk. 

Carl Otto Steen

Cecilia er utdannet Master of Science i Kommunikasjonsteknologi fra Norges teknisk-naturvitenskapelige universitet (NTNU) med spesialisering innenfor informasjonssikkerhet. Hun har kjennskap til flere moderne frontend og backend teknologier, og er opptatt av sikker, oversiktlig og logisk kode.

Hun trives i dynamiske miljøer og med utfordrende oppgaver. Gjennom en lederutdanning på befalsskolen i Forsvaret har hun tilegnet seg evnen til å være svært løsningsorientert og tilpasningsdyktig.

På fritiden deltar Cecilia på ulike kurs for å bli bedre kjent med nye teknologier, som Kotlin og Firestore. Hun er faglig nysgjerrig og har stor interesse for bredden i teknologi.

Cecilia Peinert

Christel Renée Bjerkreim

Christian er en dyktig og løsningsorientert frontend utvikler med nærmere 3 års arbeidserfaring, som også har erfaring med backend. Hans hovedkompetanse er JavaScript, Typescript, React, C#, .Net Core, Less, Durendal og Knockout.js.

Christian har fullført en bachelorgrad i IT og Informasjonssystemer ved Universitetet i Agder, og har igjennom studiet blitt kjent med Java og Python. Under studiene drev han sitt eget enkeltmannsforetak hvor han jobbet med grafisk design og utvikling av nettsider for mindre bedrifter. Blant annet utviklet han hele applikasjonen av et dekkhotell hvor han brukte Java med MySQL database og JavaFX som brukergrensesnitt.

Personlig har Christian en rolig og hyggelig væremåte. Han liker å sette seg inn i nye teknologier og holder seg oppdatert med ulike hobbyprosjekter. Christian trives med å få ansvar og dele kompetanse med andre. Han har blant annet vært ansvarlig for oppfølging av nye juniorutviklere, og var også hjelpelærer i ulike fag ved UIA. 

Christian Moen

Christian er fullstackutvikler som behersker alle arkitektoniske lag. Hans spisskompetanse er frontend og testing med teknologiene React, RxJs og Node. Hans lidenskap er å utvikle ren og skalerbar kode som er enkel å vedlikeholde, teste samt utvide med ny funksjonalitet.

Christian er opptatt av semantisk html slik at universell utforming blir ivaretatt. For å bevare riktig tidsriktig arkitektur er det viktig å utforme domene drevet arkitektur via Rest API.

Christian har også god kompetanse og kapasitet til å lede et eller flere agile kryssfunksjonelle team samtidig som han selv er utvikler. Christian er veldig engasjert i sitt fag og brenner for teknologi og smidig metodikk. Han har bred erfaring med private og offentlige aktører som hver sitt innehar samfunnskritiske systemer samt komplekse domener rundt dette

Christian er utdannet ved Universitetet i Sør-Øst Norge (USN)

Christian Svenkerud

Christian er en erfaren fullstack systemutvikler som har fokus på å oppfylle sluttbrukerens behov. Hans hovedkompetanse er Angular, JavaScript, Typescript, C#, .Net Core, Azure, og Web Security. Christian har tilegnet seg en dyp forståelse og et bredt spekter innen informasjonssikkerhet, og tar med seg denne kompetansen inn i et hvert systemutviklingsprosjekt. Hans lidenskap for cybersikkerhet og hans inderlige interesse for programvareutvikling gir ham enorm innsikt i å finne sårbarheter i nett- og stasjonære applikasjoner.

Gjennom flere prosjekter har Christian fått erfaring med webutvikling og end-to-end-systemer for frivillige organisasjoner i tillegg til veletablerte kunder. Mens han jobbet som utvikler fikk han erfaring med bruk av Git og smidig utvikling SCRUM. I tillegg har Christian jobbet som driftstekniker i telekombransjen, noe som har gitt ham en rik erfaring innen kundekommunikasjon og feilsøking av et stort offshore telekommunikasjonsnett.

Christian Sørseth

Christoffer er en fullstack frontender som behersker alle de tre store typescript frontend-rammeverkene som React, Angular og Vue. Hans spisskompetanse er React, RXJS, Express og NodeJs.

Han er opptatt av SOLID prinsippet og utvikler alltid sine REST Apier med Domain Driven mikrotjeneste arkitektur. Sensitiv informasjon som flyter igjennom en applikasjon tar Christoffer ikke lett på, han er opptatt av personvern. Han har god kompetanse på GDPR fra et av landets største banker.

Han har en mastergrad i informatikk fra NTNU og er en allsidig systemutvikler som drives av verdiskapning for kunde og sluttbruker. Som masteroppgave utarbeidet Christoffer en mobilapplikasjon med mål om å gjøre husarbeid til en engasjerende aktivitet. Christoffer har gjennom flere deltidsjobber fått et godt innblikk i forskjellige frontend- og web-teknologier.

På fritiden liker Christoffer å holde seg oppdatert på teknologier gjennom blant annet Reddit, Hacker News, Kode24 og fagbøker. Gjennom studiet har Christoffer vært undervisningsassistent og læringsassistent i webteknologi, webutvikling og programmering lab i 6 av 8 mulige semestre.

Christoffer er en utadvendt person som raskt finner seg til rette i nye omgivelser, med et engasjerende og smittende humør. Christoffer setter god kommunikasjon høyt.

Christoffer Almankaas

Christopher er fullstack-utvikler med kjernekompetanse innen java, mikrotjenester og test automatisering. Han har bred erfaring i å utvikle og forvalte samfunnskritiske applikasjoner samt anerkjente streamningstjenester.

For å ivareta god testdekning og kvalitet i det fleste ledd er han opptatt av å automatisere test-pipelinen slik at det smidige autonome teamet oppnår best mulig kontinuerlig integrasjoner og leveranser.

Han er kjent for å være kreativ og løsningsorientert person som alltid ser helheten. Han holder seg faglig oppdatert ved å lese på teknologi på fritiden samt dele sin kunnskap med sine kollegaer, gjenre i form av fagkveld med presentasjon.

Christopher Olsen

Dag Brede Ihle er en god fullstack utvikler som behersker å forvalte og ny-utvikle i alle arkitektoniske lag. Dag har fungert som både arkitekt, techlead og mentor for sine kollegaer. For å utvikle skalerbar kode utvikler han alltid Domene Drevet arkitektur via mikrotjenester, Rest APIer ved bruk av Java, Spring Boot, Gradle, Kotlin og Kafka eller Python. Dag er godt vandt med bruk av database queries og behersker spesielt Postgres godt.

På frontend har Dag god kompetanse med de fleste JavaScript rammeverkene slik som React og Angular, der alle hans prosjekter har benyttet seg av TypeScript. Han har flere ganger bygget opp frontend applikasjoner fra bunn av.

Dag har i alle prosjekter jobbet med pipelines hvor automatisert testing og bygg av hver pull requests har vært et krav. Han har erfaring med flere forskjellige Git repository managers som BitBucket, GitHub og Gitlab. Jenkins har sørget for automatisk bygg og deploy jobber for både test, staging og produksjonsmiljøer. Dag skriver alltid testene før han begynner, slik at Testdrevet utvikling blir ivaretatt.

I alle prosjektene Dag har jobbet med har continuous delivery prinsipper blitt tatt i bruk. Dag er opptatt av å benytte de agile seremoniene som gir teamet, applikasjonen og organisasjonen best leveransekraft - teknologi, rammeverk og smidige metodikker et sett av verktøy som kan benyttes.

Dag har også erfaring fra arbeid med Cloud teknologi gjennom arbeid med integrasjon mot AWS.

Dag er fremoverlent og har gode kommunikasjons og dokumentasjons-evner med å innhente behov samt forankring av disse. Dag holder seg faglig oppdatert igjennom egne prosjekter, faglig litteratur samt interne Kubernetes kurs. Han er alltid imøtekommende og er opptatt av å holde seg i form.

Dag Brede Ihle

Daniel er fullstack utvikler og har den siste tiden jobbet som javautvikler hos Toyota Norge. Der arbeider han med "Kaikaku-prosjektet" som omhandler en radikal endring av hele deres kodebase. Det jobbes med å bygge apper RESTful APIer dokumentert med Swagger, oppsett av moduler med Maven og bygging av applikasjoner med Spring. Daniel har tidligere erfaring som utvikler i mindre team hvor han jobbet på tvers av stacken og på flere plattformer. Han har jobbet med å utvikle kjernestrukturen i C#, webløsninger og API i .NET Core, mobilapper med Xamarin, samt databaser i MongoDB og Entity Framework. I tillegg har Daniel fått god erfaring gjennom utviklingsverktøyet Azure DevOps. Prosjektene har også inneholdt diverse .NET teknologier, hovedsakelig .NET Core. Som person er Daniel en omgjengelig problemløser og setter seg raskt inn i ny kunnskap. Han viser stor nysgjerrighet og engasjement for nye idéer og teknologier.

Daniel Dutta

Daniel Engebretsen er fullstack utvikler som kan forvalte og ny-utvikle i alle arkitektoniske lag med frontendkompetanse i JavaScript og React samt backendkompetanse i Java, Kotlin, Node og ulike meldingskø teknologier skrevet i Kafka, ActiveMQ og RabbitMQ. Daniel er også god på cloud teknologier.

Daniel er opptatt av tidsriktig arkitektur samt kontinuerlig utvikling og leveranse, og som et ledd i dette bryter han alltid ned applikasjoner inn i mindre selvstendige java spring boot rest mikrotjenester ut i skyen. Videre er det viktig med testdrevet utvikling for å ivareta god testdekning, samt bruk av Docker, Kubernetes, Grafana og Kibana for monitorering, logging og bygg og deploy for å oppnå stabilitet for alle APIer og integrasjoner

Daniel er selvstendig og har tro på at de beste løsningene blir gjort i samarbeid med alle andre i ett tverfaglig autonomt smidig team. Daniel er opptatt av delingskultur.

På fritiden trives Daniel med å holde seg i form, samt holde seg faglig oppdatert.

Daniel Engebretsen

Daniel er en erfaren systemutvikler og applikasjonsdrifter med mange års erfaring innenulike plattformer og teknologier. Han har en bachelorgrad i informatikk og harspesialisert seg på utvikling og drift av applikasjoner basert på Java-plattformen, i tilleggtil å ha jobbet med teknologier basert på JavaScript. Han har arbeidet innenfor mangeulike bransjer som bank & finans, energi og transport. Daniel er en god problemløser somhar en analytisk tilnærming, og trives godt med oppgaver hvor han kan løse praktiskeproblemer for kundene. Han er stadig nysgjerrig på nye teknologier og lærer nye tingsvært raskt. Daniel har et rolig lynne og godt humør som gjør ham til en utmerketlagspiller. I tillegg har han en god evne til å arbeide selvstendig.

Hva kan vi

Systemutvikling

Design og brukervennlighet

Prosjektledelse og rådgiving

Systemarkitektur

Bli en av oss

Siste blogginnlegg

European Women in Tech 2022 - Tre takeaways

Help, I’m a proxy product owner!

React Scroll Hook with Shadows

Les om hvordan det er å jobbe hos oss