We’re looking for amazing front-end programmers in a variety of flavours (junior to senior) to join our team to help us build our awesome websites for museums, the arts and cultural sectors. This is no wishy-washy CMS stuff - we like playing at the cutting edge of web design and development, giving users superpowers, and building libraries and frameworks and contributing code back to the community.

Ideal candidates will have experience in a few, but not all, of the following highly useful areas (listed below in descending order of height of usefulness). Most importantly, she/he will also be energised by the thought of diving in and getting to know the rest!

• Javascript
• backbone.js
• CSS (3 would be nice, responsive design would be nice, Sass would be nice)
• HTML (5 would be nice)
• talking to RESTful APIs
• mobile web dev
• an appreciation of good user experience
• an appreciation of graphic design
• backend experience (esp. Python/Ruby)
• contributing to open-source software
• working in a team of developers (esp. Scrum)
• formal design training
• formal comp sci training

You should also have: - some code we can look at. - fulltime availability - or close to it.

About the company

We offer a geek-friendly work environment full of smart people producing awesome software. We don’t compromise on technology (Django/Postgres on the back end; JQuery/backbone.js on the front end, OSX or Linux on the desktop) and development practices (agile, open-source, caffeine), and we are not afraid of a bit of experimentation and interdisciplinary work - the more skills and interests you have, the better. As a small company, everyone who works here has tremendous ability to shape their job and the team’s future. We do everything possible to keep work fun and interesting and, most of all, balanced with more important things, like having a life.

Don’t worry about a CV. Just send us an email that tells us about yourself (include at least one thing you do that is not on the list above) and show us where we can find some of your code to look at.

Contact Info:

Contact: Greg Turner E-mail contact: joinus@interaction.net.au Telecommuting might be OK within Aus/NZ if you really are awesome. Recruiters, we’ll call you.

We’re looking for amazing Python/Django programmers in a variety of flavours (Junior to Senior) to join our team to help us build the back-ends for our awesome websites for museums, the arts and cultural sectors. This is no wishy-washy CMS stuff - we like playing at the cutting edge of web design and development, giving users superpowers, and building libraries and frameworks and contributing them back to the community.

Requirements

• Code we can look at.
• Fulltime availability - or close to it.
• Strong ability to self-direct - find out or learn what you need to solve any problem we might throw at you.

About the company

We offer a geek-friendly work environment full of smart people producing awesome code. We try our best to use the best frameworks (Django on the back end; JQuery/backbone.js on the front end) and development practices (agile, open-source, caffeine), and we are not afraid of a bit of experimentation and interdisciplinary work - the more skills and interests you have, the better. We do everything possible to make work fun and interesting and, most of all, balanced with more important things, like having a life.

Don’t worry about a CV. Just send us a nice email that tells us about yourself and shows us where we can find some of your code to look at.

Contact Info:

• Contact: Greg Turner, Director
• E-mail contact: greg@interaction.net.au
• Telecommuting OK within Eastern Aus/NZ

Apart from GLAMkit, we have rarely mentioned our open-source projects. I wanted to quickly show three which were recently open-sourced by IxC contractors in the course of their work for us:

django-nose-lite, by howthebodyworks - a lightweight nosetests runner for Django projects. My favourite is to run it with —pdb, which drops into pdb on test failures.

django-smuggler, by semente is fairly simple. It adds a button to Django’s admin interface which dumps and loads fixtures to your (local) computer - for superusers only.

django-hashtags, also by semente, converts Twitter-esque #hashtags in text fields into a link to search for items with those hashtags - recent tweets included.

Feel free, of course, to reuse, fork and contribute changes. There are more releases in the works.

The Interaction Consortium is proud to release GLAMkit, a free, open source Web framework built on top of Django, specifically for the GLAM (Galleries, Libraries, Archives and Museums) sector. Think Drupal, but but easier, GLAM-specific, with more front-end flexibility, and much better integration with existing databases.

