Inexperienced Quality
This post was imported from blogger, to see the original, likely better-formatted post see kalebpederson.blogspot.com.
>When I first started programming I concentrated on one thing, making my program work. Not only was that the only thing that I concentrated on, but it was the only thing I was taught. My studies in computer science didn’t prepare me to program, rather, they taught theory with an occasional programming project.
Knowing nothing about proper design or clean code, I slowly added more and more functionality to my program, I’d insert a few lines here and a few lines there until my functions became long and tangled. Classes quickly bloated becoming god classes with an overabundance of dependencies.
Over time, I learned more about design and started striving to always have clean code and follow the single responsibility principle. I eventually had an epiphany — a stronger developer refactors the current design into an architecture that supports the newly required features and improves the design’s quality attributes; the weaker developer stays with the current design no matter how messy the eventual solution might become.
Quality code doesn’t come overnight, grow with a degree, or sprout with certifications, it comes with experience.
Image from: Chris Dalrymple’s Moblog
