My Workflows at Trustbit During the Quarantine

The current situation has deeply affected our daily lives. However, in retrospect, it also had a surprisingly small impact on how we get the work done at Trustbit. 

We have the less cognitive capacity to focus on work these days. Focus itself is more fragile and schedules are less predictable. Yet the tools, connections, and workflows that we’ve been employing demonstrate resilience in the face of the crisis.

Please note that there are multiple teams working on a variety of projects. Things mentioned below don’t apply to the entire company (teams can steer towards different tools, programming languages, and workflows). 

“We”, for the purpose of this article is “a small team that focuses on data science projects for one particular customer”. 

However, if it is of any indication, I don’t think the workflows have changed drastically for the rest of the company as well.

Project Management

I use a private Notion workspace as a glorified journaling solution to track the progress across multiple projects. For each project there is a separate page in the following structure:

  • Header: 

    • current status summary (once sentence, that is rewritten on any major change);

    • list of JIRA tickets (closed tickets are left but crossed out);

    • links to any Confluence pages, deployments, repositories.

  • Journal - whenever something important happens (communication with some outcomes, project delivery, work milestone), I write down data and a couple of sentences about that. 

All projects are listed within the workspace, using their titles and status icons to distinguish between:

  • ongoing work;

  • waiting for something (feedback from another team, clarification, data upload approval);

  • paused (due to the priority change);

  • project lead;

  • closed.

We usually don't have that many projects being active in parallel (5 is the top), making it trivial to review the progress and sync up with the project stakeholders as needed.

I'm half-heartedly considering reimplementing this setup in a self-hosted Ruby-on-rails app. This would allow us to include more sensitive things in project logs: like data file samples, code snippets. However, links to the data lake work well enough for now.

Work Coordination

Actual work coordination happens in JIRA. Next actionable steps for a project are broken down into tasks. After the necessary requirements are gathered, they are written down in a JIRA task and passed to somebody for the implementation.

We are working in tight contact with the customer, so the planning horizon is usually short - one-two weeks (during the emergencies I’ve seen it go down to a couple of days). There are no explicit iterations, we just focus on maximizing the throughput of work being done.

We have a simple kanban board that tracks the ongoing work. JIRA tickets are referenced in the Project Summary in Notion, making it easier to dive into the task details, if needed for the review.

There are Confluence and Bitbucket - standard setup these days.

Communications

Most of our communication happens in the chats:

  • Teams (company chat);

  • Telegram (our team and important Grafana alerts)

  • Slack -> WebEx Teams (customer chat). 

A few years ago I would've been terrified at the need to run multiple chat clients of various fidelity. These days I find it convenient to have context separated in different chats with drastically different UIs. Focusing is easier this way.

We have a company-wide Teams call on Mondays - to catch up with colleagues around the world, see their faces and hear voices. Plus, it is an opportunity to share some news, exciting hobby project or frustration with a particularly pesky integration.

Then there is a biweekly coordination call with the customer (with a tendency to be canceled, since projects and priorities are usually set clearly enough to get straight to work).

There are occasional unscheduled work-related calls, but they are pretty rare. On average, I jump to a call once per two weeks, just to spend 10-15 minutes clarifying the big picture across projects or troubleshooting some specific edge case.

During the COVID lockdown, we started doing semi-regular "coffee" calls with the team. Their purpose is to take a break, connect and think aloud through the problems or next steps we are going to take.

Development Environment

These days most of my time is usually spent outside of the coding. It is talking, writing or troubleshooting things. These activities could be done with an iPad (with a mechanical keyboard) or even a phone (Google Pixel 3a, in my case).

I find that I'm using my phone for work more frequently during the COVID-lockdown. With it you need just one hand to answer a question, pass the information or assist a team-mate (the other hand could still be used to prevent 1yo from doing whatever he intends on doing).

When actual development has to be done, it always happens on 13' MacBook Pro (2015, without the touch bar). Software being used: iTerm2, vim, GoLand, and PyCharm. 

A surprisingly large portion of work happens within the browser: Google Cloud Platform, Apache Airflow, Jupyter notebooks, Jenkins, Grafana, Confluent Kafka, Kubernetes Dashboards and (of course) StackOverflow. Safari is my main browser, while the Firefox (with Containers extension) is used to manage separate login contexts.

I still use Emacs org-mode to handle timesheets, no actual development happens there.

There is a special place in my heart for Wireshark. A non-trivial amount of problems is network-related. Besides, there was that case when two Kafka clients (both non-librd) exhibited exactly the same bug in client-server interactions. Only the Wireshark helped to identify the root cause while keeping the sanity.

Wireguard and mosh play a particularly important role in the work - I have a dedicated work server with 8 cores and 16GB of RAM. It is located in Germany (close to the actual work site) and runs resource-intensive docker builds or computations.

All this setup has worked rather well before the COVID lockdown started, and it keeps on working fine. In the upcoming months, I (hopefully) don’t expect to see any major changes in the way the work is done. 

Zurück
Zurück

Introduction to Functional Programming in F# – Part 10

Weiter
Weiter

Introduction to Functional Programming in F# – Part 9