RUG::B

When I founded trecker.com (software für farmers) in 2012, I made lots of mistakes and lots of learnings. In 2016 I quit my company and started a new one (software for architects). Since then I am bootstrapping alone and it is much more full-filling. In this talk I would like to share my experiences and learnings with you.

In the development world most people are striving for technical excellence: better code, faster run times, more convenient interfaces, better databases… But is that really what helps us create better software?

In the end software development is done by groups of people creating products together. To do that communication and collaboration are essential. You can be the best programmer ever, but if you can’t efficiently work with others what good does it do you?

This talk will introduce you to relevant, easy to grasp concepts of collaboration and communication as well as give you food for thought.

This is a preview version due to be given at heart of clojure in the future.

When you build a data intensive application, it is critical to avoid resource contention at various layer. However, does everything designed/adapted by big companies like LinkedIn, Google, Facebook suit your needs?

I’m a self-taught software engineer, now leading a technical side of data-intensive software dealing with “mid-sized data volume”. Based on the approaches we’ve taken over the past few years, I see a lot of more conventional toolkit to avoid resource contention that you can start using today.

The list of mitigations are also full of anecdotes, with real incidents behind it. So the audience will learn that depending on the type of contention you experience, there are different types of mitigations you should consider implementing.

The audience who’s familiar with Ruby, Redis, Postgres stack will get the most out of it, but is not limited to them, since the type of mitigations are generic, and can be said to other tech stacks as well. I’m personally fascinated about the contention, as it can take down the whole pipeline if badly designed, and building low latency, high throughput system is really a challenging problem to solve :)