Local and global

The opposite of “local” is “global”. Many lean and kanban enthusiasts, myself included, look down on individuals and teams trying to improve their efficiency, calling it “local optima”. The answer is to instead look at optimising the whole, but that whole tends to be at a company or organisation level. Even if the organisation is a huge multinational one, it’s not global. Just because you’re taking a few steps back doesn’t mean you’re seeing the whole picture.

As far as I understand (and I don’t understand much) systems thinking seems to be confined within the system of producing and manufacturing. It doesn’t take into account the environment, the poverty and suffering of millions of people, or what the world will look like three generations from now. To me it seems like it’s not “systems thinking” as much as it is “a system thinking”.

These are things we rarely discuss in the tech community, but I think we should. We live in the golden age of IT. We can create enormous value out of ideas, a bit of electricity and a few thousand keyboard strokes.

Problem solving can never be morally neutral. What did you disregard to solve problems today?

Philosophy for the software engineer

The weekend is here. You now have the time to sit back and think about what you are doing with your life. How much of your time is spent pondering this important question?

“The man who has no tincture of philosophy goes through life imprisoned in the prejudices derived from common sense, from the habitual beliefs of his age or his nation, and from convictions which have grown up in his mind without the co-operation or consent of his deliberate reason. To such a man the world tends to become definite, finite, obvious; common objects rouse no questions, and unfamiliar possibilities are contemptuously rejected.”

- Bertrand Russell, The Value of Philosophy

The reason why I’m asking is because you have this remarkable skill that nearly everyone wants to put to use in their organisations. But so much of our potential is wasted on work that, in my mind, doesn’t make the world a better place.

“The best minds of my generation are thinking about how to make people click ads”

- Jeff Hammerbacher

“To be true to yourself, in this problem-resolving business, you must consider moral questions before you get close to a solution, or even a definition, and thereby begin to lose your sensibility”

- Gerald M Weinberg and Donald C. Gause, Are Your Lights On?

As a software engineer, you have a unique possibility of creating something out of pure thought. Of going almost anywhere and doing almost anything you want. Are you?

We should all just decide on JavaScript and solve the interesting problems instead

Our endless bickering over the merits of different languages and paradigms isn’t all that productive, nor is it very interesting. You’re not a Ruby/C#/Java/Elixir developer, you’re a goddamn problem solver. Remove the programming language from your LinkedIn/Twitter bio, that’s not who you are.

All the things that make other languages and platforms more or less sexy are 90 % community and culture. All the loudmouths in the developer community hype things that aren’t “enterprise”. So only 10 % of the sexiness is the actual language*. And the goods news are that we humans can change culture, that’s what we do best when we really want to.

* except for Ruby of course, it is so beautiful. But I digress…

The time is right

We’re now at the stage when JavaScript is hugely popular and a lot of innovation is taking place in that community. Also, it’s a pretty open language, i.e. it’s not owned by Oracle, Microsoft or IBM. We have the chance of running the same language on the front-end and the back-end. Heck, you can even use it as an officially supported language to write FirefoxOS, Ubuntu Touch and Windows 8 desktop/phone apps.

Easier to find developers, easier to find a job

When the language barrier is removed, you can choose look for the things that matter in potential recruits and employers. Like cultural fits/misfits and interesting problem domains. You know, the hard stuff. It’s not automatically good just because it mentions “Scala”, “F#” or “Objective C” (or “agile”, “XP” or “kanban” for that matter).

It’s a pretty good language

Yeah, I don’t love JavaScript. It’s decent. To me, as a Swede, JavaScript feels like English. I don’t love it, but it’s the de facto business language in many parts of the world. Even though I could probably express myself much more poetically and succinctly in Swedish, the benefits of talking the same language as millions and millions of other people far outweighs that.

“The downsides?” you ask

Sure, there are no silver bullets, just a bunch of trade-offs. Here are a few:

You can’t easily talk about every problem in one language

