My FeedDiscussionsHashnode Enterprise
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
Todd

5 likes

·

150 reads

3 comments

Gaponenko Andrei
Gaponenko Andrei
Dec 23, 2019

Very true. Reminded me of Parkinson's law of triviality, which is

an observation about the human tendency to devote a great deal of time to unimportant details while crucial matters go unattended.

I have experience working with highly opinionated people, was one of those myself actually. Almost every code review was a passionate discussion, mostly about trivial things, not always though.

Then I also have recent experience working with people who don't care at all about how X should be done as long as it's working and doesn't look like complete piece of crap. Actually scratch that, most of the project was written like there is no tomorrow.

Nowadays it's somewhere in the middle, which I think is actually a great place to be. Trying to make a uniform code style for a team is a good effort, nothing wrong with that. Giving suggestions about why X should be done as Y (e.g. it's easier to read or less error prone) is fine.

But I think one should always remember that the code we write as stable and long lasting as a fictional sitcom family. Or enriched uranium. Being too opinionated, to the point where only your opinion is the answer, is very stressful for everyone involved, even the person himself.

3
·
·1 reply
Francisco Quintero
Francisco Quintero
Jun 12, 2020

Parkinson's law reminds me of Bikeshedding. Arguing unimportant stuff because it's easier.

·
Francisco Quintero
Francisco Quintero
Jun 12, 2020

Very interesting read here, Todd.

I recall when I was studying the teacher who taught me algorithms said that there are multiple ways to solve a problem. That's a programming truth. In the end, we just choose a style we feel comfortable with or that help us deliver.

As Gaponenko Andrei said in his comment, it's ok to have standards agreed upon, giving suggestions to improve but never getting married with an idea of how something should be done. It won't be helpful in the long term.

There's no point in chasing perfect code when the project might just be an MVP lasting 3 months 😆

·