For about a year I have been meaning to write a long-form blog post about my career advice for ICs Twitter thread… and it still hasn’t happened. 😄 I still get asked about this thread and receive comments on it quite a bit, so in the interest of making it easier to find I created this Medium post which simply links to it!
I also spoke about this thread/topic in two podcast episodes which I recommend listening to for more color:
Today we are thrilled to announce the initial OSS preview release of Envoy Mobile, an iOS and Android client network library that brings the power of Envoy Proxy to mobile platforms. This is the beginning of a journey that we hope mobile developers around the industry will join us on.
When Lyft originally announced Envoy in 2016, the project goal was simply stated as:
The network should be transparent to applications. When network and application problems do occur, it should be easy to determine the source of the problem.
Envoy proxy was initially built at Lyft to solve the networking and observability issues inherent in large polyglot server-side microservice architectures. Over the last two and a half years, much to our surprise and satisfaction, Envoy has become incredibly popular throughout the industry. Today Envoy is used by all major public cloud providers, countless end user companies, and a plethora of infrastructure startups that have recognized Envoy’s extensibility as a useful base with which to build vertical applications and services. For those not familiar with Envoy’s architecture and feature set, please see the links in the further reading section at the bottom of this post. …
I’ve increasingly noticed a disturbing trend in software engineering: the idea that any total program crash (via segmentation fault, panic, null pointer exception, assertion, etc.) is an indication that a piece of software is poorly written and cannot be trusted.
Although it’s true that, in some cases, crashes may be an indication of unreliable software and subpar development methods, crashing is also a valid error handling method that if used correctly can increase rather than decrease the overall quality, reliability, and velocity of a piece of software.
Ultimately, every line of code in a program is a liability that may lead to software defects. One particularly pernicious source of code and defect volume is rarely (or never) used error handling code. …