CSS selectors are evil and JS is the solution

This blogpost is excellent as preparation for the course Javascript Foundation, running March 22-23.

The premise

In this blog post we'll demonstrate...
  • why CSS inherently doesn't scale
  • how BEM is a partial solution
  • how inline styles through JS is a (nearly) full solution
Towards the end we'll use React as a vehicle for our example, but the concepts apply equally well to Angular or any other modern JS framework. We won't use any "CSSinJS library".
A small caveat: according to many, what we're describing in this post isn't strictly CSSinJS, but inline styles via JS. However at this stage the distinction doesn't matter much, so if you came here because you're curious about CSSinJS, by all means read on!

Our example

Imagine we have a complex webapp with lots of styling. We now want to add a new UI concept; an explanation box, meant to be shown inside a bigger context to explain some related concept.
Here's what it should look like:
cssinjsbox.png
Disregarding styling, here's the markup:
<div>

  <h2>Did you know?</h2>

  <p>Ozelots hate maccaws!</p>

</div>
We want to apply these styles to the explanation box div:
border-radius: 15px;

padding: 10px;

border: 2px solid springgreen;

background-color: moccasin;

color: magenta;
And inside the box we want these styles for the explanation headline h2:
font-weight: normal;

letter-spacing: 5px;

padding-left: 15px;

font-style: italic;

font-size: 14px;
As an added spice, also imagine these styles being applied to every h2 in our app:
font-family: Verdana;

font-size: 16px;
Now let's start exploring how to add these styles to our markup!

Take 0 - inline styles

The most primitive solution is to simply shove all needed style rules into the style prop of every explanation box:
<div style="border-radius: 15px; padding: 10px; border: 2px solid springgreen; background-color: moccasin; color: magenta;">

    <h2 style="font-family: Verdana; font-size: 14px; font-weight: normal; letter-spacing: 5px; padding-left: 15px; font-style: italic;">Did you know?</h2>

    <p>Ozelots hate maccaws!</p>

  </div>
This is of course a horrible solution since
  • the HTML becomes super-bloated and unreadable
  • the styles can't be reused
  • we'd be repeating "theme rules" (like the moccasin background color) all over the place

Take 1 - stylesheet with selectors

To counter the above we always put our styles in a separate CSS file, using selectors to direct where they are applied.
In order to be able to target explanation boxes we can introduce a class name to the markup:
<div class="explanationBox">

  <h2>Did you know?</h2>

  <p>Ozelots hate maccaws!</p>

</div>
In a separate CSS file we can now apply the box styles like this:
.explanationBox {

  border-radius: 15px;

  padding: 10px;

  border: 2px solid springgreen;

  background-color: moccasin;

  color: magenta;

}
We style the explanation headline by using a child combinator in the selector:
.explanationBox > h2 {

  font-weight: normal;

  letter-spacing: 5px;

  padding-left: 15px;

  font-style: italic;

  font-size: 14px;

}
The generic h2 styles would get their own selector:
h2 {

  font-family: Verdana;

  font-size: 16px;

}
Note that both of these later selectors will have an opinion about the font-size of our explanation headline, but since .explanationBox > h2 is more specific than h2, the former will win.

Unanswerable question 1 - the unknown killer problem

With our styles in a CSS file, we now have the following situation:
cssinjs-selector.svg
The rule blobs are connected with their respective target elements via selectors. While they work fine for our simple example, they don't scale well. As the app grows it is very easy to end up in a messy situation where we are scared to change both HTML and CSS, in fear of some selector somewhere breaking.
Even in our small example the main reasons for the unscalability are easy to demonstrate.
Look again at our HTML...
<div class="explanationBox">

  <h2>Did you know?</h2>

  <p>Ozelots hate maccaws!</p>

</div>
...and ponder this simple question with regards to the div:
What styles are applied to this element?
We have no easy way of knowing! The elements are being shot at by CSS selectors somewhere out there in the dark. From this side we have no idea whether any of them are targetting this specific element.
It is likely that there is a selector targetting the .explanationBox class in a selector somewhere. But because CSS selectors are global we'd have to search all CSS in order to know.
And consider asking the same question about the h2 - it doesn't have a class, which might imply it is not in the crosshairs, but it is in fact targeted by two selectors; h2 and .explanationBox > h2.
Just by looking at the HTML we cannot know what styles, if any, are applied to an element.

Unanswerable question 2 - the unknown victim problem

