Wellington Android Meetup – The first edition

It’s true. The Android developer community in Wellington is strong and mature, if tonight’s first Android Meetup is anything to go by.

The setup

Android Meetup Wellington

Android Meetup Attendees

Just over 30 people took part in the first (of hopefully many more to come) Meetup that I was proud to facilitate and host together with the rest of the Trade Me Mobile team at our Market Lane office. We will try to make sure this becomes a regular event, especially now that the GDG Wellington was created.

The turn out was fantastic (we had to supplement the available slots at the last-minute). The show of hands confirmed that the majority of attendees were developers but we also had designers, testers and business folk. This diversity definitely helped during the Q&A sessions…

The talks

The theme of the evening was Material Design and the agenda was simple. I gave a quick intro, then we kicked off properly with a presentation by Matthew Shearer (our Lead Android developer) about the challenges that we face at Trade Me when tacking Material Design in our app, followed by an interesting Q&A, then the spotlight was given to Glenn Parker (Xero) who showed off a few ideas/early mocks for their product. Other people in the room mentioned that Material Design was high up on their TODO list but they just haven’t gotten around to it.

The evening continued with food and drinks followed by an open discussion around the future of this group.

Where to from here?

We are very keen for this event to not be owned by one organisation. Instead, we’ll aim to put in place a roster so that other teams around town can host it and offer more diversity not just in terms of venues but also in terms of hours. We even floated the idea of doing it over lunch sometime to cater for those with young kids or who have engagements in the evenings…

Happiness Survey

Happiness Survey

As expected, the attendees behaved really well and communicated freely. There was no awkward job/hiring talk, nor any immature comments of any kind.

Toward the end of the event we brainstormed a few ideas for future sessions. We’ll vote on the group and we will decide what we will talk about next time (late January or early February). As this picture shows, people found the event valuable for the time they invested (2 hours) so I will call it a success!

Link

Michael Lopp’s Being Geek: The Software Developer’s Career Handbook
is a book I wish that my team don’t read. At the same time, I hope that my current and all my future managers have already read it.

Despite being a collection of “Rands in Repose” posts, this book is surprisingly readable. I can definitely see how a senior developer, an HR manager, and a team Leader (uppercase “L” is not a typo) would benefit from skimming this book over one weekend.

Bonus: You can learn a couple of social games while reading this book: Werewolf, and Back Alley Bridge.

Kindle Paperwhite – The Voyage was not for me

After a fair bit of research I decided to upgrade from my (basic) Kindle to the Kindle Paperwhite.

Kindle Paperwhite

Kindle Paperwhite, 212ppi, 16-level gray scale

Why upgrade?

My previous Kindle was great. I didn’t feel like I needed the touch screen, and using the 5 directional button was fine. The main thing that I wished for was backlight. In the past, I would read on my Kindle during the day (especially outdoors), and on my iPad Mini at night. I’m hoping that now I can just use one device…

Why not the Voyage?

The Kindle Voyage looks great. I wish that the Paperwhite had physical page turn buttons, but I can’t justify spending $120 more for page-press sensors, 300ppi (rather than 212ppi for the Paperwhite), and adaptive light. I’ll just buy a dozen books with that money instead!

Why not read on the iPad Mini?

I could make up tons of reasons, but the truth is that I’m just not disciplined enough. I love my iPad Mini and I just get distracted by all the apps and things that I could be doing.

Team vs Group – Some differences

A bunch of people that push each other forward and work together for a common goal form a team. A number of people who work for the same organisation but have individual goals belong to a group. One of the biggest differences between a team and a group is that a team’s achievements always outweighs the sum of all the individuals’ accomplishments.

To better explain my point of view, I will break down my definition of a successful team into the categories below and close with what I believe the manager’s role should be.

Motivation: Purpose, Accountability, and Goals

People in a group are very likely to be sold a goal. Depending on their professionalism, they will push themselves to achieve great outcomes and they will strive to be honest. Any failures or imperfections are forgettable and are perceived to be short-term. Accountability applies at personal level. In this context, the motivation for an individual is most often extrinsic.

In a team, the goals are set together through discussions, planning, and by sharing a common definition of success. The team has personality. Since the goal is shared, they push each other forward and hold each other accountable. Due to the fact that they collaborate closely they often end up raising the bar of expectations for each other in order to deliver better results at both personal and team level. Team players are intrinsically motivated.

Collaboration and Roles

Group

In a group, individuals are less likely to contribute to other skills

In a work group, people share information, they are respectful with one another, and sometimes even behave in a formal way. Meetings sometimes turn into status reporting. Peoples’ ideas don’t always get challenged or augmented. There’s hardly ever any work done outside one’s area of expertise. The skills overlap is kept to a minimum, almost as a sign of  respect. Personal development is determined by one’s own desire to better themselves rather than as a need to fill a gap. A designer is always a designer and a tester is always a tester. The Gantt1 chart for how a project runs is clear-cut. Task B always follows task A and never comes after task C.

Team

In a team, individuals tend to push their peers forward

In a team, the collaboration is not just close, but from the outside it may even look chaotic. There is energy and people often venture beyond the limit of their skill. Developers and testers may end up sketching design approaches. Designers may roll up their sleeves and help with testing. Product owners will join the designers in user testing. Personal development is often done in a way that completes the collective knowledge. A tester may learn to use prototyping tools, while a designer may learn how to work with development tools. Each person may wear the hat of any of the other team mates and may jump in when their help is required. In a Team, tasks A,B, and C may take place at the same time and make a project manager’s life a living hell.

