Skip to content

Posts by olavea

A Story About Stats on Your Pretend Personal Dev Blog

February 15th, 2021

olavea

We’ll pretend you are doing some GatsbyJS-style work on your personal dev blog. And we’ll pretend you ask yourself:

«Self, what would happen if you stopped collecting gobs of personal data about your dev friends with google analytics?»

Let’s say you installed Benedicte’s Fathom Plugin. Then you could open a single Fathom dashboard and at a glance see your top content.

«Pop! Pop!»

Into your head pops two good ideas for blog posts. You decide to go with Idea Number One, because you just FEEL Idea Number One is a better idea for your dev friends. Your gut feeling is based on stats because your top content is right before your eyes and this new Idea Number One «rhymes» with som of it.

Why don’t you take Benedicte’s Fathom Plugin for a spin around your dev blog and see if it gives you clarity?

This next story is aaalmost without pretend in it.

A Story About Benedicte Using Fathom To Focus on Her Real Work And Not Being Distracted By Distracting Data

This time I will tell you a story aaalmost without pretend in it. A story about developer-Benedicte using her own Fathom Plugin and I will tell you in advance what the pretend part is. This story is based on a real website. The website has a real product, POW! the bleh bleh. The product has real customers. Pretend Alert! I will give one of the real customers a fake identity, because …. reasons. The fake identity is Princess Lizabeth (17), I hope you can handle a little sprinkle of glittery royalty 👑. 😺 If so, let’s go!


### A Long Time Ago,
### By a Bridge Far, Far Away ….

Princess Lizabeth (17) is sunning her white face and red hair on the pink deck of her sister smart little ship. Lizabeth is writing away in her end-to-end encrypted journal mostly about her menstrual cycles. But she is also writing about toxic relationships, like her hateful sister Mary. Now dear reader, instead of going into these powerfully personal details, I will urge you to ask yourself ONE question about data.

#### Question 1:
«Self, how much data is being reported back to developer-Benedicte by Fathom about Princess Lizabeth’s current writing activity?»

#### Answer 1:
«Nothing.»

#### Question 2:
«Nothing?»

#### Answer 2:
«Nothing.»

And nothing is Just Enough, because.

#### Question 3:
«What »

Did Han Zapier Zap First?

January 18th, 2021

olavea

A is for zAp

B is Brew

C is Call for Glide from your Zap

D is «Did Han Zap First?»

E

F

D is «Did Han Zap First?»

Zap-3_D is «Did Han Zap First?»_MAKE_A_ZAP-3-1
Zap-3._Lager_1_Zap_oversikt-3-14

1.1

Zap-D_MAKE_A_ZAP_Choose_app-3-2

1.3

Zap-D.1.3_Trigger_Event-3-3

1.4

Zap-D.1.4_Choose_Account_Size631x446-3-4

1.5

Zap-D.1.5_Test Trigger_Size_631x446-3-6

How I Prepared To Get A Badass Code Review On My Dotenv Variables

January 13th, 2021

olavea

A cat talking on the phone

My 13 Step Badass Code Review Method For Junior Devs

  1. I invite Tom Erik to choose 1 of 2 times for a code review
  2. I prepare
  3. I remind Tom Erik «code review 10:30» on SMS
  4. I call Tom Erik on the telephone
  5. I listen up!
  6. I takes notes
  7. I ship my website in SMS link
  8. I show my code in a shared screen link, using https://whereby.com/
  9. I explain to Tom Erik what I did with dotenv 😺
  10. I say “Tell me what to do”
  11. I do EVERYTHING Tom Erik suggest I do, right NOW 🔨
  12. I say “Thank you” with feeling ❤️
  13. I make SketchNotes from my Tom Erik notes, Right now for 90 minutes.

2. I Prepare By Practicing

«Help I need dotenv?» I said. «What’s up?» Tom Erik said.
And as Merlin said: «Code review badassery favours the prepared junior dev.»

The other day I called up Tom Erik and asked him to review my code. The way I had prepared was according to my father’s rule of thumb about asking for chores to be done on his traditional Norwegian wooden sail ship with a crew of girls and boys, where I spent a few weeks every summer growing up. My father was the captain and owner of the ship and he said to all of us:

«Look. See what needs doing, do the work, then ask me to check your work. Don’t ask me what shall I do now? Don’t ask me how do I do this? On my ship you learn from doing, not from listening.»

So in preparation I try coding and re-coding on the problem I have decided to solve. I spread this out over several days, because daily practice works best for me. I focus on practicing the steps again and again, so that when Tom Erik asked me to do a thing in the code review, it was easier for me to understand what to do. And then I did what he asked me, I  «live coded» Tom Eriks ideas. For example in the code review Tom Erik asks me to:

«Try pasting the key right into gatsby-config.»

«Ok.» I say and do it right then and there.

A cat talking on the phone
Because I was prepared «Ok, I’ll try that NOW!»

9. I explain to Tom Erik what I did with dotenv 😺

bleh bleh

10. I say “Tell me what to do”

11. I do EVERYTHING Tom Erik suggest I do, right NOW 🔨

mkl
bleh

12. I say “Thank you” with feeling ❤️

13. I make SketchNotes from my Tom Erik notes, Right now for 90 minutes.

