I'm the CTO of a small analytics platform startup called 

. Previously I've worked as a senior consultant in 

. Technology and specifically anything related to the internet matters a big deal to me, but when I log off I have a small family with a baby girl 👶 and a husky 🐾. Some times I publish some open source software and some rare times I blog on this space or Medium.com.

Raymond Julin | Technology and thoughts

Design is a hotter subject than ever before. Apple is the most successful company in history, fuelled by design, and the subsequent “design thinking” philosophy.
The concept of “design” is far too important to be left to just the designer.

The design practice is often misunderstood. Many of our clients contact us because they want a UX revamp or some design touches on their applications, websites or other visual properties.
It is often assumed that the visual expression created five years ago is a replaceable skin with few ties into the underlying processes. This is a misunderstanding.

This belief has little grasp in reality. Design is not the act of painting, or picking, pretty colours on a house, an application, a brochure or a website.The act of design stretches from the top to the very bottom of everything you do as a team, as a company.

Design is an activity equally dependant on you — on everyone. Design is in everything, and design is a process used by people you would never label as designers.
Would you consider Elon Musk, the CEO of SpaceX and Tesla, a designer?What about the engineer that elaborately places electronic components onto a breadboard?

These are outlier examples, but they exemplify how our current idea of what a designer is, and isn’t, is broken. What we need is a better way to think and talk about design.

In the new market where segments converge and old distinctions as business-to-consumer / business-to-business are made irrelevant, design moves from being merely a procedural step in the work process to the very core methodology of all work.

Design is the process of deliberate planning and production of a system.

You cannot afford not to be a designer any more.
You cannot afford to hire an employee who doesn’t design.

I would argue that most of our clients are in dire need of changing into design-driven organisations, and we are often merely hired to help bridging the gap between them and the markets expectations. Putting lipstick on a pig. In order for our clients to catch up they need to internalise this mindset. It’s not something that can be patched up properly from the outside.

If your organisation’s success relies on selling an application, you’ll need your product managers, your customer liaisons, your system developers, your CTO and your CEO to be designers!

The CEO and CTO need to think in terms of design for every choice they make. Either they operate under false protection of a good revenue stream, or they are under pressure to resurface a sinking ship.

The customer liaison need to be a designer in order to transfer the customer domain knowledge and feedback into valuable design parameters for the further product development.
The system developers can not implement a design-driven system if they themselves does not speak design. Every micro interaction, every path a background process takes is part of the overall design that makes up the sum of the product.

The product managers need to think in terms of design in order to make the right choices for the product to compete in a market that is increasingly driven by design.

In fact, it’s very likely that you will need to redo the entire organisation chart as well.
Design-driven organisations need interdisciplinary teams to function properly. Departments cannot be split into silos anymore.

The informed reader have perhaps noticed that all of this sounds an awful like digital strategy. In fact, any strategy for business digitalization requires a shift in mindset towards that of the design thinker. It could be argued that this bloats the role of the designer and makes the title useless because it’s sounds all-encompassing, but this fuzziness is part of the digitalization shift.

When the entire organisation morph into “designers”, what happen to those with that job description in the first place? Are they out of business? Given that design is now even more important, their jobs also got more crucial. And the fact that the rest of the organisation are learning to design, the designers both have a big role in teaching how to think in design, and also to mediate the design processes.
Some designers might find it hard to open up and share the creative processes. They might feel they are giving up control of something that is “theirs”. As with any transformation there will be growing pains and frustrations, but these will be symptoms of the existing knowledge gap.

— There will be a personal computer on every desk running Microsoft software.
Bill Gates, Microsoft

In order to create exceptional products and services — which should be the aim of every company — one of the most important tools will be a shared vision of the future. We are not talking about the mumbo jumbo vision you already have. The vision needs to be a shared understanding of an attainable purpose, and the uniqueness you will possess that make you stand out amongst the crowd. It has to become a compass that guides you in making sure everyone pulls in the same direction.

A shared vision is a synthesis weaved together from conversations, discussions and analyses of the decisions you make as an organization. You need to drill the way of thinking so that every employee is comfortable that when making micro decisions, they choose the option that moves towards the shared vision of the future.
Building this intuitive shared mindset is the biggest investment you have to make. It’s important to not have a fixed idea at the beginning of this process, because the process itself is what shapes the end result.

The next time you consider purchasing a design project, or employing a designer, take a look at yourself — your organisation — and ask if that is what you actually need. And ask yourself if “just hiring a designer” is actually going to be the solution to your problem. The answer is very likely to be a solid no. At least not by itself.
The next time you consider purchasing a design project, you should reevaluate your expected outcome of the project. You should reevaluate how you approach the project, what types of people you allocate to it, and if your project team has the mandate to affect your organisation in a substantial way.
The next time you purchase a design project you should give it the attention and headroom it needs in order to reshape your organisation to better solve real problems.
And if you are a designer, rejoice, the next time you are hired it will probably be with more responsibility and more understanding for your expertise.

http://iallenkelhet.no/2015/10/20/kill-the-designer/

Kill the designer

