About a year ago we set down to document the core values of the engineering at Teem. After a lot of discussion we narrowed it to three core ideas

  1. maximize positive impact
  2. communicate
  3. be a good friend

I would add one more unofficial value: mentorship and continuous learning. About the same time we also started thinking about how we describe/define an engineers career path and we quickly realized that measuring progress is hard and that measuring commitment to our core values is even harder.

Should you remove data from the database or simply mark it as deleted? At Teem we have a lot of data that we need to manage and often “physically” deleting the data from disk can be problematic. Either the users simply wants to undelete something or the deletion would cause problems for a log. The generic solution to this problem is to soft delete/archive the data by adding a deleted_at timestamp field to the table and then filter all queries to hide rows that have been marked as deleted.

Perhaps the one piece of ubiquitous technology that you will find at any new tech company is git. There are a couple of other technologies that you will probably find, like AWS, but git is the only one I expect to find everywhere. It is also, surprisingly, many developers number one frienemy. I want to share some of my favorite tips and tweaks that I have used over the years to make it all friend and never my enemy.

A traditional Bavarian Hefeweizen: medium body, cloudy, malty, and spicy, with a smooth mouth-feel and dense, whipped-cream head.

At Teem, we aim for zero down-time deploys; so, one of the most important things we must validate is that things will not break mid-deploy!

The most sensitive step of the deploy process is the changes to our database. Prior to the automation I am about to describe, validation of the database migrations required specialized knowledge about Postgres, the changes to the application model, load on the database for that model, and a bit of general experience. This obviously slows down reviews and subsequently deploys. Worse, it was simply too easy to miss problem migrations when depending on only peer reviews. To make our lives easier we created a series of validation checks to ensure that each database migration will be backwards compatible.

How do we build a fast API against database models with foreign keys and many- to-many relationships? If you do nothing you get what I call the “waterfall of doom”. At some point in the past someone told me or I read that “joins are effectively free in Postgres”. While this might be somewhat true when you are writing all of the SQL and can control every part of your query; I have recently found that when the database gets big enough and you are using the Django ORM, joins aren’t free and less can be more!

The other day I was having lunch with a friend when he asked what resources I use to learn about management and tech leadership in general. I will share some recommendations at the end, but my answer to him got me thinking about my philosophy around management and how to be good at it, which is what I really want to share here.

TL;DR: be a multiplier for your team and reduce friction.

Lucas Roesler

I am senior engineer at contiamo.com and an ex-mathematician. I have worked on web applications, algorithms for image analysis, machine learning problems, and pure math research.

Senior Engineer

Berlin, DE