How Hashicorp works – Hashicorp develops open-source products that are widely used in the industry including Terraform, Vault, Consul, etc. “How HashiCorp Works” provides a glimpse of Hashicorp’s culture and practices. I appreciate this kind of transparency and chance to learn.
Make boring plans – a more accurate title would be “make predictable plans”. That is, the next tasks should be predictable based on the team’s knowledge regarding the product pains, bug, customers’ requests, etc.A possible good way to measure how boring the plans are is to ask the team to prioritize the top-k tasks we should work on in the next period (quarter \ sprint, etc.) and check if the tasks overlap. Disclaimer – each team member has its’ own view, pain points, and features they would like to develop and might be biased towards it.
Explainable AI Cheat Sheet – cheat sheet, video and resources regarding XAI. This is a very good way to get into this field.
I’ve code reviewed over 750 pull requests at Amazon. Here’s my exact thought process – code review is an art and is a way personal relations manifest themselves. One day I might write a longer post about code reviews but for now I want to focus on the last 2 points in this post – “I approve when the PR is good, not perfect” and “I seek feedback for whether I’m reviewing well”. “Good not perfect” – this depends on the team standards, DoD, the PR scope, etc. Specifically, in startups when the time and money are limited each delay has its’ costs. “I seek feedback” – how is the quality of my CR is measured? what are the goals of CR (familiarity with the code, finding bugs, enforcing standards, something else?)?. I would like to see or find ways to assess the quality of the CR and give feedback to the code reviewer.
My Clean and Tidy Checklist for Clean and Tidy Data – it is commonly believed that “Data scientists spend 80% of their time cleaning data”. This post provides a conceptual framework to clean data so the time data scientist spend on cleaning data might drop to 79% 😉