Good post ... although I must say that the first paragraph has no learning value, but it does establish your 'geek credentials' 😉

One informal analogy I use when thinking about 2NF is 'being on subject', or 'topicality':

Tables store data about things, and that thing, or 'topic' or 'subject', should be as narrowly defined as possible. Ideally, the table name should tersely convey this topic.

You can then ask the question 'is this field topical to the table?' or 'is it on subject?'. In your example, when viewing 'Current_Assignment' as a topic name, it becomes clear that fields 'PayGrade' and 'YearsInGrade' aren't topical: they belong to the employee, and don't add anything to the subject of 'projects employees are assigned to'.

A candidate key then becomes a minimal set of facts required to say something truly unique about the topic. If your candidate key is 'Employee and Project', then again it becomes clear that saying something about just the employee adds nothing new to the topic of project assignments.