Stop pretending that you like everything about feedback. A gift is something that is meant to be liked. Feedback is not.

Photo by Mark König

I once gave feedback in a direct message (always default to 1–1 DMs when giving constructive criticism) to a leader at a company whom I thought was acting in a way that had negative consequences. Let’s just say I was at an elevated state of emotion when I wrote that message, although the message that I eventually sent was scrubbed of superlatives and expletives.

As with most feedback, I write some things to help the feedback land gracefully, like, “I want to explicitly say that I’m only sharing this with you because I care about building good company culture, which begins with our leaders, and I care about presenting you information that I believe you’d benefit from, despite having to stick my neck out to say it.” Importantly, I wrote this at the end of my message, not at the start. The start was direct and firm.

Can you guess his first response?

“Thanks, Nick! I love feedback. Feedback is a gift!”

Sitting in my sweatpants at home, reading that reply, I rolled my eyes.

That was my reflex. The reason I rolled my eyes, as I reflected later, is this: if he had indeed thoroughly read my constructive criticism, it seems unlikely that he would be feeling good about himself; good enough to tell me that what I just told him was a gift. I did, after all, call him out directly on his bad behaviour. Nobody sane likes that on the spot. After a few days of introspection, maybe. But not on the spot.

Saying that feedback is a gift is like saying that shit is gold. Not shrivelled up shit that has all its stink dissipated and can be put in a cabinet. No. Wet shit. Wet shit is not gold, especially if it lands in your direct messages, which is the digital equivalent of your hands.

Show it, don’t say it

I think a much more reasonable thing to say is, “Thank you,” followed by an actual response to the feedback.

The “thank you” serves as a way to genuinely tell the person who stuck his neck out to give you feedback that you appreciate being given feedback. And an actual response, which likely includes some paraphrasing, helps the feedback-giver to ascertain that you interpreted his feedback as intended, and that the intended thought entered your mind.

To me, as a regular feedback-giver, that would be enough for me to know that you are someone who genuinely sees feedback as a gift, and in that way, you’ve succeeded in signalling to me to continue giving feedback to you in the future. I imagine that’s what you wanted to achieve by saying that “feedback is a gift” in the first place.

At the time of writing, I’m running this blog on Gatsby.js. It’s open sourced and you can view the code on GitHub

Running the blog on Gatsby means I have free reign on how I want the site to work. Everything can be tweaked if you decide to invest time to read the documentation and apply your React/GraphQL knowledge, which is nice.

One of the things I decided early on when I first moved to Gatsby from WordPress was to prepend the date of the post’s publication to the URL:

https://www.nickang.com/2022-01-02-my-2021-annual-review/

It’s nice because it’s date-stamped, but it’s kind of long, isn’t it?

Original intent

I originally thought that I would value being able to see my content/blog/ directory automatically sorted in chronological order (given that VS Code and most code editors in which I write for this blog sort alphanumerically). I thought this would be an easy way to look back on how my thinking has evolved over time.

But shortly after this decision I realised that the presentational layer (i.e. the blog as viewed on a browser) already shows the posts in chronological order like most blogs do. (I could change that too - free reign, remember? - but I won’t for now or the foreseeable future). In other words, I already have that feature, which, by the way, is enabled by the YAML metadata in each index.md file that corresponds to a blog post. The YAML for this particular post looks like this:

---
title: "Why I removed dates from my blog post URLs"
date_published: "2022-03-31"
date_updated: "2022-03-31"
excerpt: "I no longer see my blog posts as static after publication. They're"
tags: ["Creativity"]
fav: false
---

So I’m covered if I ever want to look back on my intellectual evolution.

In the safety of that knowledge, I’ve decided to stop prepending the date in the URL for posts going forward. To continue to make it easy for my existing posts to be searched via Google without having to setup 400+ redirects, I decided to keep their current date-stamped URLs.

Why I’ve removed them going forward

I have two reasons:

1. Shorter URLs look neater
2. I’ve changed my view on what a blog post should be

