Hasnain says:

Interesting post mortem from a long tenure at a big tech company.

Brad is no lightweight; he’s written a bunch of critical software that powers the internet - even before joining Google.

The reasons for leaving were also interesting:

“Little bored. Not learning as much as I used to. I've been doing the same thing too long and need a change. It'd be nice to primarily work in Go rather than work on Go.

When I first joined Google it was a chaotic first couple years while I learned Google's internal codebase, build system, a bunch of new languages, Borg, Bigtable, etc. Then I joined Android it was fun/learning chaos again. Go was the same when I joined and it was a new, fast-moving experiment. Now Go is very popular, stable and, while there's a lot to do, things--often necessarily--move pretty slowly. Moving slowly is fine, and hyper-specializing in small corners of Go makes sense at scale (few percent improvements add up!), but I want to build something new again.

I don't want to get stuck in a comfortable rut. (And Google certainly is comfortable, except for open floor plans.)”

Hasnain says:

This was an interesting take on procrastination and productivity - and proposes an approach that might lead to better outcomes

“Increasingly, however, psychologists are realising this is wrong. Experts like Tim Pychyl at Carleton University in Canada and his collaborator Fuschia Sirois at the University of Sheffield in the UK have proposed that procrastination is an issue with managing our emotions, not our time. The task we’re putting off is making us feel bad – perhaps it’s boring, too difficult or we’re worried about failing – and to make ourselves feel better in the moment, we start doing something else, like watching videos.”

Hasnain says:

This is an interesting new development - it’s always great when people revisit some of the fundamentals. Not sure if this info will percolate elsewhere though...

“Dr. Parsonnet suspects inflammation caused by those and other persistent maladies explains the temperature documented by Wunderlich and that a population-level change in inflammation is the most plausible explanation for a decrease in temperature.”

Hasnain says:

This was an interesting “technical” read on project management and expectations from a senior engineer.

One thing I liked was that the author was not prescriptive - rather, just laying out an expectations framework. There is a link to a more detailed document as well as a prescriptive version for people doing this for the first time - I skimmed those and they seemed legit.

“I tried to put all of these as guidance: being clear on the expected output, but not specifying the “how”. Want to do this via Scrum? Fine. Adhoc? Also good. Some weird, new method? Go ahead. Having space for tech leads to experiment is so important for growing for leads”

Hasnain says:

This was a really good read on balancing the 'I want this code to be perfect' approach with a mindset around how code evolves over time - when is the right time to work on the best abstraction, versus leaving it open to evolution before we're sure we know the right approach?

"It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code.

The Next Morning
… did not go as expected.

My boss invited me for a one-on-one chat where they politely asked me to revert my change. I was aghast. The old code was a mess, and mine was clean!

I begrudginly complied, but it took me years to see they were right."

Hasnain says:

This is a pretty good read - side stepping the discussion around the async/await hype, this goes into some really fundamental concepts of distributed systems (flow control and back-pressure) and shows how almost everyone gets it wrong.

There are some tradeoffs in making this code easier to write and more accessible - you can set yourself up for a lot of future pain without the natural railings of "hey this is getting tough maybe I should ask for help" to help out.

"The lack of back pressure however is a type of footgun that has the size of a bazooka. If you realize too late that you built a monster it will be almost impossible to fix without major changes to the code base because you might have forgotten to make some functions async that should have been. And a different programming environment does not help here. The same issues people have in all programming environments including the latest additions like go and Rust."

Hasnain says:

This is from a while ago - lessons learnt from porting an embedded graphics library from C++ to Rust, a comparison of the performance you can get, but also a good discussion of developer productivity and cognitive load.

“This is an interesting test case for Rust, because we're very much in C/C++'s home court here: the demo runs on the bare metal, without an operating system, and is very sensitive to both CPU timing and memory usage.

The results so far? The Rust implementation is simpler, shorter (in lines of code), faster, and smaller (in bytes of Flash) than my heavily-optimized C++ version — and because it's almost entirely safe code, several types of bugs that I fought regularly, such as race conditions and dangling pointers, are now caught by the compiler.”

Hasnain says:

This was a really good human interest blog mixed with technical bits. A coming of age story from a college student to a dropout to working various jobs until becoming one of the most famous engineers in the JS community. Worth reading!

“I caught a cold. As the day of our would-be trip got closer, I felt worse, but I was hoping that maybe I’d be okay. When my train from Moscow to St. Petersburg had arrived, I clearly had a temperature. She said to come to her place anyway. She made me some hot tea, gave me warm socks, and we kissed. I moved in.”