Career advice

Career advice from Principal Engineer at Amazon.

Leveraging type systems to your advantage

Video explaining how you can use Rust’s type system to describe your business logic. Many of the ideas can be transferred to other languages.

Rules of thumb for Go

In English, the phrase “rule of thumb” refers to an approximate method for doing something, based on practical experience rather than theory.

Github link.

This project’s aim is simple. To provide some rough baseline measurements for common decisions you have to do every day as a software engineer:

Do I use map or a slice here?

TL;DR: use map when len(haystack) > 100 && len(needles) > 100

I need to deduplicate this, do I use map[T]struct{} or just deduplicate the slice?

TL;DR: use map when len(haystack) > 100. Use slice when the elements are pre-sorted.

There is many more in the repository. There are so many discussions like these in every engineering team. It often comes up in code reviews - “you should use *struct here instead of copying”. OK, but why? At what point is it beneficial?

Careful with io.TeeReader and json.Decoder

Some time ago, I was investigating very strange bug in our codebase:

http: ContentLength=513 with Body length 512

It was inside our Go reverse proxy, and what was very suspicious was the exact 1 byte discrepancy.

My suspicion was on gzip middleware, which is often the cause when you forget to set request.ContentLength after compressing the payload. However it turns out it was not the case.

Do you see anything problematic here?

As

As is a library to convert numeric types with overflow check in Go.

Why?

Other languages like Rust have overflow checks on type casts (if you use TryFrom and not just as), but for Go there is nothing like that.

My need came from a simple bug, where external integer type was being type casted multiple times across multiple API boundaries. Because the original integer size was hidden across several API hops, the affected code expected too small integer size, and overflowed.