The first one probably needs no explanation. The second one needs some.

Here’s how I thought about my blog posts in the past:

• Static: once published, hardly ever updated (only for typos or important corrections)
• New or updated thinking are written in a new post
• Like a newspaper article

And here’s how I think about my blog posts now:

• Evergreen: existing posts get regularly updated when new info or new thinking emerges
• Sometimes okay to publish before they’re ready, knowing I can refine them with time
• Like a piece of online documentation

In the new mental model, the date of publication is just one of two dates that are relevant. The published date and the updated date are both important to signal to the reader about that my thoughts on something is not final (are any thoughts final?). I’ve updated each blog post to display both dates if they’re different.

What’s nice about open-sourcing my blog on GitHub is that every edit leaves a trace, so if anyone ever wanted to, they could see how my views on a topic changed and call me out. I appreciate that kind of accountability on what I post publicly because I think it makes me a better thinker.

There’s a party question that some people ask, which goes, “If you could have a superpower, what would you like it to be?” In the last few years I’ve refined my answer as this: “I would like to be able to slip out of any social situation without repercussions.” Ha ha. It usually gets a few knowing nods, especially from other introverts.

But here’s the thing I realised recently: I kind of have this superpower now that I work remotely (or, as Shopify calls it, Digital By Design).

I’d be stupid to overlook or intentionally not use this superpower.

Missing meeting agendas and other problems

The main reason I find myself needing to get out of a social situation — which is probably more accurately described as “group social situation” that I define as a group of more than four people — is that the congregation is not that interesting or valuable to me. Either that or I just find myself unable to add value to the conversation.

One reason we find ourselves in such quagmires is because social situations evolve rapidly and fluidly. There’s just no way you could have anticipated that Bob would ask 10 rudimentary questions during Q&A that could have been googled in a few seconds.

Then there’s the fact that communication is lossy, like a game of Telephone would illustrate. Two people can talk about the same thing in very different ways and therefore communicate those things in different ways. And two people hearing the same thing can also interpret it differently. Somtimes a “Payment processing workshop” is about validating payment gateways for use and not, as you thought, about how to setup your development environment to process test payments. This is especially true if the event organiser was lazy with the event description.

Right, back to the topic. The superpower.

Drop off the call if you need to, damn it

I think it is sillier to stay on a video call where you are not getting or contributing much value than to just hit the red hang-up button and drop off the call.

Why? Because honestly, it wouldn’t make a real difference to the people on the call. You would appear as a small five-second notification on the screen, “X has left the meeting.” So what? Think about how much more courage you would need to do the same thing if you were in the same physical room with the group.

The friction of leaving a group meeting has gone from very high to almost negligible because of remote work.

Another reason to leave is that you’d get your time back, which you can then use to do something else. That something else is very, very likely to be more valuable than staying in the meeting (unless you decided to join another pointless meeting, I guess; in which case, you know what to do).

Caveats

Here are the things that I consider carefully before I leave a remote group meeting:

• it must be a large-enough group meeting; if there are only three people and you leave, that’s unfortunately still going to be rude (everyone’s minimuim threshold for what constitutes a large-enough group is likely different - mine is around 5 (inclusive of me))
• is it clear that I can’t contribute here or is it more that I’m being lazy to think ways to contribute? -> if latter, stay and try to contribute
• did I organise this meeting? If so, I may have an obligation to stay and monitor progress and listen to feedback

That’s it, actually.

Go use your superpower, you lucky remote worker you.

I just watched the documentary DOWNFALL: The Case Against Boeing and have feelings stirring inside me that I want to get down in writing.

source: Netflix

The documentary takes us through the timeline of the corruption of Boeing’s previously pristine and highly functional culture of engineering (and safety) excellence until the tragic loss of 189 lives on Lion Air flight 610 and 157 lives on Ethiopian Airlines flight 302, crashes that happened within months of each other.

When lives are lost, everyone pays attention. And of course we should — this short life is all we have!

