DDD Melbourne 2018

Several of my friends in the tech scene in Melbourne had been very positive about previous iterations of DDD Melbourne – a not-for-profit, grassroots-organised developer conference, that always sold out – so was curious to check it out and was grateful when my friend Cameron arranged tix.

My first impressions were positive – volunteers were very visible in pink capes, the code of conduct was front and centre, the name tag was DIY / free text and lanyards were colour coded for photographic consent. The schedule was voted on by delegates, meaning that the sessions most desired were scheduled in bigger rooms, which worked really well, and the schedule was also printed on the back of the lanyard – this was super helpful. Rooms were colour-coded and easy to find with big signage. The venue unfortunately was really too small for the number of delegates – the official tally was just over 600, and trying to fit this many people into the Town Hall, especially for lunch and morning tea, made it a little crowded.

The content itself was also much better than I expected at a grassroots event, however I did observe that at least three of the presentations I went to were by professional developer advocates – people who are employed by tech companies to professionally present about the company’s platform or product, and the content was very Microsoft-heavy – given they were a key sponsor I didn’t know if they automatically got speaking slots as part of their sponsorship or not – this wasn’t made clear at all. The language coverage itself was also very Microsoft heavy – lots of C#, Visual Studio, Azure – and very little Python or other open source languages like PHP.

NOTE: I currently contract in a similar role at Mycroft.AI

I did find it a little odd that the event was Microsoft-sponsored, but there wasn’t any GitHub presence at all. Interesting, there wasn’t any presence from GCP or AWS – likely because of the Microsoft sponsorship and their competing Azure product.

Overall, I found it a bit too pitched at the junior-dev end of the spectrum, and too Microsoft-heavy for my tastes – but a well run, safe event that has matured beyond its grassroots beginnings.

Keynote: A Day in the Life of a CEO – Dayle Stevens, CIO, AGL Energy

Dayle Stevens - DDD Melbourne 2018

Dayle provided a real-life insight into the daily routine of a CIO – highlight how important it is to keep up to date with mission critical information, and the constant tension between a heavily filled operational schedule of back to back meetings, and the need to be focused strategically and on longer time horizons – against a backdrop of constant context-switching.  Her experiences were authentic and realistic – and highlighted that in large organisations that the operating rhythm is set via the content of conversations –

“it’s all about talking with people”.

She is inspired by the ability to drive the direction of the company – and underscored that these days, every company is underpinned by technology, so having a technology role within a company allows you to have a stronger involvement in the overall organisational strategy. Dayle went on to explain that a key challenge for companies today is the complexity of technology – many companies are old – and some still have technology from 50 years ago – so CIOs are not just dealing with “two-speed” IT – they’re working on “three-speed” IT;

  • dealing with legacy technology
  • dealing with the digital transformation of today
  • and needing to embrace the emerging technology of tomorrow

The role of the CIO as a cross-organisational role, that touches every line of business and every function, and is integral to process improvement, was underscored using a business model canvas, covering;

  • Strategy
  • Structure
  • Systems
  • Style
  • Staff
  • Skills

all combined under the umbrella of shared values – and Dayle noted that her job wasn’t just to interface with senior leadership, but to “empower everyone in the organisation”.

In her advice for engaging with CIOs, she referred to DISC personality profiling, noting that most CIOs fall into the ‘Dominant’ quadrant – people who are action oriented and outcomes-driven, and so in dealing with CIOs you need to quickly get to the point. She did however make the comment that she feels other personality types – more analytical types – are less represented at the CIO level, and that this is itself a diversity issue.

Rian Finnegan – A Practical Introduction to Quantum Computing

Ryan Finnegan - An introduction to quantum computing

This was the standout presentation of the day, and a huge credit to Rian’s presentation ability, and skill in being able co clearly communicate complex concepts.

Rian provided a primer on Quantum Computing – starting with explaining how quantum computing simulates the the the quantum world – the world of molecules – and can be used to help solve wicked problems such as climate change and food production. Personally, quantum computing was always something that was firmly in the theoretical “maybe one day far off into the future” space – and to have such an accessible and easy to follow primer was wonderful.

Rian started with the classic Schrödinger’s cat example, highlighting how observing a system in quantum computing alters the quantum state, then provided an overview of complex numbers, Bra-Ket notation and moved on to quantum states, and then an overview of Bloch spheres, qubits, quantum gates, quantum entanglement and ended with a discussion on how to provide quantum supremacy – that is, how do we mathematically prove that quantum computers are superior to classic computers?

I cannot do Rian’s presentation justice in a summary – you really do need to see this talk, or get this talk to your own conference.