The framework is made up of loosely-coupled components, most of which can be used as standalone apps, or as part of a larger GLAMkit ecosystem. Our loosely-coupled design approach makes it easy to integrate GLAMkit functionality into existing Django sites.

GLAMkit is currently in alpha development - sign up here to receive announcements about progress. We are still in the process of generalising existing code - so you can expect GLAMkit to grow very quickly over the next few weeks as we plunder our storehouse of code, which represents years of experience and hundreds of hours designing and building GLAM-specific sites. We’d love you to join in on Github or the developers’ mailing list.

Yesterday, I described the difficulty of balancing the benefits of being in a flow state, with the benefits of being interruptible. There is value to the team in both, but flow state is difficult to get into, and so all-consuming that even a small interruption can bring you back to square one.

First: the old tricks to indicate you’re in a flow state - close the office door, wear headphones - don’t work. Besides the fact that we’re open-plan and people wear headphones all day anyway, part of being in flow is that you’re not consciously aware that you’re in flow. It’s an all-absorbing state that doesn’t leave room for metacognition like that.

Second: it’s difficult to tell if someone else is in a flow state. It’s possible; looking round the office, I see people doing things subconsciously when they’re in flow. Some people talk to themselves (most common word: “Yes!”), some hum or dance. I’m a finger-drummer. I don’t think any of us frown or lean forward except for particularly crucial moments. However, telling these things requires a few minutes of observation, something which none of us have time for. Also, have you ever tried staying in flow when you know you’re being observed?

So given that A doesn’t know whether B is in flow, and if A is also in flow, A doesn’t care whether or not B is in flow and is pretty much going to interrupt B anyway, how do we minimise the fallout of the inevitable interruption?

The solution Tim suggested is to disassociate ‘interruptions’ and ‘distractions’ - and try to make interruptions that are not distracting. That happens by minimising the cognitive load of handling an interruption and allowing ‘not now’ to be OK as an answer.

Let’s talk about robots, who have no sense of social protocol. If robots did know about social protocol, what would happen is this:

Robot A sidles up very quietly to Robot B, and waits until Robot B looks up. Robot B: Yes? Robot A: Excuse me Robot B, but might you have a moment to help me with something? Robot B (already sufficiently distracted by this metaquestion to no longer be in flow state): What? Robot A: What is the airspeed velocity of an unladen swallow? Robot B is now so enraged by the passive-aggressiveness of this approach that she blows a fuse and resolves to wear headphones and a frown for the rest of the day.

Obviously this is not what robots actually do when they want to interrupt each other. What robots actually do is this:

Robot A: IRQ? (Interrupt request?) Robot B: ACK! (Acknowledged!) Robot A: What is the airspeed velocity of an unladen swallow?

or, if robot B is busy:

Robot A: IRQ? (Interrupt request?) Robot B: NACK! (Not acknowledged! I’ll let you know when I’m free) (some time later) Robot B: ACK! Robot A: What is the airspeed velocity of an unladen swallow?

The robot-speak approach minimises cognitive load (the interruption, and handling of it, is a 2-word exchange). “No” is part of the vocabulary, and “Excuse me” is not. Problem solved!

Some of us are geeky enough to employ (and let’s face it, enjoy) this protocol unadulterated, which gets us strange looks from passers-by. Others of us have refined it slightly. Instead of saying “IRQ” (“irk?”), saying the person’s name works (and doesn’t require proximity). A long drawn out “AAAAACK” means “give me a few seconds to free up my working memory”, and so on.

Next, being obsessive optimisers, we are contemplating ‘calling cards’, which can be left on someone’s desk, to be returned when the person is ready to handle an interruption. That reduces the number of words to zero, and makes ‘not now’ the default response.

This might be the nerdiest thing you’ve ever heard, but it’s already helping people stay in flow for longer and making everyone feel better about interrupting each other. We’ll see how well it fares over time.