We find the reverse of the same problem in the CSS file. Look for example at this part:
.explanationBox > h2 {

  font-weight: normal;

  letter-spacing: 5px;

  padding-left: 15px;

  font-style: italic;

  font-size: 14px;

}
Now imagine trying to answer this question:
To which elements are these styles applied?
This is impossible to know. We'd have to search through all our HTML files, or templates in case of a dynamic app. And in a dynamic setting the .explanationBox element and the contained h2 might live in completely different places, making it even harder to figure out the answer.
This makes editing a CSS file really scary. Can we remove this part? If the question above was easy to answer then we could know whether it is safe to remove a certain part, but now we cannot!

Take 2 - using the BEM naming convention

There has been many attempts to mitigate the mess caused by the inability to answer these two questions. One such attempt is the BEM naming convention, which basically boils down to...
  • have selectors consist of a single class always
  • name the classes according to a strict convention
For our example, the explanation box would be a Block, while the h2 inside of that would be an Element of that block. This is the B and E of BEM (the M stands for modifier but we don't need that here).
Using BEM logic our markup would become:
<div class="explanationBox">

  <h2 class="explanationBox__headline">Did you know?</h2>

  <p>Ozelots hate maccaws!</p>

</div>
The CSS would now be:
h2 {

  font-family: Verdana;

  font-size: 14px;

}



.explanationBox {

  border-radius: 15px;

  padding: 10px;

  border: 2px solid springgreen;

  background-color: moccasin;

  color: magenta;

}



.explanationBox__headline {

  font-weight: normal;

  letter-spacing: 5px;

  padding-left: 15px;

  font-style: italic;

}
It is now slightly more clear what styles are applied where. Both the earlier questions are easier to answer, since we can do a search for the more precise class names.
But we still have the problem of the generic h2 selector. Also class names might be dynamically created and/or added to an element, so again, in a dynamic setting it might still be hard to find out exactly what's going on.

Take 3 - inline styles in a React component

The basic idea in BEM, as well as in OOCSS or any of the other attempts at bringing structure to CSS, is to think in terms of components. All style definitions, as far as possible, should be tied to a certain component.
This jives very well with modern JS frameworks, who (almost) all have a component-centric architecture. If components are our main abstraction, then it is very easy to make an API to style individual components.
React (and most of the competition) does this by letting us provide a CSS-like JS object to the style prop:
const box = {

  borderRadius: "15px",

  padding: "10px",

  border: '2px solid springgreen',

  backgroundColor: 'moccasin',

  color: 'magenta'

};



const headline = {

  fontFamily: 'Verdana', // should live in generic h2 styling, but we're cheating for now

  fontWeight: "normal",

  letterSpacing: "5px",

  paddingLeft: "15px",

  fontStyle: "italic",

  fontSize: '14px'

};



export class ExplanationBox extends React.Component {

  render() {

    return (

      <div style={box}>

        <h2 style={headline}>{this.props.title}</h2>

        {this.props.children}

      </div>

    );

  }

}
Elsewhere in our React app we can now do this...
<ExplanationBox title="Did you know?">

  <p>Ozelots hate maccaws!</p>

</ExplanationBox>
...and we have our reusable, styled component!

Take 4 - imported inline styles

However, what you just saw was really nothing but a regression to our Take 0 attempt, where we put all styles inline. Like an animal.
But we can improve on this super easily, simply by migrating the styles to a separate file! Imagine the following living in a file named styles.js:
export const typography = {

  h2: {

    fontFamily: 'Verdana',

    fontSize: '16px'

  }

};



export const explanation = {

  box: {

    borderRadius: "15px",

    padding: "10px",

    border: '2px solid springgreen',

    backgroundColor: 'moccasin,

    color: 'magenta',

  },

  headline: {

    ...typography.h2,

    fontWeight: "normal",

    letterSpacing: "5px",

    paddingLeft: "15px",

    fontStyle: "italic",

    fontSize: '14px'

  }

};
Note the handling of the basic h2 styles!
Our React component now becomes this:
import {explanation} from styles;



export class ExplanationBox extends React.Component {

  render() {

    return (

      <div style={explanation.box}>

        <h2 style={explanation.headline}>{this.props.title}</h2>

        {this.props.children}

      </div>

    );

  }

}
We have now sort of reinvented the stylesheet! Except, where before the stylesheet used selectors to fire blindly into the dark...

cssinjs-selector.svg
...we now let the components go get exactly the styles they need via imports:

cssinjs-import.svg
It might not be immediately obvious, but the flipping of this arrow makes a world of difference!

Finding the killer

Remember the first unanswerable question?
What styles are applied to this element?
In our imported inline style setup, this becomes trivial to answer. I simply follow the thread backwards from the style prop!

cssinjs-findkiller.gif
Finding the victim
Our second unanswerable question was:
To which elements are these styles applied?
Again, because of the explicit imports, this becomes very easy to answer (if you have a semi-competent editor):

cssinjs-findvictim.gif
LESS isn't more
Through moving our style definitions to JS land, the need for CSS preprocessors goes out the window. Remember how we used the ... spread operator to mix in the h2 styles into our headline rules?
headline: {

  ...typography.h2,

  fontWeight: "normal",

  letterSpacing: "5px",

  paddingLeft: "15px",

  fontStyle: "italic",

  fontSize: '14px'

}
That was the equivalent of a LESS/SASS mixin! You'll quickly find that the other syntax they give us can be easily replicated with pure JS. For example, having global variables becomes trivial:
export const palette = {

  softcolor: 'moccasin',

  hardcolor: 'magenta',

  accentuationcolor: 'springgreen'

}



export const explanationBlock = {

  box: {

    borderRadius: "15px",

    padding: "10px",

    border: '2px solid ' + palette.accentuationcolor,

    backgroundColor: palette.softcolor,

    color: palette.hardcolor,

  },

  // ...truncated
As do implementing helper functions to add vendor prefixes, saturate colours, etc.

Wrapping up

To recap; by turning the arrows around through using JS and inline styles, almost all opaqueness of regular CSS goes away. Previously difficult tasks such as...
  • renaming a CSS class
  • identifying and removing dead CSS code
  • hitting the correct elements with selectors
  • NOT hitting the wrong elements with selectors
...suddenly become easy or entirely moot.
While there are still a lot of questions to be answered regarding moving CSS to JS space, there's no doubt in my mind that just being able to flip the arrow of responsibility makes it all worth it.
One of the primary downsides of inline JS styles is that we can't use pseudoselectors such as :hover or @media. I hope to show how we can get around that using helper libraries in an upcoming post.
--
David Waller, Edument
Edument AB was founded in 2010 by Acke Salem and Tore Nestenius. They met for the first time at a conference where they began discussing the lack of services in the development sector that included both education and mentoring. Hence the company name stems from EDUcation and MENTorship.

Today Edument has 25 employees and offices in Helsingborg, Malmö, Falkenberg and Prague. We have educated and mentoring thousands of developers around the world. And been awarded "Årets Gasell" by Dagens Industri two years in a row.

Fem anledningar att delta i The Phoenix Project (DevOps-simulering)

  1. Du får öva på kommunikation och tillit
Vad händer om kunden inte vara med och påverka utvecklingen av en tjänst? Eller om test-teamet inte involveras i rätt fas? Vad händer om teknikern gör en ”riskfri” ändring i infrastrukturen?  Konsekvenserna av brister i kommunikation mellan roller och team blir tydliga och kännbara. Deltagarna får chansen att etablera de kommunikationskanaler och metoder som krävs för att kommunikationen ska bli en naturlig del av arbetet.     

  1. Du får med dig handfasta tips på tydlig visualisering av arbetsuppgifter och flöde
”Stop starting, start finishing” är ett mantra för simuleringen. Det viktiga är inte att vara upptagen. Det viktiga är att få rätt uppgifter slutförda. Visualisering av uppgifter, både på team- och individnivå hjälper alla inblandade att skapa tydlighet och fokus. Kanban-tavlor och andra visuella stödverktyg kommer till användning.  

  1. Du lär dig prioritera och exkludera
Få team har för lite att göra. Behovet av att sålla och prioritera uppstår dagligen, både på operativ, taktisk och strategisk nivå. Med stöd av visualisering och kommunikation blir arbetet lättare. Vem är det som ansvarar för prioriteringen? Är det beställaren, produktägaren eller är det kanske hela teamet? Deltagarna får chansen att praktisera agila arbetsmetoder som sprintplanering, demos, feedback.  

  1. Du får öva på att utvärdera och förbättra
Ett nyckelkoncept inom DevOps är feedback. Det blir en framgångsfaktor att bygga in feedback i arbetssättet. Feedback från kund, feedback från team-medlemmar och feedback från testning och infrastruktur. Utifrån insamlad feedback får deltagarna utveckla tjänster såväl som arbetsmetod.

  1. Du får öva på att sprida kompetens och kunskaper
Silo-tänkandets tid är förbi. För att skapa effektiva team krävs att medlemmarna, utöver expertis inom sitt område, även har grundläggande koll på andra arbetsuppgifter som ingår i teamets ansvarsuppgifter. Deltagarna får känna på smärtan som uppstår när det saknas förståelse för varandras uppgifter eller när någon team-medlem plötsligt inte är på plats.  

Nyfiken på mer? Besök vår hemsida här.


Är du vår nästa produktexpert?


Informator har sedan länge arbetat fokuserat kring ett värderingsstyrt arbetssätt och självklart gäller detta även för alla våra partners som håller utbildning för och med oss. På videon ovan berättar vår nordiska produktchef om vilka förväntningar vi har på alla våra kursledare.

Känner du igen dig kring våra förväntningar på en kursledare!? Vi söker självklart alltid nya partners att arbeta med på konsultbasis, men just nu så vill vi även ha nya kollegor som både brinner för att dela med sig av sina kunskaper i lektionssal, men även vill bygga nya produkter inom mjukvaruutveckling och agile och designa leveranser tillsammans med oss.
Läs mer om tjänsterna som produktexpert inom mjukvaruutveckling/agila metoder och ansök snabbt och lätt på LinkedIn

4 Witty Names for Overdoing Things Upfront, and How Much Is “Lagom”?

“We’ve many names for the things we love” is a proverbial phrase (its Swedish equivalent basically swaps “things” for “child”). Which in turn makes me wonder if human nature loves overdoing the upfront spadework and sometimes even prefers it to making things take shape. Contrary to what IT-people tend to believe, IT is not alone in the overdoing trap.


1. Analysis Paralysis
Is often IT-related in some way, but can actually occur even in financial analyses or big-data analytics with unclear objectives. Long story short: YAGNI (You Ain’t Gonna Need It), plus the problem domain changing as you go (and increasingly, being automated).

2. Researchitis
(Excessively researching the background of things,) is common in journalism and other writing professions. In the age of search engines however, it tends to precede most things we do.

3. Blankscreenophobia  
(Fear of a new blank page on the screen,) is both a sequel and an aggravator of number 1. or 2.

4. Writer’s Block
(In Sweden called write-cramp). To extend from writing to drawing, coding, and other tasks: “Brainslump” fits most kinds of work, but has a shorter duration than writer’s block.


Then, how much upfront work is “lagom” (the Swedish for just right, just large enough, sufficient, adequate, not too little not too much)?
The time spent upfront shall be worth less than the benefit it brings about (as our Architecture and Agile Modeling courses point out, see diagram). Estimating that benefit implies some insight into the needs of the recipients/users: do they want it comprehensive - or rather comprehensible, up to date, in sync, and informative? How can it facilitate their work and decisions?

Summing up
Both in Agile and elsewhere, there’s a fine line between unnecessary overhead upfront and building upon the sand. Neither modeling, nor architecture (IT, SW, Product, Enterprise), nor other high-skill work is exempt from the tradeoff.



Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com

main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer),
Advanced UML2 Professional (OCUP cert level 3/3). 

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next few months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715T2716 , mainly in Swedish).
x