Ben Cull – Startup Life Lessons

Ben was the most engaging presenter of the day, and his delivery style was warm, humorous and entertaining.

He told the story of this journey founding several startups, and the lessons he’s learned from each of them, condensed around a sort of maturity model;

  • Minimum Viable Product
  • Market fit
  • Growth
  • Performance
  • Exit

He highlighted the need to focus on your own personal brand, and to have a clear understanding of what will drive you – particularly as founding a startup requires a lot of resilience.

“What is going to drive you at your lowest point?”

One aspect he advocated was that as a startup founder, you have to push yourself to be social – you have to have large networks – “go to the pub, you will get a job” –  opportunities come through social engagement. I’m not sure if I agree with this – firstly because it plays into the “bro culture” of hiring people like you – or who drink in the same pub as you – or who drink – an activity that you have in common – and because I think it’s the easy way out. Hiring the person you met in the pub at a meetup just screams due diligence.

One key takeaway from Ben’s presentation was ensuring that you are continually talking with your customers, and using their feedback to iterate on your product – it’s never a case of “build it and they will come” – because they won’t. Marketing and selling, getting product traction are incredibly important for a startup, and it can be helpful to find a partner or ambassador to help you with this – a recurring theme from startup advisors – you need the right mix of co-founders for a successful product.

Damien Brady – An Introduction to Machine Learning

Damien Brady - Introduction to Machine Learning

This was a great, accessible introduction to machine learning concepts

Damien is a Developer Advocate at Microsoft, and started by putting Machine Learning into context with artificial intelligence and deep learning, and underscored the need to start the machine intelligence life-cycle with a “sharp question” – a question that machine learning approaches can answer. He highlighted that one of the hardest parts of a machine learning development lifecycle is going to be getting your data in the right format – it’s often unstructured, inconsistent and requires a lot of cleaning.

He went on to provide an overview of how machine learning models work, and explained the concept of ‘overfit‘. He explained model functions, and how the decision boundary – what “is” and “isn’t” – is explained by a mathematical function. Here we got into some matrix-based calculus as he went on to explain the concept of a cluster function, an error function, and how we want to minimise this – using calculus minimisation techniques, such as gradient descent.

He went on to explain how model functions which are linear have specific limitations because they are linear – they are two-dimensional, but many applications of machine learning are multidimensional. To  make the model non-linear, an activation function – such as a sigmoid function – is applied.

The key takeaway here was that if you have a generalised typed of machine learning scenario you don’t need to start from scratch because there are several machine learning models and model training tools available in tools like TensorFlow.

 

 

 

State of my toolchain 2018

Back in mid-2016, about two years ago, I did a run-down of my personal productivity stack – essentially a ‘State of my Toolchain’. After almost 2 years, it’s time to provide an update and see what’s changed.

Main laptop

My Asus N76 17.3″ laptop is still going strong as my main workhorse; but its days are numbered. I’ve had to rebuild a couple of times now after hard disk drive sectors have failed, so it’s a matter of time before it’s forced into retirement – but at nearly six years old, it’s had a good run.

So the question becomes – what replaces it? I’ve always been very happy with the ASUS gear I’ve had over the years, but the Zenbook range doesn’t seem to have that much in the way of high end GPU specs – which I need for both gaming and machine learning stuff. On the other had, the RoG range doesn’t seem to have good battery life; although that really isn’t a major consideration.

Enter System 76. I hadn’t heard of these guys until some of my linux.conf.au and Mycroft AI mates mentioned them, including this kick-ass video.

https://youtu.be/TcWVKqeF0MY

After doing some asking around, folks seem pretty happy with them, but the downside is that they’re costly; especially with the poor $AUD exchange rate – and then on top of that you have to pay import duty. Might have to see if the $AUD/$USD exchange rate improves.

Mobile laptop

My Asus Trio Transformer TX201LA is still going strong as a mobile laptop; the battery life isn’t great but having the Android & Linux combination on one device has come in very very handy. I’ll be hanging on to this until it dies – and then I’m very interested in one of the newer Transformer models.

Mobile phone

Two years ago I was using the LG Nexus 5X but unfortunately it was victim to the Bootloop issue. Now I have a Pixel, and it’s brilliant. Right size, great battery life, and great bluetooth and NFC support. And yes, I often use it with with headphones.

Wearables

With Pebble being acquired by Fitbit and subsequently sunsetted, I needed to find a new smartwatch. My Fitbit flex was also degrading, so it was a natural choice to go with the Fitbit Ionic – essentially combining two wearables – fitness and watch – into one. I’ve been incredibly happy with Ionic – I was skeptical at first, but the battery life is long – about 3-4 days and the reminders to move are useful. The range of applications is limited, but the key feature – of passing notifications from my phone to my watch – works well.