The Manager’s role

In a work group, the manager is almost a dictator (sets the goals, measures progress, and is the only one who can push a member’s limits). In a team, the manager is merely a guide and a facilitator.

All teams start off as a group. It’s a manager’s job to create an environment where people:

  • feel safe
  • speak freely
  • are comfortable with themselves and can be genuine

so that they can discover each other’s strengths, accept the weaknesses, and, over time, build trust.

1 Disclosure: I really don’t believe in Gantt charts.

DevMob 2014 – Epilogue

This year’s DevMob was different compared to all the previous DevMobs: there was tangible equilibrium between iOS and Android, with both platforms showing maturity in terms of tools, design metaphors and developer attention.

Sponsors & Venue

DevMob2014

DevMob 2014 – Wellington

This (un)unconference1 would not have been possible without support from the sponsors: Microsoft, Alphero, Xero, Powershop, CactusLab, JSA, and 3 Months.

This year, the swag was particularly nice (thanks to the Alphero team). The sponsors also contributed with very interesting talks, availability and engagement throughout the weekend, and a wicked Lego Death Star draw!

It was Wellington’s turn to host, and the chosen venue was Samuel Marsden Collegiate School. I give it the thumbs up: the food was great, there were plenty of rooms (and each had a projector), and we were even allowed to use the amphitheatre.

An evolving conference

Over the years, the conference evolved from being focused on iOS only, to sharing the spotlight between iOS and Android. This reflects the marketshare and the user base of the two platforms, and the ever growing number of developers interested in them. As one of the attendees who hasn’t missed a single iteration of this event, I’m happy to see such organic growth. It’s also good to see that the Microsoft folk have not given up, and keep attending these gatherings and contributing with incredibly useful insights (Azure being one such example).

My observation (potentially wrong) is that, year after year, the iOS talks have become a bit more abstract and more high level (a good incentive for me to return). At the same time, the audience has managed to keep some practical sessions on the board:

  • the show-and-tell sessions took a UI/UX spin
  • the demos contained products that are more and more polished (even though their authors consider them “rough”)
  • the live coding sessions were focused on concepts that a newcomer would probably struggle to fully understand, but would still find valuable

If a couple of years ago Julius was struggling2 to attract a handful of devs to take part in a blue-sky discussion, this year all the Android sessions had full rooms. Refreshingly, Google’s Material Design was at the centre of most discussions. The tools and libraries that people spoke about covered everything you can possibly think of: from analytics, networking, and storage, all the way to dependency injection and reactive programming.

I’m sad to see that Android developers still have to battle with basic things such as networking and resource loading. Michael Rueger from Xero gave a very good talk about the way their app tackles this area. I definitely think his talk should be shared at one of the next Wellington Android Development Meetups. While I’m talking about Xero, Glenn Parker was particularly active and even shared some interesting work they have underway. The Poweshop folks also contributed a great amount, confirming that Wellington is the place to be for Android developers. Not to be outdone, I shared as much as I could about the way that we do things at Trade Me.

No doubt about it, Android is a first class citizen and there’s some outstanding work being done in this space.

New in 2014

Back in 2009 when Jade Software launched DevMob (under the NZiDev moniker), the questions that people used to ask were along the lines of “how do I code, test, deploy, market my app, all at the same time?”. After just 5 editions, this question has transformed into “how do I run a distributed team? how do we collaborate with designers and testers? how do you manage an app’s backlog?”.

This year, I believe two themes were new to the stage: mobile development at scale, and an in-depth look at how to build mobile software. The gimmicky apps were pretty much absent, confirming that the mobile gold rush is well and truly over. For a change, Layton and Karl did not have to too many questions on how to build the next million dollar app.

Scale

Surprisingly, managing scale was probably one of the most talked about things this year. So much so that the group ended up creating a follow-up session after Luke Gumbley‘s “Backlog management / Feature planning” talk.

Team building, maintaining happiness, and dealing with ownership, all got tackled by the audience. The information flowed freely and openly thanks to the trusted environment that makes so many people return to this event year after year.

Depth

It wasn’t just the management side of things that was new this year. The sessions went deeper into the product life-cycle with topics such as API design, security, functional testing and mocking, UX, continuous integration and more.

I was happy to see large development houses (Cactuslab, JSA, Powershop, Trade Me, Vend, Xero, etc) share intimate details about how they tackle many aspects of the SDLC. The fact that non-coding topics permeated DevMob 2014 is encouraging for future iterations of this (un)conference.

Until next time

I missed out on the socialising that traditionally happens after the first day of the conference. I suppose that’s part of the deal when the event is hosted in one’s home town.

Many thanks to the hosts Nat, Janine, TanyaJulie and everyone who contributed to making this event a success.

If I got anything wrong, or if you wish to pass any feedback, you can reach me on twitter.

Notes:
1 To learn more about (un)conferences you can visit Nat’s website, buy this Kindle book, or, my favourite option, just take part in one!
2 Julius is no longer struggling to attract new people to his talks. He now just needs to find a way to keep Sam awake. (Okay, this photo is cropped and you can’t see the 30 people sitting behind Sam, but it’s funny nonetheless.)

Julius teaches Sam Material Design

Julius teaches Sam Material Design