Varför når lyssnande ledare bättre resultat?

Som ledare ska du skapa goda förutsättningar för teamets arbete med tydliga ramar och mål. För att prestera på topp måste dina medarbetare ha hög inre motivation. För att dessutom kunna samverka optimalt krävs ett tryggt och bra gruppklimat.



Många ledare känner därför att ”allt” vilar på deras axlar. De tar sig då an uppgiften genom att peppa teamet, kommunicera ut mål och strategier och berätta om sina förväntningar på hur medarbetaren ska agera och leverera.

Men det är faktiskt mer effektivt att göra precis tvärtom och att du istället:
·     -   får medarbetarna själva att berätta vad som motiverar dem att kämpa för att nå resultat.
·     -   inom teamet för dialoger om styrkorna och vad ni vill bli bättre på.
·     -   låter var och en får komma till tals och bidra med sitt perspektiv och att ni andra verkligen lyssnar.

Vi fastnar så ofta i våra invanda tankemönster. Men vi lär vi oss så mycket när vi faktiskt lyssnar, istället för att bara sända vårt eget budskap. De som blir lyssnade på, respektfullt och nyfiket, känner sig dessutom bekräftade, och detta oavsett om vi har samma uppfattning om något eller inte.

Utifrån hur var och en med sitt eget perspektiv ser verkligheten, lär ni av varandras erfarenheter och låter en gemensam bild växa fram. Att förstå varandras synsätt ger aha upplevelser, det ökar gruppens samhörighet och bygger relationer. Förståelse för nuläget ökar också viljan att förändra och förbättra beteenden. Dessutom byggs den psykologiska tryggheten i teamet av
att vars och ens upplevelse av verkligheten accepteras.


