28 Jan 2016

Geonomics conferences attended 2015

At Geonomics we value the continuous improvement and personal development of everyone on the team, and we are always looking for ways to improve our processes and working practices. To this end a number of our team members have attended conferences, talks and events which you can find out more about below.

Chrome Developer Summit

Lewis attended this event in November. As the name implies the focus was very much on Google Chrome and discussions around a lot of the new features that are being built for the browser such as Web Service Workers to enable better offline experiences. There was a big emphasis on improving web app performance and Lewis came away with a number of short term and longer term practical points for how we can improve the end user experience of our products:

  • Ensure all images used by our apps are losslessly compressed as part of our build pipeline
  • Ensure all of our JavaScript files are concatenated and compressed (we still have a few that aren’t)
  • Target a 1 second load time for all our pages, and investigate deferred loading of resources
  • Target a frame rate of 60 fps for our canvas animation code

All of the talks are available here and the code labs are here.


David and Lewis went to the two day JAX conference in October. As with Devoxx, there was a big focus on microservices and Java 8 features. It was gratifying to discover that a lot of the best practices (such as having a static analysis phase in our build pipeline) and new features talked about during the two days are already in use here at Geonomics.

One area in particular that we had already been looking at was ORM vs native queries. David did a lot of work over the last year to learn more about improving database query performance by using less well known query language features such as the OVER clause and WINDOW functions and spreading this knowledge to the rest of the team via our regular Developer Learning Lunchtimes. As a result of this we now always consider whether or not to write a given query in Hibernate or native SQL to provide the best performance we can. For example, one of the queries we use for tracking when players made their first wager on the site vs when they made their first wager in each individual game makes use of PostgreSQL WINDOW functions. This would not have been possible using a Hibernate query. Instead we would have had to load the data into memory and process in Java.

One of the talks that Lewis found most valuable was on how we can apply the “automate everything” principle of continuous integration to non development areas of the business. This was an ever useful reminder that we can always strive to improve efficiency and productivity by automating manual tasks and processes. We already use Jenkins to automate as much of our daily release process as possible, including not just the code compilation part, but also generating email reports about which feature flags are being turned on for that release and detailed reporting about our Selenium tests. Whenever we introduce new processes, our general approach is to first do them manually. Once we have ironed out the kinks and matured the process then we automate as much as we can.

The focus on Java 8 was particularly interesting for us. Before Java 8 was released back in 2014 the dev team at Geonomics considered migrating to Scala from Java 7. We had concerns at the time regarding Scala’s compile times and complexity. It also seemed that many of the beneficial features of Scala would be included in Java 8. All of the developers on the team weighed in and the consensus was to wait for Java 8 and continue using Java. It was good to see that the Java community has embraced Java 8’s new features. Of course, Lewis is already looking forward to the future release of Java 9, in particular the introduction of value types.

The Lead Developer conference

Luke, Prem and Paul N attended this brand new conference in September. The single day conference focussed less on purely technical topics and more on how to be a good team lead and dev manager.

The conference was particularly timely for Luke, one of our developers who was just about to become a team lead. It really highlighted for him what challenges to expect in the role, such as a greater need for rigourous time management, how to deal with what motivates people, and a less purely technical focus when it comes to personal development. Because most team leads at Geonomics joined first in a technical role Luke has access to people who have been down the path he is on and can offer practical tips and advice, in addition to more formal training such as the management training course he recently went on.

The dev team lead role at Geonomics one is a broad one. First they must be an excellent developer. We believe the most effective dev managers know how to deep dive into the code just as well as the people they manage. Second they must be able to effectively manage people. Team leads need the ability to motivate and encourage the people on their team, help their team members with their own career and skill development, and give constructive feedback when something needs to be improved. Third they need to be effective project managers, acting as scrum masters and making time to deliver vs scope trade off decisions to keep our products moving forward at a fast pace.

For Prem and Paul N, two of our more established dev team leads, one of the main takeaway points was that to continue adding value as a team lead the focus becomes less on learning new technologies and more on improving other non-tech skills such as:

  • People management. One of Paul N’s favourite talks was from Sam Barnes on how you can never use yourself as an example of what is “normal”. Everyone is different and people have many different motivations which need to be taken into account when managing them.
  • Improving productivity. The excellent talk by Camille Fournier made the case that cloning yourself is not an option. A team lead can improve productivity by “training their replacements”. This enables effective delegation and trust that the right things will get done, regardless of which member of the team is doing the task.
  • Effective prioritisation and judgement. Team leads and managers are often faced with seemingly mutually exclusive options such as writing high quality code while also meeting tight deadlines. Patrick Kua gave a talk on how to deal with apparent paradoxes, advising on finding the right balance between conflicting requirements and how this balance can and should change over time.

