At ASquared, we blend commitment, curiosity and capability with innovation, and a huge part of that is having the time to take risks, explore and learn. We sat down with two of our awesome engineers to hear about their approach to using their professional development time and how it benefits them individually and as a team, as well as the company overall. So sit back as we dive into all things hackathons and tech spikes with James and Cal.
Cal: A hackathon normally takes place collaboratively in a workplace. It’s time devoted to trying to build something interesting as a team, that's not your normal type of work or project. It’s a rapid learning opportunity where engineers get creative together over a short period of time to solve a specific problem. A hackathon is different to a tech spike in my opinion, which is more of a sprint or investigation, like a time-boxed research piece to explore a certain topic or an array of possible solutions.
James: In a hackathon you’ll usually have some sort of time constraint and you'll set potentially unrealistic goals, but with the idea of pressure-cooking something good out of it, like exploring some totally new tech. It’s a form of extreme programming which is the idea that you might not get a production-quality product at the end, it’s more like a science project, the stakes are low but it’s absolutely possible to create something really cool.
Cal: Pick a topic that is current, relevant and that the team finds interesting. It could either start with a specific problem, or it could start by just wanting to do something fun!
James: For sure, it’s about making progress together as a team.You’d normally start with a statement or an idea and then decide what parts of that could form a hypothesis to explore. You want whatever you’re building to not be too dictated, so hackathons are done as non-billable work outside of projects. Sometimes they are aligned to a current project we’re working on or things we have coming up though - although usually those examples are more tech spikes to do some pre-prep spec work for new and innovative stuff. We use them to get ahead and grow our knowledge but also to ensure we have some fun internal projects which are motivating for everyone too.
Cal: Exactly, the objective is definitely not to build an end solution, it’s about the journey. That's really important. So it’s important to have some space when you get some downtime in client work, time box it, and ideally manage it like an internal project…get an awesome project manager involved, communicate with the wider team…
It’s playing to the endeavouring side of us that likes innovative thought experiments. In day-to-day work, there's not much room for that stuff because you've got constraints and time limits and definite goals. So I think a hackathon is one of the opportunities we have to have a bit of fun, play around and push our own limits a bit.
James: So sometimes we’ll initiate a hackathon and other times it’ll be a tech spike depending on the project. For simplicity we’ll talk about both examples here. In tech spikes sometimes the objective is to work out how to build something or see if an idea is actually possible or not, rather than a more explorative approach, and they definitely have a place in our developer experience too (which we’ve already written about here>>). Sometimes we need time to explore and understand what we’re doing, maybe at the proposal stage of a new project, or when preparing for a future phase of client work, so we can get ahead before the billable work starts.
This creates a lot of value for our clients as we can increase our knowledge and capabilities in a very specific area. For example, we’re doing some really interesting work in the generative AI space at the moment, and a hackathon or tech spike allows us to explore and learn the niche so we’re better placed to implement awesome work on client projects. It’s cool because we get to explore without being constrained.
Cal: We’ve also used them to improve on efficiencies before, by playing with different tech. For example, we did a hackathon to try and replicate an app that we’d already built in optimised code by using low code technologies. We thought maybe we could deliver better value for our clients by using some of the stuff that’s getting really popular now. We learnt a lot during the process and rinsed the low code technologies as much as we could. But, spoiler alert: we were faster, better and more able to deliver complex tech when we didn’t use low code.
James: Normally a hackathon is really useful if you have quite a loose goal and then you can check out whatever tech you want to. The dream hackathon is to have a complex but loose challenge and then for your team to figure out what you want to do and how you want to approach it.
James: The learnings from work like this are really useful. You make lots of decisions during a process like that to get to where you get to at the end, so the thought processes, creativity and learning leads to a ton of increased expertise.
Cal: Absolutely, they are also a chance for us to introduce some new developer tools. As an output of one of them recently we started using LinearB, which is to developers what Jira is to project management in a way. So it gives us top level insights into how we're working as a team, how quickly we're moving from starting a feature to getting it into the main project etc. Which is really interesting because it sheds a lot of light on areas where we can save time, and as a result of that we've made some significant efficiencies, like in a new project set up for example.
It also highlighted where we were already doing things well, because there are benchmarks on the time it takes to complete a ticket and get it into an app and then the amount of time you spend rewriting code and all sorts of industry insights. Generally we were doing really well already, which was also motivating.
Cal: Absolutely, from little tweaks to big changes. We can trial a way of working in a really low risk way, and it could even be something we’ve been well aware of and wanting to explore for a while. It's also a really good opportunity to see why other solutions might not work as well for us.
For example in the low code hackathon - where low code was supposed to give you 10x faster development than regular code writing - in the same amount of time, using regular code but with knowledge gained from LinearB, we delivered more features, a better documented project, an error tracking suite and something that actually worked on mobile. So, yeah: a lot of learning into ways of not working too.
James: You can come back and reap the benefits of learning new stuff as well, and dip in and out as a kind of knowledge base on projects too. Like with some really progressive AI tools, they’re fun to explore but there are definitely nuances to make things cost effective and scalable, and obviously it’s moving so fast that you have to try hard to keep at the forefront of it.
Cal: Yep, you can build something pretty progressive and then a month later some new tech has come out which replaces 90% of the work for you. But it’s still interesting to have gone through the process and really understand how it works rather than just plugging stuff together. It’s also surprising, when you really get into it, how incomplete some of the AI tech is right now. Ultimately to create anything production-ready you do still need to know what you’re doing underneath it all because the AI tech isn’t quite there yet, and you don’t have much control over fine tuning it.
It can also be a good chance for us to work outside of Typescript (which is the majority of what we do), because in AI there's a lot of Python code which is generally because of the data handling stuff, so it's always nice sort of speaking a different language for a little bit. It’s definitely linked to professional development too. It benefits you individually as an engineer, and as a team, as well as the company overall.
—
At ASquared, we believe in the continuous growth and development of our team. Amongst striving to provide an excellent developer experience >> we also provide dedicated time for our employees to focus on their professional growth and learning. We allocate professional development time for four hours every week for full time employees, and pro-rata it for part time employees. Pushing the boundaries, exploring and taking risks are things we are really proud of and actively encourage.
Let's see what we can make together.
From startups to scaleups and enterprise, we're always happy to talk to impact-focussed and ambitious organisations. Use our quote creator to get a better idea of scope, timescales and next steps.