Whenever I try to explain the small cultural differences between Australia and Sweden, like the concepts of “lagom”, “fika” and “allemansrätten”, I struggle with coming up with English words that do them justice. But most of us don’t need to understand those tiny concepts, they only affect 9 million out of the 7 billion people of this world.

Much in the same way, most developers I meet to aren’t solving very exotic technical problems. They’re solving business problems, like:

  • understanding what is the most important next step for you
  • figuring what your customers might need
  • deciding on what you need to say no to in order to survive as a business

I think that for the most of us, JavaScript is good enough to solve these problems.

JavaScript is becoming fragmented

Now that CoffeeScript is a real language (and ClojureScript is trying to become one), that adds a few weird jazzy chords and beats my “one language to rule them all” tune. But maybe having JavaScript as a common platform is almost as good as having it as the only language.

What about multi-core? Parallelism? Concurrency?

I don’t know yet, we’re still not sure how to approach this problem. Some people use Clojure, Java or Erlang to run all cores at full utilisation. Some just throw a bunch of cloud servers at it. Some find that all the latency comes from the database calls anyway.

A bit of non-blocking here and callbacks there doesn’t make this problem go away. But it is certainly not beyond the realms of possibility that we could solve this problem with JavaScript.

As always, the pendulum keeps swinging

Like so many other things, fads in IT go in 10-20-30 year cycles. In the 90′s we all hoped for Java, then the polyglot/NoSQL movement came along. We might be ready for another round of badmouthing the language and platform fragmentation. I just hope that we get together and solve the hard problems instead of declaring our geeky love for things that don’t really matter.


Editor wars. Ugh.

Yesterday I noticed that the “Sublime Text 3 Public Beta” link was on the front page of Hacker News. And now, 21 hours later, it is still there, 226 comments and all. I know we love our tools, but sometimes all the energy and time put into editor discussions dishearten me.

Arguing that an editor makes a big difference to productivity feels a bit like choosing your commuter car based on how well that model performed in the World Rally Championships. Sure, it might be fast, but was that the right kind of fast? Would you have gotten to the office faster buy having a standard car but with a GPS, so that you didn’t take any wrong turns? Or is speed not the matter, should you perhaps carpool to save money instead? Or can you take the train and do some work from there, while traveling? Or should you work from home instead, freeing more time to be with your family and/or friends?

You can type faster with an editor that you like and know more. But does it make you think better? Be more creative? Collaborate better with your teammates? Understand the user requirements better?

That being said, I do love using Sublime. Mainly because it looks good, and tools that look good make me happy.

RubyKaigi 2013 – great conference, but I probably wouldn’t go next year if I was a woman

RubyKaigi 2013 is over and it has been a very positive experience for me, I applaud the organizers and the attendees. But one incident left a bad taste in my mouth.

During a presentation, the speaker mentioned that he wanted us to come visit a conference in Taiwan next year. He gave us many good reasons of why, but one that stuck with me was that he said “Taiwanese girls are ‘kawaii’”. Kawaii is a Japanese word that means “cute”.

This was said in a joking manner. The largest room in the venue, full to the brim, lit up with cheers, applause, and laughter.

At a conference where I estimate at least 95 % of the attendees are men, how will such a thing affect how women feel about coming next year? Would this comment and reaction give the impression that this kind of conference is for men and women are meant to be looked at?

Note that I don’t mention who the presenter was. I don’t think he is a bad person, he seemed very nice. It is not only what he said that is the problem, but how almost the entire audience reacted. This is a problem in our community culture, not the fault of a single person. So I see it as my duty to bring it up, so that we can learn from it and improve. It would be much worse if I saw a problem and kept quiet about it.

Many people at RubyKaigi are also involved with RailsGirls. So there is awareness that female participation at Ruby conferences and, more importantly, in the programming community, is a problem.

I know, I know. This is not a DongleGate, nor is it a “Perform Like a Pr0n Star”. This was a minor hiccup at an otherwise great conference. But since we already have so few women here, we need to be really careful not to scare off the ones that show up.

If I was a woman, I’d feel a bit alienated. Wouldn’t you?

I’ve moved to Australia to write code