Genom att verkligen lyssna på medarbetarna, blir du starkare som ledare. Du lär dig att förstå vad som är viktigt för dem och vad som driver deras inre motivation. Det ger ökad insikt om hur du ska kommunicera för att medarbetarna ska lyssna på ditt budskap och vilja följa dig.

Vill du lära dig en metod för att arbeta på det sättet i ditt eget team?
På Informators endagskurs M1703 Teamwork Gamification – framgångsbeteende med OranginoWork lär du dig ett evidensbaserat spelverktyg. Du blir Diplomerad Teamcoach Orangino Work och får med hela verktygslådan. Sen leder du egna workshops i teamet med hjälp av verktyget, som är kul, enkla att förbereda och ger kraftfulla resultat. Anmäl dig här till nästa kurs som går den 11 december.



Ulla Osterman, Orangino AB's grundare och utvecklare av metodiken Orangino Work, är en av Informators experter inom kommunikation och ledarskap som framgångsrikt drivit förändringsprojekt i organisationer inom offentlig verksamhet och i näringslivet.


Typer

Jag har tänkt en del på typer på sistone. Jag har kommit fram till att jag gillar dem, och att de fortfarande är på uppgång i konventionella programmeringsspråk.

Jag pratar om ord som `int` i nedanstående programsats:

    int sum = 0;

