An apparently underappreciated aspect is naming. I'd like to focus on that now.

It all starts with naming things and how they map to reality in the minds of the people involved. If a name leaves any room for interpretation, expect trouble. I learned that poor natural language skills typically result in poor coding.

Beware of "fixing" names in existing environments though. If a lot of people have learned and adapted to some silly term over time and they all think about the same thing when they hear it, fixing it may cause more trouble than it prevents. If you still want to do it because it is really bad, make sure to fix it everywhere in the domain. This may be impossible though.

Naming components and classes goes a long way. What goes in it? How does it relate to other components and classes? All these decisions will be impacted by the interpretation of names. Settling on names too quickly just to get on with it is never a good thing.

I am extra keen on naming this week because I have been working on an update of a protocol implementation that required me to read a specification document and add new features to existing code. It turned out my predecessor didn't like any of the terms used in the specification document which was a PDF originating from the client. So he had "fixed" that for all the maintainers who had to deal with his code later. As you might expect I had some trouble mapping the specification to the code and getting my head around the logic. His names were way more different than they were better. I had to match everything first and resynchronize the names before I could start to do anything.

In software development there is no such thing as "just a name". If a name is not exactly right it will require knowledge to get the right idea and that is an obstacle.