I am a technologist who recently spent a year and a half working as a Ministerial Adviser in State Government. I was the Senior Adviser for Innovation and the Digital Economy in Victoria and was recruited into the role from a position in developer evangelism in the fintech sector. During that time, I was the primary point of contact in the office for a range of stakeholders in the ICT and startup/innovation sectors. I gained a huge amount of insight into the machinations of government. I also learned a lot about the way that various organisations interact with government. I was struck by the disparity in the level of sophistication of these interactions. Startups and SMEs in the innovation/technology sectors of Australia are, with a few exceptions, hugely underselling themselves with regards to Government Relations.
When I first started building a career in tech, I used hackathons to build a profile that I then parlayed into a role in developer evangelism. For a period of three years I was a ‘prolific’ hackathon participant, competing in 3–4 each year, and won many placings. These days I like to contribute to hackathons in less intense ways than competing. I mentor frequently and occasionally make appearances on judging panels. From time to time I get back on the tools and compete for fun. As someone who is an experienced hackathon participant, mentor and judge, I have insight and perspective on the role and value of hackathon mentors.
Hackathon mentors are often volunteers from corporate sponsors, and haven’t necessarily competed themselves. They are often unsure of the role they play and how to add value. A good hackathon mentor doesn’t need to have been a hackathon competitor or even a technologist to be a value add at a hackathon. As long as you understand what it is you bring to the table and how to communicate that effectively. The role of mentor can be interpreted in a few different ways, depending on the style and goal of the hackathon. I’ve made a few observations about what works and what doesn’t, which I’d like to share…
Sometimes I’m asked to help in situations where sponsorship agreements for conferences, summits, and other events have conditions of diversity and inclusion tied to them. For example, a tech conference that has a requirement for 50:50 gender diversity of those who are speaking (though, I should note that this is not the only way to have diversity and inclusion at your event).
I have quite a few projects in ‘beta’ stage for both Android and iOS, so I’ve become way more acquainted than I want to be with the painful process of beta distribution and store submission for both ecosystems. The two processes are vastly different, and in general iOS is way more of a pain and far more involved than Android. I finally decided to automate the whole thing from start to finish and make use of the amazing build tools that are out there instead of doing it manually. In the next two blog posts, I’ll share my learnings about how to use the iOS toolset in Fastlane, to completely streamline this whole schemozzle down to a single command.
When a specific integration involves one organisation/user, with one or more clients (in the server-client sense), this is the ideal use of 2-legged OAuth — where the client and server are known to each other. The basic premise of this is that since the client application is owned by the user, the user doesn’t have a need to authorise the application, the client and server just need to verify that they are who they say they are. We can skip the authorisation process and just sign our requests with a uniquely identifying signature. This has many benefits, including removing the need to repeatedly log in and verify an application, and longer term tokens.