Detta bruk av ordet "typ" är bekant för användare av språk i C-familjen, inklusive Java och C#. I samband med att vi introducerar variabeln `sum` så deklarerar vi också att den ska ha en heltalstyp med en viss storlek. Om inte annat så att kompilatorn ska veta hur den ska allokera variabeln, och vilka operationer den ska tillåta.

"OK", kan läsaren tycka. "Det låter ju rätt uppenbart." Låt oss genast göra saker lite mindre självklara.

Min bakgrund är till stor del med dynamiska språk, som Perl, Python, och JavaScript. I vart och ett av de språken anger man _inte_ typen på en variabel man introducerar:

    my $sum = 0;                 # Perl
    sum = 0                           # Python
    let sum = 0;                                          // JavaScript (ES6)

Med undantag för ytliga skillnader i syntax så gör de språken exakt samma sak i det här fallet: de introducerar variabeln _utan_ att ange att dess typ ska vara `int` (eller något annat, för den delen). Det är lite det vi menar med "dynamiskt språk".



En av de stora säljpunkterna med de dynamiska språken är att man kan skriva kod utan att vara så nitisk med sina typer. Det liksom funkar i alla fall. Den resulterande känslan är luftigare och smidigare; vägen från problem A till lösning B kantas inte av typrelaterade kompileringsfel.

En van användare av C++ eller något annat statiskt typat språk kan mycket väl fråga sig hur de dynamiska språken över huvud taget kan fungera:

Hur vet kompilatorn hur mycket minne den ska allokera om den inte vet vilken typ variabeln ska ha
Vad händer om man försöker lägga en sträng i `sum` senare?
Vad händer om man försöker göra något med en `int` som man i själva verket bara kan göra med strängar, eller arrayer?

Svaret är att kompileringsprocessen mestadels håller sig utanför sådana frågor i dynamiska språk. Variabeln `sum` i sig _har_ inte någon typ. Det är bara värdet (0) som har en typ. Vilket svarar på frågan om vad som skulle hända om man lade en sträng eller något annat i `sum` senare i programmet i ett dynamiskt språk: ingenting särskilt. Det fortsätter att fungera.

På samma sätt fungerar det att inte veta vid kompilering hur mycket minne en variabel kommer att behöva. Allt det hanteras istället under körning. Resultatet blir att vi inte är helt optimala vad gäller prestanda och minnesåtgång i dynamiska språk. Men det betraktas som en acceptabel tradeoff mot att programmet är lättare att skriva och ändra.

Slutligen, om man försöker behandla värdet 0 som en sträng eller en array eller liknande: de två saker som kan hända är

1.      att värdet 0 konverteras implicit till rätt typ innan operationen utförs, eller
2.      att ett fel meddelas vid den punkten under körning.

(Vilken av dessa som händer beror på exakt vilka typer som är inblandade, samt hur tillåtande språket är.) I ingetdera fall får vi en tidig varning under kompilering; vi måste vänta tills någonting faktiskt går fel i programmet för att vi ska märka det.