Overall this was a really valuable addition to the yearly tech conferences held in London and we’ll definitely be sending people again in 2016.


Kayhan and Paul L attended this long running Java conference in June. As was a theme at a lot of the conferences we attended this year, microservices took centre stage. Having switched to a daily release process early in 2015, we can definitely see the value in having smaller single responsibility components to enable us to release changes to production even more frequently. For those who have been living under a rock, “microservices” is a term applied to building complex applications from small decoupled components that talk to each other using language agnostic APIs. It’s pretty difficult imagine how an application will grow and ultimately where code responsibilities should lie when working in a fast-paced startup where product requirements are changing continuously. As such our codebase has grown predominantly as a monolith initially, an approach recommended by Russ Miles in his “Highway to microservices hell” talk at the Lead Developer Conference. Once the broader scope of the entire application is more well defined, then it can be broken down into smaller independent services which is on our architecture road map.

One of Kayhan’s favourite talks was about the information your continuous integration server is giving you about ways to improve your application architecture. The techniques discussed don’t help us very much when our application is a monolith, but they can definitely help us as we migrate towards a more modular application architecture.

London Technology Week – Coding & Caffeine: The Search For Technical Talent

Matt Young, our CTO, attended this talk from Joel Spolsky (of Stack Overflow fame) in June. One of the key points to come out of the talk was that attracting good candidates is not something that starts and ends with an “HR person”. Everyone on the tech team is responsible for creating an engaging and attractive place to work, with a good technical culture.

So what are some of the qualities we believe create a good technical culture?

  • Positive attitude. Any seasoned developer can look at a new codebase and point out a whole bunch of things that aren’t great about some aspect of the code. What we value is people who can come up with and implement a plan to continuously improve our code.
  • Desire to learn. Nobody is perfect, no one has all the answers. We greatly value people who are self aware enough to know what their relative weaknesses are and motivated to learn and improve their own skills. If they can do that while simultaneously improving the skills of those around them then even better.
  • Communication skills. Being able to communicate clearly and concisely, both verbally and in writing, is incredibly valuable to us. This is particularly important when working with a remote team for whom English is not their first language, as discussed below.
  • Ability to handle pressure. Sometimes things go wrong, it’s a fact of life. We value people who can keep their cool in such situations and deal with the immediate problem by thinking calmly and quickly through what went wrong and how to fix it. They can then come up with a solution to ensure that the particular problem or class of problems can never happen again. And they can do it all without feeling the need to shift the blame onto someone else.

One of the subjects touched on during the talk was remote working. We have an excellent QA team here at Geonomics, who just so happen to work in Ukraine and Russia. We have no doubt that our products are of a significantly higher quality than they otherwise would have been due to their contribution. The fact that they are not co-located with our developers does however present challenges when working on projects together. One of the biggest benefits of working in a co-located group is the ad-hoc discussion that can often occur that can see the seed of an idea turn in to a whole new product direction in a short space of time. The final outcome of such a discussion is of course communicated to all relevant parties, but the journey towards that decision or outcome is often lost for some team members when working in a distributed team. At Geonomics we work hard to ensure that both the why and the what of a piece of work is clearly documented for all team members to see, regardless of location.

Cassandra Day

Mykolas attended this single day event in April. Cassandra is a very interesting technology, offering an elegant solution to traditional problems such as the database being a single point of failure and it being difficult to scale. The ability to scale performance linearly with each node is extremely attractive (although it may come at the cost of latency). One of the big downsides in the context of our games is the “eventually consistent” nature of the database (see CAP theorem). As our games are real time in nature and one player’s wagers may affect the choices of another player we value consistency and having ACID transactions so that all players can see every other player’s actions in close to real time. As such Cassandra isn’t really suitable for our main game platform, but it’s useful to know that the technology is there should we have any future applications where availability and resilience are valued to a greater extent than real time consistency.

Sound like a place you want to work?

We’re always on the look out for talented and enthusiastic software engineers to join our team. If you’re interested in working with us then send us your CV and an optional cover letter to You can read about our interview process here, here and here.

Leave a Reply

Your email address will not be published. Required fields are marked *