In-person conferences are back! A recount of VoxxedDays Downunder 2022

“Too wild” some might say. We’re conferencing with people in person again and it’s good to be back. And guess what? The handshake is back too: “nice to meet you, I’m Bob. Please touch my filthy possibly COVID-infected hand and shake it for several seconds”. What a time to be alive.

I attended the VoxxedDays Downunder conference (associated with Devoxx) in Melbourne in February 2022 and I’d like to share my thoughts and observations. Even if you might not be interested in the talks I chose to attend I hope this gives you an insight into what others in the industry are currently focused on.

The general Voxxed vibe

I mentioned this to someone I met from Kogan: This is my second VoxxedDays conference after attending in 2019 and I like it because it has a very grassroots feel. It’s local. There’s a representation of the local software development community in one place that generally don’t meet anywhere other than at conferences (or at meetups - but that’s only starting to happen slowly again in person). I didn’t expect industry-leading international speakers flown in from their coding caves but that’s not really the point of VoxxedDays.

I like that that VoxxedDays organisers refused to do an online conference and kept pushing to do it in-person.

Observations and themes

Talk vibes

  • There seemed to be more talks on introductory Machine Learning topics. I don’t know if this was a callout from conference organisers but there was definitely more of this topic than in previous years.
  • I craved some talks on software engineering best practices and architecture design. I didn’t find any. I really wanted to find something I could take to my day-to-day work and apply it but I didn’t find much that I could practically use. Maybe that’s more of a YOW! Conference thing.
  • JavaScript is well and truly the default example language that most speakers go to. What a shame.
  • AWS is definitely not as dominant as it used to be in the industry. Far more cloud-related talks use Azure in their examples.
  • Kubernetes is still strong in terms of the ops/container space. It’s not really my area of expertise but generally that was the vibe.
  • In terms of API/backend it seems that gRPC seems to be mentioned in talks far more than REST these days. Perhaps gRPC is more dominant than I originally thought.

Non-Talk vibes

  • Sponsors are still fighting hard to remind you that they’re the best place to work. “Please, please for the love of God please apply with us” is all I heard (in my head) after I said hi to some HR representatives.
  • I have no data to back this up but it felt like more consulting firms were sponsoring the conference. I think in future we’ll see more people in the industry building their careers from consulting firms over being at product companies.
  • It was strange that there was no opening keynote or closing locknote to set the tone of the conference. The talks just kind of…started.
  • The swag was okay this year. I found that a few more sponsors are deciding to donate to charities than give out swag and hey, that’s cool.
Conference swag from the VoxxedDays Downunder 2022

Networking

Like most people, I think “networking” is a bit of an icky word and rarely people want to attend conferences for networking alone, even though deep down we know it’s somewhat important. It’s easy to think that networking is just saying hello to random people and finding out a little about them and then never talking to them again amongst a group of socially-awkward software people who’d rather be talking to their IDE. In the past I’ve planned my networking approach but this time I didn’t and I’m happy it went as follows:

  • I spoke with some former colleagues from MYOB in depth. It’s amazing how far people have spread across companies now. Speaking to someone who I started with at MYOB who’s now a Tech Lead at Bunnings and how the company is changing from a retail organisation to a technology organisation is pretty cool. I mean everyone loves Bunnings.
  • I spoke with a few second-tier connections. Yes - that awkward moment when you say “Hi I’ve seen your face before but I don’t think we worked together”. That was really nice to have a chat to people where we both knew that had mutual colleagues/friends.
  • I spoke with my former mentor who’s now at Zendesk in depth. We found it really hard to catch up in-person and this was a great place to do it. He even introduced me to some of the team at badook.ai. It was a real privilege to talk to a conference organiser and sponsor in a more informal way through a mutual friend.
  • I spoke with some graduates who are going through the graduate program that I went through many years ago. A little bit of nostalgia.

The only way I’d be able to do all of the above is to just be there and be willing to talk to anyone. I don’t consider myself a well-connected person but honestly I think every little interaction counts.

Conference Talks

I attended the following talks:

Getting on the refactor tractor

A person from Cogent presented some strategies on refactoring code. I’m not a frontend person but the React/JavaScript examples were comprehensive and the principles being conveyed were relevant and explained well. Test Driven Development wasn’t really encouraged here - which is a shame. But I don’t want to miss the point of the talk which is to look at how to refactor, in the context of a characterisation test - essentially using tests to guide you on what the current code is doing, updating your test and then using that test to know you have the right behaviour in place (and then do your refactoring). I think this is great in the scenario where you don’t have tests. I would be wary of ever going somewhere that didn’t have tests but since the speaker works at a consulting firm I suppose they could walk into any client with a mess like that on day one.

