After six years in the field, Chris has shared his strong opinions on software development practices, languages, and methodologies. I like his attitude. Willingness to continuously put one’s personal views under scrutiny, eventually adapting or even changing them as needed, is not a common trait. Not in our field. While I generally agree with most of his opinions, I feel the urge to comment on a few of them.
Typed languages are better when you’re working on a team of people with various experience levels
Typed languages are better, period.
Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
Perfect. I am stealing this line.
Clever code isn’t usually good code. Clarity trumps all other concerns.
Good and clever code is very possible, though. Agree on the second part.
Bad code can be written in any paradigm
Ça va sans dire
So called “best practices” are contextual and not broadly applicable. Blindly following them makes you an idiot
Not following them also makes you an idiot.
Designing scalable systems when you don’t need to makes you a bad engineer.
But how do I know in advance whether I need to be scalable or not? Not always an easy call. Also, scalability doesn’t necessarily imply complexity.
In general, RDBMS > NoSql
In general, use the right tool for the right job.
Functional programming is another tool, not a panacea.
The jury is out on this one. In my admittedly limited experience, functional programming tends to win over OOP. It’s not a coincidence that most OOP languages keep adding functional features (looking at you, C#.).
Pencil and paper are the best programming tools and vastly under used
Old fart me concurs.
Trading purity in exchange for practicality is usually a good call
Don’t get carried away with that.
Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy
The word “scalable” has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word
I plea guilty on this one.
Despite being called “engineers,” most decision are pure cargo-cult with no backing analysis, data, or numbers
I am a software craftsman.
People who stress over code style, linting rules, or other minutia are insane weirdos
I am an insane weirdo.
Code coverage has absolutely nothing to do with code quality
It also has nothing to do with tests quality.
Monoliths are pretty good in most circumstances
TDD purists are just the worst. Their frail little minds can’t process the existence of different workflows.
Ouch. This hurts.
I am not sure I would have had so many well-formed opinions only six years in. Read them all on Chris’ website.