September last year my wife and I moved to Australia. I work as programmer at an awesome company called Cogent (join us!). We’re a small consultancy and product shop in the beautiful, sprawling and “Look at the size of the biceps on that kangaroo! This really is on the other side of the planet!” city of Melbourne (pop: 4 million).


Accra, Ghana (source: Wikipedia)

To start from the beginning: late 2010, fed up with the cold and darkness of Sweden and its people, we moved to Ghana. There I worked as a developer at ExplainerDC, another small consultancy and product shop based in the sprawling, messy and “What is that smell? Oh, just the open sewers everywhere and people burning trash in their backyards. I really am in Africa!” city of Accra (pop: 4 million). Living in West Africa was an awesome experience: the weather was fantastic, Ghana is safe and stable compared to many neighbouring countries, the people are very kind and easy going, and beer was cheap. But after a while my wife and I started getting fed up with power/water/internet supplies coming and going, policemen requiring bribes all the time and nothing really turning out the way you’d expect. Plus, being white, having long curly hair and a beard in and very christian African country means that people will yell “Jesus!” (or worse: “Hey, Judas!”) after you everywhere.


Melbourne, Australia (source: Wikipedia)

So after 18 months there, I went through a bunch of Skype interviews with companies in Australia and the US (boo US immigration policies, might I add), we packed our bags and flew down under. I haven’t regretted it so far, I love this place.

The process was super easy: Cogent sponsored my four-year e457 visa which also means my wife could tag along to work and study as she pleases. It took roughly a month to get everything sorted, compared to 18 months to still not have everything sorted in Ghana. A big bottleneck was us having to send over chest x-ray scans, since African TBC is not welcome here.

Life in Melbourne is very different from that in Accra, it is a lot more like my native Sweden. The hierarchies aren’t so strict, people curse the public transport system, the money is good and beer is expensive. It is safe and reliable, maybe a bit too reliable. Once I got used to everything going to shits all the time in Ghana, a stable life can seem a bit boring at times.

One mistake that I made and many other do as well: I assumed that the entire country would have nothing but sunshine all year round. Melbourne has certainly slapped that misconception out of me, since it has four proper seasons. No, not in a year. In a day.

A week of no media consumption

“when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.”

- why the lucky stiff

In my spare time, I tend to read a lot. Also, since I recently discovered the joys of Netflix, I watch a lot of Louie. But the above _why quote, combined with reading and re-reading the highly recommended essay/lecture “Solitude and leadership” by William Deresiewicz, has made me think about what I do with my evenings and weekends.

The people I look up to the most aren’t people who read a lot. They are people who create things. Sure, they might have been avid consumers for all that I know, but they also produced.

I have always seen myself as a creative person trapped in a lazy person’s mind. I don’t want my decently shaped skull and its gooey content to be a slave to other people’s thoughts and actions. I want to explore my own thoughts, listen to my own music, read my own text and use my own apps for a while.

So now I want to conduct yet another little experiment (my life is filled with those): no media consumption for a week. Well, some media is allowed. What I mean is:

  • No reading, unless directly related to what I am making. An example might be API documentation.
  • No watching movies unless I do it as part of hanging out with my wife, as we do enjoy the occasional quirky comedy. But no Louie when I am on my own. “But he’s so funny and sad, Peter. Watching him suffer makes you feel better about yourself!” my mind tells me now, to which I firmly reply “NO LOUIEEE CEEE KAAAAY FOR A WEEEEEK!!!”.
  • Music is fine. I can play the latest Converge or Armin van Buuren albums while I am coding/writing/drawing, since it makes me focus better. No podcasts, however.

It is always easy reaching for Hacker News when I am tired and lazy after a day of coding. But now I can’t, so I’ll be forced to create things instead. Will that mean more blog posts, more drawings, my electronica album finally getting finished or a me making new web framework?

I don’t know yet, but I’ll keep you posted.

Notes from the Relevance Postcast episode about Pedestal

The Relevance Podcast episode 27 featured Tim Ewald talking about the Clojure web framework Pedestal. Here are my raw notes that I took while listening to that. I figured they might be useful for somebody else too.

