open information means better outcomes

In the last couple of organisations I’ve worked for, the flow of information to a team has always correlated to perceived seniority.  Starting as a “developer” and not a “senior developer” or a “team lead” means that people’s access to information is restricted.  This hasn’t always been an active decision, it’s just happened because people decide to cut the sphere of information down to people they think are relevant.

Unfortunately, titles don’t always match the people who are most passionate about an idea or a problem.  If information flows are restricted, a new employee’s ability to learn about – and potentially change – an organisation is severely limited.  Conversely, if a problem or topic is universally acknowledged, then those who are keen to solve it will be at the forefront of ideas and discussions.  You get a limited amount of time to harness a new starter’s energy and observations on how your company can improve before they start blending in with everyone. It’s hugely valuable; don’t waste that opportunity!

At a previous company, 7digital, twice a week the entire development team would get together to discuss general development issues. It really levelled the playing field, and titles became irrelevant; people weren’t afraid to bring up concerns, ideas were debated on merit, and participation was totally up to individuals. You could tell who was passionate about any given topic pretty easily. Conversely, if you weren’t interested in the topic, you didn’t go to the discussions.

If you’re going to hire “smart and gets things done” people, open up access to information and give them the ability to execute.  The effect on teams and people when they feel empowered is a fantastic thing to be part of.

responsive web design @ girl geek dinners

Last night, the lovely women at Sydney Girl Geek Dinners were given a treat – a presentation by me 🙂

Between April and July, one very awesome team at Mi9 built the YouDecide9 site.  It’s a project integrating Ninemsn, Twitter and the Nine Network’s audience in the lead-up to the federal election.

Quite literally, everything about the project was new to me. It’s built on node.js using CoffeeScript, deployed to Amazon Web Services using Beanstalk, and we used sass for the front end styles. But one of the most interesting things to me was the page’s responsiveness.  It’s the first responsive site I’d ever built, and the concept is so natural that I can’t understand why we, citizens of the internet, haven’t caught on to this earlier.

If you go to the website and make your browser window larger and smaller, you’ll see that it adjusts to fit. That’s responsive design in a nutshell. The user always has a great experience, no matter what device they’re using. Mobile browsing experiences have traditionally been the second-rate versions of their desktop cousins, but responsive design solves all of that.  And, with mobile internet usage predicted to overtake desktop internet usage this year, it’s an increasing problem that people need to tackle.

From my perspective, the most interesting points from our project were:

  • Designing for mobile first, since it’s the one with the most limited resources
  • Adjusting the mobile version of the site to the desktop design took around 15% more effort (a win compared to the effort of building two entirely separate sites, one for desktop and one for mobile)
  • The range of CSS media queries available is incredible. We generally queried the screen width to adjust our content.
  • The Viewport Resizer Bookmarklet, an extremely handy tool for testing responsive sites.

The slides for my presentation are available on prezi. Thanks so much to the Sydney Girl Geek Dinners group for being a wonderful audience.

tweets… on a map!

I love hack days; they’re a great chance to remind yourself what’s possible in insanely short time periods.  Last week we were given 24 hours over two days at work (2pm – 2pm) to build anything we liked, using any kind of technology.

I was very curious about the Twitter API and wanted to investigate different tools and libraries around that offer Twitter support. Partly because there was an upcoming team forming at work around Twitter functionality (which I am now on! Success!) and partly because social integration products are always fun.  I didn’t really mind what the project was, but I did want something working by the end.  In the end I teamed up with a fellow new developer Gareth Hughes, and we built Tweets on a Map*.

Inspired by the UK Snow Map, which shows you where it is snowing in the UK based on user tweets, we wanted to visualise tweets over a map of Sydney in real time. So we asked users to tweet at an account (@tweetsonamap), with a postcode, a rating out of ten, and an optional message.

@tweetsonamap 2017 8/10 We're feeling pretty good today!
We used TweetSharp to interact with the Twitter API, an open source library written in C#. It was surprisingly easy to make the first call to a non-streaming API; TweetSharp hides all of the complexities of OAuth from you. Simply plug your API credentials and it worked. An example from the documentation:
using TweetSharp;

// In v1.1, all API calls require authentication
var service = new TwitterService(_consumerKey, _consumerSecret);
service.AuthenticateWith(_accessToken, _accessTokenSecret);

var tweets = service.ListTweetsOnHomeTimeline(new ListTweetsOnHomeTimelineOptions());
foreach (var tweet in tweets)
{
    Console.WriteLine("{0} says '{1}'", tweet.User.ScreenName, tweet.Text);
}

Getting the streaming endpoints to work  not as simple. We had to create a patched version of TweetSharp that fixed a bug with deserialization when getting a user’s timeline in realtime (based on a pull request by kensykora that has now been merged into master).  There were also no options to customise the parameters given to the API, for example to get all replies for a user’s timeline. But other than a few hiccups, it was nice to have the API abstracted away.

On the front end, we used SignalR to push the incoming tweets straight to Google Maps. The Google Maps API is lots of fun to play with, mostly because there are some comprehensive code samples that show what it can do. Gareth was the SignalR wizard and got us up and running using this stock ticker example.

By 9pm on the first day, we had our working prototype that listened to a tweet stream, picked up new tweets, parsed the postcode and displayed the tweet on a map at that location. It’s definitely the most relaxed hackathon I’ve ever participated in. We both went home, got a good night’s sleep and made things pretty before the presentations at 3pm. We even had time to make a prezi.

Result: we won Mi9’s most viable product award for Hackathon, and came 3rd in the popular vote category! We were pretty pleased with that.

Learnings:

  • Like a boy scout, be prepared. The TweetSharp API was investigated and patched before the hackathon started, avoiding the stress of working out the bugs during crunch time. We also got code samples of SignalR and read the Google Maps documentation.
  • TweetSharp is a nice library to use for twitter, but be prepared to tweak the edges if you need to. Luckily, it’s open source and hosted on GitHub.
  • SignalR is shiny.
  • I personally learned a lot about the Google Maps API and more javascript, which I’d like to learn properly this year.

* Disclaimer: the code has no tests – it was a hackathon after all 🙂