I’ve just (October 21 2015) got news that my latest course for PluralSight is published.

Find it here.

This time I took the opportunity to put together a course on using npm (Node Package Manager) as a build tool. I think it makes for a very lightweight and flexible option for any JavaScript (or front-end heavy btw) project.

As you might know I’ve written a couple of posts on the topic:

• npm scripting: git, version and deploy
• npm scripting: configs and arguments… and some more tricks
• Pre and Post hooks for npm scripting

The #NoEstimates movement have lived a turbulent life on twitter. I guess that happens when you present ideas that challenges how we, as a collective, view the world today.

What’s funny is that after awhile, when the dust settles, it seems so natural and you ask yourself; “well, what was the fuzz about”. This is when the idea has got traction and maybe some of the early rough edges has been rubbed off.

My friend Tobbe puts it nicely;

I beleive #NoEstimates is a transient conversation, when dust settles it will be simply how we now view estimation, in a slightly new light.

— Tobbe Gyllebring (@drunkcod) October 6, 2015

One of those moments I think is when someone decides to write something (substantial) down to present compelling, practical, solutions to some of the discussions that’s been had so...

At my current client, the hospital RS Bungsu in Bandung, we are working a lot with metrics and visualizations. This has proven to have a profound effect in interest, focus and understanding for the entire staff.

During the last years a couple of “rules” (I’ll come back to the quote marks soon) has established itself. Based on our experience and feedback we have come up with a few guidelines that helps us to do better metrics and visualizations of them.

In this post I wanted to share our current set of “rules”. Hopefully this will be helpful to you and maybe even you can share your guidelines with me.

“This works for us” (™), “Your millage might vary” (™) and “Please see past the practice and look for principle that you might find useful in your setting” (™). All of those applies to this post.

These are more like...

I’ve seen many people change into something better over my years as a consultant. It’s a beautiful thing - but I’ve never experienced something like that I witnessed today.

I was a small, small part of that change and I wanted to share the story with you. It’s a powerful testament to what capabilities live in each human being that can be released if given the right circumstances and room.

Ibu Elsye

This is Ibu Elsye (lady dressed in black in the picture) or Mrs. Elsye for you westerners.

She’s General Manager of a hospital, Rumah Sakit Bungsu, that I’m helping, here in Indonesia. General Manager; what is that, in a hospital - is a very natural question to ask. Basically, she’s in charge of everything that is not health care. Food, laundry, maintenance, security staff, drivers … you name it.

If...

This is just a short post on a (in the western world) well-known topic. I think I read it first in Switch

People doesn't oppose change. People opposed being changed

Or maybe with more details, if you make a change without a compelling reason for doing so the change management will be uphill from day one.

I’ve mostly been the changer in this, but recently I was the person being changed (the changee?) and I wanted to share my experience and thoughts. So that I, at least, never ever does this again.

You are happy to meet me among the living. The error I’m describing nearly killed me with frustration, and if that didn’t happen I was about to help it by finish myself off.

No worries though - I found the solution. Hence I’m alive and can tell the story.

This is the error, that haunted me into the wee hours of the night, in all it’s glory:

1) Uncaught error outside test suite: Uncaught Error: listen EADDRINUSE :::3000 at Object.exports._errnoException (util.js:837:11) at exports._exceptionWithHostPort (util.js:860:20) at Server._listen2 (net.js:1231:14) at listen (net.js:1267:10) at Server.listen (net.js:1363:5) at Application.app.listen (node_modules/koa/lib/application.js:70:24) at Object.<anonymous> (index.js:10:5) at Object.<anonymous> (test/site.spec.js:1:73) at Array.forEach (native) at StatWatcher._handle.onchange (fs.js:1285:10) 

I got that error from mocha when watching my tests with the --watch flag. But only when I ran that watching command as a npm script from package.json. Yeah, it...

This is my second attempt to write this post. It’s not that the post itself is hard to write but the concept makes my head … go ouchie. That tend to happen to my head when I see potential quantum leaps.

Instead of the fancy intro I had planned, I’m just going to give a short introduction, point you to an awesome article, tell you how to get this to run.

So what is it then? Basically runtimejs is a tiny, unikernel OS that you can bundle together with your application, as a dependency to your application. Which is basically what a OS is, right? Our application needs some libraries like koa, a runtime-platform (like Node) and an OS (like Linux) that the platform can run.

What if that last part just was a dependency like normal to our application? Like this:

The other week, we put up a thick rope to use as a liana, al á Tarzan, for our kids. Extremely simple; just a rope, and I made a big tangled knot at the end. You can see my kids using it in the picture to the left. They loved it.

Then one day, one of our neighbors, who often helps us and stops by - nice people, came by. He looked at the rope, saw my kids struggling to climb it, and said:

“You know… it should really have a plank or something at the end so it’s easier for them to stand on.”

I said, “Nah… this is good enough for them. They are enjoying themselves plenty.”

Two days later…

This is a post on coaching, asking before helping, and not improving things that work fine.

Read More

Today I had a session with the management group of one of our hospitals. We ended up talking about how to choose what we’re going to do next. Questions like; “but how can we know what is best”, “there’s so many things to do” or “everyone have a different opinion” were discussed during and after the meeting.

I was reminded of a tip from a colleague and (to me) mentor from way back, Lars Littorin. I was complaining about so many things to do, not knowing where to start etc. His answer:

Great! Then you know exactly what to do; make a list of the things you need to do, and then start doing one of them.

There’s much truth in there. I think Lars is a great guy, but I doubt he knew how much use I have had from this single quote. Maybe, just maybe, he doesn’t...

Got a recommendation to read Nature by Ron Jeffries and I did. What a read! I loved it from the get go.

My short review is quite simply;

“This book made me think. It left me with more questions than I had going in. But better more concrete questions. Seeking simple(r) answers. Also it’s sprinkled with challenges and gentle provocations of the current state of mind and process.

The underlying principle ‘Simplify it’ is something that resonate very deeply with me. I recommend anyone doing, struggling to do or thinking about doing this thing we call ‘agile’ to read this book.

And then give a copy to every important person in your organization.

Thank you for a great read!”