I’ve found that over time, my smartwatch is very definitely part of my toolchain – it’s no longer a nice-to-have extra – it’s a tool that I regularly check and rely on.

Quantified Self

My Fitbit records and stores a lot of data about how active I am, however I’m still using RescueTime and BeeMindr to help with day to day productivity and long term goals. RescueTime gave me a great deal on a premium upgrade (big ups, guys!) and I’m using the “focus” features a lot – which prevent you from using time-wasting websites like Facebook for a period of time. RescueTime also continues to deliver great visualisaitons that help to see where you’re spending your time.

rescuetime-usage-2017
My RescueTime logged time by category for 2017

Headphones

Plantronics Backbeat Go 2 Bluetooth headphones were great, but being an idiot I left them in a hotel room while travelling. I replaced them with the Jabra Rox – the magnetic earbuds are great for not losing them, however I’ve struggled to use the “wings” to get a good fit.

My Logitech H800 is still going strong. Great headphones.

I did splash out on some Plantronics Backbeat Pro bluetooth headphones that have noise cancellation for concentrated, focused work in noisy places – like co-work spaces. They’re great – 20-odd hour battery life, and they really do cancel out a lot of distracting background sound. My one niggle with them is that the ‘active off’ feature – which pauses music when you take them off – activates with movement, like walking around the house or getting up off a chair.

Streaming Media

With Pandora moving out of the Australian and New Zealand market, I needed to find another streaming music provider. Spotify was an easy choice because of their cross-device support – including a native Linux desktop app. On the plus side, Mycroft AI has a Spotify Skill that, due to API restrictions, is only available with Spotify Premium accounts.

Input devices

My keyboard, graphics tablet and presentation pointers haven’t changed in two years, but I did back Sensel Morph on Kickstarter, and have started using it, but because the Linux driver isn’t great (yet), it tends to work better under Windows. I’m hoping that the Linux support matures in the future.

Voice Assistant

Would I like an always-on spy listening device in my house? Hell no.

Would I like a useful voice assistant that doesn’t save what I say to sell me advertising and invade my privacy? Hell yes.

Which is one of the reasons I went to work for Mycroft AI. But I digress. As part of my role, I do a lot of testing and documenting for the Mark 1 hardware – and I have three of them around the house. They’re solid little units with microphones that are better than I expected for RPi-based devices.

One thing I did need to get for working with the Mycroft Mark 1 was a new set of torx hex keys – the ones I had didn’t have a long enough handle to disassemble the Mark 1.

We also have a build of Mycroft for Raspberry Pi – Picroft – that needs a microphone and speakers. For this I got  a Jabra 410 – it’s much better than I expected for a mid-range omni-directional USB microphone.

For Picroft I also need some Micro SD cards; my key learning here has been that cheap Micro SD cards will cause you pain and misery and suffering and segfaults. Don’t use cheap Micro SD cards. You’re better than that.

Internet of Things and Home Automation

My bevvy of LIFX light bulbs continues to grow; I really like the range. I did have an issue with their LIFX Z light strip; one of the three strips that was delivered didn’t work, but it was covered under warranty and they shipped me a replacement. One of my favourite integrations here is with Google Home; I can turn off my bedroom light using the power of my voice.

I’ve also been hacking around with some Ruuvi tags; I want to spend more time on these, they’re pretty cool as sensors.

Software

My software stack hasn’t really changed in two years – I’m still using LibreOffice, with Firefox and Thunderbird, and Atom Editor. In particular,  LibreOffice Draw is becoming my go-to tool for diagrams and process flows. Scribus, Inkscape and GIMP are still top in my toolbox too. The new version of GIMP is much smoother.

Gaps in my toolchain

Even with all these great tools, I’m still missing a few components from my overall stack.

  • Visual Git Editor – The range of visual editors for Git on Linux is limited. I tried GitKraken but didn’t like it much. GitHub for desktop doesn’t yet have an official Linux build; I tried to install the shiftkey fork, but couldn’t figure out how to install it.
  • Better internet – my internet is connected at about 6Mbps down, 1Mbps up. It’s slightly faster than two years ago. It’s usable, but very slow. If I have to download or upload a large image – which I often have to do for work – I have to plan ahead. Oh NBN. I simply don’t have the words.

 

Have I missed anything? What do you use?

Developer Experience as a fitness function for platform teams

