Tag: work

“I don’t need to comment this, I’ll know what’s going on. I wrote it for god’s sake.”

“No one could possibly fail to understand my simple user interface”

“I’ll remember what I did here without adding a comment to explain it.”

“Code is self documenting.”

“This bug won’t take too long to fix”

“I can do this easy. It should take like what? 2 hours max?”

“There is just one more bug, then it wil be fixed.”

“5 more minutes and I can go home.”

“My homebrew framework will be nimble, lightweight, debugged, and easy to use.”

“My own parser will do fine.”

“I know this is dirty code, I will rewrite it later.”

“We’ll fix this in a later release.”

“I’ll come back and comment this later”

“This bug can be ignored for now”

“I’ll refactor this before I release it.”

“That is going to be a simple minor change..”

“It’s just one line… it won’t break anything”

“This should never happen”

“This minor unrelated change in the code could not possibly be the cause for the unit tests failing.”

“It works on my machine”

“It’s not a bug, it’s a feature!”

“if it compiles, it must be correct!”

“If it passes tests, it must be correct.”

“It works”

“I can skip design and architecture and leap right into coding.”

“I totally understand that legacy code!”

“I know what the client wants.”

“I don’t need version control.”

“I know what I’m doing.”

“It’s a simple one-line change, we don’t need to test it.”

“If it’s written in C, it will be fast.”

“It’s written in Python, so it’s easy to extend.”

“Java runs everywhere.”