Det är den här sista punkten jag har tänkt på mycket på sistone. Förespråkare för de statiskt typade språken kan omedelbart peka på detta som en form av vansinne: varför skulle man vilja få fel vid körning som man skulle kunna få vid kompilering? Varför skulle man välja att ens starta ett program som var felaktigt på det sättet? ("Skjut aldrig upp till körning vad du kan göra vid kompilering"...)

Man kan ju svara att program som skrivs i de dynamiska språken ofta är rätt småskaliga: de är inte så långa i antalet rader mätt, och de tar inte så lång tid att köra. Så alla eventuella fel man gör på vägen upptäcker man också rätt snabbt.

Även om det antagandet ofta stämmer, så tror jag att det allt oftare är fel. Idag skrivs storskaliga, ambitiösa, affärskritiska program även i dynamiska språk. Ta PHP hos Facebook som exempel. Eller JavaScript hos i princip vem som helst med frontend-kod. Det är två exempel på språk som gradvis har funnit sig i betydligt större skor än vad de ursprungligen skapades för. När saker skalar upp så blir avsaknaden av statisk typning allt mer kännbar.

Något spännande har dock hänt de senaste åren. Facebook har lanserat Hack, en statiskt typad version av PHP. Microsoft har släppt TypeScript, en statiskt typad version av JavaScript. Båda de här insatserna vinner framgång genom att *behålla* de dynamiska språken som redan har vunnit popularitet, men att i efterhand förse dem med statisk typning. Ofta kan man skriva sin kod som man brukade göra, men där man vill kan man ange en statisk typ, och då kontrolleras den vid kompilering. Det är på många sätt den bästa av två världar: ett dynamiskt språk med statiska drag.

Även Python har på sistone fått statisk typning, via PEP 484 (ett förslag om "Type Hints" i språket) och det externa verktyget `mypy`. Men känslan är lite annorlunda än Hack och TypeScript &mdash; PEP 484 är tydlig med att det _inte_ handlar om att få typfel vid kompilering, utan att det är en sorts API-dokumentation. Riktlinjer, snarare än hårda regler. I slutänden får marknaden avgöra om man vill skriva Python med eller utan typer. Jag ser fram emot att prova med, och känna hur det känns.

Jag gillar tanken på att kunna ha ett dynamiskt språk som inte är i vägen när man skriver små saker, men som också klarar av att stötta upp en med statisk typkontroll när man behöver struktur och skala.

Typer i programmering har en intressant historia. Tre till synes oberoende definitioner har flödat samman till ett enda koncept:

·    Typ som i "datatyp", precis som i `int sum` ovan: representationen av ett värde i minnet. Det bruket går tillbaka till Algol på 60-talet, och är vad de flesta idag menar med ordet. Innan kunde man se ordet "typ" användas på ett vardagligt sätt; i och med Algol börjar det betyda "representation".

·    Typ som i "algebraisk typ" eller "typalgebra": insikten att typer är värden som kan kombineras och manipuleras på olika sätt. `struct` i C är en typisk produkttyp, till exempel, men även `Tuple` i många språk. Det finns typer som `Either` och `Option` som indikerar val av olika slag. Den största påverkan den här traditionen har haft på industrin är nog dock generiska typer: om man har en `String` så kan man också bilda en `List<String>` eller en `Promise<String>`.

·    Typ som i "typteori". På tidigt 1900-tal gick matematiken igenom en kris i sina grundvalar. Bertrand Russell och andra undersökte sätt att undvika paradoxer i formella logiska system; typer blev en möjlig mekanism. Långt senare visade det sig att det finns en bro som överför alla resultat i logik till motsvarande resultat i programmering, och vice versa. Det som man hade kallat typer i matematik är precis det som man kallar typer i programmering.

Vi som industri har rätt bra koll på den första definitionen av typ. Vi får allt bättre förståelse av den andra definitionen. Den tredje har fortfarande inte börjat lämna spår i konventionella språk, men det känns som att det är i den riktningen vi rör oss.

Vi vet inte hur de kommande årtiondens programspråk kommer att se ut, men min gissning är att de kommer att utnyttja statisk typning på alltmer intressanta sätt. Man får mersmak av att skriva program som gör rätt sak första gången man kör dem.







Carl Mäsak 
A developer with a fondness for dynamic languages, evolutionary design, and meaningful unit testing. Likes to heal ailing legacy applications. Designs and implements programming languages in his spare time.