Borrowing from several antecedent disciplines, developer experience is beginning to emerge as a distinct practice of its own. It borrows heavily from more general user experience techniques, as well as from developer relations and community management approaches. One of the pieces that I’ve felt was lacking in this space was a coherent framework – maturity model if you like – of how to approach the practice of developer experience.

Enter Thoughtworks and “Developer Experience as a fitness function for platform teams“. I’ve been a fan of Thoughtworks for a long time – not just their Tech Radar and their support of several tech community groups, and internet freedom events – but for their thought leadership – they challenge norms and aren’t afraid to be skeptical of the latest fad or industry ‘buzzword’. So when Andy Marks and Liauw Fendy were going to put on a session around Developer Experience I knew it would be worth a 3 hour round trip commute.

What is Developer Experience?

The session started off by defining Developer Experience – summarised as “user experience when the users are developers“, or more verbosely – building on the meaning of user experience itself;

“peoples perceptions and responses resulting from the use or anticipated use of a product, system or service”

We then explored what it means when we say ‘platform’ – and that most people have a very narrow view of what a platform is, but really, each platform has several components – it’s not just an API;

  • client libraries
  • test stubs
  • documenation
  • source code
  • tutorials
  • FAQ
  • quick start guide
  • community
  • evangelists
  • support processes
  • deploy pipeline
  • update and release strategy

The term “fitness function” itself is taken from Thoughtworks’ book ‘Building Evolutionary Architectures‘ – and is

“an objective integrity assessment of some architectural characteristics”

which can be used for continuous improvement purposes.

The discussion then turned to what is meant by good Developer Experience – both form and function. Using Aaron Waker’s Hierarchy of User Needs, we explored what it means for a Developer Experience to be

  • functional
  • reliable
  • usable
  • pleasurable

In the absence of a more formal maturity model, the hierarchy of user needs serves as a good starting point for understanding an organisation’s current level of Developer Experience and a way to prioritise improvement.

Drivers for investing in Developer Experience

We also discussed the drivers for investing in Developer Experience – which were generally very practical and focussed on reducing the cost of support;

  • If you build it, they won’t necessarily come; there are lots of development platforms available these days. If the development experience is poor then developers can easily switch to a different platform; developer experience is vital as an attractor for your platform, particularly if it’s commercially oriented.
  • If you don’t provide a strong developer experience, then developers who use your platform which build their own processes and approaches – essentially a shadow developer experience, which you can’t control. A robust developer experience gives you more control over the community.
  • Strong developer experience ‘frees up’ the platform team to be able to build more functionality and features, because support load reduces – developers are better able to ‘help themselves’, reducing interaction time on the platform team.
  • If you have strong developer experience, you will have more productive developers – able to build stronger, more featureful applications on top of your platform.

Measuring your Developer Experience

This was one of the most useful parts of the session – how to measure your Developer Experience, because if you can measure something, you can manage something.

  • Frequency of errors – what errors do your users get, and how frequent are they?
  • Documentation – which docs are used the most? Focus your effort here.
  • Repos – Issues created, PRs, repo stars and repo forks
  • Deployment processes – speed and ease of deployment, and continuous integration and continuous deployment processes.
  • Community – in bound requests and Net Promoter Score values.

When questioned about whether there was ‘one metric to rule them all’, the presenters offered;

“Mean time to first hello world”

which I found really interesting on several levels – getting something working quickly is more important now that teams have adopted Agile and minimum viable product approaches. On a psychological level, it also makes sense because if you can build something quickly, you’re going to be more motivated to expand your development.

I found all of these very informative for building a Developer Experience Metrics framework – even a cursory glance around the web shows that there isn’t a lot out there in this space – certainly not an industry-adopted ‘standard’ found in more established disciplines such as Service Desk Management or Incident Resolution.

Developer Experience lifecycle

Another key concept that was used to explain how maturity could be increased in Developer Experience was that of a ‘lifecycle’;

  • Find – Is there a platform? Here the developer is seeking a platform for their needs. How is your platform found? What are developer first impressions?
  • Learn – How do developers learn to use your platform? How good are the docs? The tutorials?
  • Build – How do your developers build? What do they get blocked on? What are their key obstacles or pain points?
  • Run – How do your developers operate the software? How quickly does it run?
  • Grow – How do you grow the number of consumers on your platform?

Together these stages form a ‘funnel’ – like a sales or marketing funnel, but with the aim of moving developers from ‘interested’ in your platform to active builders, and hopefully, advocates.

Parting thoughts

This was an excellent session – and the practice of Developer Experience is here to stay.

Image: Ember Code by Kovah on Flickr, CC-BY