Takeways:

  • The benefits of refactoring are for: faster future development, creating less bugs and having fun. I would also add readability for other developers working in the codebase.
  • The costs of refactoring are: time (tradeoff of not delivering customer value) and the risk of breaking things.
  • The speaker’s suggested strategy is to only refactor if you’re working on something where another change is being made at the same time and/or if you know someone else will make a change soon. Use tests to determine current behaviour.
  • Martin Fowler’s Refactoring book is a good one to read according to the speaker. I have this book but haven’t worked my way through it yet (mainly because I’ve gone through other books on this topic already and I have different books I want to get through first)
  • Michael Feathers’ Working Effectively with Legacy Code book is a good one to read according to the speaker.
  • If using JSX with React, don’t just use regular unit tests. Add snapshot tests to help you get an idea of state. Nothing new here, I was using snapshot tests in our React app at MYOB in 2018-2019. Also I don’t know if this is best practice in terms of testing state on the frontend…
  • The slides are here and the Github repo is here
ArrowKt: Kotlin functional programming

A speaker from CashApp presented on their functional programming journey with the ArrowKt library. It’s basically a way to write Scala in Kotlin… I like that the speaker focused on not ‘over-FPing’ the codebase and looked at readibility in terms of introducing some functional concepts but not overwhelming the code with functional programming style code as to make it so hard to refactor unless someone had come from an FP background.

Key takeaways:

  • Functional programming has its own concepts that you need to understand first. The speaker discussed Pure Functions, Immutability, Declarative code, no side effects (ie. deterministic) and referential transparency (substitution.). This blog post (unrelated to the speaker) summarises some of these concepts.
  • The speaker’s opinion is that Functional Programming makes it harder to write lazy or illogical code.
  • Examples were given in the context that we can think of our code as a giant state machine.
  • ArrowKt gives you a way to add functional error handling: the Option and Either types, for example.
    • Option type - it was the speaker’s opinion that using this type is easier to read than using chains of ?. everywhere. I don’t agree.
    • Either type - this can be used to show that a function return a value or an error. I quite like this - nice example here
    • side effects as values: IO type - can wrap it around something eg. like java’s File read.
  • The speaker then dived into some specifics of the library maintainers deprecating IO and then un-deprecating it which caused some pain moving from IO to suspend functions with Kotlin coroutines. Sounded painful. But the speaker likes coroutines anyway and said it was worth it in the end.
  • The main learnings were not to go overboard with introducing Functional Programming to programmers that are not FP-natives - there is a massive readability tradeoff. Complexity was introduced with validations and combining validation results; hard to get right. Learn together as a team what a good balance is. Lightning talks & book clubs worked well for her team.
What’s all this about quantum?

A person from Microsoft presented on the current state of quantum computing. Fortunately, it was not a Microsoft sales pitch. This person is a Principal SDE and worked on the first quantum programming language - Q#. An overview was given about where we are today in ‘classical’ computing and the types of problems quantum computing is trying to solve. I’m not from a science background and the talk became a little too specific to physics/chemistry modelling but it was interesting to see where the state of the technology is today and that it may not even be in our lifetimes that we see this technology mature.

