Last year, we had to do a big university project in randomly selected groups (5-6 students in every group).Three of the five guys were completely useless, I mean, both the other competent guy and me wrote around 20,000 lines of code each, the other ones wrote around 500 lines of code (combined).
After our first few meetings we quickly knew that we have to give them a small task which was so trivial that not even they can fuck it up. But we were wrong. Oh boy, so wrong.
They simply had to code the excel export of the data, which means they had to use two functions from a library and pass the correct data. But their solution was so bad, I lost faith in humanity and was fascinated by it at the same time.
For example, there was this simple class "Room", which had a few properties like size or number of seats and a few getter/setter etc. That was a core class and written by the other qualified guy. So how did the others fuck up the excel export? They somehow rewrote that class in German (although the other code was completely in English), implemented a function for each property that would write its value to a hardcoded cell in a hardcoded excel file.
And this was just the tip of the iceberg. Needlessly to say that I had to rewrite the whole export in the night before we had to present the project.

"He types too fast, he must be a hacker"

I hate it when colleagues name their commits with a non descriptive name like "minor changes", "minor fixes", "small changes" and so on. I know that good naming is a difficult task in software development, but do I expect to much when I want them to explain shortly what exactly they changed since the last commit?
Good commit messages are always helpful if you want to do good PR reviews and furthermore if you want to go back to an older commit because someone fucked something up.
Don't get me wrong, my colleagues are great people and great developers, but some of them ignore the fact that good commit messages might be useful in the future for others and themselves

Paper and pencil. It's always helpful to draw little sketches and write short notes that help you to understand a problem you are trying to solve. I think mostly because you stop staring at your code and you start thinking about the problem in a different way.