This is the lesson I learned that the documentary revealed to me: profit-above-all corporate culture is incompatible with a culture of engineering excellence and can lead to catastrophes.

why I care about this

As I heard the narrators explain the technical fault — that the “MCAS system” took over based on faulty input (because the system had a single point of failure, relying on just one point of attack sensor that could be misled by something as simple as a “happy birthday mylar balloon” knocking onto it mid-flight) — I frowned hard.

I’m a software engineer. I could have been the one who wrote the software that processed the input from the point of attack sensor and did something with it. I wasn’t, but I could have.

I encourage you to watch the documentary to understand the other forces at play (greed, mainly) that caused the crashes. I want to focus on the software piece of this story.

The problem wasn’t that the software was faulty—but it does sound to me like the software engineers wrote software that expected valid inputs.

So the cascade of information in the MCAS system purportedly goes like this:

1. point of attack sensor continually sends nose angle data into the system software
2. software processes data and if the nose angle is deemed too high, it sends a message to move the jackscrew motor at the tail of the airplane so that the horizontal stabilisers moves up (I think it’s up) and forces the plane to take a nose dive to correct for the high nose angle
3. after 10 seconds, software enforces a cool-off for 5 seconds before restarting the process if the nose angle is still deemed to be too low

What could go wrong? I mean, really, if I sat down as a non-aviation software engineer and asked myself this question, what would I list down? This is what I can come up with:

• runaway software: if the input is corrupt (e.g. based on a the malfunction of a single point of failure like the single point of attack sensor), the code could be incorrectly causing the nose angle to dip, and potentially causing a full-on nose dive. Or, as they say: garbage in, garbage out
• bug in the code: if there was an edge case in the code that had not been tested for, since it had control of the horizontal stabilisers, the code could cause catastrophic adjustments

The list isn’t long, probably because I’m still racking up my years of experience as a software engineer, but even I would think about the potential problem of corrupt inputs. And I would have certainly raised this as a problem. (The documentary reveals that engineers at Boeing who raised safety concerns were fired or had their salary cut. What the f**k!)

engineer, not developer

I currently work at Shopify as a software engineer and this documentary makes me take my work more seriously. A life may not be on the line, but several thousands of livelihoods might if I fail to develop and test the code that I write before pushing it to production. That is still a huge responsibility.

I’m not sure how easy it would be for me (or other software engineers) to make a catastrophic mistake at work as I punch the keyboard in my home office and push my code to production, although it does feel like it could happen rather easily if I let my guard down and not strive for engineering excellence.

To end this off, I want to say this: I think there’s good that comes from calling ourselves software engineers and not software developers.

I, at least, feel like I hold myself to a higher standard when I liken my work to that of mechanical, civil, and aircraft engineers, to name a few. Lives are at stake!

An Annual Review is a personal note that is designed to spark self-reflection about the year that just went by. The goal is to take stock of the year, appreciate the little things, digest the learnings, and apply them in the years to come.

This is my second year writing an Annual Review in this format. You can find my reviews from yesteryears here: 2017, 2018, 2019, 2020.

In the review, I ask myself three questions:

1. What went well this year?
2. What did not go so well this year?
3. What did I learn this year?

I go into each of these in the sections below. Let’s go!

1. What went well this year?

New life. We successfully grew a baby in Charlane’s womb and then raised her through her first three months of human existence. Her safe delivery was easily one of our biggest achievements this year. Her presence makes me smile, a lot.

Independence abroad. By handling the delivery and post-partum confinement on our own, we proved to ourselves that we can independently take care of ourselves and live happily abroad on our own away from the comforts of family and familiarity.

Clarity of home. We travelled back to Singapore for a visit despite covid restrictions and spent three weeks in quarantine and three weeks out roaming the city we grew up in. This trip helped me realise that I’m much happier now living in Germany than in Singapore. (This is true at least for now.)

Personal Knowledge Management. I used Obsidian almost every single day and have gradually built up confidence in using the software and my processes with it (they’re described in two posts 1 and 2). This has helped me become more focused and productive.