Hela Informators kursutbud inom Webbutveckling hittar du här


Odla kultur – skörda resultat

Kulturen sitter i väggarna.. slitet uttryck men ack så fel. Om det var i väggarna det satt så hade det bara varit att måla om. Kulturen sitter i människorna. Och framförallt relationen mellan människor. Kultur finns överallt där det finns minst två människor. Det är ett hett ämne på agendan och man ser hur pingisbord och flipperspel presenteras som lösningar på dålig kultur och hur man får engagerade medarbetare. Det är svårt att se kulturen, och kan man inte se den så är det ännu svårare att göra något åt den. Det pratas om dåligt ledarskap och oengagerade medarbetare, men handen på hjärtat; ingen vill vara en dålig chef och medarbetare vill vara engagerade på arbetsplatsen. Det är min tes när jag hjälper företag och organisationer som har en kultur som skaver.



Det finns massor av potential i medarbetare och chefer och ofta handlar det bara om att kalibrera om sitt fokus på styrning, ledarskap och kommunikation. Ofta så motverkar de varandra och skickar fel signaler för att man inte ser hur det hänger ihop. Ett tydligt exempel jag ofta ser är att man vill ha kreativa medarbetare samtidigt som man har mobilförbud på möten med syfte att få engagerade medarbetare. Men om man inte ens är betrodd att använda sitt arbetsredskap, mobiltelefonen, så är det inte så högt i tak för misstag och experimenterande vilket är en förutsättning för kreativitet. Man kan inte säga att man vill ha kreativa medarbetare och samtidigt utöva hård styrning i detalj. Det blir ingen kreativ av. För att vara kreativ krävs en tillåtande miljö där det är ok att prova och misslyckas. Det är också en av de stora utmaningarna nu med digitalisering och all ny teknisk utveckling som sker så fort. I arbete med digitalisering i sjukvården så blir det så tydligt hur kulturen är en kritisk del. Att se kulturen för att kunna förtydliga vilka spelregler som gäller vart. Som medborgare och patient så vill vi att en läkare har full tilltro till sin kompetens och förlitar sig på vetenskapen och ska sträva efter att göra rätt i mötet med patienten. Det ligger också helt i linje med den kultur som gäller inom yrkeskåren och yrkesstoltheten. Däremot så behöver samma läkare vara öppen för att göra fel och experimentera inom tydliga ramar när man arbetar med digitalisering för att man ska hitta rätt lösningar. Då utvecklingen går så fort så kan man inte fastna i analyserande utan genom testande av tekniken så når man framsteg – fail forward. Varje misslyckat resultat är ett steg närmare lyckat resultat.

Kulturen anses vara den största felorsaken till att man misslyckas med digitalisering och det kan jag skriva under på. Efter 15 års erfarenhet av förändringsledning av såväl teknisk utveckling, omorganisation, hopslagning av bolag etc så är det en helt ny spelplan nu med fler dimensioner som man behöver ta hänsyn till. De gamla ledarskapsmetoderna räcker inte utan man behöver komplettera med kulturkartläggning för att inte konfundera medarbetare om var man behöver använda vilka spelregler. Pingisborden jag nämnde ovan är bra exempel på något som fungerar inom vissa kulturer men som skulle få helt motsatt effekt inom andra organisationskulturer.
  
Det är en spännande tid vi lever i. Det har aldrig gått så fort som det gör nu, och det kommer aldrig mer gå så långsamt igen. Den ständiga förändringen kommer bli den nya vardagen. Och det går fort, mycket fortare än tidigare, vilket gör att man behöver vara mer snabbrörlig i sina beslut, och även medarbetarna behöver hänga med och ställa om snabbare. Vi behöver ha en tydligare vision och kan inte förlita oss på statiska mål utan snarare förtydliga riktningen som kan ändras när ny kunskap utvecklas. Vi behöver föra en bättre dialog för att snabbare få återkoppling, få in synpunkter och utvärdera för att nå framsteg.