What is it?

Separation between app (clojurescript) and services (clojure). Pedestal is a set of libraries, try not to use the word framework. Rich browser-based apps with back-end services. CLJS – CLJ. Why doing this? There are already many web frameworks.

  • They like building stuff in Clojure. Found issues that they wanted to address, so they are using it themselves.
  • There is an advantage in working with one language end-to-end. Dev/test tools, cross-compiling code, etc.
  • App model separates the logic from the rendering, but all can be built in Clojure. Behaviour cross-compiled and then rendered in the browser.

Browser based apps are more exposed than server based ones. Anyone can pry it open, presents an interesting challenge. If you make a decision in the browser and updates the screen, it needs to send something to the server. If it sends a result, how does the server know this is an acceptable result? E.g. sending $1000 to someone. So don’t send the side-effect/decision, send information so that the server can make the decision. If you want a fast app and a secure server, having the same language simplifies it. No having to rewrite validation checking for decisions in two languages. Is going to be pretty important.

Server side

Services are based on an abstraction called an interceptor. Ran into limitations of Ring. Ring has a lot of work behind it, cookies, sessions, parameter mapping, flash, file info, etc. But the execution model is bound to a single thread, a request follows a thread and then returns a result. But if you want long polling or other techniques where you don’t hold but keep the connection open, without blocking a thread. Interceptors are not bound to a thread, they can release a thread and then resume processing on another one. Have worked hard to keep interceptors compatible with Ring, worked with Ring team to refactor Ring to accommodate both the classical and the interceptor approach. Can still use all Ring middleware and so on. There are leiningen templates with basic routing and interceptor plumbing.

Client side

Imagine creating a word processor as a web app. If you try to do that through event handlers and DOM handling in js, it will get messy really fast. If the possible states of the DOM explodes, you need another way of doing that, you can’t reload the world every now and then by refreshing the page. So if we maintain a separate data structure to maintain state, and javascript to render just the parts of the DOM that have changed. You don’t want to write the code that does all of that though, since the state changes might be big, so Pedestal solves that problem. Comparing the data structures and rendering based on the delta, helped by immutable data structures (?). Data model, app model (a tree) which is a list of deltas, and a renderer that uses that list of changes to change the DOM.

Why giving this away?

Still far from done. Altruism, they like open source. Relevance has a long record of contributing stuff back. Plus, a web framework these days that is not open source doesn’t have much of a chance. You also want input from the people who use it to see if it solves their problems. If they want Pedestal to grow and have a broad user base, it needs to be free. Started work on it around Halloween. Sometimes full-time of 4-5 people, some times only 20 % time (Fridays). They want to use it themselves for client work.

Ring and interceptors

Interceptor is more complex than ordinary Ring model. Don’t want to let ease of use trump flexibility. E.g. Rails has an ambient database, it’s just there. But if you want to use 2 dbs, it is not easy at all. It is a limitation. As an app grows, you want to do more and more complex things, and Pedestal has been made with that in mind. There is capability and flexibility that they feel from experience that they need.

Linking and routing

Route table maps requests onto the interceptor path. More dynamic than Ring. Anyone in the middle of the path can know where the request is going, or change it. Can read meta-data from path and make some decision based on that.


Working on it. Chat example demonstrates pretty much all the pieces of both apps and services. App has mock service so you can run stand-alone and work on UI. Services can be worked on without app, just curl.


Debugging is easy, you can verify from command line using curl to see if the problem is client-side or server-side. Dev-mode, going back and forth in history. Since the service is sending deltas to the app, you can debug rendering on a delta by delta basis. It is super useful for pinpointing bugs.


Support for CORS, cross-origin resource sharing (see sample here https://github.com/pedestal/samples/tree/master/cors), which makes it easier having 10 different apps using 20 different services. The coupling between apps and servers become looser.

The name “Pedestal”

Tim has a background in building architecture. A pedestal is near the bottom of classical buildings, something that you base stuff on. A good, solid base to build apps on top of.