Image by Randall Munroe, xkcd.com
I'm Andrew Newdigate. I'm from Cape Town in South Africa. I have a degree in computer science from the University of Cape Town, and I've worked as a software engineer in the healthcare, finance, telecoms, and tech sectors.
I've founded several companies, but the only one you may have heard of is called Gitter, which was acquired by GitLab in 2017. This is how I joined the company.
I lived in London in the UK for 17 years, but moved back to Cape Town in 2019. When I'm not working I love building stuff, travel, photography, music and camping and hiking in the great outdoors.
The Distinguished Engineer, Infrastructure is a member of the Infrastructure team and works with both department leadership and individual contributors to achieve the department's objectives.
DE Infra Issue Board: this board contains many of the issues I am currently focused on. I try to keep it up to date. Higher priority items are near the top.
feature_categories). This is a two-way process: it's about encouraging development teams to be involved in the execution of their code in production and infrastructure teams communicating back to the development teams.
Of all the attributes that go to make up a distinguished engineer, being the engineer that inspires and helps others is, to my mind, the single most important. A distinguished engineer is someone a team can build around for any project, a person who will spend time developing others and making them far better at their job then they were before.
Engineering ICs are welcome to reach out to discuss career development, mentoring, either on a formal or informal basis. Setup a coffee chat, or find me on Slack to start a discussion.
A distinguished engineer will bring a relentless focus on delivering value for customers. They understand the customer need, and when it’s a new market they spend a lot of time trying to understand what the potential needs will be. They adjust course when necessary, and bring their team long with them.
I'm happy to engage with technical teams at prospects and clients. Account Managers are welcome to book time in my calendar for this.
Inspiration taken from https://randsinrepose.com/archives/how-to-rands/.
A heavy bias towards action
Long meetings where we are endlessly debating potential directions are often valuable, but I believe starting is the best way to begin learning and make progress. This is not always the correct strategy. This strategy annoys those who like to debate.
Related to the previous point, frequent, small, low-risk reversible incremental changes are almost always preferable to big risky changes. Compounding small incremental changes leads to big outcomes while keeping risk low. Big changes are nearly always a smell and I will encourage
I am always willing to accept feedback, and will try my best to address it. Please DM me on Slack, or better yet, setup a call.
Occassionally I will talk at conferences. Here are some of the talks I have given:
Good observability is critical to managing complex systems at scale; having quality metrics is key to this. But as system grow, the number of metrics they produce rapidly increases. Dashboards and alerts can become difficult to maintain and lead to technical debt. This talk describes the strategy we’re using at GitLab to tackle this.
Practical Capacity Planning Using Prometheus
GitLab.com’s monolithic Rails application experiences high week-on-week traffic growth. To ensure availability, GitLab’s Infrastructure team track and plan ahead in order to avoid hitting capacity limits in the application, whether these limits be CPU, database connection pools, memory, storage or any number of other finite resources. Hitting these limits could result in hours, or days, of degraded service while workarounds are put in place.
With this in mind, the team set about building a set of tools on top of Prometheus recording rules and alerts to provide them with the information they need to be sufficiently forewarned, up to a month in advance, of potential resource saturation issues.
If you’ve ever felt that you’re reactively responding to resource saturation issues, this session will provide practical examples of how we’re building resource planning into our SRE team workflow. We’ll be presenting our open-source solution and explaining how it works for us.
Practical Anomaly Detection using Prometheus
At Google Cloud Next '19, GitLab Staff Engineer Andrew Newdigate presented our migration experience and the steps we took to make it happen. Migrations seldom go as planned but we hope that others can learn from the process.