> You'll only really know if it's good code (or why) after you start trying to change it. I like this and it is true. In addition, I have found that good code

> You'll only really know if it's good code (or why) after you start trying to change it. I like this and it is true. In addition, I have found that good code also tends to survive refractors despite having the quality of being easy to change. The Ask HN post specifically mentioned good code but what follows are some (of my subjective) thoughts about the benefits of reading bad code. Bad code is haphazard and varied and good code is “samey”. You are a pattern matcher and this is part of your training. Good code will make more of an impact on your understanding if you have read a lot of bad code beforehand. Being able to read and understand bad code is a far more lucrative skill to have in the workplace than being able to quickly understand good code. In a big team you will spend a lot (most if you’re senior) of time reading other people’s code. Best to get good at it. I have yet to be presented with a steaming mess of code to read and explain to an interviewer; yet it is the very first thing most new joiners face at any seniority level.