Growing as a leader. I was presented the opportunity to become a Team Lead at Smartly.io from the start of the year and I took it. In a few months, I had seven direct reports, which still sounds crazy. I’ve learned many things about leading people and managing a team’s output. I’ve grown as a leader and mentor this year.

Consistency. I continued to discover who I am as I published a blog post every single week this year. This habit has helped me reflect on my life at least once every week, which has given me clarity throughout the year about where I am at and where I am headed. I’m also more confident now in executing projects that call for a consistent schedule. I can confidently say that I’m a consistent guy.

Found a sustainable solution to re-live memories. In October, after Charlotte turned a month old, I started to publish one Instagram post every single day (@nickangtc) to encapsulate our experiences each day into a daily log. I’ve done it for close to three months now and have found a way to do it in less than 30 minutes each day and I intend to keep doing it throughout 2022. This matters to me because I have a bad memory, among other things.

A rekindled passion in software development. I worked hard and found a new job, which I’ll be starting in February 2022! I will be building software every day again and this time I feel a strong motivation to approach software development as a craft to master. A nice bonus is that as a developer I’m going to be paid more. I also enjoyed studying software system design & architecture and practising implementing algorithms and data structures when I was preparing for interviews. I love knowing that I enjoy studying something.

Climbing again. I have restarted my once-a-week climbing routine. I love climbing and this is a nicely paced break introducing exercise back into my life. I’m already in better shape after three sessions. I also enjoy the company of climbers, which is a nice bonus.

2. What did not go so well this year?

Not reading books. I didn’t read as many books as I’d hoped. The quantity wouldn’t bother me much if I had consciously picked only a handful of books to read throughout the year, but I didn’t. I took a much more sporadic approach to what I read this year, which seems like poor design.

Finding and sustainably engaging my community. I still don’t understand how online communities function despite having spent a lot of time on Twitter, Instagram, Discord, and Slack with people. I’m not sure if it’s the case that I don’t understand how communities function or that I just haven’t found my people yet. It’s frustrating because I know there are many interesting people in this world with whom I share interests but will probably never accidentally encounter in real life. I’ll have to continue to learn where to find my people and sustain a largely online relationship with them.

3. What did I learn this year?

I love being a dad. I mean I love everything that comes with it! The responsibility and the corresponding satisfaction, the bigger heart, the meaningful suffering. I also learned that I’ve changed since I became a dad. I now want to spend all the time afforded to me outside of work to be with Charlotte and watch her grow alongside my partner-in-life Charlane, trying foods, visiting places, dreaming and executing side projects, and so on. As far as the new me is concerned, this is a perfect life.

Away. I learned that I want to stay abroad for at least a few more years.

Leadership. I learned through action and feedback that I’m a decent leader of people.

Things will expand and contract again and again. I learned that almost everything in life works in a contract-expand cycle. This is a useful way to see the world because it puts chaos into perspective and makes it bearable, even understandable.

For example, I used Obsidian for note-taking and wrote a lot of notes for a while (expand), and at some point, I went back to delete and merge notes (contract). Or, take the example of moving apartments. I’d construct boxes and throw stuff all around the house (expand) before being able to pack them neatly into boxes (contract) and before finally taking things out of the boxes to put around the new apartment again (expand).

I enjoy working remotely. I learned that remote work is a model that works very well for me. I like spontaneous interactions with people but what I like even more is not being interrupted when I’m working. Not being interrupted means I can do more with less time, giving myself time back to spend with my family, reading, writing, or doing side projects. Remote work with a sprinkling of once or twice yearly in-person meetups with the team sounds like the perfect model of the future of work to me!

I’m decent at programming. I learned that I’m not bad at building software and that because of that I like building software. One more data point to the hypothesis that we tend to like what we are good at.

Regularity and consistency beat a pursuit of quality any day. The sun goes up, the sun goes down. I can also get my head around that. I learned to enjoy prioritising regularity over quality. Shawn Wang echoes a similar thought.