One unsolved problem: many of us, wary of RSI or other ergonomic issues, have “work break” timers installed, which makes you get up and do something else every 30 minutes. Of course, having a stretch, or going for a walk around the block is great for posture and for mulling over tricky problems, but I can’t think of anything worse for interrupting flow state than when this is imposed by a stopwatch. How can people be reminded to do these things in a way that doesn’t interrupt flow?

Finally, I haven’t forgotten about managing computer-generated interruptions. That is a fine art, and everyone must choose their own balance between awareness and distraction. My top tips: I myself have turned off automatic notifications of anything that isn’t critical. No emails, no tweets. Growl is the devil’s work. OS X interrupts you less than Windows (or did last time I looked). Concentrate is an OS X tool that blocks websites and closes apps for a given period.

Oh, and pair-programming. But that’s a post for another day.

Over tea last week we had yet another enlightening chat with Dr. Tim, this time about how interruptions affect the running of the company.

The discussion arose because we at the Interaction Consortium all spend a lot of time in a creative flow state - whether that’s building architecture, coding, designing or researching. Being in the flow is awesome - you’ve probably felt it at one time or another. When I’m in flow, my work is usually very solutions-focused (the work is challenging, but I ‘know’ what I have to do) and I notice the passage of time less. I become ‘one’ with my work. Very productive stuff, which is good for us, and good for our clients.

You see flow in other places too. Musicians playing, and jugglers juggling (this man has so much flow he’s grown an extra arm).

Reaching that flow state takes a lot of preparation. Long-term, you have to acquire the skills necessary to do the work. Medium-term you have to spend time letting the particular problem percolate, becoming familiar with all of the factors that might come into play. Short-term you have to try to arrange all of those factors into some sensible formation in your head, that can be moved in chunks into working memory (7, plus or minus 2, is the approximate number of objects most of us can hold in working memory).

Sometimes the problem requires you to take into account a lot of things at once, sometimes the problem requires you to do something very demanding of your immediate attention. The juggling equivalent would be the number of balls you can keep in the air, versus the types of tricks you can do.

As you can imagine, being in flow takes up virtually all of your cognitive capacity, which means that distractions are perilous to the flow. If you are juggling all the balls you can keep track of, then someone hands you an armadillo, something’s going to get dropped, and it’s a going to take time to build up that momentum again. Everyone hates being distracted at times like these.

However, interruptions are vital to the running of any company, or any team. If we didn’t have to deal with external factors (and in a flow state, everything is external), then we are fundamentally limited to our own capacity, which means there’s no point being in a team. We can’t just not interrupt.

So the circus trick we are trying to pull off in our team is to balance the way we interrupt each other, with the way we handle interruptions. The crux of the problem is that interrupting someone in flow is a bad thing, unless it’s urgent. Interrupting them at any other time is a good thing.

Tim came up with an excellent suggestion which it’s already working out well here, and which I’ll describe in my next post. Warning, it might be the geekiest thing you’ve ever heard.

Webjam 10 truly lives up to its name - 200 of the finest (mostly Australian) minds in the web crammed into a bar at the top of CBD hotel. Sixteen of us vied for people’s attention with 3-minute back-to-back presentations.

My picks were PaperFree, a ‘Smoke’ mashup thing that doesn’t appear to have made in onto the site yet, and of course the winner gRaphael for doing very pretty JavaScript graphs (someone remind me to do a post about the looming ‘interactive wars’).

My own presentation, on the glorious About New South Wales, and the fashionable History of the Australian Web, went down well. I think the technology compensated for the fact that no-one could hear me! I came 3rd in the voting and now have a ticket to either Edge of the Web or WebDU next year. Which should I go for, do you think?

Welcome to the Interaction Consortium’s maiden voyage into the blogosphere.

We will endeavour to bring you all-things-web, from the latest news and events, our projects, what’s inspired us, a little bit of geek-talk and designerly ideas, and our passion for the arts and culture scene in Sydney (and beyond)!

Subscribe to our RSS feed for the next updates - coming to a screen near you!