Takeaways:

  • Think of computing today as ‘classical’ computing - what we do with 1’s and 0’s. Moore’s Law is a big topic here: “the number of transistors in a dense integrated circuit (IC) doubles about every two years” - but the clock speed frequency MHz has plateaued since early 2000’s according to the speaker. Single electron transistors have already been built - this is now achieved. Therefore we can’t make chips it any smaller. Also we can’t remove heat fast enough. TL;DR: Moore’s law will fail in future.
  • The speaker discussed a (large) molecule simulation. A molecule is a quantum system. Some ‘classical problems’ need more atoms than the number in the universe to solve. Solving 1000-10000 electron systems cannot be solved with classical computing. Another example: Cryptography - finding the 2 prime factors of RSA; even halving 2048, a 1024-bit number will take half-million core years to factor (ie find the prime factors to ‘crack’ it).
  • I remember touching on this at university but I’m no expert - the great P versus NP problem is super relevant to quantum computing. The speaker didn’t dive in too deep, only to say that NP Complete problems (for example the Travelling salesman problem) and other related problems are all really hard to solve for large n. And they don’t scale well in classical computing.
  • How does quantum computing help to solve these problems? Well, the speaker didn’t go into what a qubit is but the premise is that quantum computing scales better. Solving a problem twice as big requires only one additional qubit (for quantum problems).
  • The main issues is that scientists are still trying to find ways to build qubits. Now it is like “writing something the sand” - they wash away easily. We can’t build them reliably. Research is happening globally at both universities and big tech. They all have the same problem - they’re noisy. They don’t hang onto information long enough for you to operate on them. We have systems now with around 6 qubits. We will need 1 - 10,000 physical : 1 logical qubits to solve some major problems. There is no mass manufacturing possible yet and there are significant engineering challenges. especially due to low temprature requirements.
  • The other problem is that we have no industry standards yet. Using a quantum computing machine at IBM won’t be the same as at another company.
  • The languages are very primitive; it’s very early stage. Code optimisation is not there yet. There are decades worth of improvements to come. Only a few algorithms exist. But there isn’t a lot of progress on developing new algorithms to leverage quantum mechanics/computer to let us use it practically to make it worth it. Critics have said that it might not even be worth it. And that it might be a long time until we have hardware to even let you develops new algorithms. This could be decades. Current algorithms are not actually that practical. They are more for determining whether QC ‘has legs’.
  • As of today, we can successfully factor 35 into 7 x 5. Ie factorisation to crack RSA-2048 you’d need 4000 logical qubits. If we can make it to that point and get to somewhere we can actually have 4000 logical qubits, then the industry might not even be using RSA-2048 anymore.
  • You can’t use it unless you have your own quantum computing rig but you can read more about the Q# language and SDK here.
Riding the streams - event streaming at CashApp

Some speakers from CashApp looked into replacing some of their backend systems with Kafka and it wasn’t suitable for their specific use case. They decided on Apache Flink as an alternative. This involves creating your own event streaming cluster and writing all the ops tooling around it. Not a small feat but for the most part this was a very niche use case where Kafka probably fits most use cases in this area, it didn’t suit them.

Takeaways:

  • One use case was for scheduled jobs (reports). They had monoliths communicating with each other via gRPC. The moved their data flow to event streaming.
  • Apache Flink fit their use case best. Kafka was not chosen due to: unreliable kafka consumers in K8’s; needing to do DB provisioning; inefficient use of DB storage. And they didn’t want to go with a managed cloud provider service.
  • Flink has similar concepts to Kafka. For example, connectors with other sources; watermarks are checkpoints in time in the event stream;.
  • They built their own ops apps for observability, analytics and provisioning in golang to manage the flink cluster itself (CLI tools)
  • Flink is viable for this use case but some challenges: distributed architecture programming model was hard to grasp at first; state management and evolution of the domain model was managed with protobuf (better for versioning in their case).
Well-architected framework at scale

Speakers from MessageMedia discussed the fact that they had to solve ‘interesting’ engineering problems such as having big traffic spikes on some days with their SMS service. The main premise of the talk was about team empowerment rather than the technical solutions.

Takewaways:

  • MessageMedia took the AWS Well Architected Framework and customised it to their own needs; helps to drive conversations with teams.
  • People need to continually learn and master their craft. Developers don’t like asking for permission to do this stuff. They considered how to make it organic/easy.
  • They found some success in giving AWS certifications to all engineers. The team bonded over learning together. Their view is that upskilling everyone via AWS certificates led to a better understanding in teams during technical discussions (having a common language).
  • Decoupling an API with SQS with async saved them money. The AWS Well Architected Framework drove that change since their engineers were empowered to come up with their own SQS solution.
Governance from day one - AWS Config

Like most talks from people at Amazon, this talk reinforced the idea to the audience that AWS products are the answer to all your problems. This was not a technical talk but rather a high-level product overview.

Takeaways:

  • Make sure you consider ‘How to be auditable?’ in your systems.
  • That there is a challenge of of “move fast vs stay secure”.
  • A reminder to view the Guideline/framework - AWS has the 6 pillars in the well architected framework architecture.
  • Use AWS GuardDuty for incident response. It is the best thing evererer.
  • Use a playbook. A playbook is looser than a runbook. Less defined steps.
  • With IAM make sure you configure stuff properly.
  • Follow the principle of least privilege.
  • Configure your policies properly.

Final thoughts

  • I should think about doing a talk next year. Something Kotlin related. I don’t know what just yet but I think at this point in my career I want to think about what I could contribute over what I could take from this community that gave me so much.
  • Even though the talks were not groundbreaking, it is still absolutely worth attending these conferences.