Kommunikation blir viktigare då vi behöver kunna nå fram till mer heterogena målgrupper med olika referensramar då de kommer från olika kulturer, bakgrund etc. När jag hjälper organisationer kartlägga sin kultur tar vi utgångspunkt utifrån deras kontext, var befinner de sig? I vilket land, i vilken marknad, i vilken region och hur påverkar det människors förhållningssätt till beslut, makt, förtroende? Efter att ha arbetat och bott i 14 länder på 5 kontinenter så finns det några kulturella olikheter men också några likheter mellan oss människor och de organisationer vi verkar i. Jag ser varje organisation som ett träd, dvs likt ett träd i skogen så är varje organisation unik. Ett träd tillhör en sort men du hittar inte två likadana björkar i skogen och lika är det med företagen, de verkar i samma bransch men är ändå unika. Vad man producerar i sin organisation kan kopieras men hur man gör det är kulturen och den är unik. De anställda och samarbetspartners som bidrar till utvecklingen är snarare som blommor som växer runt trädet, om de vill. Dvs en blomma kan välja att växa nära ett träd om det mår bra av det och det är viktigare för organisationer i allmänhet att förstå att det är medarbetarna som väljer var de vill vara. Så gör det enkelt att välja, såväl för medarbetare som för kunder.

Gör det enkelt för de att välja att arbeta hos er, att sluta avtal med er för att det är tydligt vad ni står för och att ni är äkta i att ni lever som ni lär. Transparensen blir större och större och därför kan man inte ha fina värdeord på väggarna om man inte lever de. Det blir för stort glapp mellan varumärke och den inre kulturen, och oäkta är ingen vinstlott. Då kan de anställda bli varumärkesmarodörer istället för ambassadörer. Om medarbetarna mår bra så mår företaget bra, och för att växa i rätt riktning behöver ledningen vara tydlig med sin riktning, varför finns man och vad är viktigt?



När vi köpte hus för några år sedan så fanns det en stor trädgård och jag såg fram emot att se vad som växte upp. Men jag såg inte skillnad på ogräs och det som var planterat, för mig var allt grönt och växte. Jag bad en trädgårdsdesigner komma över och under några timmar gick hon igenom hela trädgården med mig. Den här passar bättre i skuggan och den här kan du dela på så trivs de bättre om de får mer luft runt sig. De här ska du vara noga med, trots att de har fina vita blommor så är det ogräs som tar över trädgården om du inte håller efter. Och med en sån liten insats kunde jag dra nytta av de växter som redan fanns i trädgården  men som behövde förändrade förutsättningar för att trivas. Det här är väldigt likt kulturen i företag, den finns och gror vare sig du odlar den eller inte. Och när den väl finns där så är den stark och bildar sin egen motståndskraft mot förändringar. Kulturen är ett resultat av samspelet mellan styrning, ledarskap och kommunikation och ibland kan det vara svårt att se när man är mitt i den. 

Hur ser det ut hos er? Hänger er kultur ihop med hur ni kommunicerar ert varumärke utåt med värderingar, vision etc. Hur arbetar man när inte chefen tittar på? Hur når medarbetarna? Är de stolta och lojala? I en fruktsam kultur har man högre produktivitet, lägre sjukfrånvaro och nöjdare kunder då medarbetarna gärna gör det där lilla extra. Personalomsättningen minskar och man får en mer generös kultur där man hjälps åt vilket får positiva bieffekter i att personalen själva arbetar för ett effektivare arbetssätt när man får ett tydligare strategiskt kundperspektiv. Ofta när man gör en kulturkartläggning så inser man att man gör mycket bra och att det är så lite kalibrering som behövs för att förstärka de positiva beteenden som faktiskt finns redan på vissa ställen i organisationen och ta bort motsägelsefulla förutsättningar som motverkar visionen. När man gjort en kulturkartläggning så man ser hur det hänger ihop så får man en ny syn på hur man arbetar med styrning, ledarskap och kommunikation då man ser konsekvenser och effekter tydligare.


Några vanliga orsaker till problem med kulturen är ofta att man bytt ut ledningen, gjort en större förändring utan att tagit hänsyn till kulturen tex ihopslagning, ändrad strategi utan förankring hos medarbetarna. Det har blivit ett glapp mellan hur man arbetat tidigare till vad som förväntas framåt och det har inte kommunicerats så det börjar skava. Men när man belyser det, sätter ord på det så kan man se samband och vad som är grundorsak och vad som är konsekvens istället för att bara sätta plåster på situationen så kan man ta itu med grundorsaken. Det är enkelt men inte lätt.

Under kursen M1717 Organisationsutveckling - kultur som framgångsfaktor får du arbeta fram en handlingsplan för den egna kulturen med förbättringspotential och prova på olika verktyg och metoder. Läs mer om kursen här





Mia Liljeberg
Är en av Informators experter inom Ledarskap och företagskultur och håller kurserna M1717 Organisationsutveckling - kultur som framgångsfaktor och M1723 Processkartläggning - effektiv processutveckling