You see them here as images 😺👍

Do you have a story about a code review? Badassed or not I want to hear your story, so please send me an email at

ola 🐘 olavea.com

How I Prepped To Get A Badass Code Review On My .env File

January 9th, 2021

olavea

First we’ll look at the tasks I did in 8 steps, then we’ll look at why and when I do Code Reviews in our indie hacker webapp and in my programming play projects. My main inspiration comes from observing my father captaining his traditional Norwegian wooden sail ship with a crew of girls and boys, in the summers of my boyhood and early manhood. That is why I call it:

Skipper-Ola’s Code Review Tasks

  1. Prepares 
  2. Calls Tom Erik
  3. Listens up!
  4. Takes notes
  5. Ships my website in SMS link
  6. Says “Tell me what you are doing” 
  7. Shows my code in shared screen link
  8. Explains what I did with .env
  9. Do EVERYTHING Tom Erik suggest I do, right now
  10. Says “Thank you”
  11. Makes Tom Erik SketchNotes from notes, Right now for 90 minutes

8. is the most important to spend time on. I spent 90 minutes on 8 and 90 minutes on the other seven.

The point of this kind of usability testing is clarity. To make the 1-Job-Prototype clear for the one tester I am testing on, Martin G. So that Martin G. can go in, do the 1 job he is supposed to do without becoming distracted. And that is hard. It is suuuper hard to make a prototype that is easy-to-use. (

What Are the Eight Tasks of Usability Testing?

Let’s go to 1. Prepares.

1. Prepares 

Skipper-Ola’s Preparation Tasks For Usability Testing:

  • Sends warning to Martin G.
  • Finds two test dates.
  • Invites Martin G.
  • Writes a short script.
  • Tests 1-Job-Prototype on his own iPhone. (17:46)
  • Reminds Martin G.

2. Calls Martin G.

  • Calls
  • Smalltalks
  • “Are you alone?”
  • ” … and put your headset on.”

3. Listens Up!

  • Hearing accurate input
  • Listens actively
  • Gives UNDIVIDED attention
  • Immerses his mind in:
    • Voice and silences
    • Noises like a low “Grrrh!”

4. Takes Notes

Shuts up and writes down

5. Ships my prototype

  • I send SMS with a link to Marita’s prototype
  • “Did you click that SMS link?”

6. “Tell Me What You Are Doing.”

  • “I will read my script.”

7. Says “Thank You!”

  • Martin G. knows: VERY Valuable

8. Re-Works My Martin-G.-Notes

I sit and observe my thoughts on:

  • What Martin G. did
  • Remove:
    • Choices.
    • Distractions.
  • Make my 1-Job clearer for Martin G.

First thing: for 90 minutes:

  • I re-work my notes.
  • I capture fresh ideas.
  • I see my next task, so:

TODO: First find two good testing dates in your calendar

Why Usability Testing?

Benedicte has limited time and treasure.

So without doing usability testing timely, Benedicte cannot build to DONE. (See upcoming blog post on how I define DONE.)

Because nothing beats a real human trying to use Benedicte’s 1-Job-Prototype. To flush out ideas that don’t work.

When To Do Usability Testing?

  • As
  • Soon
  • As humanly
  • Possible

Feel Ready?

Six Benefits I Got From Making My Switch Statement Playfuller

December 20th, 2020

olavea

While I was working on the new «welcome thingy» for new customers in our GatsbyJS app, I asked myself:

«Self, how do I make my switch statement playfuller?»

Because to better remember new JavaScript things I learn, I try to practice in a playfuller way every day 😺.

But before I tell you The Long Story I will jump straight to the benefits to my family and our indie hacked GatsbyJS app from using this excellent tip from the great and powerful Josh W. Comeau. 

Six Benefits For My Family From Making My Switch Statement Playfuller

  1. I got to draw parrots 🦜 and
  2. I got to ask Lillian (5.5 🦄 ) to colour those parrots with her new colouring pens. Why parrots? Look further below 🔽 in the The Long Story.
  3. It saved me programming work. Less code = less bugs 🐛 🦋🐌 🐜 🐝 🦗 🕷️ 🕸️ at least for me 😺
  4. It saved my boss programming work. 😺
  5. The final switch statement made my variable safe from bleeding outside of her snug little case. Better safe than sorry, as my father Captain Vea said.
  6. (Coming soon. This blog-post is still just a draft.)

Send Me YOUR Playfuller Practice Tip

I always look for one more way to practice playfuller, mail me your tip for playfuller programming practice ola 🐘 olavea.com

Ok, let’s go! I are now entering the start of The Long Story.

A long time ago, on a bridge
far, far away ….

DevOla took his first sip of dark coffee and opened issue #182 in the pow-app repo on github. Then he opened the Welcome.js file in VS Code and after ONE look he played with this idea:

I will make my switch statement 🦄 unicorny better by wrapping each case with {}

I will make my switch statement unicorny 🦄 better by wrapping each case with {} or squgglies as Josh W. Comeau calls them. But where I come from we say squigglies are hungry twin parrots squaking  «Mine! Mine!» like the gulls in Nemo. 🐠

Hungry Twin Parrots = squigglies as @JoshWComeau calls {}