There are two approaches to handling asynchronous control flow in JavaScript at the moment: Callbacks and Promises. Node.js core APIs, and thus most things written for Node, are callback based. I’m not claiming that callbacks should never used, but I believe Promises simply are a better solution to the same problem. Whereas callbacks are “the simplest solution that would work”, Promises is a thought-out solid solution that, we will see, don’t break your code!

Node.js core APIs uses callbacks to allow your to write code that executes after an I/O operation is either finished or erred. The case for callbacks is that adhering to Node.js APIs brings familiarity for other developers. The function(err, data) pattern will not raise eyebrows for other JavaScript developers. The case against callbacks is that they break the exception system, it brings 

 it requires you to write your functions wholly differently that you’d do if they weren’t async. 

argument? And they even break language (any language) standards such as Exceptions!

The Callback Hell argument is weak as there is nothing in the pattern forcing you to write ten levels of callbacks nested as anonymous functions inline, but the pattern does make it easy for you as a developer to do so.

Promises is a coming ECMAScript 6 specification that’s extracted from open source libraries providing this functional approach to solving control flow for async code. The concept behind promises is that when returning a Promise you are returning an object that promises to either successfully resolve with a value or to reject with a reason.

referring to one of the most important parts of the specification stating that every Promise must have a method 

that takes one or two functions as arguments, a resolvedHandler and a rejectedHandler. Every such handler must then return a new Promise — often handled by the library for you as well — thus achieving chaining: 

promiseMe().then().then().then(resolved).

Some of the important benefits promises brings to the callback-table are that they

… don’t force me to rewrite all of my code

The nice thing about promises is that they don’t interfere with a functions arguments but rather strictly adheres to arguments as input and return values as output. Callbacks are notoriously bad because they conflate inputs and outputs for a function. Promises are also interchangeable so instead of passing a callback 5 levels deeper you can just return the promise in every function — even changing it on the way — before you grab it from the entry point.

It is true that some code at some point has to change to create the promises, but most changes can be kept at wrapping function calls.

Promises are composable so you can achieve g(f(x)), an impossible feat using callbacks. The syntax changes so this isn’t perfect either, but supporting square(square(2)) would require more cruft in the square function.

Lets compare this with how we would solve this out of the box with callbacks:

Lets take the Promise composition example and adapt it to use an existing sync square method to prove that we can wrap existing code into promises/thenables:

Promises correctly bubbles exception upwards, aligning Promise based code with its synchronous counterpart. Look at this callback implementation, it’s obviously convoluted and brittle:

Promises uses plain normal exceptions for its error handling, meaning we automatically can work with built-ins like JSON.parse in this example.

Unfortunately we need to fight Node.js when going pure Promises. It introduces some complexity but promises libraries help us out with wrapper methods:

I’m in a romantic relationship with async.js

You’re in luck! Most things you thought async kicked ass at, Promises pretty much one-ups! Lets take something a little “complex” — the 

example for async.js and the same written using Promises:

Having said so, async.js is still an awesome library with a ton of great control flow helpers.

This used to be a valid argument but with the Bluebird Promise library the arguments moot. 

Gorgi Kosev shared an analysis of async patterns where Bluebird is almost as fast as plain callbacks

, and over twice as fast as async.js. The same is the case for memory usage.

There’s a lot of Promises implementations popping up, but I will recommend three concrete ones:

 — One of the older and more mature libraries. Heavily used and feature rich

 — My favourite library. Unmatched performance

I would also recommend you to learn more from people smarter than me who has written about Promises:

Gorgi Kosev — Why I am switching to promises

Domenic Denicola — You’re Missing the Point of Promises

Jake Archibald — JavaScript Promises – There and back again

Matt Greer — JavaScript Promises … In Wicked Detail

Writing solid asynchronous code using Promises

Hackers, makers and doers. These are the three kinds of people that makes this world an interesting place to be. We need to pay more hommage to the people that go into the world, day by day, and hacks it, makes it newer and does it better. If you are one of the amazing people that wake up and makes shit better then this is my salute to you! And if you don’t do this but feel like you should, then this is my call out to you to drop what you’re doing and get started!

I’m sitting in bed typing this after 3 great days at the 

. I’ve been inspired by my peers, I’ve had fruitful discussions and I’ve learnt new shit. But most of all I’ve witnessed people that get up and put an honest attempt into improving something, and for me that has to be the true motivation behind every person that makes a difference in moving some part of our existence forward.

Theres a saying that “If you are the smartest person in the room, you’re in the wrong room”, a saying we all should try damn hard to make sure doesn’t become true. Hackers, makers and doers are people that helps prevent this. By seeing how someone makes some tiny part of the world better by sheer will, and some smarts, should serve as a slap in the face unless you are pulling your part.

By now you might think this has anything to do with programming or something geeky, well your damn wrong. Hacking, making and doing applies to everything! If you feel something is broken go out into the world and fix it!

If you are not a hacker, maker or doer, either become one or ensure you at least don’t ever stand in the way of one!

👋🏼 I'm Raymond.

Featured blog posts

Kill the designer

Writing solid asynchronous code using Promises

Hackers, makers and doers