Monthly Archives: February 2026

How to ask for feedback at work

Here’s how I successfully asked for feedback from a colleague at work recently.

  • I did some personal reflection and wrote a self-evaluation. I reflected on the main areas where I observed problems, friction, or opportunities to improve as a coworker.
  • I emailed my colleague saying: It’s been a while since I asked for feedback from the team, I’m always trying to improve, and would appreciate any thoughts you have in this area for me. I attached my self-evaluation at the bottom. I asked if they would be open to a 25-minute meeting to chat about this. They could either prepare thoughts beforehand, or we could just chat about the self-evaluation and explore in real time.
  • They agreed, and we did the call. I shared my screen with a copy of the self-evaluation, so we had something to look at, and so I could annotate with notes in realtime.

In the past, I sent such an email without the self-evaluation attached, or worse, with a long list of specific feedback questions I wanted answered.

The self-evaluation + call strategy works well because it reduces the amount of creative energy the feedback giver needs to spend.

Rather than reflecting from scratch on your performance (which they may not even have close to mind), they have a set of initial prompts which might spur ideas.

Doing your own self-evaluation also shows that you’re self-aware of your own weaknesses.

Making some “critical” comments about yourself can make it easier for a colleague to give feedback that they might be shy about. They might not want to sound negative, and might be reluctant to bring something up, but if you were able to anticipate it and “pre-critique” yourself, that makes it easier for them to agree and possibly elaborate on the topic.

What to know about GPLv2 vs GPLv3

An important thing to note about the GPLv3 is that it is not just an incremental improvement or modernization of the GPLv2, contrary to its name.

It’s effectively a different license that’s even one level stricter than the GPLv2 in a substantial way.

In addition to the base requirements of the GPLv2 for releasing source code for distributed binaries, it goes one step further and requires that modified binaries can be installed onto the hardware that distributed the original binaries.

Unlike simple release of source code, this has engineering implications for hardware manufacturers. It prevents “locked down” devices and forces devices to be open and reprogrammable. “Tivo-ization” is a term referring to the practice of “locking down” a device, which is often used in discussions around GPLv3.

This is why Linus Torvalds refused to adopt GPLv3 for Linux, because in his view, this was going too far.

So if you’re in the market for a copyleft OSS license, keep in mind that GPLv3 is not automatically the best fit, and should not necessarily be automatically used over GPLv2 just because it’s the newest version in the “GPL series”.

It represents an additional step of strictness on the restrictiveness scale. If you’d like distributors to release source code, but don’t necessarily need them to make their devices openly programmable, GPLv2 is still the license to use.

Resources: